How on-demand Android environments turn validation into a repeatable pipeline stage

In the first article, we looked at automation: how Android environments can be created and managed programmatically. In the second, we looked at scaling: how shared infrastructure can make those environments available to more developers, tests, and workloads.

This third article looks at the next step: integrating those environments directly into CI/CD.

A CI/CD system may already automate much of the software delivery process, from producing an application or Android image to triggering tests and reporting results. The Android execution environment, however, can still sit outside that workflow. Consider the following disconnects:

• An application may be built automatically, but someone must connect a device before validation can begin.
• A pull request reaches a manual stage because the required Android environment is not available to the pipeline.
• A test passes on one workstation and fails on another because the underlying environment has changed.

This is the gap CI/CD integration closes. With Anbox Cloud, the Android execution environment becomes another resource the pipeline can request when needed. The workflow can request the necessary environment, deploy the artifact, initiate validation, collect results, and release resources once the task is completed.

Instead of treating Android as a separate component of the pipeline, the environment is integrated into the automated software delivery process.

In this article, “Android execution environment” refers to the Android instance in which the application or system is run and validated, including the Android image, configuration, allocated resources, and test setup.

Make Android part of the workflow

CI/CD pipelines are built around repeatability. A change produces an artifact, tests run against defined inputs, and the pipeline records enough information to understand the result.

The execution environment is part of that process. CI/CD pipelines already provision temporary resources such as containers, virtual machines, databases, and services as part of a job. With Anbox Cloud, the Android execution environment can become another resource requested by the pipeline when needed.

Instead of treating a physical device or local emulator as a prerequisite, the pipeline requests an Android environment with a known image and configuration. It deploys the artifact, performs the required validation, collects the evidence, and releases the resources.

Anbox Cloud does not build the Android application or platform. That remains the responsibility of the existing build system. Its role is to provide the Android environment required for validation through a programmable and repeatable lifecycle.

A typical Android pipeline

The exact tooling varies, but the workflow is typically consistent. The pipeline first produces or retrieves the artifact to validate. For an application team, that may be an APK. For a platform team, it may be a complete Android or Android Automotive OS image.

Usually, after requesting the predefined environment, the process can then deploy the artifacts, get the test data ready, and establish a connection (using ADB, for instance). Once that is done, and before deleting the environment, test reports, logs, screenshots, crash data, and performance metrics are gathered.

Every stage of the process should be explicit. The pipeline should know which artifact was tested, which Android environment was used, which configuration was applied, and which outputs were produced.

Without that context, automation may speed up testing but not improve the reliability of the results.

Reproducibility matters more than automation alone

Being able to start Android automatically is useful, but starting the same environment consistently is way more valuable.

When the Android version changes between runs, a setting is manually changed, cached data influences the outcome, or an older application is still installed, the results are difficult to trust. Making those inputs explicit in the CI/CD workflow reduces manual configuration errors and improves reproducibility.

The Android image, application artifact, instance resources, display settings, test inputs, and expected outputs can all be associated with a specific execution. The workflow can also wait for known states instead of relying on arbitrary delays or assumptions about when an environment is ready.

A script says, “Start Android and run this test.” A reproducible pipeline says, “Run this version of the test against this artifact, in this defined environment, with these inputs, and preserve enough evidence to explain the result.”

That second model is what teams need when a failure blocks a release.

Preserve evidence, not unnecessary infrastructure

Disposable environments allow every run to begin from a clean state, but removing an environment should not mean losing the information required for debugging.

When validation fails, the pipeline should collect the relevant diagnostics before releasing the resources. It may also record the environment definition so that an engineer can recreate the same conditions later. In selected cases, preserving an instance temporarily for interactive investigation may be useful.

The goal is not to retain every failed environment indefinitely. A better principle would be to preserve the evidence by default and preserve the environment when it adds value.

This keeps the workflow efficient while giving teams enough information to understand and reproduce failures.

One operating model, different Android workloads

Application and platform teams validate different artifacts, but the operational model remains the same.

An application pipeline may install an APK and run instrumentation, UI, compatibility, or integration tests. A platform pipeline may validate a complete Android system image, an Android Automotive OS configuration, platform services, or a custom OEM build.

The execution environment may differ as well. Application-oriented workloads may benefit from containerized Android when density and startup time matter. Complete system workloads may require virtualized Android with a full virtual-machine boundary.

Those are implementation choices. The pipeline story remains consistent: a change produces an artifact, the workflow requests the appropriate Android environment, and validation begins without waiting for someone to prepare hardware.

Keep people and hardware where they add value

Not every validation decision can be automated. Developers may need to inspect a graphical issue, QA engineers may need to review a visual difference, and platform engineers may need to investigate system behavior interactively. A pipeline-created environment can still be recreated, streamed, or shared temporarily for that work.

Physical hardware remains essential for validating sensors, peripherals, radios, drivers, power consumption, thermal behavior, and final production performance. But it does not need to carry the full weight of the development process. Programmable environments can provide earlier feedback and broader parallel validation before software reaches the final hardware stage.

A balanced strategy would be to run every change, validate broadly in the cloud, and finally prove it on target hardware.

Android should no longer be the manual exception

Automation makes Android environments programmable. Scaling makes that capacity available when workflows need it. CI/CD brings both capabilities into the software delivery process at the point where feedback is most valuable.

The pipeline can request an environment, deploy the artifact, run validation, collect evidence, and release the resources without waiting for someone to connect a device or prepare a test machine.

Android becomes part of the workflow rather than an external dependency on it. Physical hardware remains the final proof, but routine Android feedback no longer needs to wait for it.

That is the broader transformation explored throughout this series: Android moves from a scarce physical asset to programmable engineering infrastructure.

Further reading

Read Part 1: Android development shouldn’t start with a physical device

Read Part 2: Scaling Android development without scaling hardware

For any questions, feel free to get in touch with the Anbox team.

How shared Android capacity helps engineering teams move beyond fixed device labs

In the first blog of this series, we discussed how programmable Android environments can replace manual device preparation with a repeatable lifecycle. A workflow requests an environment with a predefined configuration, executes the required task, collects the results, and releases the resources once the work is completed.

Automation enables a team to create a single Android environment reliably. The next question is about scaling: how can that same operating model support every developer, test, session, and workflow that needs Android?

Running one Android environment in the cloud is useful. Making Android capacity available on demand, at scale, is where the operating model begins to change.

Fixed hardware, variable demand

Physical device labs grow one device at a time. Each additional phone, development board, display, or hardware bench must be purchased, prepared, connected, maintained, shared, and eventually replaced.

That model can work when demand is small and predictable. Engineering demand, however, rarely is. Consider these common use cases:

• A CI pipeline may need many temporary environments after a code change. 
• A QA team may need additional capacity before a release. 
• A streaming service may experience a sudden increase in active sessions. 
• An automotive team may need to validate several Android Automotive OS configurations in parallel.

The traditional approach leaves teams compromising. They can either provision enough hardware for average demand and accept queues during busy periods. Or they can provision for peak demand and leave equipment idle when activity falls.

This creates a clear mismatch. Dedicated Android devices provide a fixed amount of capacity, while development, testing, and streaming workloads create demand that changes over time.

Target hardware (the real components, such as sensors, peripherals, and GPUs) remains essential for validating the characteristics of the final product. However, the number of phones, development boards, or hardware benches available should not determine how quickly every software activity can move.

From device inventory to requested capacity

Cloud infrastructure handles variable demand by pooling compute resources and allocating them to workloads when required. Those workloads run in containers or virtual machines on shared host infrastructure, depending on their technical requirements.

Android can use the same model through Anbox Cloud. Instead of reserving a particular phone, board, or hardware bench, a workflow requests an Android environment with a defined image, configuration, and resource profile. Anbox Cloud runs that environment as a managed container or virtual machine on the available host infrastructure.

Once the task is complete, the Android instance can be removed and its CPU, memory, storage, and graphics resources returned to the shared pool. That capacity can then serve another developer, test, or session.

Android capacity becomes something workflows request rather than something people reserve. Teams can make more environments available when demand rises without assigning a dedicated Android device to every task.

Scale for the workload

Scaling discussions often begin with one question: how many Android instances can run on one server?

There is no universal answer. 

• A streamed Android game does not have the same resource profile as an automated test. 
• An interactive development environment creates a different demand pattern from a nightly validation pipeline. 
• A complete Android Automotive OS image requires different resources from an application-level workload.

Some environments are constrained primarily by CPU and memory. Others depend on GPU capacity, storage performance, network throughput, startup time, or predictable frame delivery. These differences matter more than the raw instance count.

The more useful question is, how much capacity does this workload require to produce predictable results?

Teams need to measure representative applications and Android images under realistic conditions. They need to understand average concurrency, peak demand, session duration, and which infrastructure resource becomes constrained first. Density matters, but predictability matters more.

To match the execution model to the workload, Anbox Cloud supports both containerized and virtualized Android execution. 

• Containers are suited to application-oriented workloads where density, startup time, and efficient resource use matter, including testing, streaming, automation, and gaming. 
• Virtual machines are suited to workloads that require a complete Android system with its own kernel and virtual-machine boundary, such as custom Android system development and system-level validation.

Neither execution model is intrinsically better. The appropriate model depends on the workload, while the operational objective remains the same: provide the required Android capacity with predictable behavior.

Scaling teams, not only instances

Shared Android capacity also removes organizational bottlenecks, by making environments centrally managed and remotely accessible.

A development board may be located in one office while the engineer who needs it works in another country. A hardware bench may be assigned to one team even when it remains idle. A device may need to remain in a specific degraded state until another engineer is actually assigned or available to investigate it.

When Android environments are centrally managed and remotely accessible, developers no longer need to know which server hosts an instance or where that infrastructure is located. QA engineers do not need to reserve a particular device days in advance, and support teams can access a reproducible environment instead of waiting for hardware to be prepared or shipped.

The same environment can also support both automated and interactive workflows. A failed test can be recreated for investigation, an instance can be streamed to a browser for visual inspection, and a temporary session can be shared with another team.

Scaling therefore means more than running additional instances. It means giving more people access to the right Android environment when they need it.

Reusable capacity

Shared infrastructure remains efficient only when resources are released after use. Temporary Android instances should be removed once their outputs have been collected, while persistent environments should exist because a workflow explicitly requires them.

For a single environment, this improves reproducibility. At fleet scale, it prevents unused instances from consuming capacity required by active workloads.

From scalable capacity to continuous workflows

Automation makes Android environments programmable. Scaling makes that capacity available to more developers, tests, sessions, and engineering teams. Together, they allow Android capacity to be requested by software rather than reserved by people. Tests can run in parallel instead of waiting for individual devices, while interactive environments can be accessed remotely rather than tied to a particular laboratory.

Dedicated Android devices and target hardware still have an essential role. Teams must ultimately validate sensors, peripherals, drivers, radio interfaces, thermal behavior, performance, and other device-specific characteristics on the final product.

However, those devices can be reserved for work that genuinely depends on their physical characteristics, rather than expecting those same devices to carry every development and validation task. Teams can run early checks in programmable environments, execute broader test matrices in parallel, and reproduce software failures, all without waiting for a particular device.

This creates a more balanced validation model: run early, validate in the cloud, and prove on target hardware.

Once Android capacity can be requested on demand, the next question is what should request those environments and when.

The answer is the development pipeline.

In the next article, we will look at how Android environments can become a standard part of continuous integration and delivery: created automatically for each change, used for validation, and removed when the workflow is complete.

Read Part 1: Android development shouldn’t start with a physical device
Read Part 3: Android belongs in your CI/CD pipeline

Learn more about Anbox Cloud or contact our team: https://canonical.com/anbox-cloud 

How on-demand Android environments lay the foundation for Android engineering

Software 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: 

1. A developer connects a phone to reproduce an issue. 
2. A QA engineer then reserves a device from a shared lab. 
3. 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 environments

Modern 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 lifecycle

Android 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 build

Teams 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 path

By 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.

Read Part 2: Scaling Android development without scaling hardware
Read Part 3: Android belongs in your CI/CD pipeline

Learn more about Anbox Cloud or contact our team: https://canonical.com/anbox-cloud