Foreword
In the Android build system, there are some mechanisms and tools that can help us customize and optimize source code, such as:
- overlay: This is a mechanism for modifying or replacing system resources such as strings, icons, layouts, etc. System resources can be customized and optimized without modifying the source code.
Android source code customization: remove useless lunch | create new lunch | customize customize.mk
Android source code customization: MK file execution sequence | attribute override
In this article, the basic concepts and usage of these mechanisms and tools will be introduced, and some examples will be used to show how to use them to customize and optimize Android source code. We’ll also cover how to debug whether our modifications are taking effect, and how to view the details of our modifications.
1. How to customize the overlay directory
In Android, overlay is a mechanism used to modify or replace system resources (such as strings, icons, layouts, etc.). Overlay can customize and optimize system resources without modifying the source code. Overlays are usually located in device-related or manufacturer-related directories, such as:
device/rockchip/common/overlay
vendor/customize/rk3568_s_beta/overlay
(This is a customized directory)
When the build system generates a system image, it will select the corresponding overlay directory according to different target platforms and products, and add it to the DEVICE_PACKAGE_OVERLAYS
variable. This variable is used to specify which directories contain overlay resources.
# This is the system default DEVICE_PACKAGE_OVERLAYS + = device/rockchip/common/overlay
Because my customize.mk
is included by device/rockchip/rk356x/device.mk
, so I tested it in vendor/customize/customize.mk The result of printing
is $(LOCAL_PATH)
in device/rockchip/rk356x
. If you want to use $(LOCAL_PATH)
and make sure it points to the correct directory, you need to make sure no other Makefile modifies it before trying to access it, and that you call vendor/customize/customize directly from the build system .mk
instead of including it from another Makefile.
So customize a variable MY_CUSTOM_PATH := $(TOP)/vendor/customize
and print it out as ./vendor/customize
MY_CUSTOM_PATH := $(TOP)/vendor/customize $(warning Enter $(MY_CUSTOM_PATH)/rk3568_s_beta) # This sentence means to load the overlay path of the current device manufacturer./vendor/customize/rk3568_s_beta/overlay DEVICE_PACKAGE_OVERLAYS + = $(MY_CUSTOM_PATH)/rk3568_s_beta/overlay
In this way, when make
is executed, the build system will add this directory to the search path for overlay resources.
When a system resource is modified or replaced in multiple overlay directories, they may conflict and overwrite. To avoid this situation, Android’s build system provides some rules and tools to check and handle resource conflicts and overrides.
The overwriting order of resources is determined by the directory order specified in the DEVICE_PACKAGE_OVERLAYS
variable. That is to say, the directory specified later will overwrite the resources of the same name and type in the directory specified earlier.
- Let’s test it. For example, the system SettingsProvider is called
def_bluetooth_on
, which is used to specify whether Bluetooth is turned on by default. It is defined and assigned in the following places:
# This is in the system source code directory ln28@ln28-pc:~/sourcecode/rk_android12.0_sdk/frameworks/base/packages/SettingsProvider$ grep -rn "def_bluetooth_on" src/com/android/providers/settings/DatabaseHelper.java:2476: R.bool.def_bluetooth_on); res/values/defaults.xml:39: <bool name="def_bluetooth_on">true</bool> #Default overlay part of source code: ln28@ln28-pc:~/sourcecode/rk_android12.0_sdk/device/rockchip$ grep -rn "def_bluetooth_on" common/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml:22: <bool name="def_bluetooth_on">false</bool> common/overlay_go/frameworks/base/packages/SettingsProvider/res/values/defaults.xml:26: <bool name="def_bluetooth_on">false</bool> rk356x/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml:26: <bool name="def_bluetooth_on">false</bool> # Customize the overlay part. I clearly wrote true here, but I compiled and tested and found that Bluetooth is still not turned on by default. ln28@ln28-pc:~/sourcecode/rk_android12.0_sdk/vendor/customize$ grep -rn "def_bluetooth_on" rk3568_s_beta/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml:27: <bool name="def_bluetooth_on">true</bool>
I suspect it’s because there are several overlays. Suspicious points: One is device/rockchip/
common/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml, the second is /vendor/customize/
rk3568_s_beta/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml
- In the
device/rockchip/common/overlay
directory, there is a resource file calleddefaults.xml
, which is used to modify or replace system resources. It modifies the value ofdef_bluetooth_on
tofalse
in the following places:
device/rockchip/common/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml:22: <bool name="def_bluetooth_on">false</bool>
- In the
vendor/customize/rk3568_s_beta/overlay
directory, I customized the overlay directory. There is also a resource file calleddefaults.xml
, which is used to modify or replace system resources. It modifies the value ofdef_bluetooth_on
totrue
in the following places:
rk3568_s_beta/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml:27: <bool name="def_bluetooth_on">true</bool>
My initial understanding is that when executing
make
, the build system will add the above directories to the search path for overlay resources, and follow them in theDEVICE_PACKAGE_OVERLAYS
variable The order in which resource coverage is handled. Becausedevice/rockchip/common/overlay
is specified first, and thenvendor/customize/rk3568_s_beta/overlay
is specified, the latter will overwrite resources with the same name and type in the former. . In other words, in the final generated system image, the value ofdef_bluetooth_on
will be set to true, but the result will still be false. . .
The actual test later is not the same as the understanding at all, so I plan to comment out the original overlay directory in the system manufacturer directory and only use the customized overlay directory.
+ + + b/device/rockchip/rk356x/rk3568_s/rk3568_s.mk @@ -13,7 + 13,12 @@ # See the License for the specific language governing permissions and # limitations under the License. # # First lunching is S, api_level is 31 PRODUCT_SHIPPING_API_LEVEL := 31 PRODUCT_DTBO_TEMPLATE := $(LOCAL_PATH)/dt-overlay.in @@ -26,7 + 31,7 @@ $(call inherit-product, device/rockchip/rk356x/device.mk) $(call inherit-product, device/rockchip/common/device.mk) $(call inherit-product, frameworks/native/build/tablet-10in-xhdpi-2048-dalvik-heap.mk) -DEVICE_PACKAGE_OVERLAYS + = $(LOCAL_PATH)/../overlay + #DEVICE_PACKAGE_OVERLAYS + = $(LOCAL_PATH)/../overlay PRODUCT_CHARACTERISTICS := tablet ln28@ln28-pc:~/sourcecode/rk_android12.0_sdk$ git diff device/rockchip/common/BoardConfig.mk diff --git a/device/rockchip/common/BoardConfig.mk b/device/rockchip/common/BoardConfig.mk index 4724a3bd46..d164031bf5 100755 --- a/device/rockchip/common/BoardConfig.mk + + + b/device/rockchip/common/BoardConfig.mk @@ -199,12 + 199,12 @@ VENDOR_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH) TARGET_BOOTLOADER_BOARD_NAME ?= rk30sdk TARGET_NO_BOOTLOADER ?= true -ifeq ($(filter atv box, $(strip $(TARGET_BOARD_PLATFORM_PRODUCT))), ) -DEVICE_PACKAGE_OVERLAYS + = device/rockchip/common/overlay -ifneq ($(BOARD_HAS_RK_4G_MODEM), true) -DEVICE_PACKAGE_OVERLAYS + = device/rockchip/common/overlay_wifi_only -endif -endif + #ifeq ($(filter atv box, $(strip $(TARGET_BOARD_PLATFORM_PRODUCT))), ) + #DEVICE_PACKAGE_OVERLAYS + = device/rockchip/common/overlay + #ifneq ($(BOARD_HAS_RK_4G_MODEM), true) + #DEVICE_PACKAGE_OVERLAYS + = device/rockchip/common/overlay_wifi_only + #endif + #endif
2. Debug whether the overlay resource is effective
After we modify or replace system resources, we may want to verify whether our modifications are correctly applied to the system image. In order to quickly debug this, you can use some tools to view the resource information in the system image and compare whether they are consistent with our overlay resources.
A commonly used tool is aapt
, which is a command line tool for processing Android application packages. It can be used to view, add, delete or modify resources and metadata in the APK. You can use aapt
to view the resource information in an APK file in the system image, for example:
aapt d resources out/target/product/rk3568_s/system/priv-app/SettingsProvider/SettingsProvider.apk
This command will print out all resource information in SettingsProvider.apk
, including resource name, ID, type, value, size, reference, etc. If we want to view a specific resource, we can use the grep
command to filter the output, for example:
aapt d resources out/target/product/rk3568_s/system/priv-app/SettingsProvider/SettingsProvider.apk | grep def_bluetooth_on
This command will print out resource information related to def_bluetooth_on
, for example:
ln28@ln28-pc:~/sourcecode/rk_android12.0_sdk$ aapt d resources out/target/product/rk3568_s/system/priv-app/SettingsProvider/SettingsProvider.apk | grep def_bluetooth_on spec resource 0x7f02000d com.android.providers.settings:bool/def_bluetooth_on: flags=0x00000000 resource 0x7f02000d com.android.providers.settings:bool/def_bluetooth_on: t=0x12 d=0xffffffff (s=0x0008 r=0x00)
This output indicates that def_bluetooth_on
is a Boolean resource with a value of true
(0xffffffff). You can use this output to determine whether our overlay resource is effective.
Modify def_bluetooth_on
in vendor\customize\rk3568_s_beta\overlay\frameworks\base\packages\SettingsProvider\res\values\defaults.xml
to
After compiling you see the following output:
ln28@ln28-pc:~/sourcecode/rk_android12.0_sdk$ aapt d resources out/target/product/rk3568_s/system/priv-app/SettingsProvider/SettingsProvider.apk | grep def_bluetooth_on spec resource 0x7f02000d com.android.providers.settings:bool/def_bluetooth_on: flags=0x00000000 resource 0x7f02000d com.android.providers.settings:bool/def_bluetooth_on: t=0x12 d=0xffffffff (s=0x0008 r=0x00)
This means that our overlay resources have taken effect. In the end, I also found in actual testing that Bluetooth is turned on by default when booting.
Modify def_bluetooth_on
in vendor\customize\rk3568_s_beta\overlay\frameworks\base\packages\SettingsProvider\res\values\defaults.xml
to
ln28@ln28-pc:~/sourcecode/rk_android12.0_sdk$ aapt d resources out/target/product/rk3568_s/system/priv-app/SettingsProvider/SettingsProvider.apk | grep def_bluetooth_on spec resource 0x7f02000d com.android.providers.settings:bool/def_bluetooth_on: flags=0x00000000 resource 0x7f02000d com.android.providers.settings:bool/def_bluetooth_on: t=0x12 d=0x00000000 (s=0x0008 r=0x00)
Then it means that the overlay resource is effective, but the result is that def_bluetooth_on
is turned off.
In order to easily compare resource information under different overlay settings, a table is used to display it for easy comparison:
Resource name | Resource ID | Type | Value | Size | Resource reference |
---|---|---|---|---|---|
com.android.providers.settings:bool/def_bluetooth_on(overlay set to true) | 0x7f02000d | bool | 0xffffffff (true) | 0x0008 | 0x00 |
com.android.providers.settings:bool/def_bluetooth_on(overlay set to false) | 0x7f02000d | bool | 0x00000000 (false) | 0x0008 | 0x00 |
0xffffffff
usually meanstrue
in this context.0x00000000
meansfalse
.r=0x00
: This is a reference to the resource. In this case it is 0, which means the resource does not reference other resources.
Test
Added in vendor\customize\rk3568_s_beta\overlay\frameworks\base\packages\SettingsProvider\res\values\defaults.xml
. This purpose is to turn on wifi, Bluetooth, and default backlight 244 by default.
<resources> <bool name="def_wifi_on">true</bool> <bool name="def_bluetooth_on">true</bool> <integer name="def_screen_brightness">244</integer> </resources>
Add default_wallpaper.png
to vendor\customize\rk3568_s_beta\overlay\frameworks\base\core\res\res\drawable-sw720dp-nodpi
. This purpose is to overlay the desktop wallpaper. .
OK, the compilation and burning test results are the same as before burning. This is because I know the burning results through aapt
after compilation, and I no longer have to worry about the system’s default overlay overwriting. The code change is confusing.
Summary
This article introduces some mechanisms and tools for Android source code customization, including:
- overlay: Introduces the concept and directory structure of overlay, and how to customize overlay directories and resources.
- Debugging Tools: Introduces the use of the
aapt
tool and how to view resource information in the system image.
I hope this article can be helpful to you. If you have any questions or suggestions, please leave a message in the comment area. Thanks!