How on-demand Android environments lay the foundation for Android engineeringSoftware engineering has evolved dramatically over the last decade. Development environments that once depended on dedicated hardware have become resources that can be provisioned, configured, and removed on demand.Infrastructure is now expected to be reproducible, automated, and integrated into continuous development workflows. However, Android has largely remained an exception.Many Android workflows still rely on physical devices or locally managed emulators. Here’s the typical flow: A developer connects a phone to reproduce an issue. A QA engineer then reserves a device from a shared lab. A platform team maintains development boards to validate new Android builds.These approaches are familiar, and they can work well for small teams. However, as projects grow, hardware must be managed and shared. Environments gradually diverge, and reproducing an issue can depend as much on finding the right device as on finding the bug itself. Before proceeding, a quick note on terminology. In this blog, a “physical device” means a phone, development board, automotive bench, or any other dedicated Android target. “Target hardware” refers to the real components themselves, such as sensors, peripherals, radios, GPUs, or vehicle interfaces whose specific behaviors must eventually be validated on the final product. Both are specific forms of physical hardware. Physical hardware will always have an important role in Android development. But it should not be the starting point for every test, investigation, or validation workflow.The challenge is not Android itself. It is that Android is still often treated as a dedicated physical asset rather than as a programmable part of the wider engineering infrastructure. This is beginning to change.From devices to environmentsModern infrastructure platforms are built around a simple principle: resources should be requested by workflows rather than handled manually. Their value comes from being provisioned automatically, configured consistently, and removed when they are no longer required. Android should follow the same model.Instead of asking someone to prepare a phone or start an emulator, a workflow should be able to request an Android environment with a known configuration, use it to perform a task, collect the results, and release it when the work is complete.This is the approach we have taken with Anbox Cloud.Anbox Cloud runs complete Android systems as managed containers or virtual machines on supported cloud, edge, or bare-metal infrastructure. This moves routine Android execution away from dedicated physical devices, while retaining real target hardware for the validation that genuinely depends on it.The purpose of Anbox Cloud is not to reproduce every physical characteristic of the final product. It is to containerize or virtualize the Android execution environment so that development, testing, debugging, and streaming workflows do not each require their own dedicated device.With Anbox Cloud, teams can create, configure, access, stream, copy, and remove Android instances programmatically. Containerized instances support application-oriented workloads where density and efficiency matter, while virtualized instances support workloads that require a complete Android system inside a virtual machine.Whether the environment is used for application testing, streaming, platform validation, or Android Automotive development, the same consistent lifecycle applies: request, configure, use, collect, and release. Android capacity is provided exactly when the workflow needs it rather than reserved manually in advance.A repeatable Android lifecycleAndroid projects vary considerably, but their workflows often follow the same sequence.With Anbox Cloud, a workflow can:Request an Android instance from a known image.Configure it with the required application, resources, settings, user data, or test parameters.Use it through ADB, shell access, browser-based streaming, or an automated test runner.Collect logs, screenshots, test reports, recordings, or other outputs.Release the instance or preserve it intentionally for further investigation.Treating this lifecycle as code rather than as a manual procedure is what makes the Android environment programmable.A more efficient, timely way to buildTeams can manage the Android lifecycle with Anbox Cloud using the Anbox Management Client, the AMS HTTP API, or SDKs. This allows Android environment management to be integrated into existing development tools, automation platforms, and CI systems instead of being designed around manually prepared devices or local emulators.Making the lifecycle programmable also makes its configuration explicit. The Android image, application version, display settings, resource allocation, input data, expected outputs, and cleanup behavior can all become part of the workflow. Every execution begins from a defined configuration rather than undocumented setup, steps, or settings that exist only in someone’s local environment.This makes the lifecycle a lot smoother: A CI job can launch an environment, execute a test suite, collect the results, and remove the instance automatically. A QA engineer can recreate the same environment to investigate a failure. A support engineer can launch a temporary interactive session to reproduce a customer issue. The value is not simply that an API can start Android. It is that developers, QA engineers, CI systems, and support teams can repeatedly create the same environment from the same definition. When a problem occurs, teams can identify the configuration that produced it, rather than trying to determine which manually prepared device was used.This same operating model also supports interactive work. An environment can be created automatically and still be accessed through ADB, shell, or browser-based streaming when human investigation is required. Automation and interactive access are not separate approaches. They are different ways of working with the same environment.Persistence also becomes an explicit workflow decision. Instead of allowing long-lived devices to accumulate installed applications, cached data, logged-in accounts, and undocumented changes, each execution can begin from a clean environment. When persistence is required, teams can copy an instance, preserve its data, or publish a configured environment for reuse.This makes Android environments easier to understand, reproduce, and trust.Removing hardware from the critical pathBy moving routine Android execution to managed containers and virtual machines, Anbox Cloud turns Android from a scarce physical asset into programmable engineering infrastructure. This enables repeatable CI, QA, and support workflows while reserving target hardware for validation that genuinely depends on it.Automation is the first step. However, once teams can launch one Android environment reliably, the next challenge is no longer how to prepare an environment. It is how to make hundreds or thousands of environments available efficiently without simply building a larger device lab.That is where scaling becomes the next logical step.In our next article, we will look at how Android teams can scale development without scaling hardware.Learn more about Anbox Cloud or contact our team: https://canonical.com/anbox-cloud