| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| |
| | |
https://android.googlesource.com/platform/build into u14.0
Android 14.0.0 Release 50 (AP2A.240605.024)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
How it works:
1. build/make/core/Makefile generates a txt file with the kernel
version, which is taken from an explicit BOARD_KERNEL_VERSION value,
or extracted from the kernel image on the source tree, or extracted
from the kernel image extracted from the prebuilt boot.img.
The file is saved at
$ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt.
2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to
be determined by the kernel version, build/make/core/Makefile copies
kernel_version.txt to
out/soong/dexpreopt/kernel_version_for_uffd_gc.txt.
3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to
out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an
explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py,
which reads kernel_version_for_uffd_gc.txt and determines the flag
accordingly.
4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt.
5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on
the same logic.
Bug: 321751629
Bug: 319554951
Bug: 318763448
Bug: 319648491
Test: m --no-skip-soong-tests nothing
Test: atest uffd_gc_utils_test
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no
UFFD support -
1. Check the existence of `-Xgc:CMC` in
out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation
(dex2oat invocation for a boot image)
2. Check the existence of `-Xgc:CMC` in
out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation
(dex2oat invocation for an app defined in .bp)
3. Check the existence of `-Xgc:CMC` in
$ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation
(dex2oat invocation for an app defined in .mk)
4. Check the value of ro.dalvik.vm.enable_uffd_gc in
$ANDROID_PRODUCT_OUT/product/etc/build.prop
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with
UFFD support, and do the steps above.
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps
above.
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps
above.
Change-Id: I8df6e5be1644da05d2d5c57b3520f29601dfd7a4
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Squashed with the following commits:
Author: Scott Mertz <scott@cyngn.com>
Date: Thu Feb 26 10:51:44 2015 -0800
Enable ADB by default when ro.adb.secure is not 1
* Property ro.build.type is not part of the default.prop we can't
use this to decide how to apply adb by default within this function
Change-Id: Ib3eb24c655353966d64c7148d7530244b628ce94
Author: LibXZR <i@xzr.moe>
Date: Sat Apr 30 16:29:35 2022 +0800
tools: Let adb secure check depend on "==0" rather than "!=1"
We are using PRODUCT_SYSTEM_DEFAULT_PROPERTIES to set
`ro.adb.secure` property. But unfortunately this flag only
affect system partition, which means in other partitions
e.g. vendor and system_ext `ro.adb.secure` stays empty.
Thus `persist.sys.usb.config=adb` is unconditionally set
in partitions other than system, which lead to adb enabled
by default even on user build.
Change-Id: I1f8b463b3ec645309369f36014bed556e75ed210
Signed-off-by: LibXZR <i@xzr.moe>
Change-Id: I33ae5c6f2787017a62e679aa0c28d4b909d45935
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
BOARD_API_LEVEL and BOARD_API_LEVEL_FROZEN are set by the release
flags.
BOARD_API_LEVEL sets ro.board.api_level that shows the API level of
the vendor API surface.
BOARD_API_LEVEL_FROZEN sets ro.board.api_frozen that shows if the
ro.board.api_level is finalized.
Bug: 295269182
Test: getprop ro.board.api_level
Change-Id: Ie57c57b6c9f1fc0c98968195843059a48da8e512
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This reverts commit 8ad4bb16a0d8b8ff9b4d17e860db336111bef34d.
Bug: 184103246
Test: forrest test build
Change-Id: I9111ae2d6150dfed86c785e6db205c64e4c8d5e0
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 9a32636759822bfb04071c9e28b101e9714ce305)
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 b302cdf6a417b9c8eaedee713187735a74707d6a)
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 7aeb8de74e08eb2d305686aa8eff45353973e7d7)
Change-Id: I9c073a21c8257987cf2378012cadaeeeb698a4fb
|
| |
|
|
|
|
|
|
|
|
|
| |
post_process_prop.py doesn't simply drop a line when deleting a prop.
Instead, it makes the line as comment and leave a comment to clearly
mark that the prop was force removed. This is to aid the debugging.
Bug: 117892318
Test: m
Change-Id: I53c05800ff71d431a56dc370bcfe8bfc95c03bfc
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The script is refactored to not parse lines everytime a prop is looked
up or updated.
Also it is now built using python_binary_host.
Bug: 117892318
Test: m
Change-Id: I1677ca5aa919c54b7b0740fdc52e1399009f9a12
|
| |
|
|
|
|
|
|
|
|
| |
default.prop files are gone. Remove the code in post_process_prop.py
that handles the file.
Bug: 1313599
Test: m
Change-Id: I3b4ff4adac57a406b70300d34ece7028cb52eb2d
|
| |\
| |
| |
| |
| |
| | |
am: 1d6e8e31d0
Change-Id: I4a3872a59ba39289bf58741e19ca05b9b9c7bbee
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Bug: 23102347
Bug: 34954705
Test: provide a fingerprint >92 characters long and see that it
successfully works
Change-Id: Ida9ffd5266acb3b432b208780804a08e8f7391b4
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch tries to fix the problem where the default properties need
to go with the system image especially on non-AB devices where
/default.prop is on the ramdisk image. A symlink is created at
/default.prop for backward compatibility.
Bug: 37815285
Test: Tested with ag/2416542. Booted pixel phones, checked the location
of prop.default, verified the symlink, checked a few properties
(via adb shell getprop) and manually tested a few apps (Camera,
Maps etc).
sign_target_files_apks.py was tested with:
sign_target_files_apks -o -e DynamiteLoader.apk= -e DynamiteModulesA.apk= \
-e DynamiteModulesB.apk= -e DynamiteModulesC.apk= -e DynamiteModulesD.apk= \
-e GoogleCertificates.apk= out/dist/*-target_files-*.zip signed-target_files.zip
Booted to recovery and ran 'adb sideload' successfully.
Change-Id: I1a9a2ba49c8252afc13ced3dea71253afbd3091e
|
| |\
| |
| |
| |
| |
| |
| |
| | |
daac92eb51
am: 319fcc7668
Change-Id: Idb24042310fa9de8f534e9988285a16b714daf10
|
| | |
| |
| |
| |
| |
| | |
Bug: http://b/33926793
Test: boots
Change-Id: I12cdae782090fb0856171e5c90a268e91ba2ae1a
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If ENABLE_TREBLE and early mount of vendor partition are enabled,
overrides in PRODUCT_DEFAULT_PROPERTY_OVERRIDES will be stored in
vendor/default.prop.
If ENABLE_TREBLE and vendor partition are enabled, overrides in
PRODUCT_PROPERTY_OVERRIDES will be stored in vendor/build.prop.
default.prop of recovery image will include all the contents of
vendor/default.prop and vendor/build.prop additionally.
ENABLE_EARLY_MOUNT is added to specify whether early mount is enabled
or not, but it should be removed later when early mount becomes
default for all ENABLE_TREBLE products.
Test: building succeeded, and verified on bullhead.
Bug: 34116668
Change-Id: Ic2eb8882ae71921a76c02b3d62d3289c45949295
|
| | |
| |
| |
| |
| |
| |
| | |
This reverts commit 3c51c2bc487e6dd68fe586aba01ceb5f55e44671.
Bug: 32223614
Change-Id: I1addc93b175e9442d9fc2f5e7a557fe818201a27
|
| |/
|
|
|
|
|
|
|
| |
Default.prop can interfere with UsbDeviceManager's management of usb state.
Adb is now enabled for userdebug and eng builds directly from UsbDeviceManager.
Bug: 31814300
Test: Manually verified that logcat is not kicked
Change-Id: I69c998c0dd184f9440cc236d82cc2f25f36e8734
|
| |
|
|
|
|
|
| |
The 'adb' configuration might have already been added by a
device-specific Makefile, so add it only if it's not already there.
Change-Id: I6f96645f44c96f6f827cc8c842a8b769f92be13a
|
| |
|
|
|
|
|
| |
Let developers know the issue earlier when they set up new
products.
Change-Id: I3f2ecbc3a833c1a8a84bd75407a5c035e5fea70a
|
| |\
| |
| |
| | |
Change-Id: I5573d097d741f4922b791b33de5c941af08127c6
|
| | |
| |
| |
| | |
Change-Id: I49179c83ae163de6f6fb398c5de60c5d296ca009
|
| | |
| |
| |
| |
| | |
Bug: 14024566
Change-Id: I70b8d3c8cfc968a7f039728375f3f7f341cdc11a
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Certain products can define a list of system properties that should be
delegated to the OEM. Since these properties may be ro.*, we give
them first shot at defining.
Also support blacklist of properties that should never be defined by
build.prop, used to delegate to runtime fingerprint generation.
Bug: 13367676
Change-Id: I3f00db732f485818205a7b76b31edbdc3a89aac0
|
| |
|
|
| |
Change-Id: I76c2344d9033eadede7048689a879c9a69a05b7f
|
| |
|
|
|
|
|
|
|
|
|
| |
exceeds 92 symbols (91 valid symbols + \0). It is better to catch that
issue on earlier stage, i.e. fail the build with an appropriate message.
For developer's build, show warning message instead of failing the build
(in the latter case, as developers do not usually care about build properties
too much).
Change-Id: I03ced7b486d43a71b1921e0a9c48b43aa30727c7
|
| |
|
|
|
|
|
|
|
| |
Tungsten is the first device we have done since post_process_props.py
and UsbDeviceManager were added that by default has no services running
on usb. Everything else has mtp. This makes it so we always populate
the property with something.
Change-Id: Ic24f52462ed8866e87499c715dd21937e5b1128d
|
| |
|
|
|
| |
Change-Id: I78b642400c46019165f12d409a238344ca6e09dd
Signed-off-by: Mike Lockwood <lockwood@android.com>
|
|
|
Change-Id: Ib78fe238d90dd4523326e4fa088d9333edc9e299
|