This is used when Soong and Make don't know the full output file list,
and so use a tool to generate a per-module apkcerts.txt file instead.
Bug: 160119159
Bug: 162464887
Test: m apkcerts-list
Merged-In: I48183bc8cbf9dcc521f791812734205ed3f28f4c
Change-Id: I48183bc8cbf9dcc521f791812734205ed3f28f4c
This location allows the agent to be attached to arbitrary processes.
It only makes sense to include libdumpcoverage.so on coverage builds,
as these are the only builds that have any information to be dumped.
Bug: 148178774
Test: manual, used examples in README (see other CL) to test whether
it works on a userdebug_coverage build on cuttlefish
Change-Id: Ib2fece1b41a3b5d16c8a2a444c5486137e475fda
Merged-In: Ib2fece1b41a3b5d16c8a2a444c5486137e475fda
(cherry picked from commit 7185f8cc2d)
libprofile-extras has a wrapper to getenv() that appends the effective
userid (euid) of the current process to GCOV_PREFIX. This avoids
conflicts and permissions issues when multiple processes try to
create/access the same directories and files under /data/misc/trace.
This library needs to be added and the -Wl,--wrap,getenv flag needs to
be passed to all link steps. Since Android.mk does not propagate flags
and libraries across dependencies, this change just adds the library and
flag to all non-static-library Android.mk modules. As a consequence,
*ALL* binaries created via Android.mk will have the signal handler and
property watcher thread in libprofile-extras but they are no-ops in
non-coverage-enabled binaries.
The dependency is added early enough in core/binary.mk so that the
LOCAL_SOONG_LINK_TYPE resolutions occur correctly.
Bug: 148178774
Test: Verify that coverage files are written to
/data/misc/trace/<euid>/proc/... instead of /data/misc/trace/proc/...
Change-Id: I4d5f849c15e9a278253f2148185ddf3ab2878e2f
Merged-In: I4d5f849c15e9a278253f2148185ddf3ab2878e2f
(cherry picked from commit b8f898ef88)
We need to get files generated by a droidstubs target into the SDK. So
we first copy them into the out/target/common/obj/PACKAGING folder where
they can be picked up by the SDK build.
Bug: 142480924
Test: m sdk
Change-Id: I7a0b22907603e1d17ac05901ee7f8bb9cff89f7f
Merged-In: I7a0b22907603e1d17ac05901ee7f8bb9cff89f7f
The avb_pubkey may not be present, if the apex was initially
unsigned or generated from a bundle. In this case, running
sign_apex to generate a signed apex binary would result in an error.
This fix checks for presense of avbpubkey before attempting the
deletion
BUG: 139994107
Change-Id: I3cb2e88a11ad8797e38ba5fb98c96a4ec4135fc8
Apex payload dev keys are stored as .pem files.
Apex payload also utilizes .avbpubkey as public keys.
Change-Id: I65ced74be02008b666d7bb608f0d0a3ef3769c9c
BUG: 138623265
Bug: 134509111
Bug: 136633978
Test: add "require_root: true" to init_benchmarks and libpower_test
build the modules, confirm the extra target preparer is added in the
test config.
Change-Id: I2fdae79d45fd1e5866ee94d1f0e59df106be2a87
Merged-In: I2fdae79d45fd1e5866ee94d1f0e59df106be2a87
This allows sharing the same signing config on different target_files
zips. Nonexistent APEX will be ignored with a warning.
Bug: 137249701
Test: Run sign_target_files_apks with APEX overrides.
Change-Id: I2bad0f5c00753ed36ec5ae3431c7dc2ff1fc3e9c
We want to use prebuilts for apex modules for qt-dev, but it is
running afoul of the vendor file check. Disable the check for
now until we figure out a better solution.
Using Merged-In instead of DNM
Bug: 137033385
Test: Forrest run build_test
Change-Id: I9db5cb227780ede6aaff0070cd2fd59e95e635e6
Merged-In: 874b7a7766a569613dcd3ae526eaa6e1d4b78866
Merged-In: I99431a9a342e9b0617510e250597f3024ef39322
product_services partition is designed for the test purpose only. It
must not be included in the target devices.
Bug: 134359158
Test: Build configuration for product_services partition must return
error message.
Change-Id: I6f8cdf73d18ad3174c7b31edb5d5ee10df75a776
These LMK properties are product properties. The configuration will
be absent when GSI is installed as GSI doesn't mount the product
partition. Without these settings, some CTS test cases could
fail due to an aggressive LMK.
The patch puts these properties in GSI as default values.
Bug: 136212765
Bug: 134460917
Test: `run cts -m CtsFileSystemTestCases`, all pass
Change-Id: I6fde8db51debcb9bb269aece3a3e4c7e5bb991f6
It is now set on the /product partition by relevant devices.
Bug: 135569569
Test: lunch mainline_system_arm64; inspect system/etc/prop.default
Test: boot crosshatch and check the sysprop is still true via "adb shell getprop"
Change-Id: I34696977f584a65741c6002e6688d86e66a1f121
Merged-In: I34696977f584a65741c6002e6688d86e66a1f121
Currently, GSI does not include apex support and TARGET_FLATTEN_APEX is true.
This will cause issues for vendors with apex support (e.g. Cuttlefish).
This change set ro.apex.updatable to false in product to override that sets
in vendor.
Bug: 135411972
Bug: 134673003
Test: $ lunch aosp_x86-userdebug; m -j; emulator
$ lunch aosp_cf_x86_phone-userdebug
# Replace system.img in super.img with GSI
# The resulted CF could boot and browse the web successfully.
Change-Id: I08fd7a1b254aac276926329e064c35b714764936
Merged-In: I08fd7a1b254aac276926329e064c35b714764936
(cherry picked from commit fae280264e)
Pure GSI build targets has no vendor partition, such as
aosp_$arch_ab and gsi_$arch. The system properties defined by
PRODUCT_PROPERTY_OVERRIDES will be in /system/build.prop.
The patch defined a fake BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE to
let these system properties flow to vendor and won't pollute the
system.img.
The bug also move some properties to /product/build.prop.
Bug: 135508595
Bug: 131162245
Bug: 134781120
Test: check the /system/build.prop do not have "ro.carrier=unknown"
Test: adb remount on GSI Q on P
Change-Id: Ib200d66cf98fea572c26338e058bce29eb5e0cd7
Merged-In: Ib200d66cf98fea572c26338e058bce29eb5e0cd7
(cherry picked from commit 711d696eb3af759c63c416b0224faeac1f6c04f1)
When using Verified Boot 2.0, releasetools specifies a salt value based
on build fingerprint, so that to give idempotent images.
However, the change that removed static `ro.build.fingerprint` [1] broke
the behavior, as common.LoadInfoDict still relies on fingerprints.
Without a fixed salt, the first call to make_recovery_patch.py and the
second one (which writes IMAGES/{boot,recovery}.img) will see different
images, which leads to install-recovery.sh failure.
Note that currently there's a dependency that requires getting bootable
images through two separate calls. make_recovery_patch.py has to happen
first to get (placeholder) files in the system image. We then generate
canned fs_config files, and finally use add_img_to_target_files.py to
write the images.
This CL adds a quick workaround to force rebuilding the
recovery-from-boot patch while calling add_img_to_target_files.py.
[1] https://android-review.googlesource.com/c/platform/build/+/892933
Bug: 134123803
Bug: 134525174
Test: TreeHugger
Test: Build a non-A/B target that uses AVB. Run validate_target_files.py
on the generated target_files.zip.
Change-Id: I5859e30be63bfd54398cf41fd2d907f15285f560
Merged-In: I5859e30be63bfd54398cf41fd2d907f15285f560
(cherry picked from commit 4978fa99d1)
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
Jaewoong Jung