The patch also update the mainline whitelist.
Bug: 133295307
Test: build gsi_arm64-userdebug and flash on a Pixel device,
Test: long press on the homescreen, WallpaperPicker is in the selection
Change-Id: I7831471cc920a24d64512341f0e4f3fef5024b30
(cherry picked from commit 5f23fee45f)
The current solution expects BOARD_PREBUILT_DTBIMAGE_DIR to
contain prebuilt DTB files that are concatenated by the build system
to create $OUT/dtb.img. In order to accommodate devices that build
the dtb image locally, when BOARD_PREBUILT_DTBIMAGE_DIR is undefined,
make boot.img creation depend only on $OUT/dtb.img.
Bug: 133161451
Test: Build with BOARD_PREBUILT_DTBIMAGE_DIR undefined and verify
using unpack_bootimg.py that $OUT/dtb.img was included in boot.img.
Change-Id: Iae2c634ccdc1d83589b26d382882f75fb8565a31
Merged-In: Iae2c634ccdc1d83589b26d382882f75fb8565a31
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink:
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Test: make dist with an odm.img, checks $OUT/odm/etc/build.prop is loaded
Change-Id: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
Merged-In: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
(cherry picked from commit 6c62884000)
Bug: 132687993, 131687150
This CL moves SignApex() from sign_target_files_apks into apex_utils,
and adds sign_apex that allows signing a standalone APEX file directly.
Test: Run the following command and check the output file.
$ build/make/tools/releasetools/sign_apex.py \
-v \
--container_key \
build/make/target/product/security/testkey.x509.pem \
--payload_key external/avb/test/data/testkey_rsa4096.pem \
--payload_extra_args \
"--signing_helper_with_files ./signing-helper.sh" \
foo.apex \
signed-foo.apex
Test: Run sign_target_files_apks.py on crosshatch target_files.zip.
Change-Id: I4b2422fd5cb1c60a3aa94511475e2a0e5b1666ca
Soft omx plugins are already removed from vndk,
these should have been removed together. Keeping
them in vndk with have both 32 and 64 bit on system,
but soft omx only uses one set.
bug: 132466615
test: build and check these libs are now on vendor/lib.
Change-Id: I0242ece971ac75266cdf84e2341e5fa4b087451b
os_version is important for keymaster version binding, where it
refuses to perform operations with a key that is bound to an old
system version. This ensures that an attacker who discovers a
weakness in an old version of system or TEE software cannot roll a
device back to the vulnerable version and use keys created with the
newer version.
Previously, os_version for system.img is added into boot.img header
for bootloader to read the value then pass to TEE before booting the
HLOS. However, with project Treble to modularize each partition, all
images are now in the trajectory to be built independently (still
on-going). Also, in the Generic System Image (GSI) compliance test,
the os_version in OEM's boot.img cannot reflect the actual version of
GSI.
This CL adds per-partition os_versions into AVB metadata, which is
readable by bootloader via libavb without file system dependency. It's
still unclear for how os_version in non-system partition should be used.
We just add them for completeness here.
See more details in:
https://source.android.com/security/keystore/version-binding
Bug: 132233601
Test: build and avbtool info_image $OUT/vbmeta.img
- Prop: com.android.build.boot.os_version -> '10'
- Prop: com.android.build.system.os_version -> '10'
- Prop: com.android.build.system.security_patch -> '2019-06-05'
- Prop: com.android.build.vendor.os_version -> '10'
- Prop: com.android.build.vendor.security_patch -> '2019-06-05'
- Prop: com.android.build.product.os_version -> '10'
- Prop: com.android.build.product.security_patch -> '2019-06-05'
Change-Id: I21a77420f2e8a3456f7a8cae5158eb8fc41319e7
Merged-In: I21a77420f2e8a3456f7a8cae5158eb8fc41319e7
(cherry picked from commit 9b54801b58)
These are installed by media.codec as required modules,
and they're usually on vendor partition now. We don't
want to install the system targets here.
bug: 132466615
Change-Id: I8375563648bc2a5016dac4760b853cb32dde5429
Should be in product_config.mk, before the variables are readonly'd, or
the default will fail to work.
(cherry picked from commit 269dd013a5)
Bug: 131576555
Test: set PRODUCT_SHIPPING_API_LEVEL := 29 in mainline_arm64.mk && lunch
Change-Id: I25faee7ec0a3fff17e1d08b834d868834effda36
Merged-In: I25faee7ec0a3fff17e1d08b834d868834effda36
