aosp_${device}.mk all have this system property set inside
vendor/build.prop:
ro.com.android.dataroaming=true
so move this common setting into aosp_product.mk
We don't move this to //device/google/${device}/device-${device}.mk
because this property is only used by AOSP builds, so it may cause
issues if we make it a common setting across all device builds.
Bug: 136525499
Bug: 135502030
Test: Compare $ANDROID_PRODUCT_OUT before and after this change
Change-Id: Idd9e235707d9a7fea28fa8c741ad1a4014f71c86
The Legacy GSI is used on O/O-MR1 devices.
Do not need to support anymore. Phase out it.
Bug: 135977699
Test: none
Change-Id: I48b563a3aceca3c926e744165eb1dd88eff7a3d2
After moving NNAPI to an APEX, android.hardware.neuralnetworks@1.X
were added as explicit dependencies to enable NNAPI static tests
to run.
It's possible to make them included in NNAPI static tests as static
libraries, no point in keeping them here.
Bug: 139120468
Test: flashed crosshatch, NNAPI static tests
Change-Id: Ib7fb001cb76c9f36dc651f268c9acb7c7bb43a43
After applying the patch, the contents in system/product align
to the mainline_system/aosp_product.
aosp_x86_arm is not releaseded for GSI. The patch also inherits
from BoardConfigMainlineCommon.mk instead of
BoardConfigGsiCommon.mk. But keeps output system_ext and product
files to /system/system_ext/ and /system/product/.
Bug: 136616665
Test: Compare the product out folder with/without the patch
Change-Id: I2aefbd2d3e71e26219508e53161fa8a3cc2fd652
The commit in d14b895665
(https://android-review.googlesource.com/c/platform/build/+/728287)
changed partition layout, to always build the root dir into system.img,
even for devices not using system-as-root (i.e. the ones with separate
boot ramdisk).
With the new layout, there will be two root dirs for non-system-as-root
targets during the boot. If such a device uses Verified Boot 1.0,
/verity_key needs to be available in both roots, to establish the chain
of trust.
- bootloader uses the baked-in key to verify boot.img; it then loads
the ramdisk from the verified boot.img
- First stage init uses /verity_key (in ramdisk) to verify and mount
system.img at /system, then chroot's to it
- Second stage init uses /verity_key (in system.img) to verify and
mount other partitions
This CL adds rules to additionally install verity_key into ramdisk for
such targets.
Bug: 139770257
Test: Set up a target to use non-system-as-root
(BOARD_BUILD_SYSTEM_ROOT_IMAGE != true). `m dist`.
Test: Check that both ROOT/verity_key and BOOT/RAMDISK/verity_key exist
in the built target_files.zip.
Test: Run validate_target_files to validate the above target_files.zip.
$ validate_target_files \
--verity_key_mincrypt /path/to/verity_key \
target_files.zip
Test: Run sign_target_files_apks to sign the above target. Re-run
validate_target_files on the signed target_files.zip.
Test: python -m unittest test_validate_target_files
Change-Id: Ibe7e771c8c376429add85851ac86055564765d3c
It has been added to the individual products that have prebuilts that
reference libprotobuf-cpp-full.so or libprotobuf-cpp-lite.so.
Bug: 117607748
Test: treehugger
Change-Id: I49b79bc0a0b154596158b66cfafebab451c90a95
1. prepare two build targets one for updatable module another
for the legacy platform module with diferent config
2. a new cellbroadcastpermissionconfig module to expose
a signature permission.
3. by default, the build include the legacy version.
Later we will switch to the updatable module after more validation
e.g, usre data migration due to uid change
4. for go devies, always include the platform cellbroadcast to
to avoid creating new process
Bug: 135956699
Test: unit test and test app
Change-Id: I4d757e27b1e36fbf4890d08afbd45a141bccfc7c
Merged-In: I4d757e27b1e36fbf4890d08afbd45a141bccfc7c