Modular System Components

Project Mainline, officially known as Modular System Components, is Google's initiative to decouple core OS components from the monolithic Android firmware update process. By modularizing these components into APEX files or specialized APKs, Google can deliver critical bug fixes, security patches, and even feature updates directly via the Google Play Store, bypassing OEM and carrier delays.

List of Key Mainline Modules

The list of Mainline modules has grown significantly since Android 10. They cover various functional areas of the OS:

• Runtime and Core Libraries:
  • ART (Android Runtime): Allows updating the Dalvik virtual machine and core Java libraries, improving performance and fixing security issues without a full OS update.
  • Conscrypt: The core cryptography library (Java security provider).
  • Bionic (via Runtime APEX): The C library (libc), math library (libm), and dynamic linker.
• Networking and Connectivity:
  • DNS Resolver: Updates to the system's DNS client, enabling features like DNS-over-TLS or DNS-over-HTTPS.
  • WiFi: Modularized Wi-Fi stack.
  • Tethering: Handles hotspot and tethering functionality.
• Media and Formats:
  • Media Framework / Codecs: Updates to libstagefright and software video/audio codecs.
  • ExtServices: Updates to core system background services (like notification ranking).
• Time and Locale:
  • TZData (Time Zone Data): Crucial for delivering rapid daylight saving time rule changes.

Module Boundaries and Allowed API Surface

A Mainline module is treated as a highly isolated entity. It cannot arbitrarily call private APIs within the Android framework, because the framework version might not change when the module updates.

Modules must adhere to strict API boundaries:

1. System APIs (@SystemApi): Modules can call stable Java System APIs exposed by the framework.
2. NDK (Native Development Kit): Modules containing native code must rely only on stable NDK APIs (like stable libc or liblog exports).
3. Module-Specific APIs: If a module needs to expose functionality to the framework, it defines an API surface that is guaranteed to remain stable across module versions.

If a developer attempts to use a private @hide framework method from within a Mainline module's codebase, the build system will enforce the boundary and fail the build.

Module Testing Requirements

Because a broken Mainline module update can potentially brick millions of devices across hundreds of different OEM hardware models, the testing requirements are exceptionally stringent.

• CTS (Compatibility Test Suite): Each module has a dedicated suite of CTS tests that must pass.
• MTS (Mainline Test Suite): A specialized test suite specifically designed to verify the functionality of individual Mainline modules across different device configurations.
• Rollback Testing: Automated tests ensure that if a module update fails to boot or crashes repeatedly, the system can successfully detect the failure and roll back to the factory-installed version of the module.

Module Build System Configuration

In the AOSP source tree, modules are defined using the apex Soong build module type in Android.bp files.

An example Android.bp for an APEX module looks like this:

apex {
    name: "com.android.tzdata",
    manifest: "apex_manifest.json",
    // Binaries to include
    binaries: ["tzdatacheck"],
    // Prebuilt data files
    prebuilts: ["tzdata"],
    // Cryptographic key for signing
    key: "com.android.tzdata.key",
    // The certificate to use
    certificate: ":com.android.tzdata.certificate",
    updatable: true,
}

The updatable: true flag signifies that this APEX is intended to be updated via Google Play System Updates. During the build process, the system aggregates all dependencies, creates the ext4 image, configures dm-verity, and signs the final .apex archive using the specified keys.