AndroidEnv: a reinforcement learning environment that drives a simulated Android device

One action interface, an unlimited number of tasks

AndroidEnv is a Python library that exposes an Android device as a reinforcement learning environment. The description is short: reinforcement learning research on Android devices.

The architecture is two separated halves. A simulated Android device runs independently from the environment, completely unaltered, working in exactly the same way as the devices humans use and exposing the same features and services. The environment process talks to it. An agent sends touch and lift events, and the environment returns pixel observations and rewards.

What makes it a platform rather than a benchmark is that the action interface does not change between tasks. Any existing Android application, or any custom one you build, can be the subject. The documentation points at Android games as an example, from card games to puzzle games to time reactive games, since those demand varied action combinations and interaction types.

The rewards come from task definitions rather than from the library. The documentation says rewards might be given for events such as successfully scrolling down a page, sending an email, or achieving some score in a game, depending on the research purpose and how the user configures the task. So the library supplies the interaction mechanism and the observation pipeline, and the objective is something you define.

The documentation is organised into five pages, linked from the README: environment details, running AndroidEnv, setting up a virtual Android device, defining a task, and a page of example tasks available for download.

The action space is a continuous point and a discrete touch or lift

The action interface is the part of the design that most affects what an agent has to learn, and the documentation is unusually explicit about its difficulty.

The raw action is a hybrid: a continuous tuple giving the action location, and a discrete signal deciding whether the agent wants to touch the screen or lift its virtual finger. That is the entire vocabulary. There is no text entry, no accessibility-node action, no intent broadcast.

The reason this matters is composability. Android's own UI was designed for common touchscreen gestures, tapping, scrolling, swiping, pinching, drag and drop, and AndroidEnv inherits that. The documentation's own example makes the point: to reach the next image in a photo gallery, the agent has to perform a swipe, touching the screen multiple times and gradually shifting the action positions to the right. Raw actions do not trigger state changes unless they are correctly chained together into a human gesture.

That is the central difficulty for a learning agent. A single action rarely changes anything, and the reward for a task may only arrive after a long, precisely timed chain of them.

Two properties follow from the design and are worth stating separately. The action interface is closely related to the observation space, because meaningful touch and lift events are often co-located with or strongly correlated to the location of salient objects in the observation, for instance the position of a button aligning with the actions that press it. That correlation helps learning rather than hurting it.

The library also provides tools to alter the action interface when a study needs it, such as discretization or hard-coding gesture skills. The documentation is clear that this does not remove the underlying problem, stating that the real challenge remains in devising agents capable of dealing with a large suite of diverse tasks through this complex unifying action interface.

Real-time dynamics you cannot speed up

The environment runs on top of a real-time simulation of an Android device. The documentation states this plainly and draws the conclusion: the environment dynamics do not wait for the agent to deliberate, and the speed of the simulation cannot be increased.

That single constraint shapes the whole cost model of a project using it. A training run that would take minutes in a vectorised simulation takes hours here, because the phone is running in wall-clock time whether or not the agent is thinking. For a research group with a compute cluster and a wall-clock budget, that is a real budget line.

The observation is a collection of RGB values corresponding to the displayed pixels on the screen. The documentation notes that the exact screen resolution depends on the simulated device and that in general it will be considered relatively large in an RL context, and that users have the option of downsampling each observation. Downsampling is therefore not a minor optimisation, it is the main lever on the observation size, and it is the one the documentation points at explicitly.

The reward signal arrives through the same channel as the task definition, which means the environment is a communication substrate rather than a problem. If you want an agent that scores points in a game, the task definition has to detect that condition from the device state and emit the reward. The library does not offer a catalogue of built-in objectives beyond the example tasks that are available for download, and the documentation is organised so that defining a task is a first-class activity with its own guide.

Installing it, and the Bazel path for working on it

The pip route is the easy one, and it comes with a caveat about what you get.

$ python3 -m pip install android-env

The documentation notes that `/examples` are not included in this package, so an installation from PyPI gives you the library and not the sample agent scripts.

For working on the library itself, or for testing, the route is a git clone of the `main` branch with Bazel:

$ git clone https://github.com/google-deepmind/android_env/
$ cd android_env
$ bazel test //...

And the PyPI wheel can be built locally with Bazel too:

$ bazel build //:android_env_wheel

The repository layout matches that workflow. There is a `BUILD.bazel` at the root, a `MODULE.bazel` for the Bazel module system, a `.bazelversion` file, a `.bazelrc` and a `.bazelignore`, plus `py_grpc_library.bzl` and `protoc_runner.py` for the protocol buffer and gRPC plumbing that the client needs. The `android_env/` directory is the library itself and `examples/` holds the sample agents, of which three are listed: `run_acme_agent.py`, `run_human_agent.py` and `run_random_agent.py`.

The presence of a human agent example is worth noting. It means a person can drive the same interface the agent drives, which is the standard way to collect demonstrations for imitation learning, and the presence of a random agent gives you a baseline that needs no learning at all.

There is one platform caveat that is stated in the installation section rather than buried. The environment now runs on Windows, but the documentation says to keep in mind that this option is not well maintained or widely supported, as Unix-based systems are the primary target platforms of the project.

Dependencies and the extras that pull in agent frameworks

The package metadata is a useful map of what the environment expects underneath.

Python 3.10 or newer is required. The runtime dependencies are `absl-py>=2.1.0`, `dm-env>=1.6`, `grpcio>=1.70.0`, `numpy>=2.1.0`, `portpicker>=1.6.0`, `protobuf>=6,<8`, `pygame>=2.6.0` and `pillow>=10.4.0`.

Two of these explain the design. `dm-env` is DeepMind's own environment interface, so AndroidEnv plugs into the same API shape as the rest of DeepMind's RL stack rather than inventing a Gym-style one. `portpicker` is there because the environment and the device communicate over the network and need a free port. `grpcio` and `protobuf` carry that traffic, which is why the repository has `protoc_runner.py` and a gRPC build rule. `pygame` is the rendering surface for the human agent view. `numpy` and `pillow` handle the pixel data and the downsampling.

The optional dependency groups are where the agent frameworks appear. `testing` pulls in `gymnasium` and `pytype`. `acme` pulls in `dm-acme`, DeepMind's own agent library. And `gym` also pulls in `gymnasium`.

That last one is the practical detail. Installing the `gym` or `testing` extra gives you a Gymnasium-compatible surface, which is how you would connect AndroidEnv to the wide ecosystem of existing RL tooling. The `acme` extra is the path if you intend to use DeepMind's own agents, and the `run_acme_agent.py` example in the repository is presumably written against it.

The `requirements.txt` file at the root lists a slightly wider set than the packaged dependencies, including `gymnasium>=0.29.1`, `grpcio-tools>=1.70.0`, `farama-notifications`, `typing-extensions>=4.11.0`, `psutil>=5.9.8`, `dm-tree` and `attrs>=18.2.0`, which is what you would install for development rather than for use.

Apache-2.0, an arXiv paper, and a version cadence you can plan around

The licence is Apache-2.0, recorded in the package metadata as `license = {file = "LICENSE"}` with a `LICENSE` file in the repository root. That is a permissive grant with an explicit patent clause, so a company can build a product on top of the environment without an obligation to publish its own source. This is a licensing observation rather than legal advice, and the `LICENSE` file governs.

The project links its paper, arXiv 2105.13231, and a DeepMind publications page, which is a good sign for a research tool because the environment specification and the published protocol are the same artefact.

The release history is short and recent enough to be a sign of ongoing work. v1.2.2 was published on 2023-04-27, v1.2.3 on 2025-04-23, and v1.3.0 on 2026-06-30. The package manifest in the repository declares version `1.3.0`, matching the newest tag, and the last push was on 2026-10-18, so the tree is ahead of the last release.

The version numbers also tell you about API stability. A 1.x version in Python packaging convention signals a stable public API, and the long gap between 1.2.2 in April 2023 and 1.2.3 in April 2025 suggests a slow, conservative release cadence. The upstream paper and the environment guide are likely to be more reliable for a research reproducer than the current source tree.

The repository also carries a `CONTRIBUTING.md`, a `.github/` directory with a `tests.yml` workflow, and a `.bazelignore`.

The honest assessment of where this project sits: it is a research instrument with a permissive licence, a published specification, and a real-time dynamics constraint that dominates the practical cost of any experiment built on it.

Editorial conclusion

AndroidEnv fits a reinforcement learning researcher who needs agents to act on a full, unmodified Android operating system rather than a toy environment, and who is prepared to accept real-time simulation speed and a hard action space in exchange for that realism. It does not fit someone who needs fast iteration, since the simulation runs at real time and cannot be sped up, and it does not fit a Windows-first team, since the project states that Windows support is not well maintained while Unix-based systems are the primary target. Verify first that the task you need can be expressed through the touchscreen action interface rather than through an app-specific API, that your emulator setup matches the device the environment expects, and that the reward signal you need is available from the task definitions, because the library provides the interaction and the observation but the objective comes from the task configuration.

Frequently asked questions

Official sources

1. google-deepmind/android_env on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases