System Properties in AOSP

In the Android Open Source Project (AOSP), 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.

So, ultimately system properties are key-value pairs used to store configuration settings and other important information that can control the behaviour of the system and applications. These properties allow for dynamic configuration, customisation, and debugging without needing to recompile the entire operating system.

This article provides a detailed guide on what system properties are, why they are needed, how to create and use them, their advantages, and a comprehensive example demonstrating their implementation.

What are System Properties in AOSP?

System properties in AOSP are configuration settings stored as key-value pairs. These properties are used by the Android system and applications to retrieve and modify configuration settings at runtime. They play a crucial role in controlling various aspects of the operating system’s behavior, system services, and hardware configurations.

Why are System Properties Needed?

System properties are essential for several reasons:

1. Configuration Management: They allow developers and system administrators to manage system configuration settings dynamically without recompiling the entire OS.
2. Customization: OEMs can customize their devices by setting specific properties.
3. Debugging and Testing: Developers can enable or disable features, logging, and other settings without modifying the code.
4. Performance Tuning: They help in tuning system performance by adjusting configurations based on different conditions.

Use Cases of Android System Properties

System properties can modify the Android operating system’s behavior on various devices. While typically available to root users, anyone with administrator permissions can use them. Common uses include:

• UI: Modify user interface settings.
• Sound: Adjust audio configurations.
• Display: Change display settings.
• Bluetooth: Configure Bluetooth settings.
• Telephony: Customize telephony features.

Types of Custom System Properties

There are three common types of custom system properties in AOSP:

1. System properties added to /system/build.prop
2. System properties added to /vendor/build.prop
3. System properties added to /product/build.prop

Defining the system property

When you add a system property, decide on a name for the property, and associate it with an SELinux property context. If there’s no appropriate existing context, create a new one. The name is used when accessing the property; the property context is used to control accessibility in terms of SELinux. Names can be any string, but AOSP recommends that you follow a structured format to make them clear.

[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]

Use either “” (omitted), ro (for properties set only once), or persist (for properties that persist across reboots) for the element prefix.

Prefix: "", "ro" (read-only), or "persist" (persistent across reboots).
Example: ro.device1.test=2.0

Note: The details I will write in another article, regarding to the Property name, Property Context ,how to determine required accessibility levels, how to add it to system/sepolicy & finally find the stability requirements.

1. Adding System Properties to /system/build.prop

Let’s first look at /system/build.propsome source code related to generating files:

# build/make/core/Makefile

ifdef TARGET_SYSTEM_PROP
system_prop_file := $(TARGET_SYSTEM_PROP)
else
system_prop_file := $(wildcard $(TARGET_DEVICE_DIR)/system.prop)
endif

In the above we analyzed that the content of the system_prop_file file will eventually be written to /system/build.prop, and the value comes from TARGET_SYSTEM_PROP, so we add a property file and then modify TARGET_SYSTEM_PROPthe value of .

Steps:

1. Define system.prop File: In your custom product directory device/jelly/device1directory, create a file named system.prop with the following content:

ro.device1.test=2.0

2. Modify BoardConfig.mk: Add the path to your system.prop file in the BoardConfig.mk file:

TARGET_SYSTEM_PROP += device/jelly/device1/system.prop

3. Build the System: Rebuild the system to include the new system properties.

source build/envsetup.sh
lunch device1-eng
make -j16
emulator

4. Verify the Property: After starting the emulator, check the property value using adb shell:

adb shell
getprop ro.device1.test #end of device/jelly/device1/system.prop

# 2.0

2. Adding System Properties to /vendor/build.prop

Similarly, let’s first look at /vendor/build.propsome source code related to generating files

ifdef property_overrides_split_enabled
FINAL_VENDOR_BUILD_PROPERTIES += \
    $(call collapse-pairs, $(PRODUCT_PROPERTY_OVERRIDES))
FINAL_VENDOR_BUILD_PROPERTIES := $(call uniq-pairs-by-first-component, \
    $(FINAL_VENDOR_BUILD_PROPERTIES),=)
endif  # property_overrides_split_enabled

Here PRODUCT_PROPERTY_OVERRIDESthe value in the variable will be written to FINAL_VENDOR_BUILD_PROPERTIES. As you can see from the variable name, this is the final vendor property file, so we can add properties by modifying the value of the PRODUCT_PROPERTY_OVERRIDES variable.

Steps:

1. Modify device1.mk: Add the custom properties directly to the PRODUCT_PROPERTY_OVERRIDES variable in your device1.mk file:

# device/jelly/device1/device1.mk
PRODUCT_PROPERTY_OVERRIDES += \
    ro.vendor.xxx=xxx \
    ro.vendor.yyy=yyy

2. Build the System: Rebuild the system to include the new vendor properties.

source build/envsetup.sh
lunch device1-eng
make -j16
emulator

3. Verify the Property: After starting the emulator, check the property values using adb shell:

adb shell
getprop ro.vendor.xxx #xxx
getprop ro.vendor.yyy #yyy

3. Adding System Properties to /product/build.prop

Similarly, let’s first look at /product/build.propsome source code related to generating files:

ifdef TARGET_PRODUCT_PROP
product_prop_files := $(TARGET_PRODUCT_PROP)
else
product_prop_files := $(wildcard $(TARGET_DEVICE_DIR)/product.prop)
endif

FINAL_PRODUCT_PROPERTIES += \
    $(call collapse-pairs, $(PRODUCT_PRODUCT_PROPERTIES) $(ADDITIONAL_PRODUCT_PROPERTIES))
FINAL_PRODUCT_PROPERTIES := $(call uniq-pairs-by-first-component, \
    $(FINAL_PRODUCT_PROPERTIES),=)

You can see that product_prop_filesthe files, PRODUCT_PRODUCT_PROPERTIESvariables, and ADDITIONAL_PRODUCT_PROPERTIESvalues ​​in the variables will be written into the final properties file.

So both methods introduced in the previous two sections are acceptable.

Steps:

1. Modify device1.mk: Add the custom properties directly to the PRODUCT_PRODUCT_PROPERTIES variable in your device1.mk file:

# device/jelly/device1/device1.mk
PRODUCT_PRODUCT_PROPERTIES += \
    ro.product.xxx=xxx \
    ro.product.yyy=yyy

2. Build the System: Rebuild the system to include the new product properties.

source build/envsetup.sh
lunch device1-eng
make -j16
emulator

3. Verify the Property: After starting the emulator, check the property values using adb shell:

adb shell
getprop ro.product.xxx #xxx
getprop ro.product.yyy #yyy

Advantages of System Properties

1. Dynamic Configuration: Allows changes in system settings without recompilation.
2. Flexibility: Enables easy enable/disable features or adjust settings for testing and debugging.
3. Customization: OEMs can customize the system behavior as per their requirements.
4. Performance Tuning: Helps in adjusting system parameters for optimal performance without altering the source code.

Conclusion

System properties are a powerful feature in AOSP that allows for dynamic configuration and customization of the Android operating system. By understanding how to create and use these properties, developers and OEMs can tailor the system to their specific needs, making the development and deployment process more efficient and flexible.

For further details and deep dives, consider referencing the AOSP documentation and other related resources.