Vision

• Starting point is the latest vanilla google AAOS emulator.

• We shall not fork and modify any upstream repositories unless absolutely necessary.
  Instead, we shall use overlays (both compile and runtime), Soong "overrides" directive, and define new devices to avoid modifying upstream as much as possible.
  Also see: https://fosdem.org/2025/schedule/event/fosdem-2025-6326-forking-android-considered-harmful/

• We work together in distributed fashion on making necessary changes, such as:

  • exchanging boot animation with COVESA logo/animation,

  • adding UnifiedPush distributor Sunup APK to enable push notifications,

  • adding additional System Services needed to support https://github.com/COVESA/covesa-aosp-sdk or any other COVESA standard,

  • adding support for Automotive App Host (to be able to run distraction optimised templated apps based on the Cars App Library).

  • integrate Media Controller Test app with platform signature (to simplify the testing for Media(audio) Apps)

• Each change is peer-reviewed, and (automatically) verified for at least "build succeeded" (by build host), and "BOOT_COMPLETED" achieved (by test host), before being merged.

• Tagged versions of emulator are automatically released by CI to binary repository (CD) and are directly available publicly (we can also consider publishing latest "development" version automatically).

General requirements

• Team Size

  • ~1-5 people working on it at the same time.

• Source code hosting

  • ~5-20 repositories.

  • Not expected to be checked out many times, mostly for those who actually work on it and by CI server.

• Code review

  • Gerrit (http://gerrithub.io) or Github.

• CI Server

  • Any typical CI server which can connect Gerrit or GitHub, and Binary Storage solutions.

• Build host

  • See https://source.android.com/docs/setup/start/requirements

  • To build AOSP today we need at least 500GB of fast storage and minimum of 64GB RAM.

  • For each additional version or "flavor" of emulator we would need 500GB storage and separate build directory.

  • The server should run latest Ubuntu LTS (also headless).

• Test host (for starters we can run tests directly on build host, but it would be good to split responsibilities).

  • See https://developer.android.com/studio/run/emulator#requirements

  • Needs 16 GB RAM, 64bit OS, 16 GB disk space.

  • A (virtual) display to take screenshots from.

  • If it is a VM, then we need support for nested virtualization. We will be building Goldfish emulator, which is run using QEMU/KVM.

• Binary repository

  • ~100 GB should be good for starters (storing all releases and temporary build artifacts)

  • One emulator archive with Android 14 is ~2 GB, it is only going to grow. Note: in GitHub, each individual file must be smaller than 2 GiB (https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas), which could be easily exceeded with emulator.

  • We would need to store binaries for all releases: at least 3 latest versions (e.g., Android 13, Android 14, Android 15). Maybe also adding flavors to each version in future (with/without additional services).

  • Also all artifacts from pending PRs should be stored there

Preferred options

• Code Review System

  • COVESA Github

• Source Code Hosting

  • COVESA Github

• CI

  • GitHub Actions should be enough

  • otherwise Travis CI seems to have free tier for Open Source

• Build host

  • COVESA VM

  • alternatively Crave.io for FOSS maybe possible, need to ask them

• Test host

  • COVESA VM

  • maaaybee also ask Crave.io, but that would be a stretch

• Binary hosting for releases and finished builds

  • no preference, ideally a highly available trusted source

Notable examples of similar infrastructures

LineageOS

LineageOS is an Open-Source AOSP-based project with a rich history and huge codebase.

It uses Gerrit (self-hosted) for code-review. For such a scale and amount of things Lineage is doing it is essential.

Their Gerrit replicates all repositories to GitHub, which gives 2 advantages which are possibly irrelevant for us:

• scale (less traffic to their Gerrit server, less load),

• backup of repositories and all Gerrit data (since Gerrit v3).

Snapp Automotive

Snapp is distributing non-GAS AAOS Emulators since several versions of Android.

Everything is done in Github, no Gerrit is needed. The reasoning is that the number of cross-repo changes for such a product is too small to justify added complexity. Using a single well-established tool also increases a likelihood of external contributions.

https://github.com/snappautomotive