foo=true
foo=true
foo?=false
Consider the above case: Then the duplication of foo is allowed because
they have the same value (true). However, there was a bug that the
optional assirgnment foo?=false is left unmodified.
This fixes the bug by commenting such optional assignments.
Exempt-From-Owner-Approval: fixes a broken build
Bug: 117892318
Bug: 158735147
Test: atest test_post_process_props
Test: m out/target/product/vsoc_x86/vendor/build.prop for cf_x86_auto
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: Iba9b61d9779d93e86d9bead2286f945f8d51ab1d
(cherry picked from commit 9a32636759)
Change-Id: Iba9b61d9779d93e86d9bead2286f945f8d51ab1d
As the final step for the refactoring of sysprop configuration, this
change adds BUILD_BROKEN_DUP_SYSPROP which is the escape hatch for
the new restriction. When it is turned on, the new syntax `a ?= b`
collapses to the old syntax `a = b`, duplicated assignments are allowed,
and the dups are resolved following the legacy rule of preferring the
first.
This change also summarizes all the user-facing changes to the Change.md
file.
Lastly, post_process_prop.py is refactored to accept new argument
'--allow-dup' which when turned on allowes duplicated sysprops.
Bug: 117892318
Bug: 158735147
Test: atest --host post_process_prop_unittest
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: I7bdfffd47d50aad66a78e28a30c3dad7ebac080c
(cherry picked from commit b302cdf6a4)
Change-Id: I7bdfffd47d50aad66a78e28a30c3dad7ebac080c
The mk file is designed to provide safe default values which can be
overridden by target-specific mk files. Previously it was difficult to
correctly configure the mk files because the final prop value that
is baked in the system/build.prop is highly dependent (and sensitive as
well) to the mk file inheritance order which is very difficult (and
non-intuitive) to follow.
I9c073a21c8257987cf2378012cadaeeeb698a4fb is an attempt to make it much
easier and intuitive. Specifically, the new `a ?= b` syntax makes the
assignment optional, which means it is used only when there is no
non-optional assignment for the same prop regardless of the relative
ordering among them. In addition, the change prohibits having multiple
non-optional prop assignments for the same prop name.
pm.dex.* prop in runtime_libart.mk are now set using the `a ?= b` syntax
to explicitly mark that they provide default values.
Bug: 117892318
Bug: 158735147
Test: m
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: I044486d313d699607cd54222ae34d9eae24762b9
(cherry picked from commit bca4ea477a)
Change-Id: I044486d313d699607cd54222ae34d9eae24762b9
Some properties that are designed to provide a safe default value are
explicitly set as optional using the 'a ?= b' syntax.
Bug: 117892318
Bug: 158735147
Test: m
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: Ie6a50ab7e0bcb210e282bc18e8c1daf412903f90
(cherry picked from commit dfb3937ce4)
Change-Id: Ie6a50ab7e0bcb210e282bc18e8c1daf412903f90
The setting of ro.zygote in base_system.mk is optional, which means the
value can be overriden by other (probably more specific) mk files.
Bug: 117892318
Bug: 158735147
Test: atest --host post_process_prop_unittest
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: Ia7a67c0a04fad343d6591417f40dd4b9ddadc5e4
(cherry picked from commit b1261aac33)
Change-Id: Ia7a67c0a04fad343d6591417f40dd4b9ddadc5e4
GSI and emulator should not be specialized for tablet.
This is also to avoid the expected sysprop conflict after
I9c073a21c8257987cf2378012cadaeeeb698a4fb gets in. With the change,
duplicate assignments of a sysprop is prohibited. We currently have the
duplication due to the following hierarchy chain:
aosp_arm64.mk
-> emulator_vendor.mk -> goldfish/vendor.mk -> phone-xhdpi-2048-dalvik-heap.mk
-> generic_arm64/device.mk -> tablet-dalvik-heap.mk
Many of the dalvik.vm.* properties are duplicated between phone-*-
dalvik-heap.mk and tablet-dalvik-heap.mk files.
Bug: 117892318
Bug: 158735147
Test: atest --host post_process_prop_unittest
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: I4d1e2f819fe688a4a85e58387b6af58d603399d3
(cherry picked from commit 9f2f6dd9c9)
Change-Id: I4d1e2f819fe688a4a85e58387b6af58d603399d3
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 7aeb8de74e)
Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
foo=true
foo=true
foo?=false
Consider the above case: Then the duplication of foo is allowed because
they have the same value (true). However, there was a bug that the
optional assirgnment foo?=false is left unmodified.
This fixes the bug by commenting such optional assignments.
Exempt-From-Owner-Approval: fixes a broken build
Bug: 117892318
Bug: 158735147
Test: atest test_post_process_props
Test: m out/target/product/vsoc_x86/vendor/build.prop for cf_x86_auto
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: Iba9b61d9779d93e86d9bead2286f945f8d51ab1d
(cherry picked from commit 9a32636759)
Change-Id: Iba9b61d9779d93e86d9bead2286f945f8d51ab1d
As the final step for the refactoring of sysprop configuration, this
change adds BUILD_BROKEN_DUP_SYSPROP which is the escape hatch for
the new restriction. When it is turned on, the new syntax `a ?= b`
collapses to the old syntax `a = b`, duplicated assignments are allowed,
and the dups are resolved following the legacy rule of preferring the
first.
This change also summarizes all the user-facing changes to the Change.md
file.
Lastly, post_process_prop.py is refactored to accept new argument
'--allow-dup' which when turned on allowes duplicated sysprops.
Bug: 117892318
Bug: 158735147
Test: atest --host post_process_prop_unittest
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: I7bdfffd47d50aad66a78e28a30c3dad7ebac080c
(cherry picked from commit b302cdf6a4)
Change-Id: I7bdfffd47d50aad66a78e28a30c3dad7ebac080c
The mk file is designed to provide safe default values which can be
overridden by target-specific mk files. Previously it was difficult to
correctly configure the mk files because the final prop value that
is baked in the system/build.prop is highly dependent (and sensitive as
well) to the mk file inheritance order which is very difficult (and
non-intuitive) to follow.
I9c073a21c8257987cf2378012cadaeeeb698a4fb is an attempt to make it much
easier and intuitive. Specifically, the new `a ?= b` syntax makes the
assignment optional, which means it is used only when there is no
non-optional assignment for the same prop regardless of the relative
ordering among them. In addition, the change prohibits having multiple
non-optional prop assignments for the same prop name.
pm.dex.* prop in runtime_libart.mk are now set using the `a ?= b` syntax
to explicitly mark that they provide default values.
Bug: 117892318
Bug: 158735147
Test: m
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: I044486d313d699607cd54222ae34d9eae24762b9
(cherry picked from commit bca4ea477a)
Change-Id: I044486d313d699607cd54222ae34d9eae24762b9
Some properties that are designed to provide a safe default value are
explicitly set as optional using the 'a ?= b' syntax.
Bug: 117892318
Bug: 158735147
Test: m
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: Ie6a50ab7e0bcb210e282bc18e8c1daf412903f90
(cherry picked from commit dfb3937ce4)
Change-Id: Ie6a50ab7e0bcb210e282bc18e8c1daf412903f90
The setting of ro.zygote in base_system.mk is optional, which means the
value can be overriden by other (probably more specific) mk files.
Bug: 117892318
Bug: 158735147
Test: atest --host post_process_prop_unittest
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: Ia7a67c0a04fad343d6591417f40dd4b9ddadc5e4
(cherry picked from commit b1261aac33)
Change-Id: Ia7a67c0a04fad343d6591417f40dd4b9ddadc5e4
GSI and emulator should not be specialized for tablet.
This is also to avoid the expected sysprop conflict after
I9c073a21c8257987cf2378012cadaeeeb698a4fb gets in. With the change,
duplicate assignments of a sysprop is prohibited. We currently have the
duplication due to the following hierarchy chain:
aosp_arm64.mk
-> emulator_vendor.mk -> goldfish/vendor.mk -> phone-xhdpi-2048-dalvik-heap.mk
-> generic_arm64/device.mk -> tablet-dalvik-heap.mk
Many of the dalvik.vm.* properties are duplicated between phone-*-
dalvik-heap.mk and tablet-dalvik-heap.mk files.
Bug: 117892318
Bug: 158735147
Test: atest --host post_process_prop_unittest
Exempt-From-Owner-Approval: cherry-pick from master
Merged-In: I4d1e2f819fe688a4a85e58387b6af58d603399d3
(cherry picked from commit 9f2f6dd9c9)
Change-Id: I4d1e2f819fe688a4a85e58387b6af58d603399d3
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 7aeb8de74e)
Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
This is used when Soong and Make don't know the full output file list,
and so use a tool to generate a per-module apkcerts.txt file instead.
Fixes: 160119159
Test: m apkcerts-list
Change-Id: I48183bc8cbf9dcc521f791812734205ed3f28f4c
