AOSP

AOSP is the source code and documentation of Android, which Google makes available to anyone. Google describes it as a full, production-quality developer product, open for customization and porting. You can use it to create custom variants of the Android operating system for your own devices. The code covers the operating system itself, from the Linux kernel and the hardware abstraction layer to the Android framework, the runtime and the system apps.

Most of AOSP is licensed under Apache 2.0, which the project names as its preferred license. Exceptions are handled case by case; the Linux kernel patches, for example, are under GPLv2.

What AOSP does not contain is Google Mobile Services (GMS), which the documentation defines as a collection of Google apps and APIs that can be pre-installed on devices. Google Play belongs to that layer. A device is eligible for potential licensing of Google Play and GMS only when it is Android-compatible: it must meet the requirements of the Compatibility Definition Document (CDD) and pass the Compatibility Test Suite (CTS). Compatibility makes a device eligible; it does not grant the license automatically. So the Android on most consumer phones is AOSP plus GMS plus the manufacturer's own changes, while a device built on AOSP alone runs Android without Google's apps and services.

Google changed how it publishes the code. Since 2026, it publishes source code to AOSP in Q2 and Q4, and the android-latest-release manifest branch always points to the most recent release pushed to AOSP. Security fixes follow their own rhythm: the Android Security Bulletins come out on the first Monday of each month, and platform security fixes are merged into AOSP 24 to 48 hours after the quarterly bulletins in March, June, September and December.

Building on AOSP gives you control over the whole system, and with it every job Google's layer normally does for a phone maker. Requirements for a team that plans its own AOSP-based system:

• App distribution is yours. Without Google Play, apps reach devices through your own store, a managed channel or sideloading. Someone has to review apps, sign them and publish updates.
• Updates are yours. The fleet needs an OTA update backend, release keys, full and incremental packages and staged rollouts. AOSP gives you the update mechanism on the device; it does not give you the server.
• Security patches arrive on a schedule. Each monthly bulletin has to be assessed, and with source drops in Q2 and Q4 your own changes have to be merged onto a moving base. Plan who does that and how often.
• Board support is hardware work. Drivers, the kernel and vendor components come from the chip and board supplier. Without a maintained board support package, a new Android version may not reach your hardware.
• Fleet management may need to live in the system. On company devices you may need MDM functions, network controls such as deep packet inspection and remote wipe, and in a custom OS they can be built into the operating system rather than added as an app.
• The build needs serious hardware. Google lists at least 400 GB of free disk space to check out and build the code (250 GB for the checkout and 150 GB for the build) and at least 64 GB of RAM on 64-bit x86 Linux. A full build takes about 40 minutes on a 72-core machine and about 6 hours on a 6-core machine.

AOSP itself is a code base with licenses, not a regulation. A device that wants Google's apps has to follow the Android compatibility program: the CDD lists the hardware and software requirements, and CTS is a free test suite available as a binary or as source in AOSP. A device that does not seek compatibility can use the source for any legitimate purpose, but it is not part of the Google Play ecosystem. A connected device built on AOSP and placed on the EU market is also a product with digital elements, so the update obligations of the Cyber Resilience Act described under OTA update apply to it as to any other device.

From 2019 to 2021 we built RAW OS for Raw Control, a hardened Android-based phone system built on CopperheadOS. Around the system we built a store with only pre-approved apps, packet inspection inside the operating system and device management with an administration panel.

Keeping a custom Android current was a project of its own. The project had an ongoing workstream for keeping RAW OS in line with Copperhead's changes and with new devices: syncing our repositories with Copperhead's and preparing and testing the system for new hardware. When Copperhead moved to Android 11, the team aligned the repositories, built Copperhead's Android in July 2021, fixed compilation errors when merging our changes into frameworks/base, Android's framework repository, and got the Settings app and a release build running in August. Our features then had to be moved to the new base and checked one by one, SIM card detection among them. We closed the task of running RAW OS on Android 11 in September 2021.

For Mudita, our engineers work on the App Store and the OTA platform around Mudita's phones. We did not build Mudita's operating system.