ro.product.first_api_level looks like the value we actually want to read
to since it inherits from $PRODUCT_SHIPPING_API_LEVEL. Other variables
we attempted to look at were giving other values (e.g 202504 for pixel
watch)
Bug: 331202590
Test: th
Change-Id: Ied3da247cba45611132db6c9e3cdefb447891f96
This reverts commit 35839ec1a3.
Reason for revert: CI breakages for 2 targets. Please refer to bug for more details
Bug: 334152807
Change-Id: I0e38583cd3fa57afef432406374ec8d4ddc57e72
This reverts commit 1c4c94d784.
Reason for revert: CI breakages for 2 targets. Please refer to bug for more details
Bug: 334152807
Change-Id: I76853ccfd8a41f99670a7b7513f358f076f9b271
This reverts commit 39dcf40403.
Reason for revert: CI breakages for 2 targets. Please refer to bug for more details
Bug: 334152807
Change-Id: Ic2fc942b1769aed03553fc305ac283666eb9e3f5
`PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO` overrides
`TARGET_NO_BIONIC_PAGE_SIZE_MACRO` value in the build system. Enabling
TARGET_NO_BIONIC_PAGE_SIZE_MACRO implies those targets no longer rely
on the `PAGE_SIZE` bionic macro. Page size would be queried at runtime
using getpagesize() / sysconf(_SC_PAGE_SIZE).
Bug: 310232825
Test: lunch <target> && get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
Change-Id: I37133cb2419566e9616a2cde640372352178980f
This updates the VSR_VENDOR_API_LEVEL for which
TARGET_NO_BIONIC_PAGE_SIZE_MACRO is set to false from < 34 to < 35
Bug: 310232825
Test: lunch <target> && get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
Change-Id: Ib6b8ba94fe6b2c8b7bbf31fb56e07bd97eb79fc2
Currently flag info query api is called get_boolean_flag_attribute, in
this change, we switched it over to a flag value type generic
implementation get_flag_attribute. So in the future we want to add more flag value types, this api can stay the same.
Bug: b/312444587
Test: atest -c
Change-Id: I2b272f3fa3cb1d0edc8b77a44bf37752ffe95925
Add keys to the dict `partitions` in serial to have a deterministic
insertion order.
This guarantees the generated vbmeta.img is always the same on the same
input, fixing image consistency issues.
Reference:
https://android-review.googlesource.com/c/platform/build/+/2585397
Bug: 332550989
Test: Generate vbmeta several times, confirm identical result.
Change-Id: I39da5844045f497fdc89e6477a7e32ddacb70764
`PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO` overrides
`TARGET_NO_BIONIC_PAGE_SIZE_MACRO` value in the build system. Enabling
TARGET_NO_BIONIC_PAGE_SIZE_MACRO implies those targets no longer rely
on the `PAGE_SIZE` bionic macro. Page size would be queried at runtime
using getpagesize() / sysconf(_SC_PAGE_SIZE).
Bug: 310232825
Bug: 333124272
Test: lunch <target> && get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
Change-Id: I1786c735eb2ba2ede70e1432f1854694c5831a01
expose the flag to soong. the flag is to indicate a custom VM can
use para-virtualized devices.
Bug: 333495394
Test: build
Change-Id: I4e1854b5701302ae0ec1bf73862f264642b6e418
* changes:
aconfig: update storage write api
aconfig: update storage read api
aconfig: update storage file creation to allow storage files to store flag index instead of byte offset
aconfig: update storage file to store flag index instead of file byte offset
google products that include mainline apexes use
RELEASE_APEX_CONTRIBUTIONS_* for source vs prebuilt selection.
RELEASE_APEX_CONTRIBUTIONS is aware of aosp products via a parallel
special-case in core/product_config.mk, so we do not need this duplicate
special case here.
Bug: 308188056
Test: presubmits
Change-Id: I2fc904d3f661c105ec9a48a313723bc881a623f8
supporting negative compression levels in ota_from_target_files in the
format of zstd,-$compression_level
Test: ota_from_target_files
Change-Id: If2ca592829f10e7a0226cb41680cb47223d17c71
Now we are storing flag index instead of flag byte offset in storage
files, need to update storage write api accordingly.
Bug: b/321077378
Test: atest -c
Change-Id: I67e55287a242df0af1925ede886f8c087d343c1f
With the update to store flag index instead of flag byte offset in
storage file. We need to update flag read api accordingly.
Bug: b/321077378
Test: atest -c
Change-Id: Iccbf939fc5b7fe0ce0f2c33f7e3aa403c268120a
Previously, in package.map, we store the byte offset of the first flag
in a flag package in a flag value file. In flag.map, we store the within
package flag byte offset. Once we know the total offset, we can locate
the flag in the flag value file. However, this offset may not work for
flag info file. Currently we only have boolean flags. Each boolean flag
value and info takes up 1 byte in flag value and flag info file. So the
byte offsets are the same. But in the future, when we add a new flag
value type, or add more contents to flag info file. Then the byte offset
for flag value file and flag info file may not be same.
Instead, we should store index rather than offset. The package map
should store the index of the first flag in this package. The flag map
stores the within package index. Then flag value read api and flag info
read api can then infer the byte offset independently.
Bug: b/321077378
Test: atest -c
Change-Id: Iad89776d5369715ba2d8faaea18261ac3271f13b
