The Android Open System Platform (AOSP) is a 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.
A brief idea about the components
An android app is created solely using the available Andriod API. These android apps can be downloaded easily from the Google play store.
Applications created using both Android and system APIs are privileged applications. These applications have System level privileges and can use system-level API.
These apps come preinstalled as privileged apps on an android device.
Device manufacturer app
An application created using a combination of the Android API, system API, and direct access to the Android framework implementation are Device manufacturer apps.
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.
The System API represents Android APIs available only to partners and OEMs for inclusion in bundled applications. These APIs are marked as @SystemApi in the source code.
The Android API is the publicly available API for third-party Android app developers. For information on the Android API, refer to the Android API reference.
A group of Java classes, interfaces, and other precompiled code upon which apps are built. Portions of the framework are publicly accessible through the Android API. Other portions of the framework are available only to OEMs through the use of the system APIs. Android framework code runs inside an app’s process.
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 runtime environment is provided by AOSP. ART performs the translation of the app’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 lets you 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.
The kernel is the central part of any operating system and 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.