The aosp folder structure is organized to separate different layers and components of the Android operating system. Each folder serves a distinct role, whether it's related to the kernel, application frameworks, hardware abstraction, or core system libraries. Understanding the aosp folder structure is the first step for any developer working with Android — it is hierarchical by design, allowing easy scalability and maintainability across diverse hardware targets.
The typical AOSP root directory in the aosp folder structure includes these main folders:
- frameworks/
- hardware/
- kernel/
- system/
- packages/
- build/
- vendor/
- device/
In addition to these core folders, there are other directories related to device-specific code and tools. Let's break down these directories in detail and see what they contain.
ASOP Folder Structure
frameworks/ Directory
Within the aosp folder structure, the frameworks/ directory is the heart of AOSP and contains the Android framework code. This is where the core system libraries and APIs that applications or APK use to interact with the underlying operating system reside.
Key Subdirectories:
- frameworks/base/: This is where the core framework of Android lives. It includes essential components like the Activity Manager, Window Manager, and Content Providers, which provide the building blocks for Android apps. It also includes Android's Java API libraries for apps.
- frameworks/opt/: opt means optional, it contains additional framework components that are optional but may be included in certain Android builds. This might include extra features like telephony, net, graphics, Bluetooth or advanced location services.
- frameworks/native/: This folder contains the native code that powers the framework, including services like SurfaceFlinger (responsible for drawing the UI) and media components for handling audio and video.
- frameworks/av/: This folder handles Android's media framework, which is responsible for all media playback, encoding/decoding, and related operations.
Example:
If you're working on adding or modifying system-wide features, such as UI behavior, app lifecycle management, or system services like media or notifications, most of your modifications will occur in frameworks/base/.
Hardware/ Directory
The hardware/ directory contains the code related to hardware abstraction and drivers. This layer serves as an interface between Android and the actual hardware of the device, providing a standard way for the operating system to interact with different hardware components. Embien's Edge Computing Services leverage the hardware/ directory's modular HAL isolation to deploy Android reliably across diverse edge hardware platforms.
Key Subdirectories:
- hardware/interfaces/: Defines the Hardware Abstraction Layer (HAL) or HIDL interfaces. These interfaces define the communication protocol and API for interaction between the Android framework and the hardware components without needing to know the underlying device-specific details. HAL is divided into multiple subfolders based on specific hardware components like camera, audio, and GPS.
- hardware/libhardware/: Contains the implementations of the HAL interfaces. It provides the underlying libraries that HAL modules depend on.
- hardware/ti/ and other vendor-specific directories: These folders contain device-specific hardware components and drivers, typically provided by hardware vendors. For example, hardware/ti/ might contain code for Texas Instruments hardware.
Example:
Developers working with custom hardware or implementing new hardware features will modify the HAL code here. If you're building for a specific device and need to add custom drivers or interfaces, hardware/ is where you'll spend most of your time.
Kernel/ Directory: The Android Kernel Folder
The android kernel folder in AOSP contains kernel configuration and build files necessary to integrate Linux kernel features with Android. The android kernel folder includes defconfig files, config fragments (android-base.config, android-recommended.config), and architecture-specific or conditional configurations (android-base-conditional.xml). These files define kernel requirements for Android functionality, optional enhancements, and device-specific customizations. Configuring the android kernel folder correctly is critical to ensure that platform drivers and Android-specific kernel features are properly enabled for your target SoC.
Example:
To add Android kernel features to your platform:
- Start with your platform's defconfig (e.g., arch/arm64/configs/your_platform_defconfig).
- Use the merge_config.sh script to combine it with required Android config fragments:
bash Copy code ARCH=arm64 scripts/kconfig/merge_config.sh your_platform_defconfig android-base.config android-recommended.config
- Verify the generated .config file, ensure compliance with android-base-conditional.xml, and rebuild the android kernel folder artifacts.
System/ Directory: The Android System Folder
The android system folder houses essential system components that are used across the Android platform. It includes system libraries, utilities, and other key infrastructure. The android system folder is where you would make changes when working on low-level platform behavior — modifications here directly impact how Android initializes and runs core services.
Key Subdirectories:
- system/core/: Contains the essential core libraries that the android system folder depends on. This includes things like libc, libm, and other standard C libraries, as well as utilities like the init system and runtime.
- system/bt/: Includes the Bluetooth stack, which Android uses to manage Bluetooth devices and connectivity. It contains both the user-space and kernel components.
- system/netd/: Manages networking services in Android, handling network connectivity, IP management, and routing.
Example:
The android system folder is where you would make changes if you're interested in improving the operating system's low-level features, such as system libraries, Bluetooth management, or networking.
packages/ Directory
The packages/ directory contains the code for various Android applications that ship with the OS, such as the Phone app, Contacts, Settings, and Camera. This directory also includes packages for services and utilities.
Key Subdirectories:
- packages/apps/: Contains all the apps that ship with AOSP, such as Launcher, Settings, Contacts, and Phone. If you're working on custom ROMs or developing new system applications, this is where you will likely add or modify apps.
- packages/services/: Contains core system services that run in the background. This includes services for telephony, account management, and more.
- packages/input/: Contains the input method framework, responsible for handling touch and hardware input devices like keyboards and styluses.
Example:
If you're modifying or adding apps to AOSP or need to customize existing apps like Settings, you'll be working with the files in packages/apps/. For adding system services or modifying UI behavior, this directory is also your main area of focus.
build/ Directory
The build/ directory in the aosp folder structure contains everything related to building the AOSP source code. This includes scripts, configuration files, and makefiles that dictate how the code is compiled and assembled into an Android image.
Key Subdirectories:
- build/: Contains the build configuration files, including makefiles and scripts for setting up the build environment and managing the build process.
- build/soong/: This folder contains the Soong build system, which is Android's primary build system for managing code and dependencies. Soong uses Android.bp files to define modules and their dependencies.
Example:
If you're involved in modifying how AOSP is built (such as adding new build modules, customizations, or adjusting build scripts), you'll spend time in this directory. The Soong system is especially important for modern Android builds.
device/ Directory
The device/ directory contains device-specific code for different manufacturers and configurations. This includes hardware configuration files, device drivers, and settings tailored for specific devices. Embien's Embedded Android Development Services cover end-to-end aosp folder structure customization including device tree configuration, product makefiles, and full BSP bring-up for custom hardware targets.
Key Subdirectories:
- device/<vendor>/<device_name>/: Each Android device will have its own subdirectory in this folder, containing device-specific configurations and files necessary for building that particular device. These include kernel configurations, device trees, and other settings.
Example:
If you are working on building AOSP for a specific device, you'll interact heavily with this directory. Device configuration files, kernel settings, and vendor-specific drivers all live here.
vendor/ Directory
The vendor/ directory is where third-party vendors provide Android-specific customizations. This could include proprietary drivers, custom hardware abstraction layers (HALs), or specific functionality like camera or audio.
Key Subdirectories:
- vendor/<vendor_name>/: Each vendor will have a directory where it places device-specific drivers, HALs, or other proprietary code.
Example:
If you're working on a custom Android project with proprietary hardware or software, you'll need to interact with this directory to integrate vendor-specific components (binaries, libraries, etc.) into AOSP.
Android Customization via Device and Vendor Directories
Android customization at the platform level is primarily driven through the device/ and vendor/ directories within the aosp folder structure. Whether you are adding a custom launcher, modifying system UI behavior, integrating proprietary peripherals, or shipping a fully branded firmware image, Android customization depends on correctly configuring these directories. Product makefiles, overlays, and BoardConfig.mk files all work together to tailor the Android build for target hardware without modifying the core AOSP source.
Embedded OS Porting and BSP Development with AOSP
Embedded OS porting and BSP development with AOSP requires a thorough understanding of how the device/, vendor/, and android kernel folder directories interact during the boot and build process. Embedded OS porting and BSP development involves configuring board support packages, writing device tree overlays, integrating SoC-specific drivers, and validating platform bring-up against Android's Compatibility Test Suite (CTS) and Vendor Test Suite (VTS). Teams undertaking embedded OS porting and BSP development must align their platform configurations with both the android kernel folder requirements and the android system folder's expected runtime environment.
Conclusion
Mastering the aosp folder structure is essential for efficient Android development, enabling developers to navigate and modify specific components seamlessly. Each folder in the aosp folder structure — such as the android kernel folder, android system folder, device, and vendor — plays a distinct role in organizing configurations, binaries, and platform-specific code. The device folder focuses on device-specific configurations, while the vendor folder houses proprietary hardware binaries. At Embien Technologies, we have successfully customized AOSP for many customers, delivering tailored solutions that meet unique requirements and drive tangible benefits. By mastering these directories, developers can build robust and innovative Android solutions across diverse hardware platforms.