Configuration overview

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

• System properties
• 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

Note: Previous to Android 10, AOSP used a ConfigStore HAL to store system properties. ConfigStore HAL is deprecated and should no longer be used. For information on the ConfigStore HAL, refer to ConfigStore HAL.

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.

Note: Don’t configure the HAL to use system properties as a side-channel communication mechanism 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. Foris 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.