AOSP Architecture

Stay organized with collections Save and categorize content based on your preferences.

The Android Open System Platform (AOSP) is publicly available and modifiable Android source code. Anyone can download and modify AOSP for their device. AOSP provides a complete and fully functional implementation of the Android mobile platform.

There are two levels of compatability for devices implementing AOSP: AOSP compatibility and Android compatability. An AOSP-compatible device must conform to the list of requirements in the Compatibility Definition Document (CDD). An Android-compatible device must conform to the list of requirements in the CDD and Vendor Software Requirements (VSR) and tests such as those in the Vendor Test Suite (VTS) and Compatability Test Suite (CTS). For further information on Android compatibility, refer to the Android compatibility program.

AOSP architecture

The software stack for AOSP contains the following layers:

AOSP software stack architecture
Figure 1. AOSP software stack architecture.
  • Android app. An app created solely using the Android API within the Android SDK. Google Play Store is widely used to find and download Android apps, though there are many other alternatives. In some cases, a device manufacturer might want to preinstall an Android app to support the core functionality of the device. If you're interested in developing Android apps, proceed to developers.android.com.
  • Privileged app. An app created using a combination of the Android and system APIs. These apps must be preinstalled as privledged apps on a device.
  • Device manufacture app. An app created using a combination of the Android API, system API, and direct access to the Android framework implementation. Because a device manufacturer might directly access unstable APIs within the Android framework, these apps must be preinstalled on the device and can be updated only when the device's system software is updated.
  • Android framework. A group of Java classes, interfaces, and other precompiled code upon which apps are built. Portions of the framework are publicly accessible through the use of the Android SDK's Android APIs. Other portions of the framework are available only to OEMs through the use of the Android SDK's system APIs. Android framework code runs inside an app's process.
  • Android SDK. A software development kit for use in creating apps that interact with the Android framework. The Android SDK consists of the Android API, available to all apps, and the system API, available only to privledged apps. For further information on the Android SDK's Android API, proceed to developers.android.com. Note that there is also an Android native development kit (NDK) that allows you to write part of your Android app using native code.
  • System services. System services are modular, focused components such as system_server, SurfaceFlinger, and MediaService. Functionality exposed by Android framework API communicates with system services to access the underlying hardware.
  • Android runtime (ART). A Java application runtime environment provided by AOSP. ART performs the translation of the application's bytecode into processor-specific instructions that are executed by the device's runtime environment.
  • Hardware abstraction layer (HAL). A HAL is an abstraction layer with a standard interface for hardware vendors to implement. HALs allow Android to be agnostic about lower-level driver implementations. Using a HAL allows you to implement functionality without affecting or modifying the higher level system.
  • For further information, see the HAL overview.
  • Native daemons and libraries. Native daemons in this layer include init, healthd, logd, and storaged. These daemons interact directly with the kernel or other interfaces and don't depend on a userspace-based HAL implementation. Native libraries in this layer include libc, liblog, libutils, libbinder, and libselinux. These Native libraries interact directly with the kernel or other interfaces and don't depend on a userspace-based HAL implementation.
  • Kernel. The central part of any operating system, the kernel talks to the underlying hardware on a device. Where possible, the AOSP kernel is split into hardware-agnostic modules and vendor-specific modules. For a description, including definitions, of AOSP kernel components, refer to the Kernel Overview.

What's next?

  • If you're new to AOSP, and want to get started with development, proceed to the Get started section.
  • If you want to learn more about a specific layer of AOSP, click the layer's name in the left navigation and begin with the overview for that layer.