platform_build/tools/post_process_props.py

268 lines
9 KiB
Python
Raw Normal View History

#!/usr/bin/env python3
#
# Copyright (C) 2009 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import argparse
import sys
Determine GC type based on BUILT_KERNEL_VERSION_FILE. How it works: 1. build/make/core/Makefile generates a txt file with the kernel version, which is taken from an explicit BOARD_KERNEL_VERSION value, or extracted from the kernel image on the source tree, or extracted from the kernel image extracted from the prebuilt boot.img. The file is saved at $ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt. 2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to be determined by the kernel version, build/make/core/Makefile copies kernel_version.txt to out/soong/dexpreopt/kernel_version_for_uffd_gc.txt. 3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py, which reads kernel_version_for_uffd_gc.txt and determines the flag accordingly. 4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt. 5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on the same logic. Bug: 321751629 Bug: 319554951 Bug: 318763448 Bug: 319648491 Test: m --no-skip-soong-tests nothing Test: atest uffd_gc_utils_test Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no UFFD support - 1. Check the existence of `-Xgc:CMC` in out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation (dex2oat invocation for a boot image) 2. Check the existence of `-Xgc:CMC` in out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation (dex2oat invocation for an app defined in .bp) 3. Check the existence of `-Xgc:CMC` in $ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation (dex2oat invocation for an app defined in .mk) 4. Check the value of ro.dalvik.vm.enable_uffd_gc in $ANDROID_PRODUCT_OUT/product/etc/build.prop Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with UFFD support, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps above. Change-Id: I8df6e5be1644da05d2d5c57b3520f29601dfd7a4
2024-01-18 18:22:13 +01:00
from uffd_gc_utils import should_enable_uffd_gc
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
# Usage: post_process_props.py file.prop [disallowed_key, ...]
# Disallowed keys are removed from the property file, if present
# See PROP_VALUE_MAX in system_properties.h.
# The constant in system_properties.h includes the terminating NUL,
# so we decrease the value by 1 here.
PROP_VALUE_MAX = 91
# Put the modifications that you need to make into the */build.prop into this
# function.
Determine GC type based on BUILT_KERNEL_VERSION_FILE. How it works: 1. build/make/core/Makefile generates a txt file with the kernel version, which is taken from an explicit BOARD_KERNEL_VERSION value, or extracted from the kernel image on the source tree, or extracted from the kernel image extracted from the prebuilt boot.img. The file is saved at $ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt. 2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to be determined by the kernel version, build/make/core/Makefile copies kernel_version.txt to out/soong/dexpreopt/kernel_version_for_uffd_gc.txt. 3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py, which reads kernel_version_for_uffd_gc.txt and determines the flag accordingly. 4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt. 5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on the same logic. Bug: 321751629 Bug: 319554951 Bug: 318763448 Bug: 319648491 Test: m --no-skip-soong-tests nothing Test: atest uffd_gc_utils_test Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no UFFD support - 1. Check the existence of `-Xgc:CMC` in out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation (dex2oat invocation for a boot image) 2. Check the existence of `-Xgc:CMC` in out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation (dex2oat invocation for an app defined in .bp) 3. Check the existence of `-Xgc:CMC` in $ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation (dex2oat invocation for an app defined in .mk) 4. Check the value of ro.dalvik.vm.enable_uffd_gc in $ANDROID_PRODUCT_OUT/product/etc/build.prop Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with UFFD support, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps above. Change-Id: I8df6e5be1644da05d2d5c57b3520f29601dfd7a4
2024-01-18 18:22:13 +01:00
def mangle_build_prop(prop_list, kernel_version_file_for_uffd_gc):
# If ro.debuggable is 1, then enable adb on USB by default
# (this is for userdebug builds)
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
if prop_list.get_value("ro.debuggable") == "1":
val = prop_list.get_value("persist.sys.usb.config")
if "adb" not in val:
if val == "":
val = "adb"
else:
val = val + ",adb"
prop_list.put("persist.sys.usb.config", val)
Determine GC type based on BUILT_KERNEL_VERSION_FILE. How it works: 1. build/make/core/Makefile generates a txt file with the kernel version, which is taken from an explicit BOARD_KERNEL_VERSION value, or extracted from the kernel image on the source tree, or extracted from the kernel image extracted from the prebuilt boot.img. The file is saved at $ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt. 2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to be determined by the kernel version, build/make/core/Makefile copies kernel_version.txt to out/soong/dexpreopt/kernel_version_for_uffd_gc.txt. 3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py, which reads kernel_version_for_uffd_gc.txt and determines the flag accordingly. 4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt. 5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on the same logic. Bug: 321751629 Bug: 319554951 Bug: 318763448 Bug: 319648491 Test: m --no-skip-soong-tests nothing Test: atest uffd_gc_utils_test Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no UFFD support - 1. Check the existence of `-Xgc:CMC` in out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation (dex2oat invocation for a boot image) 2. Check the existence of `-Xgc:CMC` in out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation (dex2oat invocation for an app defined in .bp) 3. Check the existence of `-Xgc:CMC` in $ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation (dex2oat invocation for an app defined in .mk) 4. Check the value of ro.dalvik.vm.enable_uffd_gc in $ANDROID_PRODUCT_OUT/product/etc/build.prop Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with UFFD support, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps above. Change-Id: I8df6e5be1644da05d2d5c57b3520f29601dfd7a4
2024-01-18 18:22:13 +01:00
if prop_list.get_value("ro.dalvik.vm.enable_uffd_gc") == "default":
assert kernel_version_file_for_uffd_gc != ""
enable_uffd_gc = should_enable_uffd_gc(kernel_version_file_for_uffd_gc)
prop_list.put("ro.dalvik.vm.enable_uffd_gc",
"true" if enable_uffd_gc else "false")
def validate_grf_props(prop_list):
"""Validate GRF properties if exist.
If ro.board.first_api_level is defined, check if its value is valid.
Returns:
True if the GRF properties are valid.
"""
grf_api_level = prop_list.get_value("ro.board.first_api_level")
board_api_level = prop_list.get_value("ro.board.api_level")
if grf_api_level and board_api_level:
grf_api_level = int(grf_api_level)
board_api_level = int(board_api_level)
if board_api_level < grf_api_level:
sys.stderr.write("error: ro.board.api_level(%d) must not be less than "
"ro.board.first_api_level(%d)\n"
% (board_api_level, grf_api_level))
return False
return True
def validate(prop_list):
"""Validate the properties.
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
If the value of a sysprop exceeds the max limit (91), it's an error, unless
the sysprop is a read-only one.
Checks if there is no optional prop assignments.
Returns:
True if nothing is wrong.
"""
check_pass = True
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
for p in prop_list.get_all_props():
if len(p.value) > PROP_VALUE_MAX and not p.name.startswith("ro."):
check_pass = False
sys.stderr.write("error: %s cannot exceed %d bytes: " %
(p.name, PROP_VALUE_MAX))
sys.stderr.write("%s (%d)\n" % (p.value, len(p.value)))
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
if p.is_optional():
check_pass = False
sys.stderr.write("error: found unresolved optional prop assignment:\n")
sys.stderr.write(str(p) + "\n")
return check_pass
def override_optional_props(prop_list, allow_dup=False):
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
"""Override a?=b with a=c, if the latter exists
Overriding is done by deleting a?=b
When there are a?=b and a?=c, then only the last one survives
When there are a=b and a=c, then it's an error.
Returns:
True if the override was successful
"""
success = True
for name in prop_list.get_all_names():
props = prop_list.get_props(name)
optional_props = [p for p in props if p.is_optional()]
overriding_props = [p for p in props if not p.is_optional()]
if len(overriding_props) > 1:
# duplicated props are allowed when the all have the same value
if all(overriding_props[0].value == p.value for p in overriding_props):
for p in optional_props:
p.delete("overridden by %s" % str(overriding_props[0]))
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
continue
# or if dup is explicitly allowed for compat reason
if allow_dup:
# this could left one or more optional props unresolved.
# Convert them into non-optional because init doesn't understand ?=
# syntax
for p in optional_props:
p.optional = False
continue
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
success = False
sys.stderr.write("error: found duplicate sysprop assignments:\n")
for p in overriding_props:
sys.stderr.write("%s\n" % str(p))
elif len(overriding_props) == 1:
for p in optional_props:
p.delete("overridden by %s" % str(overriding_props[0]))
else:
if len(optional_props) > 1:
for p in optional_props[:-1]:
p.delete("overridden by %s" % str(optional_props[-1]))
# Make the last optional one as non-optional
optional_props[-1].optional = False
return success
class Prop:
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
def __init__(self, name, value, optional=False, comment=None):
self.name = name.strip()
self.value = value.strip()
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
if comment != None:
self.comments = [comment]
else:
self.comments = []
self.optional = optional
@staticmethod
def from_line(line):
line = line.rstrip('\n')
if line.startswith("#"):
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
return Prop("", "", comment=line)
elif "?=" in line:
name, value = line.split("?=", 1)
return Prop(name, value, optional=True)
elif "=" in line:
name, value = line.split("=", 1)
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
return Prop(name, value, optional=False)
else:
# don't fail on invalid line
# TODO(jiyong) make this a hard error
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
return Prop("", "", comment=line)
def is_comment(self):
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
return bool(self.comments and not self.name)
def is_optional(self):
return (not self.is_comment()) and self.optional
def make_as_comment(self):
# Prepend "#" to the last line which is the prop assignment
if not self.is_comment():
assignment = str(self).rsplit("\n", 1)[-1]
self.comments.append("#" + assignment)
self.name = ""
self.value = ""
def delete(self, reason):
self.comments.append("# Removed by post_process_props.py because " + reason)
self.make_as_comment()
def __str__(self):
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
assignment = []
if not self.is_comment():
operator = "?=" if self.is_optional() else "="
assignment.append(self.name + operator + self.value)
return "\n".join(self.comments + assignment)
class PropList:
def __init__(self, filename):
with open(filename) as f:
self.props = [Prop.from_line(l)
for l in f.readlines() if l.strip() != ""]
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
def get_all_props(self):
return [p for p in self.props if not p.is_comment()]
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
def get_all_names(self):
return set([p.name for p in self.get_all_props()])
def get_props(self, name):
return [p for p in self.get_all_props() if p.name == name]
def get_value(self, name):
# Caution: only the value of the first sysprop having the name is returned.
return next((p.value for p in self.props if p.name == name), "")
def put(self, name, value):
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
# Note: when there is an optional prop for the name, its value isn't changed.
# Instead a new non-optional prop is appended, which will override the
# optional prop. Otherwise, the new value might be overridden by an existing
# non-optional prop of the same name.
index = next((i for i,p in enumerate(self.props)
if p.name == name and not p.is_optional()), -1)
if index == -1:
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
self.props.append(Prop(name, value,
comment="# Auto-added by post_process_props.py"))
else:
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
self.props[index].comments.append(
"# Value overridden by post_process_props.py. Original value: %s" %
self.props[index].value)
self.props[index].value = value
def write(self, filename):
with open(filename, 'w+') as f:
for p in self.props:
f.write(str(p) + "\n")
def main(argv):
parser = argparse.ArgumentParser(description="Post-process build.prop file")
parser.add_argument("--allow-dup", dest="allow_dup", action="store_true",
default=False)
parser.add_argument("filename")
parser.add_argument("disallowed_keys", metavar="KEY", type=str, nargs="*")
parser.add_argument("--sdk-version", type=int, required=True)
Determine GC type based on BUILT_KERNEL_VERSION_FILE. How it works: 1. build/make/core/Makefile generates a txt file with the kernel version, which is taken from an explicit BOARD_KERNEL_VERSION value, or extracted from the kernel image on the source tree, or extracted from the kernel image extracted from the prebuilt boot.img. The file is saved at $ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt. 2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to be determined by the kernel version, build/make/core/Makefile copies kernel_version.txt to out/soong/dexpreopt/kernel_version_for_uffd_gc.txt. 3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py, which reads kernel_version_for_uffd_gc.txt and determines the flag accordingly. 4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt. 5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on the same logic. Bug: 321751629 Bug: 319554951 Bug: 318763448 Bug: 319648491 Test: m --no-skip-soong-tests nothing Test: atest uffd_gc_utils_test Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no UFFD support - 1. Check the existence of `-Xgc:CMC` in out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation (dex2oat invocation for a boot image) 2. Check the existence of `-Xgc:CMC` in out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation (dex2oat invocation for an app defined in .bp) 3. Check the existence of `-Xgc:CMC` in $ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation (dex2oat invocation for an app defined in .mk) 4. Check the value of ro.dalvik.vm.enable_uffd_gc in $ANDROID_PRODUCT_OUT/product/etc/build.prop Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with UFFD support, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps above. Change-Id: I8df6e5be1644da05d2d5c57b3520f29601dfd7a4
2024-01-18 18:22:13 +01:00
parser.add_argument("--kernel-version-file-for-uffd-gc", required=True)
args = parser.parse_args()
if not args.filename.endswith("/build.prop"):
sys.stderr.write("bad command line: " + str(argv) + "\n")
sys.exit(1)
props = PropList(args.filename)
Determine GC type based on BUILT_KERNEL_VERSION_FILE. How it works: 1. build/make/core/Makefile generates a txt file with the kernel version, which is taken from an explicit BOARD_KERNEL_VERSION value, or extracted from the kernel image on the source tree, or extracted from the kernel image extracted from the prebuilt boot.img. The file is saved at $ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt. 2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to be determined by the kernel version, build/make/core/Makefile copies kernel_version.txt to out/soong/dexpreopt/kernel_version_for_uffd_gc.txt. 3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py, which reads kernel_version_for_uffd_gc.txt and determines the flag accordingly. 4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt. 5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on the same logic. Bug: 321751629 Bug: 319554951 Bug: 318763448 Bug: 319648491 Test: m --no-skip-soong-tests nothing Test: atest uffd_gc_utils_test Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no UFFD support - 1. Check the existence of `-Xgc:CMC` in out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation (dex2oat invocation for a boot image) 2. Check the existence of `-Xgc:CMC` in out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation (dex2oat invocation for an app defined in .bp) 3. Check the existence of `-Xgc:CMC` in $ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation (dex2oat invocation for an app defined in .mk) 4. Check the value of ro.dalvik.vm.enable_uffd_gc in $ANDROID_PRODUCT_OUT/product/etc/build.prop Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with UFFD support, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps above. Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps above. Change-Id: I8df6e5be1644da05d2d5c57b3520f29601dfd7a4
2024-01-18 18:22:13 +01:00
mangle_build_prop(props, args.kernel_version_file_for_uffd_gc)
if not override_optional_props(props, args.allow_dup):
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
sys.exit(1)
if not validate_grf_props(props):
sys.exit(1)
if not validate(props):
sys.exit(1)
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
# Drop any disallowed keys
for key in args.disallowed_keys:
Support optional prop assignments This CL adds a number of changes to make the assignment of system properties to be less confusing. 1. Added `a ?= b` syntax, which is called optional prop assignments. The prop `a` gets the value `b` only when there is no non-optional prop assignment for `a` such as `a = c`. This is useful for props that provide some reasonable default values as fallback. 2. With the introduction of the optional prop assignment syntax, duplicated non-optional assignments is prohibited; e.g., the follwing now triggers a build-time error: a = b a = c , but the following doesn't: a ?= b a = c Note that the textual order between the optional and non-optional assignments doesn't matter. The non-optional assignment eclipses the optional assignment even when the former appears 'before' the latter. a = c a ?= b In the above, `a` gets the value `c` When there are multiple optional assignments without a non-optional assignments as shown below, the last one wins: a ?= b a ?= c `a` becomes `c`. Specifically, the former assignment is commented out and the latter is converted to a non-optional assignment. 3. post_process_props.py is modified so that when a prop assignment is deleted, changed, or added, the changes are recorded as comments. This is to aid debugging. Previously, it was often difficult to find out why a certain sysprop assignment is missing or is added. 4. post_process_prop.py now has a unittest Bug: 117892318 Bug: 158735147 Test: atest --host post_process_prop_unittest Exempt-From-Owner-Approval: cherry-pick from master Merged-In: I9c073a21c8257987cf2378012cadaeeeb698a4fb (cherry picked from commit 7aeb8de74e08eb2d305686aa8eff45353973e7d7) Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-22 10:30:57 +02:00
for p in props.get_props(key):
p.delete("%s is a disallowed key" % key)
props.write(args.filename)
if __name__ == "__main__":
main(sys.argv)