Decoding AOSP Folder Structure for Developers

AOSP’s 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. The structure is hierarchical, allowing easy scalability and maintainability.

The typical AOSP root directory 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.

frameworks/ Directory

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.

Key Subdirectories:

• hardware/interfaces/: Defines the Hardware Abstraction Layer (HAL) or HIDL interfaces. These interfaces defines 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 kernel folder in AOSP contains kernel configuration and build files necessary to integrate Linux kernel features with Android. It 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.

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 kernel.

System/ Directory

The system/ directory houses essential system components that are used across the Android platform. It includes system libraries, utilities, and other key infrastructure.

Key Subdirectories:

• system/core/: Contains the essential core libraries that Android 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 system/ directory 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 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.

Key Subdirectories:

• device///: 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//: 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.

Conclusion

Understanding the AOSP folder structure is essential for efficient Android development, enabling developers to navigate and modify specific components seamlessly. Each folder, such as kernel, 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.

Reference:

Decoding AOSP Folder Structure for Developers