Vision:

• we "fork" from vanilla google emulator (can we also fork emulator with GAS?);
• we only fork repositories which we modify, the rest will be pointing to upstream AOSP;
• 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;
• 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.
• Number of repositories: ~5-20 repositories, depending on how many things we change in AOSP. Not expected to be checked out many times, mostly for those who actually work on it and by CI server.
• Code review: Ability to bundle code changes across different repositories (Gerrit feature). Possible to do without Gerrit, but long-term adds complexity and is very error-prone.
• CI: any typical CI server which can connect Gerrit, GitHub, and Binary Storage solutions.
• Build host: To build AOSP we need at least 500GB of fast storage and minimum of 64GB RAM. For each additional "flavor" of emulator we would need 500GB storage and separate build directory. By default we would build on every change request (Gerrit's term for Pull Request). It can run latest Ubuntu LTS (also headless). See https://source.android.com/docs/setup/start/requirements
• Test host: needs support for nested virtualization (we will be building Goldfish emulator, which is run using QEMU/KVM). For start we can run tests directly on build host, but it would be good to split responsibilities. Needs 16 GB RAM, 64bit OS, 16 GB disk space (see https://developer.android.com/studio/run/emulator#requirements). Also it needs a (virtual) display to take screenshots from.
• Binary repository. One emulator archive with Android 14 is ~2 GB, it is only going to grow. 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). For ease of use we would also need all builds and logs from change requests on Gerrit.
  ~100 GB should be good for starters.
  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.

Preferred options:

• Code Review System: Gerrit (e.g., for free via http://gerrithub.io, or self-hosted on a COVESA VM).
• Source Code Hosting: Gerrit or Github (need to check if http://gerrithub.io has any restrictions compared to free tier on GitHub)
  NOTE: LineageOS uses Gerrit (self-hosted), and replicates all repositories to GitHub, which gives 2 advantages which may be irrelevant for us:
  • scale (less traffic to their Gerrit server, less load),
  • backup of repositories and all Gerrit data (since Gerrit v3).
• CI: no preference (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.