dexpreopt usually gets a dex jar instead of the final APK, which
means targetSdkVersion can't be parsed out of it. Move the
shared library verification to a tool that operates on the final
AndroidManifest.xml instead. verify_uses_libraries.sh is still
used to verify prebuilts where we don't have an AndroidManifest.xml
and must parse it out of the APK.
Test: m Gallery2
Bug: 132357300
Change-Id: I6ade74b6144c73aee094f5d5ff343067ca0a0e5a
Filter out LOCAL_OPTIONAL_USES_LIBRARIES entries that are listed
in INTERNAL_PLATFORM_MISSING_USES_LIBRARIES before using them as
a dependency.
Bug: 132357300
Test: m Gallery2
Change-Id: I09bf331f7dc95d1aaa8e5176603bcd343dd93001
All users have been removed.
Test: treehugger
Change-Id: I2cfe720bef88cc5485e90746d85a7e0a5d068ef7
Merged-In: I2cfe720bef88cc5485e90746d85a7e0a5d068ef7
You can get a system.img without current VNDK libs.
This may help when you want a smaller system.img given that the image
will be used with a specific version (not current) of vendor image.
Bug: 132140714
Test: m TARGET_SKIP_CURRENT_VNDK=true && see if current VNDK is not
installed
Change-Id: Ie0815e6dd6ce2f861b6c42e637da4bb146320673
This enables mixed builds to use the file_contexts.bin from the system
build when regenerating images that come from system target files, and
similarly for file_contexts.bin from the other build when regenerating
images from other target files.
In monolithic (non-mixed) builds all image-specific selinux_fc props
point to the same file_contexts.
Bug: 132108151
Test: Built and booted mixed build devices.
Change-Id: Id51ed6d96ea6337879f1ab21d47c93c67bc25312
arm64 guest libraries are located in lib64/arm64
Bug: http://b/77159578
Test: lunch cf_x86_64_phone-userdebug in internal master; mm -j48 dist
Change-Id: I9f1f9426cbaed0a269126cb242e1a6df9249b167
Since aosp/887473 removed ro.expect.recovery_id,
There is no usage of "RECOVERYIMAGE_ID_FILE" which points
$(PRODUCT_OUT)/recovery.id.
Test: m && boot
Change-Id: I704af874b7e4141d2e006595242f7b681aa47f05
Running 'm samplecode' fails with
"build/make/core/main.mk:1834: error: overriding commands for target
`out/target/common/samples/libsimplejni.so', previously defined at
build/make/core/main.mk:1834"
This proves that noone has been using 'samplecode' target at least since
the build started generating both 32- and 64-bit shared libraries by default,
because development/samples/SimpleJNI/jni/Android.mk defines libsimplejni.so
as 'sample', and the deleted code in core/main.mk causes duplicate rule in
such case.
Test: treehugger
Change-Id: I38a4c478fcb0e60793129fe2513a8cdc6d2c79fb
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
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)
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, make boot.img creation depend on $OUT/dtb.img
only when BOARD_PREBUILT_DTBIMAGE_DIR is undefined.
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
- Updates the fuzzer builds to use SANITIZE_TARGET='fuzzer' instead of
'coverage'.
- Removed an old dependency that made fuzzer builds without ASan
an error.
- Fixed up the build flags to allow fuzzers to be built. Previously, the
coverage flags were manually provided. As the toolchain has moved on,
these flags are no longer compatible with libFuzzer, and so I've updated
them to use the correct, compatible flags.
Bug: 121042685
Test: With all patches in the bug merged, build a fuzzer using
'SANITIZE_TARGET=fuzzer mmma <your_fuzzer>'.
Change-Id: I86e6a26d27c22b3622cf6ea8760f502f607df6f0
patricktu