Each Android phone, TV, car display and wearable contains the AOSP – without it you couldn’t launch applications and do most of the tasks that underpin the Android OS. It’s the open source operating system code that Google oversees and manufacturers tweak, and which allows Android’s wide scale and varied experience without subjecting everyone to a single broad stroke of sameness.
Consider AOSP to be the framework on which Android is built. It’s the sandbox where Samsung’s One UI, Xiaomi’s HyperOS, Google’s Pixel UI, Amazon’s Fire OS, and privacy-conscious initiatives like LineageOS all play. It’s this common base that allows Android to achieve this coverage and yet to let each vendor differentiate.
What AOSP actually is
The AOSP is a complete operating system: a Linux kernel, system libraries, system services, the Android run-time, application frameworks, and system apps. It’s basically offered under the Apache 2.0 license (the kernel is still GPLv2), so companies can use, modify, and ship it with relatively few strings attached—one factor that led to the ecosystem expanding at such a rapid pace.
Google drives the development and accepts contributions from the community through its code review system and monthly security bulletins. Google says more than three billion active devices run Android, and StatCounter’s browser-segment data consistently finds Android around 70% of the world’s mobile OS market—scale that AOSP’s laissez-faire model helped generate.
AOSP vs. “stock Android” and GMS
AOSP is not what you see on a Pixel and it does not include Google Mobile Services (GMS). When downloaded to your device, AOSP doesn’t come with Google’s proprietary apps and APIs, such as the Play Store, Play Services, Google Maps, or Wallet. Those arrive through other commercial agreements and compliance programs.
Manufactures that are looking for GMS must pass Google compatibility tests including CTS, VTS and GTS (the Google Mobile Services Test Suite) and quality gates. Regulators — notably, the European Commission — have been keeping an eye on how these bundles are getting out there, leading to the way that choice screens and defaults have been presented in some places.
Because AOSP doesn’t include device specific drivers, it isn’t an out-of-the-box smartphone OS. Chipset manufacturers such as Qualcomm and MediaTek provide board support packages and drivers for the modem, camera, GPU, sensors. That extra layer is what can lead to sluggish update times: the open-source core is updated, but low-level components have to be revalidated on a per-device basis.
How does the AOSP stack work?
AOSP follows a traditional layered OS architecture. At its base, the Linux kernel coordinate CPU, memory, and I/O. Above that, the HAL standardizes how system functions (audio, camera, sensors, Bluetooth) communicate with hardware. Binder IPC allows for secure and efficient process communication.
ART runs the bytecode compiled android applications at the install time and optimizes them for the device. Applications rights are from notifcations to location to telephony to media to everything else. Native libraries include OpenGL ES, Vulkan and WebView, while part of the build system is the AOSP one.
Updates, Treble, and Mainline
Updates have been slowed by Android’s historical tight coupling with vendor code. Project Treble re-architected the OS framework to separate OS framework and vendor implementations using a stable vendor interface, known as the VNDK. It’s that decoupling that has allowed so many new devices to receive major updates much more quickly than was the case in the early years of Android.
Project Mainline went a step further, modularizing core components—like media, networking, and the ART—to enable Google to push fixes through Play system updates. The result: critical patches and improvements can reach users, without waiting on a full OEM firmware release.
Security is ongoing effort in AOSP. Google’s security teams coordinate monthly bulletins, and the project has moved to memory-safe languages such as Rust for new low-level components. Google has also publicly claimed a significant reduction in memory safety issues since adopting Rust into Android’s codebase.
Who builds on AOSP — and why
Big OEMs stir up AOSP to produce what we know as branded experiences: Samsung One UI, Nothing OS, Oppo ColorOS are some of the popular ones. Amazon’s Fire OS leverages AOSP with no GMS for its tablets and TVs. Huawei replaced Google services with its own HMS after being cut off from U.S. technology and continues to base phones on AOSP-derived code.
Open-source communities depend on AOSP as well. LineageOS offers continued support for your aging phones; GrapheneOS focuses first and foremost on hardening the security of a limited selection of Pixels. Outside of phones, AOSP also underpins Android TV, Android Automotive OS, and parts of Wear OS—evidence the same core system can scale from car dashboard to living room.
Governance, licensing, and compliance
Most AOSP code is Apache 2.0 with broad reuse w/ attribution; the Linux kernel (and its drivers) are GPLv2, so driver changes to the kernel must be shared; etc. Contributions come through Google’s Gerrit and the mailing list where Google, silicon vendors, and OEMs work together on features and fixes.
To ensure compatibility, Google publishes the Android Compatibility Definition Document (CDD), which includes requirements that devices must meet to be considered “Android compatible.” Going through the CTS and the like suites allows OEMs to advertise their apps against a stable API surface – and then if they so choose to, add GMS atop it via separate agreements.
Developer opportunities: GSIs and testing
To ease it’s predictability, AOSP provides Generic System Images (GSIs) that runs the current framework on any Treble-compatible device. Devs and phone-makers employ GSIs to check apps and hardware compatibility with the latest APIs, finding regressions ahead of time, before slapping custom skins and services on top.
AOSP also comes with comprehensive test suites, documentation, and build tooling. That infrastructure is what allows a small team to port Android to a new board, validate HALs, and bring up the UI months before a commercial skin is available.
Why AOSP is important now — and next
The openness of AOSP is the reason Android can truly be everywhere without being the same. It establishes a common denominator for security, performance and developer APIs, but allows hardware suppliers to compete on design, features and services.
Google still experiments—Fuchsia is a stand-alone open-source OS that runs the kernel Zircon, for instance—but Android is a juggernaut thanks to the AOSP’s shared-power approach. Through larger and larger updates to modules, as silicon vendors upstream more drivers, memory-safe code proliferates, and more, the Android base gets faster, more secure, and more consistent for everyone while still allowing for a wide variety of choice.