Incremental OTA generation was failing since the
function _CheckSecondTokenNotSlotSuffixed was in
broken state, this change fixes the same.
Bug: 160215626
Test: Incremental OTA now gets generated and applied
successfully a non-ab device.
Change-Id: Ifb3886396fe65dcdaeba16c568419b9fa084193d
Merged-In: Ifb3886396fe65dcdaeba16c568419b9fa084193d
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
add_img_to_target_files.py
See bug description:
"When resigning images, the validate_target_files.py can be used to
verify the images using avbtool. The script will use the vbmeta.img to
achieve this, and all relevant images need to be in the IMAGES folder.
However, due to changes on add_img_to_target_files.py and specifically
the commit 5277d1015, some images (e.g. acpio.img and tos.img) are no
longer copied from RADIO to the IMAGES folder. This causes an error on
validate_target_files.py indicating that it cannot find image such as
IMAGES/acpio.img."
This CL fixes this by symlink images under RADIO directory to IMAGES
directory before invoking avbtool.
Bug: 159299583
Test: python3 -m unittest test_validate_target_files
Change-Id: I5769ee2ab5230d2a3a7cef10706dcc5788e654f8
If multiple kernels are defined for a build, use the first one when
generating the kernel config file.
Bug: 159975506
Change-Id: Ia136264eb0d0b544bf0685bc22e600de187a9a9b
* As a side product .strip() calls in releasetools are redunant,
but since these scripts are also used out of tree we can't
remove them to guarantee compatibility
Test: m dist
Change-Id: I5c513a4654e293c3d4eab98c8759ea094015fab1
Starting from http://go/aog/1328118, we chained the 1st GKI
boot image into vbmeta. However, this fails avb validation;
because the avbtool constructs the image path based by using
"partition name + ext".
This cl works around the issue by renaming boot-5.4.img to
boot.img, so avbtool can find the image correctly.
Bug: 159656873
Test: run validate target file
Change-Id: I577226596e139e5b5f3e6ca3c28ced02431ca392
build.prop for the ODM partition should be placed under ./etc directory
to support GSI. For detailed reasons, see
I0733c277baa67c549bb45599abb70aba13fbdbcf
The path was changed to /odm/build.prop during the recent refactoring
around build.prop filems and this change fixes the mistake.
Bug: 132128501
Test: check if odm/etc/build.prop is created
Change-Id: Icc2c564250aa08786f32294a839cc81e86b7d368
If the BoardConfig defined BOARD_VENDOR_KERNEL_MODULES_LOAD and
BOARD_VENDOR_CHARGER_KERNEL_MODULES_LOAD, generate both a
modules.load and modules.load.charger respectively on
/vendor/lib/modules.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 159424228
Bug: 151950334
Test: build, confirm, change to charger mode, confirm set of modules loads
Change-Id: I55677ed74d80ff3909fe8cbe26e6766f9b5283d5
This script belongs with other manifest-related scripts, and the future
plan is to rewrite it in Python and share common functionality with
other scripts.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I4b90129e5023ca1a2c818fc160c34b0b7da943ef
A call to lz4 was added in http://go/aog/1329115. But the binary
isn't added to otatools, leading to a signing failure.
Bug: 159656873
Test: build otatools
Change-Id: I9cab00f36ce3c39cc174b4c9feffdf360f0364ef
Add select-bitness-of-target-host-required-modules that resolves module
bitness for TARGET_REQUIRED_FROM_HOST and HOST_REQUIRED_FROM_TARGET.
Also re-indent select-bitness-of-required-modules.
Bug: 7456955
Test: TH
Test: compare value of ALL_MODULES.<*>.*_REQUIRED_FROM_*
Change-Id: I9483685d8dd528cb1a4ef1e2ec53cbe2caa598a4
Virtually nothing uses libunwind, and no one should start using it, so
it's unlikely to be critical.
(Code should use libunwindstack.so to collect backtraces, and it should
use libc.so's _Unwind_* APIs for C++ exception handling unwinding.)
Test: build Android
Change-Id: I81882a4634ff4d397abe8a7cf5ff15a22a3eed2f
Merged-In: I81882a4634ff4d397abe8a7cf5ff15a22a3eed2f
(cherry picked from commit 9355aeba79)
The extension for the generated vendor ramdisk should be updated based
on the compression scheme used.
Bug: 158433703
Change-Id: I25fff0b8a7879f6aa6d6fe2fce9f5a53f90eb636
Protect against an invalid boot jar, e.g. one containing .dex files is
used instead of .class files.
Test: add a prebuilt for framework-tethering
Run `m check-boot-jars` with the first fix from
https://r.android.com/1341756 and the build fails due to no
.class files because a dex jar is used.
Run `m check-boot-jars` with all fixeds from
https://r.android.com/1341756 and the build works.
Bug: 158304459
Bug: 159112414
Merged-In: I0e8ebd318312949bc58ba7a5c89f9e265b8bedf2
Change-Id: I0e8ebd318312949bc58ba7a5c89f9e265b8bedf2
(cherry picked from 92d41de8f2)
