Effective in 2026, to align with our trunk stable development model and ensure platform stability for the ecosystem, we will publish source code to AOSP in Q2 and Q4. For building and contributing to AOSP, use android-latest-release. The android-latest-release manifest branch will always reference the most recent release pushed to AOSP. For more information, see Changes to AOSP.

Configuration overview

AOSP offers the following options for storing configuration information on a device:

System properties
Early boot device configuration
Hardware abstraction layer (HAL) properties
System config XML files
Resource overlays (static and runtime)

System properties

System properties are string key/value pairs stored in the build.prop global dictionary. System properties are system-wide resources that are easy to use and have a low performance overhead. When using system properties, you don't need to use interprocess communication (IPC) even if a system property is shared across multiple processes. However, system properties are similar to global variables and can be harmful when misused. The misuse of system properties can result in issues such as security vulnerabilities and apps becoming inaccessible to users. Before using system properties to store configuration information, consider the other configuration options.

For further information on system properties, see Add system properties

Early boot device configuration

In Android 17 and higher, the init_dev_config service provides support for device configuration and system property initialization. This dynamic architectural mechanism runs automatically at early boot.

When a single system or vendor image must support multiple hardware variants, configuration values can't always be hardcoded at build time. The init_dev_config service executes during the early-init phase, right before apexd-bootstrap, letting vendors inspect the hardware state (for example, from bootloader arguments, early-mounted partitions, or hardware configuration tables) and dynamically initialize system properties before dependent services and libraries are initialized.

Service integration and lifecycle

The init_dev_config service is defined by default in the system init.rc and executed synchronously during early-init, before apexd-bootstrap. Integrators don't need to declare a new init service.

Instead, the existing service uses property expansion on its executable path, decoupling the system service declaration from the vendor binary. Integrators specify the path to their vendor binary using the ro.vendor.init_dev_config.path property, and configure it with the required SELinux labels and permissions.

Vendor implementation requirements

To integrate with init_dev_config:

Configure the vendor binary path at build time using PRODUCT_VENDOR_PROPERTIES. The provided binary path must be a valid path to a binary installed in the system:
```
PRODUCT_VENDOR_PROPERTIES += \
    ro.vendor.init_dev_config.path=/vendor/bin/init_dev_config
```
If this property is unset, init skips service execution and boot continues normally.

Because the service runs before apexd-bootstrap, the full APEX-provided bionic libraries aren't yet available. In Android.bp, set bootstrap: true:

rust_binary {
    name: "init_dev_config",
    vendor: true,
    srcs: ["src/main.rs"],
    rustlibs: [
        "librustutils",
    ],
    bootstrap: true,
}

Write the service logic to detect the hardware variant and set the appropriate system properties:

use rustutils::system_properties;

fn main() {
    let hw_sku = read_hardware_sku();

    // Dynamically initialize vendor-specific properties:
    let display_type = match hw_sku {
        1 => "oled",
        _ => "lcd",
    };
    system_properties::write("vendor.display.panel_type", display_type)
        .expect("Failed to set vendor display property");
}

Label the vendor binary with init_dev_config_exec:

 /vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0

Grant the init_dev_config domain permission to set the required property types:
```
 set_prop(init_dev_config, vendor_my_sku_prop)
```

For information on using init_dev_config for APEX activation and disabling, see Vendor APEX selection at bootup.

HAL properties

When the source of truth for a configuration is from a hardware component on a device, the HAL for the hardware must provide the information for that component. Define a new HAL method in the existing HAL for accessing the configuration. For further information on developing a HAL, see AIDL for HALs.

System config XML files

When the configuration data is static but complicated (structured), consider using XML or other such formats for the configuration data. Ensure that the file schema remains stable. For XML files, you can use xsd_config to keep the schema stable, and to take advantage of an autogenerated XML parser.

Resource overlay

You can use resource overlays to customize a product. There are two types of resource overlays:

Standard resource overlay used to customize a product at build time. For information on standard resource overlays, see Customizing the build with resource overlays.
Runtime resource overlay (RRO) is used to change the resource values of a target package at runtime. For example, an app installed on the system image might change its behavior based upon the value of a resource. Rather than hardcoding the resource value at build time, an RRO installed on a different partition can change the values of the app's resources at runtime. For more information on RROs, see Change the value of an app's resources at runtime.