AOSP, the Android Open Source Project, is the publicly released source code of the Android operating system, together with the build tools, documentation and compatibility program that let anyone build, modify and ship Android-based software. Among mobile platforms, AOSP is the shared foundation beneath nearly every Android phone, tablet, watch, TV and car system, while the Google apps and services that most users associate with Android are separate, proprietary components.
Google leads the project and writes most of its code. Device makers take an AOSP release, add drivers, hardware support and their own interface, and either license Google services or ship the device without them.
What AOSP contains
AOSP covers the complete operating system stack needed to boot and run a device, from the kernel interface to the system user interface. Most of the user-space code is licensed under the Apache License 2.0, while the Linux kernel underneath remains under the GPL version 2, which obliges vendors to publish their kernel changes.
The table below lists the main layers of the code base and their role.
| Layer | Content | Role |
|---|---|---|
| Linux kernel | Android common kernel with vendor drivers | Hardware access, scheduling, memory |
| Hardware abstraction layer | Standard interfaces implemented by vendors | Isolates the framework from hardware details |
| Android Runtime | ART with ahead-of-time and just-in-time compilation | Executes app bytecode |
| Native libraries | Media, graphics, SQLite, Bionic C library | Performance-critical services |
| Java and Kotlin framework | Activity manager, package manager, content providers | APIs used by every app |
| System apps | Launcher, settings, dialer, basic apps | Minimal user-facing functionality |
The source is spread across hundreds of Git repositories, managed with the repo tool and a manifest that pins each repository to a release branch. Building a full image from source typically needs a powerful Linux machine, several hundred gigabytes of disk space and hours of compilation on modest hardware.
AOSP compared with Google Android and vendor skins
The word Android is used for several different things, which causes confusion. AOSP is the open base, whereas the Android experience on most commercial phones adds Google Mobile Services and a manufacturer interface on top.
| Layer | License | Who provides it | Examples |
|---|---|---|---|
| AOSP | Open source | Google with community contributions | Core system, framework, basic apps |
| Google Mobile Services | Proprietary license | Google, by agreement | Google Play, Google Play services, Maps |
| Android skin | Proprietary | Device manufacturer | One UI and other vendor interfaces |
| Custom ROM | Mostly open source | Community projects | LineageOS, GrapheneOS |
Many apps depend on Google Play services for push notifications, location, maps or account sign-in. A device that ships only AOSP code therefore runs the platform correctly but may break apps that assume Google services are present. This is the main practical gap between pure AOSP and certified Google Android.
Compatibility and certification
AOSP itself can be used by anyone without permission, but the Android trademark and Google apps are tied to the Android compatibility program. Its rules are written in the Compatibility Definition Document, and conformance is verified with automated suites such as the Compatibility Test Suite and the Vendor Test Suite.
Passing these tests ensures that apps written against public Android APIs behave the same on every certified device. Manufacturers that want Google Play must pass certification and sign a separate agreement with Google.
Two architectural projects made AOSP updates easier to deliver. Project Treble, introduced with Android 8.0, separated the vendor implementation from the framework through stable interfaces, so a new Android version no longer requires rewriting all hardware code. Project Mainline, introduced with Android 10, turned selected system components into modules updated through Google Play, outside full system updates.
Who builds on AOSP and why
AOSP is attractive because it offers a mature, app-compatible operating system without license fees. Different groups use it for very different goals, as the following table shows.
| User | Typical goal | Usual approach |
|---|---|---|
| Phone manufacturers | Differentiated consumer devices | AOSP plus skin plus Google services |
| Custom ROM projects | Longer support, privacy or performance | Rebuilt AOSP for many devices |
| Ecosystem owners | Own app store and services | AOSP-based system without Google services |
| Embedded and enterprise vendors | Kiosks, scanners, point-of-sale terminals | Trimmed AOSP with locked-down apps |
| Automotive makers | In-vehicle infotainment | Android Automotive OS based on AOSP |
For embedded products, AOSP provides a touch interface, app framework and security model that would be costly to build from scratch. The trade-off is a large code base that must be patched monthly to stay secure.
Limitations and practical pitfalls
AOSP is open, but it is not developed in the open in the way many community projects are. Google designs new releases internally and has moved toward publishing source in periodic drops rather than continuously, so outside contributors and downstream projects often see a new version only at release.
- Hardware support is not included for most devices: proprietary drivers and firmware come from chipset vendors.
- Security patches must be merged by each vendor, which delays fixes on many devices.
- Pure AOSP lacks many consumer apps, such as a full browser, email client or app store.
- Long-term maintenance cost grows with every customization that diverges from upstream code.
Teams that adopt AOSP for a product should therefore plan for keeping their changes small and isolated, ideally in separate repositories or overlays, so that each new release can be rebased with limited effort. A fork that rewrites core framework code quickly becomes too expensive to upgrade, which leaves devices stuck on an old, unsupported version.
In plain words
Think of AOSP as the open recipe for Android. Anyone can read it, cook with it and change the ingredients. Phone makers use the recipe as a base and then add their own decoration, such as a different look or extra features.
The Google apps you know, such as the Play Store, are extra ingredients that are not in the open recipe. A company must get permission from Google to add them. That is why some Android devices have Google apps and others do not.
A real-world example
A company that makes self-service ordering kiosks for restaurants needs a touchscreen operating system with reliable app support and long product life. Instead of writing its own system, it builds firmware from an AOSP release for its chosen chipset, removing the dialer, camera and other unnecessary apps.
The kiosk boots directly into the ordering app in a locked task mode, and updates are delivered by the company’s own servers because the device does not ship Google services. The engineering team merges the monthly AOSP security patches into its branch. The result is a stable, license-free platform that runs across several hardware generations with the same app code.