Also always use BUILD_NUMBER_FROM_FILE in the BUILD_FINGERPRINT.
The build number file now always exists, even if HAS_BUILD_NUMBER is
false.
Bug: 297269187
Test: m bazel_sandwich
Change-Id: Idf745b600b167e5cec161e07139be09a037bdc13
In GSI images attestation specific properties
(ro.product.*_for_attestation) are empty, which causes attestation
failure on devices with different values in ro.product.* and
ro.product.vendor.* from actual values provisioned in Keymint.
Hence these values added only if they are set in build files.
Bug:294190893
Test: atest CtsKeystoreTestCases:android.keystore.cts.DeviceOwnerKeyManagementTest#testAllVariationsOfDeviceIdAttestation
Change-Id: Icaf1bcd089767b2c47d0b57064aa72a4c9483bb5
Signed-off-by: wufei3 <wufei3@xiaomi.corp-partner.google.com>
This change allows ARC to define ARC-specific system properties in
Android build without changing these property definitions for other
Android builds. Please see go/arc-sigprop-changes and
go/arc-android-sigprop-sync for additional details.
Bug: 195609932
Test: built bertha_x86_64 with forward declarations
Change-Id: I22bd9d60c2491506fe5c633dbbb9e7516f529b35
BF_BUILD_NUMBER has hostname by mistake during refactoring.
Bug: 286453356
Test: build with BUILD_NUMBER
Change-Id: Id3fd7975057dfd70dfb7c02650672e670c6d5984
* Extract BUILD_NUMBER, BUILD_HOSTNAME to file to avoid kati change
* Handle FILE_NAME_TAG_PLACEHOLDER string in dist in build/make/packaging/distdir.mk
Test: check if kati isn't invoked even though BUILD_NUMBER, BUILD_HOSTNAME
is changed
Test: m && m, and check if the second m is no-op
Bug: 278060169
Change-Id: I1b37760242853c1a145bad255d0bb15524234b25
Merged-In: I1b37760242853c1a145bad255d0bb15524234b25
Original aosp/2374663 was reverted, so this change cnotains the implementation but disabled by default and SBOM will not be built by default with "m dist".
The feature will be enabled later in small CLs after running tests successfully in forrest.
Test: m sbom
Test: m dist
Test: on aosp, lunch aosp_bluejay-userdebug && m dist
Bug: 266726655
Change-Id: I926d0f97f3a0330ef61d059f12ea660005d370e6
Added new properties, which could be set for AOSP/GSI builds.
These properties are going to be used for attestation feature through
Build.java class. Earlier in AOSP builds attestation ids were different
from provisioned ids in Keymint. These properties will be identical to
provisioned ids.
Bug: 110779648
Bug: 259376922
Test: atest VtsAidlKeyMintTargetTest:PerInstance/NewKeyGenerationTest#EcdsaAttestationIdTags/0_android_hardware_security_keymint_IKeyMintDevice_default
Test: atest VtsAidlKeyMintTargetTest:PerInstance/NewKeyGenerationTest#EcdsaAttestationIdTags/1_android_hardware_security_keymint_IKeyMintDevice_strongbox
Test: atest CtsKeystoreTestCases:android.keystore.cts.KeyAttestationTest CtsKeystoreTestCases:DeviceOwnerKeyManagementTest
Change-Id: I9eea5e0f2fabc667b3efedeeefdf12e7b4fc9502
This variable is always false or empty now, so clean up remaining
references of the variable.
Remove "buildvariant=" kernel commandline as it was used by
system-as-root kernels to determine the system build variant. It is
unsupported now.
Bug: 241346584
Test: Presubmit
Change-Id: I0f97b6e0bf8b03429f65366119ff78f9c7983516
Added code to support a single system image that can start the
64 bit zygote only, or both the 64 bit and 32 bit zygote. By
default, the system will default to 64 bit only.
For this image, all abilist properties are only present in the
vendor partition. All other copies of these properties are deleted.
Bug: 227482437
Test: Verified that secondary doesn't start with same disk image
Test: with ro.zygote set to zygote64 and abilists set appropriately.
Test: Verified that secondary does not start when restarting netd.
Test: with ro.zygote set to zygote64_32 and abilists set appropriately.
Test: Verified that secondary does start when restarting netd.
Test: Verified that a 64 bit device only starts the primary.
Test: Verified that a 32 bit device only starts the primary.
Change-Id: Ifc6413cecc4df8ba041699f7d0b10786d1926d64
Right now they're named ro.bootimage.* which is really confusing.
Change it so that if generic ramdisk is in boot.img, then name the
properties as ro.bootimage.*, otherwise if generic ramdisk is in
init_boot.img, then name the prop as ro.init_boot.*.
Bug: 211823573
Test: m dist
Change-Id: Icff3c7be04b9a3c6490fbf49ba4f05565b029890
Add PLATFORM_DISPLAY_VERSION to version_defaults.mk that will propagate
to the ro.build.version.release_or_preview_display property and
be shown as the Android version for preview releases by Settings.
Bug: 221950960
Test: manual
Change-Id: I697cc59f77f92aa98a8a2573662797e6d3bd2042
The goal of this change is to cause ro.product.first_api_level to be
set in /system/build.prop in targets with PRODUCT_FULL_TREBLE=false
(which may be the case for targets without the usual set of
hardware interfaces, such as the mini targets being added in
https://r.android.com/1966051).
Setting ro.product.first_api_level is necessary for devices with newer
kernels to boot because it controls which metadata encryption format
is used, and an old format that is incompatible with new kernels is
used by default (see commit 4073c0b5241b635cb59e9e8a75ddcc783b5a99ce in
system/vold). There also appear to be e.g. bionic tests that check this
property. So it seems reasonable to set it even if PRODUCT_FULL_TREBLE
is false.
To begin with, stop adding it to ADDITIONAL_SYSTEM_PROPERTIES. There's
basically no point in adding it there because it will be filtered
out by the property blocklist for the system partition, whether
PRODUCT_FULL_TREBLE is true or false. This lets us remove the
blocklist entry, which causes ro.product.first_api_level to
appear in /system/build.prop via ADDITIONAL_VENDOR_PROPERTIES on
PRODUCT_FULL_TREBLE=false targets.
Bug: 217455793
Change-Id: I8c07baf9d308ea734ffed5d9b1776b60cdbf3435
It defines values for Build.VERSION.KNOWN_CODENAMES constant, and should
contain all codenames starting from Q, including current codename
for in development branches.
Bug: 211747008
Test: presubmit
Change-Id: If8995750e369ba39bfc7041580c21b2f96632a78
_prop_files is missing a trailing _
Bug: 195034733
Test: manual - check that expected prop files are in the image
Change-Id: Ie042acc74fa56d5515cacd5f41ddc0f82d74f20c
Background in http://go/compatible-build-fingerprint. If we want
to append unique vbmeta digest to build id, we cannot setup the
prop value at build time. Instead, set the old value as
ro.build.legacy.id; and let init set ro.build.id at runtime.
Bug: 186786987
Test: build a target file with the flag on
Change-Id: Ie139725bb7e5c65bd3f28f43b9975ba48ee10354
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
The patch rename the original ro.product.cpu.abilist* to
ro.system.product.cpu.abilist*. The property service will
define ro.product.cpu.abilist* by the intersect ABIs of
ro.{partition}.product.cpu.abilist*.
Bug: 176520383
Test: build aosp_arm64-userdebug and check the system/build.prop
Change-Id: I26e404632b28e9f6abd462920e0084ad2022a763
Common ro.product properties are always generated for the
product partition, even if it is not present. This was introduced
for the R release with Ia88c8efecb18db9c27baa466e492bfd898b581d3
"Generate product build props always" commit.
It violates CDD requirements for the devices which were released
earlier. Add optional parameter to build-properties which allows to
skip the common properies generation and product partition specific
checks to make sure common properties are not generated for
the devices released before R and without product partition.
Test: manual, build product/etc/build.prop for shipping levels 28, 30
and for the devices with and without product partitions
Bug: 174677451
Change-Id: Ia3275d7229d0a873e0a4f1d1ea7a25c758c85bb9
Move the OEM property imports so that they take higher precedence over
product and can still be overridden by factory properties.
Bug: 171304788
Test: manual
Change-Id: I0c0be446d5e9af77acfcdeb5145b5776c8d5820f
The ro.build.version.release has updated to use the last stable platform
version in go/ab/10260813. But the logic for per-partition build prop
has never been updated. This mismatch eventually reflects in the
device's build fingerprints and cause confusion. This cl updates the
partition build props to match the behavior of the top level build props.
Also the device's fingerprints is heavily used in static analysis, e.g.
ota targeting, the change to its computation may cause unexpected effects.
Bug: 170968068
Bug: 158483506
Test: build system image for coral, check the build prop
Change-Id: Icf741c915f2eba970258979efc274e424187ac69
Add a build.prop file for ramdisk. Properties uses the
name ro.[product.]bootimage*.
These ro.[product.]bootimage.* properties are also included in recovery
properties.
The file is installed to system/etc/ramdisk/build.prop under ramdisk.
On devices with dedicated recovery partition, the file is
installed to ramdisk/, which is installed to the ramdisk in the boot
image. The file is NOT installed to recovery/root to prevent
collision.
On devices with recovery_as_boot, in addition to ramdisk/, it is also
installed to recovery/root, which is installed to the ramdisk in the
boot image.
Test: m bootimage and inspect output
Bug: 169169031
Bug: 162623577
Bug: 170411692
Bug: 170364317
Change-Id: Ica6515b2a4e0f4a7fe4440434a3d7085fde64387
Bug: 163854285
Test: m on crosshatch. Vendor overrides are included in
system/build.prop on legacy devices.
Change-Id: Ib134f934de8546af3dff27312f6877eafe5ed22c
* changes:
Create $OUT/{vendor,odm}/lib before symlink modules
Add odm_dlkm/etc/build.prop
Install ODM dlkm to appropriate place and symlink
Add notice files for odm_dlkm
Add odm_dlkm partition.
aosp/1317598 has made a regression that the dependency from
buildinfo.prop to INSTALLED_ANDROID_INFO_TXT_TARGET is removed. As a
result, buildinfo.prop is not re-builty even after installclean, which
caused inconsistency between ro.build.display.id (from buildinfo.prop)
and ro.system.build.fingerprint (from build.prop which is re-built).
Fixing the issue by moving buildinfo.prop from $(call
intermediates-dir-for,ETC) to $(call intermediates-dir-for,PACKAGING)
so that it gets deleted by installclean.
Bug: 158583916
Test: m out/target/product/generic_arm64/system/build.prop
m installclean
m out/target/product/generic_arm64/system/build.prop
Inspect out/soong/verbose.gz and check that buildinfo.prop was newly
created.
Change-Id: Id82b8fdc872deffb6a1764ca6d3c7114301dee1d
build.prop files under system_ext, product, and odm partitions are moved
to the ./etc subdirectory. This is to be in-line with the established
practice of having all configuration files under ./etc subdir.
build.prop doesn't need to be an exception.
However, system/build.prop and vendor/build.prop were not moved because
there are a lot of apps and tools that depend on the path.
Bug: 158735147
Test: device has build.prop under ./etc and is bootable
Change-Id: I37c79f7337680f92406d9e196e5762bb8e7da5d8
* changes:
Handle the case when non-optional props have the same value
BUILD_BROKEN_DUP_SYSPROP as escape hatch for the new sysprop restriction
pm.dexopt.* props in runtime_libart.mk becomes optional
Some properties are set as optional
ro.zygote in base_system.mk is optional
Don't inherit tablet-dalvik-heap for GSI and emulator
Support optional prop assignments
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
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
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
Properties for <partition>/build.prop are now added via
PRODUCT_<PARTITION>_PROPERTIES.
PRODUCT_SYSTEM_PROPERTIES is added. PRODUCT_SYSTEM_DEFAULT_PROPERTIES
will be deprecated.
PRODUCT_VENDOR_PROPERTIES is added. PRODUCT_PROPERTY_OVERRIDES and
PRODUCT_DEFAULT_PROPERTY_OVERRIDES will be deprecated in favor of the new
variable.
For other partitions (odm, system_ext, product), there is no change.
Exempt-From-Owner-Approval: cherry-pick from internal master
Bug: 117892318
Test: m
Merged-In: I98f3b5d0da661b3ad75260a23754e655103b7a44
(cherry picked from commit ad810b6dae)
Change-Id: I98f3b5d0da661b3ad75260a23754e655103b7a44
Like other <partition>/build.prop files, the build rule for
system/build.prop is also created using the build-properties macro.
system/build.prop has a few number of auto-generate properties that the
macro doesn't create. Those properties are emitted to intermediate files
using manually crafted rules, the paths to the files are fed to the
macro, where their contents are copied to system/build.prop.
This change also refactors the code fragment that defines BUILD_*
variables that identifes the given build.
Bug: 117892318
Test: m
Change-Id: Ic218283b40fedeaddacb3fda93167edbec86094c
The shell script was responsible for appending some system properties
that are common to <partition>/build.prop files. The values of the
system properties were given via environment variables whose names were
slightly different from their corresponding make var names.
This change removes the script and instead write the system properties
directly in Make, thus eliminating the need to keep track of the mapping
across sysprop names, environment variable names, and make var names.
Bug: 117892318
Test: m
Change-Id: I4d88733c1afa30ea0c0c4fcfc2b349f07f7fc090
The macro `build-properties' is defined to generate build rules to
create <partition>/build.prop.
build.prop files in all partitions except for the system partition are
now build using the macro.
system partition will use the macro in the following changes.
Bug: 117892318
Test: m
Change-Id: Ibed9c96dac4366251ec59a0b1317aa92f501c9a3
The former doesn't use anything from the latter. The dependency is not
needed.
Bug: 117892318
Test: m
Change-Id: I61aeea9feb1ac4467af4f185f3d6930b03145afd
ro.bootimage.build.date.* are not used anywhere.
ro.bootimage.build.fingerprint was used in the recovery mode, which has
now been switched to ro.build.fingerprint.
Bug: 117892318
Test: m
Change-Id: I3776c4154f86ddb908b24c6899037c6a7df037df
