The biggest bottleneck in AOSP product development is hardware. We have all seen it: a release slips past schedule because not enough EVT units are available for developers to test on. Or worse, a developer skips integration testing all together and a bug makes it into the next OTA update. If you only perform system validation on hardware, the throughput of your engineers will be limited by your supply chain.
To break this dependency, we need to treat hardware as software, and luckily AOSP ships with high-quality virtualization tools. By “virtual device”, I’m not talking about the Android emulator that’s used for app development. Instead, I am referring to Cuttlefish, an AOSP virtual device platform that boots the same system image that you would flash to hardware. I’ve seen the benefits of Cuttlefish firsthand at Meta’s Reality Labs, where Cuttlefish virtual devices have enabled pre-silicon development and validation that otherwise would have been blocked by hardware delays.
Catching bugs sooner by shifting left
The main strategic insight is that, for most organizations, software features evolve much faster than board layout. Cuttlefish runs the same system image that you would flash to a physical device, so any bugs above the HAL are reproducible. Since virtual devices are programmable and deterministic, they allow us to reliably observe how the software handles hardware degradation without the risk of bricking a board. In fact, we are able to test remote server integrations and OTA updates months before EVT units arrive. This allows validation to “shift left” for the upper layers of our stack.
Compared to physical device bring-up, virtual device bring-up is cheap and fast. The AOSP source tree contains virtual device build targets for common form factors, such as phone, watch, TV, and automotive. These build out of the box, or can be used as references for customization. A virtual device runs on generic server hardware and boots a system image in seconds. Emulation is known for being slow, but a VM with hardware acceleration can run a virtual device directly on the host CPU. The cost of a broken image “bricking” a virtual device is near zero. Just reboot the VM. The economics are naturally suited for massively parallel development with coding agents and automated testing on every commit.
Tooling is an investment that pays off at scale
For all these benefits, however, adopting virtual devices carry a maintenance overhead that otherwise wouldn’t exist. A virtual device can run the same system image that is flashed to hardware, but cannot reuse HAL implementations. Under the hood, Cuttlefish uses the VirtIO framework to emulate components in your device tree. VirtIO comes with a standard library of components including storage, network interfaces, graphics, and inputs. However, if these don’t cover your product’s device tree, then your team will need to extend VirtIO to close those gaps.
It should also be obvious that a virtual device cannot fully replicate all hardware features. To understand a product’s thermal behavior, for example, it is necessary to test on a physical device. For certain industrial use cases, timing-sensitive interconnects must be validated on hardware. Virtual device testing should complement physical device testing, not substitute it.
The tradeoffs are different for every organization, and not every company has Meta’s scale. However, if you are managing dozens of engineers, facing frequent system changes, or deploying coding agents that require massive parallel testing capacity, the answer is clear. The overhead of maintaining a virtual device is far lower than the cost of a missed release or a team idle waiting for boards.
Why EmulatorFarm?
I'm Bobby, and I work on AOSP and developer productivity at Meta’s Reality Labs. I'm a nerd about virtualization and I'm building EmulatorFarm to bring better tooling to the AOSP ecosystem.
Join the mailing list to get updates about EmulatorFarm.