Commit graph

6 commits

Author SHA1 Message Date
Justin Yun
870ea2e188 Allow setting future api level before REL
At the dev stage, devices may set ro.board.(first_)api_level to the
future API level

Bug: 276927022
Test: test_post_process_props.py
Change-Id: I85c29af74ed8daa780278f64b023480bb6659781
2023-04-10 15:37:19 +09:00
Justin Yun
48aa78ed3c Remove grf_required_api_level
As we don't fix the grf window, we may not calculate the grf
expiration date and the required api level.
The verification of this will be covered by the tests at run time.

Bug: 176950752
Test: atest --host post_process_props_unittest
Change-Id: I1205f0d9a9da5bc508a49acbcbb7da581800bf45
2021-04-13 17:58:59 +09:00
Justin Yun
07ceaa71c1 Use BOARD_API_LEVEL to define ro.board.api_level
GRF devices must define the API level of which the SoC is first
shipped by setting BOARD_SHIPPING_API_LEVEL. As this is a permanent
value, vendors may not change this value even if they implement new
features under the GRF policy.

BOARD_API_LEVEL can be optionally defined in this case to manually
set the api level of the vendor implementation.
The current api level will be set to `ro.board.api_level` property.

Bug: 176950752
Test: atest --host post_process_props_unittest
Change-Id: Ib126c1a622ded9848650f3f60c0f15005867272d
2021-04-06 16:33:07 +09:00
Jiyong Park
24d9cad563 Handle the case when non-optional props have the same value
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
2020-06-30 18:44:51 +09:00
Jiyong Park
0b4fccb66d BUILD_BROKEN_DUP_SYSPROP as escape hatch for the new sysprop restriction
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
2020-06-30 18:44:40 +09:00
Jiyong Park
d721e870bc 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 7aeb8de74e)
Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
2020-06-30 18:44:01 +09:00