jacoco-report-classes-all.jar now depends on all installed files
including apks in /apex. Previously, it depended only on files under
system.img and as a result jacoco for other partitions were missing.
Bug: 147296855
Test: m
Change-Id: I755de1205ebc43c197af36a13cca5f4b49e275e8
They are now created from Soong, and therefore put in a separate config file
out/soong/dexpreopt_soong.config.
Test: m
Bug: 145934348
Change-Id: I27e710f09c37e64e8975b8e763d13434e5de71b3
People have asked me on several occassions how to fix this error. It's
somewhat confusing since scripts aren't usually on a path. However, in
this case, the script is added to the path on host. Hopefully, using
tick marks here will make that more clear.
Bug: N/A
Test: N/A
Change-Id: I8601a5a9eb348b2e358875b45eae57ec910c9a06
In order to provide a more descriptive name, and to be consistent
with HIDL, the stable AIDL package names are switching from
vintf-vibrator format to the package format
(android.hardware.vibrator).
Bug: N/A
Test: all build time
Change-Id: I382074d66b06669876d8f9fa4fc95b8a9c4dbf2a
Merged-In: I382074d66b06669876d8f9fa4fc95b8a9c4dbf2a
* Mostly new Java and Kotlin warnings found in nightly builds.
* More clean up of Java and C++ warning patterns will follow.
Test: warn.py --url=http://cs/android --separator='?l=' build.log > warnings.html
Change-Id: I8776401d15c3a59535722d52a5eec03f954d3b15
Now that ninja uses lstat and can support installing arbitrary symlinks,
switch jni lib symlinks from LOCAL_POST_INSTALL_CMDS to real rules.
Bug: 128577186
Test: List of files under PRODUCT_OUT is the same before/after this change
Test: out/target/product/generic/.installable_files now includes the symlinks
Test: m installclean; m NfcNci -> symlinks installed with correct dest
Test: m NfcNci; m NfcNci -> ninja: no work to do
Change-Id: I078dca53ab3d93f74c36fa66d5577e6e3e0640d6
Earlier CL Ida40dfae8c83bf7c2e737d5c7ea418e1197ad826 introduced
Soong-generated Make variable 'DEXPREOPT_IMAGE_LOCATIONS'. That CL was
erroneous in that it did not take JIT-zygote config into account and
generated identical location for "boot" and "apex" boot images.
This caused build breakages, because in case of JIT-zygote config the
two variables 'DexPreoptImages' and 'DexPreoptImageLocations' in the
module's dexpreopt.config were out of sync: 'DexPreoptImages' was
for the "apex" image, and 'DexPreoptImageLocations' was for the "boot"
image.
CL I9a91fc48e54d7d43abec2cb2b5a11e3581db380b introduced a workaround
for this problem: incorrect 'DexPreoptImageLocations' from the module
dexpreopt.config was ignored, and instead boot image location was
manually reconstructed from 'DexPreoptImages'. This workaround would
not work when we start using boot image extension and location will
become more complex.
This CL fixes the way 'DexPreoptImageLocations' is generated by
spliting the 'DEXPREOPT_IMAGE_LOCATIONS' variable in two variables
depending on the boot image flavour "boot" of "apex". This is
aligned with the way other similar variables are generated.
Test: aosp_walleye-userdebug boots.
Test: walleye_jitzygote-userdebug builds
(on git_rvc-release branch with this CL cherry-picked).
Change-Id: I449c968909635dd8cc431323fccbc7fce440fea5
unpack_bootimg in conjunction with mkbootimg can be used to re-create
boot.img with a different kernel image and ramdisk.
Change-Id: I9615facc9335885989772a0dd7f08217e2143a45
