32-bit libaudiohal is used by 3rd party modules on the system
partition which get loaded by client apps. In the long term,
this dependency has to be eliminated, see b/142811260.
Bug: 141989952
Bug: 142811260
Test: vendor/google/build/build_test.bash
Merged-In: I41241922c7e48c5d8bf95363944932569cb20c0a
Change-Id: I41241922c7e48c5d8bf95363944932569cb20c0a
Now the update_engine is able to read public keysfrom otacerts directly.
So the update_engine_payload_key is no longer needed.
Also remove the key replace in sign_target_files_apks.py. So we should
not use the new script to sign the old target files.
Bug: 116660991
Test: build the system image, unit tests pass
Change-Id: I9dae1f8b397f2b5efafed66a8faac1cb9087c741
This temporariliy turns off treble sysprop neverallow rules which
enforces marking the owner and accessibility to each system property.
Bug: 131162102
Bug: 142684203
Test: m sepolicy_tests
Change-Id: Ie9de9576fcf28c432543ab8f8971c1d048c55819
VNDK APEX replaces VNDK libs under /system/libs/vndk[-sp].
For current VNDK (vndk_package), com.android.vndk.current APEX is
installed instead of VNDK libraries.
For older versions of VNDK (vndk_snapshot_package),
com.android.vndk.v## APEXes are installed along with prebuilt VNDK libs.
The reason why phony targets of VNDK prebuilts are still installed is
that phony targets install the required *.libraries.##.txt files to
/system/etc.
After those .txt files are moved to APEXes, then we can remove those phony
targets.(b/141450808)
Bug: 141451661
Test: m && boot (tested with cuttlefish)
Change-Id: Ibfa06d42ec0081fa7010091ef097bb940bacf8d6
required seems to conflict with apex with the following error:
build/make/core/main.mk:1338: warning: build/make/target/product/aosp_x86_64.mk produces files inside build/make/target/product/mainline_system.mks artifact path requirement.
Test: treehugger
Change-Id: Ifb1072b4585a94355909b33e3b8129455c35714a
For example, module libprotobuf-cpp-lite has installed library name
libprotobuf-cpp-lite-3.9.1.so.
VNDK library list should use this installed name instead of module name.
Bug: 141019581
Test: m $ANDROID_PRODUCT_OUT/obj/PACKAGING/vndk_intermediates/libs.txt
Change-Id: I7f19fedafdd2809e0b8738bbab6ad513ddb30ea0
This matches what is done for mainline_system_arm64
(in this particular branch).
Test: lunch mainline_system_x86 && m nothing
Change-Id: I4eb236d086bd36b4821ed11411fa404f2d45f2b9
Merged-In: I607781ce7c6299cbc98c54c683d04db3b65c2e21
Trying to do it on per-device basis is prone to errors and already
bitten us several times. For example, currently aosp_taimen doesn't
install shim apex on system partition, but specifies
ro.apex.updatable = "true", which means that it doesn't pass CTS tests.
Unconditionally installing shim APEX shouldn't introduce any problems
since apexd will skip its activation of devices that don't support
updatable APEX.
Test: m checkbuild
Bug: 140957666
Change-Id: I6b5e668b40b97752295c831684a7291842533c40
healthd had been deprecated from Android P.
Does not need to support it now.
Bug: 142164625
Bug: 138284857
Test: lunch gsi_arm64-userdebug;make -j
Test: No healthd in out folder
Change-Id: I48db70f4bf39f6322bd2e80e536e2ec96b3a6408
When `OVERRIDE_TARGET_FLATTEN_APEX` is defined (e.g. set in the
environment), `TARGET_FLATTEN_APEX` is forcibly assigned its value.
This is useful to enable/disable APEX flattening from the command
line (thus ignoring the product's default configuration), for testing
purposes.
Note: Previously it was possible to set `TARGET_FLATTEN_APEX` directly
and have the same effect, but recent changes in the build
configuration now prevent that option.
Test: Check that:
export OVERRIDE_TARGET_FLATTEN_APEX=true \
&& . ./build/envsetup.sh \
&& lunch aosp_walleye-userdebug \
&& export OVERRIDE_TARGET_FLATTEN_APEX=true \
&& build/soong/soong_ui.bash --dumpvar-mode TARGET_FLATTEN_APEX
returns:
true
Bug: 121117762
Change-Id: Ib9ccae38430340de38e4758b4f55df2c65ea60d5
The build system default was changed to not support apex, but
we want the mainline device to enable it.
Test: make mainline_system
Merged-In: I9f29e8354acffb1856dfd8a173b80a3f9324630c
Change-Id: I9f29e8354acffb1856dfd8a173b80a3f9324630c
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change includes the platform build system and release tools changes to
move the recovery resources from system to vendor (or /system/vendor). The
release tools need to know where to generate the recovery patch, and they
discover this from misc_info.txt variable board_uses_vendorimage, which the
platform build system generates.
We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required
module in target/product/base_vendor.mk.
Several release tools rely on the misc_info.txt board_uses_vendorimage variable
to know how to generate and detect the recovery patch.
This change partially removes the --rebuild_recovery flag from the
merge_target_files.py script. The flag will be fully removed in a follow-on
change.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
Turn on RRO enforcement for /system modules for products
that use mainline_system.mk
Bug: b/137727426
Test: compare_images
Change-Id: Ia1824481c85fb031d5e156307bf7a848e4721d9e
- libstagefright_enc_common
- libstagefright_amrnb_common
Bug: 141885505
Test: build and boot.
Checked libstagefright_enc_common.so doesn't exist in /system/lib64.
libstagefright_amrnb_common.so is still there because other system
module, librtp_jni.so, is using it, but there is no reason to keep
this in base_system.mk.
Change-Id: I43692b50bd23e0b857606b42cb000c8566489dd6
Ensure only /system partition modules defined in mainline_system.mk is
included.
Test: lunch mainline_system_arm64-userdebug; m
Change-Id: I0cf9e28dd95fdc0f8f1eb88aefa07e230223b996
Since they are empty.
Bug: 135686713
Test: builds
Change-Id: Ic7206bfc4fb3ba481ea025eb709054c6b8fc307d
(cherry picked from commit 344e791de74c1de8df770b6189988e2224e1b948)
Required in order to run test self test for the vendor copy of
libcrypto.so which may differ from the one in /system and so will use
differently name flag files in order to avoid running the BoringSSL
Known Answer Tests on every process startup, impacting system health.
Bug: 141150335
Test: TH
Change-Id: I1db922379a59fa66fc65b6d92d370f33a2c65799
Merged-In: I1db922379a59fa66fc65b6d92d370f33a2c65799
(cherry picked from commit e3ab8eab25)
Some device requires VNDK_USING_CORE_VARIANT list, but it was not
implemented in previous. Adding this library list to the build target so
it can be added to system image.
Bug: 141695559
Test: m -j passed & Tested from Cuttlefish
Change-Id: Ic6847fd1966d4e1884cdce97015c8c1d1e0f3422
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
Merged-In: 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
libbinder communication from APEX is not allowed, because it doesn't
form a stable way to communicate. After an update, if system libbinder
and APEX libbinder are out of sync, then they may fail to work with each
other.
libbiner usage is moved into libneuralnetworks_packageinfo library,
which is a stable API library.
Test: build & flash crosshatch
Bug: 139282353
Change-Id: I7238025af13e9430c266a1aea69f0d0381110df8
This property has a stable API so it can be moved to /product
partition. The interface between /product and /system should be
stable, but that between /system and /system_ext need not.
https://android-review.googlesource.com/c/platform/system/libsysprop/+/952375
Bug: 140788609
Test: build and checks /product/build.prop
Change-Id: I3545b22af9aaf4d7f51e88e626e73ac75ded78fc
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
We're now adding a core CSI system.img that is common across different
targets. So GSI-specific things should be moved to /system_ext.
Also renaming various generic*/system.prop to generic*/system_ext.prop.
This is to put the customization into /system_ext/build.prop instead of
/system/build.prop.
Bug: 137711197
Test: boot a GSI on crosshatch, and checks the value of those properties
Change-Id: Id344124280d5f4a6c10d390a9e8a4a50cc7f28fb
When TARGET_SKIP_CURRENT_VNDK=true current vndk libs are not installed.
Related *.libraries.txt files also should not be installed.
Bug: 132140714
Bug: 137511540
Test: TARGET_SKIP_CURRENT_VNDK=true m systemimage # and, look into /system/etc
Change-Id: Ieea7444c359410dd9a14ac0dd369cae38d18b63a
Some prebuilt vendor modules contain references to
libprotobuf-cpp-*.so, but the interface is not stable. Upgrading
protobuf would cause those modules to fail, so the vendor version
of the new protobuf library is renamed to libprotobuf-cpp-*-3.9.1.so.
Manually install old libprotobuf-cpp-*.so files to /vendor
to avoid breaking products that have prebuilts that reference them.
Once the new version of protobuf is in each product can be
inspected for references to libprotobuf-cpp-*.so on /vendor and
these packages can be included only on those devices that need
them.
Bug: 117607748
Test: m checkbuild
Change-Id: I8ac955eb703e3faf22ff930c59b30385f374ad0a
Merged-In: I8ac955eb703e3faf22ff930c59b30385f374ad0a
This library is being deleted. People who need symbols from this library
should use libhwbinder instead.
Bug: 135558503
Test: build only
Change-Id: I7dd343cf2b95047f9c22b39bbc5cd9fa98c6c0b3
Only common files can reside in system partition, other files
should be moved to the newly added system_ext partition.
Note that for GSI, it will be a single system.img that includes the
contents of product and system_ext partitions, under /system/product
and /system/system_ext, respectively. After moving skip_mount.cfg to
system_ext partition, it also needs a symlink file under system
partition:
/system/etc/init/config -> /system/system_ext/etc/init/config
This allows Q-launched first-stage init (in /boot partition) continue
to use the same path when new GSI image is used.
Bug: 138281441
Test: build aosp_arm64-userdebug and boot it on crosshatch
Test: rm -rf out && build/soong/soong_ui.bash --make-mode \
TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=userdebug droid
Change-Id: Iae9f5fb688f49497563864eb882d5f0ae33c744a
We're now adding a core CSI system.img that is common across different
targets. So emulator-specific things should be moved to /system_ext.
Bug: 137711197
Test: build and checks those properties are in /system_ext/build.prop
Change-Id: I0f8afdeda77849b06842dd4f6cd04b7aab08ada4
Only common files can reside in system partition, other files
should be moved to the newly added system_ext partition.
Note that for GSI, it will be a single system.img that includes the
contents of product and system_ext partitions, under /system/product
and /system/system_ext, respectively. After moving skip_mount.cfg to
system_ext partition, it also needs a symlink file under system
partition:
/system/etc/init/config -> /system/system_ext/etc/init/config
This allows Q-launched first-stage init (in /boot partition) continue
to use the same path when new GSI image is used.
Bug: 138281441
Test: build aosp_arm64-userdebug and boot it on crosshatch
Change-Id: Ida7c2d1b0152c7ef77fa9aeb5d0766d17aec59c5
