ART tests require that "out/host/linux-x86" is included.
This requires making the dexLocations per-variant specific.
Test: m test-art-host-gtest
Bug: 147817558
Bug: 147819342
Change-Id: I7839ee15cb6dfc62508bdd3fa0f306336af17055
Implement support of dumping host boot.art.
That was not possible before because imageLocation is different on host.
This CL makes imageLocation per-variant so can access for the host variant.
Test: m dump-oat-boot
Change-Id: Id82161e4901a6b77f220238aec460b8609fd765f
This reworks CL https://r.android.com/1180134 as follows:
1) Do not reorder the list of system server jars passed from Make to
Soong via the product variable PRODUCT_SYSTEM_SERVER_JARS. This means
that for some products the order of jars on the system server
classpath may be non-optimal: a jar X that depends on Y may be
dexpreopted before Y, so that all references to the classes and
methods from Y wil be unresolved.
Unfortunately for such products, fixing the order is not a simple
matter of rearranging their PRODUCT_SYSTEM_SERVER_JARS, because the
conflicts may arise when the product-specific variable gets merged
with the common variable.
2) As a consequence of 1), do not add artificial dependencies between
system server jars: this is now impossible, as it would create
circular dependencies for those products that have non-optimal order
of jars.
3) Copy dex files for system server jars to a predefined build location.
This is necessary because at the time when Soong generates class
loader context for k-th jar, it needs to know the paths to jars 1 ..
(k-1), and it might have not processed those jars yet (so Soong can't
query the paths from the modules).
This approach is similar to the way Soong handles bootclasspath jars.
4) Do not exclude from dexpreopting system server jars that are not
Soong modules (those that are Make modules). The previous CL excluded
them because Make modules do not have ModuleContext. But it turns out
that ModuleContext is not necessary, as all the information is passed
via the dexpreopt config.
Test: aosp_walleye-userdebug boots and there are no messages in the
logcat regarding class loader context mismatch:
$ adb logcat | grep 'mismatch'
# empty
Test: Class loader contexts in the oat files for system server jars
match expectations:
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/com.android.location.provider.odex 2>/dev/null | grep '^classpath'
classpath = PCL[]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/services.odex 2>/dev/null | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1989208671]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/ethernet-service.odex 2>/dev/null | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1989208671:/system/framework/services.jar*4040443083:/system/framework/services.jar!classes2.dex*2210087472]
Test: The phone boots and logcat has no scary messages related to
class loader contexts:
$ lunch aosp_walleye-userdebug && m
$ adb reboot bootloader && fastboot flashall -w && adb wait-for-device
$ adb root
$ adb shell stop
$ adb logcat -c
$ adb shell setprop dalvik.vm.extra-opts -verbose:oat
$ adb shell start
$ adb logcat | egrep -io 'system_server: .*load.*/system/framework.*'
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/services.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/services.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
Bug: 141785760
Bug: 140451054
Bug: 148944771
Bug: 147017252
Change-Id: I33c4087f8bfacd0ecb89877aa150b75360d06710
Merged-In: I33c4087f8bfacd0ecb89877aa150b75360d06710
(cherry picked from commit a4a83b0ef9)
Exempt-From-Owner-Approval: cherry-pick.
This will allow us to remove the core.art image compiled in make.
Test: lunch aosp_x86_64 && m test-art-host-gtest
Bug: 147817558
Bug: 147819342
Change-Id: I864f72198d875dc1421c9c029a683bafbe7b71ac
We plan to add boot image variants for host tests.
Distinguishing the variants by arch does not work,
since both host and device can have the same arch.
Change-Id: Iea73c77367affb074f97a0fc318389417ce537da
dexpreopt package.
Preparation for a future CL that will need to get the make-written
GlobalConfig from within dexpreopt.
Also rename the Load*Config functions to Parse*Config, since they don't
actually load the config files anymore.
This relands https://r.android.com/1211982.
Bug: 145934348
Test: m
Change-Id: Icb9332a93811d77d2d8b06e983b92501b180a358
caching of it.
Introduce a Once cache for GlobalSoongConfig to allow it to get binary
tool paths from ordinary module dependencies (coming in a future CL)
that are then reused in singletons.
This relands https://r.android.com/1205729.
Bug: 145934348
Test: m
Change-Id: I039d6e204bee5ddc16d8e2d85057fbec20e326fe
This patch excludes non-Soong system server jars from dexpreopting.
System server jars should be dexpreopted together for better
performance: each jar should have all preceding system server jars
in its class loader context (that is passed to dex2oat and recorded
in the resulting .oat file to be used by the loader).
This means that we need a total order on system server jars. The
default order provided by PRODUCT_SYSTEM_SERVER_JARS is not good, as
it does not always respect genuine dependencies between jars (counter-
examples are rare, but non-trivial to fix: b/148219586).
This patch adds a post deps mutator pass that creates additional
dependencies and enforces global order. These are later used to
generate precise class loader contexts and system server classpath.
Test: Class loader contexts in the oat files for system server jars
match expectations:
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/com.android.location.provider.odex | grep '^classpath'
classpath = PCL[]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/services.odex | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1919890654]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/wifi-service.odex | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1919890654:/system/framework/services.jar*4269704903:/system/framework/services.jar!classes2.dex*134345935]
...
Test: The phone boots and logcat has no scary messages related to
class loader contexts:
$ lunch aosp_walleye-userdebug && m
$ adb reboot bootloader && fastboot flashall -w && adb wait-for-device
$ adb root
$ adb shell stop
$ adb logcat -c
$ adb shell setprop dalvik.vm.extra-opts -verbose:oat
$ adb shell start
$ adb logcat | egrep -i 'system_server: .*load.*/system/framework'
02-03 14:14:26.912 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
02-03 14:14:26.914 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
02-03 14:14:26.914 5016 5016 I system_server: Loading /system/framework/oat/arm64/services.odex with executable: 1
02-03 14:14:26.916 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 1
02-03 14:14:26.927 5016 5016 I system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 1
02-03 14:14:26.933 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 1
02-03 14:14:26.933 5016 5016 I system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 1
02-03 14:14:26.934 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 1
02-03 14:14:26.946 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
02-03 14:14:26.947 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
02-03 14:14:26.947 5016 5016 I system_server: Loading /system/framework/oat/arm64/services.odex with executable: 0
02-03 14:14:26.948 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 0
02-03 14:14:26.948 5016 5016 I system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 0
02-03 14:14:26.948 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 0
02-03 14:14:26.949 5016 5016 I system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 0
02-03 14:14:26.949 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 0
02-03 14:14:30.480 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
02-03 14:14:30.481 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
Bug: 141785760
Bug: 140451054
Bug: 148944771
Change-Id: Idac678dbd1f5fe0e381ce8e0e3561423f8a31389
This is to unify boot jars with system server jars:
PRODUCT_SYSTEM_SERVER_JARS and PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS
do not overlap.
Test: aosp_walleye-userdebug boots
Exempt-From-Owner-Approval: cherry-pick.
Bug: 146363577
Change-Id: If001049a46f8e9d38921dabeedbd61e971ebfe73
Merged-In: If001049a46f8e9d38921dabeedbd61e971ebfe73
(cherry picked from commit ef4358e536)
The primary image name should be "boot.art" in case of
"boot-framework.art", and "apex.art" in case of "apex-framework.art".
Although "boot.art" and "apex.art" are identical binaries, dex2oat
has hard-coded logic based on the image name.
This has been broken since boot image extension has been enabled for
JIT-zygote config in CL I5493e575ebf90bad1d5ad2850004d54590bbc079.
Test: compare boot-framework.art and apex-framework.art,
they were identical before this CL, and differ after this CL.
Test: JIT-zygote config boots, steps 1-2:
1. Temporarily enable Jit zygote in the product device config (in
this case device/google/muskie/aosp_walleye.mk):
+# System server should not contain compiled code.
+PRODUCT_SYSTEM_SERVER_COMPILER_FILTER := verify
+
+# Use the apex image for preopting.
+DEXPREOPT_USE_APEX_IMAGE := true
+
+# Have the runtime pick up the apex image.
+PRODUCT_PROPERTY_OVERRIDES += \
+ dalvik.vm.boot-image=/apex/com.android.art/javalib/apex.art:/system/framework/apex-framework.art
2. Build and flash:
$ lunch aosp_walleye-userdebug && m \
&& adb reboot bootloader && fastboot flashall -w
Change-Id: I98de271852ecc33feb9fd4c9b0addf0feba01856
Revert submission 1211982-dex2oat-soong-dep
Reason for revert: Build failures. See b/148312086.
Reverted Changes:
Ibc427a9a8: Make dex2oat(d) visible for use as implicit dexpre...
I71df11c1e: Move the Once cache for dexpreopt.GlobalConfig int...
I38317f2d5: Get the dex2oat host tool path from module depende...
I440a09dba: Separate dexpreopt.GlobalSoongConfig to allow inde...
Bug: 148312086
Bug: 145934348
Exempt-From-Owner-Approval: Plain revert
Change-Id: Ice3990225635a737e49e9aed7373f06516fccea3
Revert submission 1211982-dex2oat-soong-dep
Reason for revert: Build failures. See b/148312086.
Reverted Changes:
Ibc427a9a8: Make dex2oat(d) visible for use as implicit dexpre...
I71df11c1e: Move the Once cache for dexpreopt.GlobalConfig int...
I38317f2d5: Get the dex2oat host tool path from module depende...
I440a09dba: Separate dexpreopt.GlobalSoongConfig to allow inde...
Bug: 148312086
Bug: 145934348
Exempt-From-Owner-Approval: Plain revert
Change-Id: I6b656afb5feaad70d958b9d38b6c6eab7b03fba1
package.
Preparation for a future CL that will need to get the make-written
GlobalConfig from within dexpreopt.
Also rename the Load*Config functions to Parse*Config, since they don't
actually load the config files anymore.
Bug: 145934348
Test: m
Change-Id: I71df11c1e042ca8135d273a7263e9539ea3cd68f
it.
Introduce a Once cache for GlobalSoongConfig to allow it to get binary
tool paths from ordinary module dependencies (coming in a future CL)
that are then reused in singletons.
Bug: 145934348
Test: m
Change-Id: I440a09dba7d337965a196527566b0966a18e3653
This relands I12a0f907753fefd1997ab8b4ea2ac331234093cf along with
a fix to blueprint for absolute paths.
Store the current working directory and then change to the root
directory so that all file accesses must go through helpers in
the android package that properly track dependencies.
Change-Id: I24ac485677aa102eec1a2521d16820da6ee1ae77
Fixes: 146437378
Test: m checkbuild
Test: m OUT_DIR=/tmp/out nothing
Store the current working directory and then change to the root
directory so that all file accesses must go through helpers in
the android package that properly track dependencies.
Fixes: 146437378
Test: m checkbuild
Change-Id: I12a0f907753fefd1997ab8b4ea2ac331234093cf
This reverts commit 3fae7662ee
Reason: re-applying the change after resolving the problem with
coverage builds (in a related CL).
Use boot image extension for framework libraries.
This patch splits the system boot image in two parts:
- The ART boot image. This is the primary boot image that is
included in the ART apex and contains dexpreopted Core Libraries.
- The framwework boot image extension. It depends on the ART boot
image and contains framework libraries.
The third "apex" boot image (used in the JIT-zygote experiment)
remains unchanged; it is a monolithic primary boot image that
contains both libcore and framework libraries.
Dexpreopting of APKs now uses the framework boot image extension
(which in turn pulls in the ART boot image as a dependency).
Bug: 146462581
Bug: 119800099
Test: aosp_walleye-userdebug boots.
Change-Id: I06c5ac5fca011fa639ed208735462ab32451df3a
The dexpreopt global config is now split into the part that is generated
from make (in build/make/core/dex_preopt_config.mk) and the part that is
generated from Soong. Since the goal is to generate the dex2oat path from
Soong dependencies, the old GlobalConfig.Tools struct is simply repurposed
for the Soong generated config, although the intention is to allow more
settings to migrate from make to Soong, and hence from GlobalConfig to
GlobalSoongConfig.
Since the new dexpreopt_soong.config is written from a Soong-created ninja
rule, it doesn't need to be rewritten to out/soong/<device>/ like the old
make-created config file.
Test: m
Test: env USE_DEX2OAT_DEBUG=false m
(check that out/soong/dexpreopt_soong.config points to dex2oat instead of dex2oatd)
Bug: 145934348
Change-Id: Ifd45c4a08e2ec55b86f4a93f0d85bd39cf2cf189
Previous CL Ia9b34aa92ebb1b4de96ea0f8f290d798be19b2cf introduced
asymmetry in handling "boot" and "apex" boot images: in JIT-zygote
experiment, though the "apex" boot image was installed, the "boot"
boot image was still used for generating dexpreopt configs.
It is unclear why this asymmetry was needed at that point; it seems
incorrect to use different boot images for dexpreopting and for
installing on device. After recent changes the asymmetry started
breaking walleye_jitzygote-userdebug on git_rvc-release, because APK
dexpreopt commands refer to inexistent boot image files.
Test: lunch aosp_walleye-userdebug && m
Test: cherry-pick CL in internal, walleye_jitzygote-userdebug boots
Change-Id: Id877c10269cf79caf6ae74b1dc169a31e6a2211b
This reverts commit 4d2eeed0da.
Reason for revert: breaks avd/avd_boot_health_check test
on cf_x86_phone-userdebug_coverage on branch rvc-release
(the device fails to boot).
Test: m
Test: aosp_walleye-userdebug boots
Bug: 145749668
Exempt-From-Owner-Approval: revert
Change-Id: Ie1d93a200222e26461c1bcd384fdb69b7351e259
This patch splits the system boot image in two parts:
- The ART boot image. This is the primary boot image that is
included in the ART apex and contains dexpreopted Core Libraries.
- The framweork boot image extension. It depends on the ART boot
image and contains framework libraries.
The third "apex" boot image (used in the JIT-zygote experiment)
remains unchanged; it is a monolithic primary boot image that
contains both libcore and framework libraries.
Dexpreopting of APKs now uses the framework boot image extension
(which in turn pulls in the ART boot image as a dependency).
Test: m
Test: phone boots:
lunch aosp_walleye-userdebug && m \
&& adb reboot bootloader && fastboot flashall -w
Bug: b/119800099
Exempt-From-Owner-Approval: rebased after getting approval.
Change-Id: Ida40dfae8c83bf7c2e737d5c7ea418e1197ad826
Use apex:jar pair values for updatable boot jars to align with
updatable system_server values.
Test: Compiles & flashed device. Ensured that the bootclasspath & system_server class
paths remain the same.
Change-Id: I1d6dfe3325d9091b7c724458be4e6471f9086666
This reverts commit 01f6b0a656.
Reason for revert: Build failure is not reproducible.
Forrest build on the same build ID 6033773 and same target
cf_x86_phone-userdebug_coverage finished successfully.
Change-Id: I5077f8332aa0b8037e324b89d41f35b86b8cf216
This reverts commit 61c325ebcc.
Reason for revert: broken build git_master/cf_x86_phone-userdebug_coverage (likely caused by these changes).
Exempt-From-Owner-Approval: revert.
Change-Id: I88ddd3af3a6c4ffdaa1fbb881d965356c5c75ad3
Test: m
Test: The list of updatable system server jars is empty now,
so I tested that the filer works with a manual experiment:
- temporarily add ethernet-service to PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS
- m nothing
- fgrep -e 'ethernet-service' $ANDROID_BUILD_TOP/out/soong/build.ninja | grep dexpreopt
- expect empty output (no dexpreopt command is generated)
Change-Id: I0b231e823d5a5a97632daa2b5eb7be3e06782004
Allow system_server jars delivered via apex. Regular system_server
jars are located in /system/framework folder. But, jars delivered via
apex are mounted at /apex/<module_name>/javalib.
Bug: 144722612
Bug: 141785760
Test: Compiles
Change-Id: Ia40bb91d2e05b2601a52eac28a985fe2d8da3481
This reverts commit bf0e47648a.
Reason for revert: coverage build with EMMA_INSTRUMENT_FRAMEWORK=true
is fixed by inspecting the environment variable and not generating
boot image in case it is set.
Dexpreopt artifacts for the libcore part of the boot class path are
now packaged in the ART apex. The system image still contains
dexpreopt artifacts for the full set of boot class path libraries
(both libcore and framework); the libcore part will be removed and
boot image extension will be used in a follow-up CL.
Since this is specific to the ART apex and makes no sense for other
apexes, the implementation adds a boolean flag "is ART apex" rather
than a new apex module property.
Build rules for the new set of dexpreopt artifacts are created using
a new variant of the global boot image config. Previously we had two
variants: "default" (for the system image) and "apex" (for the
JIT-zygote experiment). This patch adds a third "art" variant.
Test: m
Test: m art/build/apex/runtests.sh
Bug: 144091989
Change-Id: I113c0d39222d6d697cb62cd09d5010607872fc2b
This reverts commit 24babe3a66.
Build failures are fixed after reworking the patch:
- 'missing dependencies' on aosp-master-art branch is fixed by
disabling profile generation in case default profile is not
found (it is part of framework absent in aosp-master-art)
- invalid dex2oat invocation should no longer happen after
disabling dexpreopt on targets that do not use default ART config
(fixed in CL If2d4fe2cdcb6a81c7c6d730d18c2b681a74fb0b7)
Dexpreopt artifacts for the libcore part of the boot class path are
now packaged in the ART apex. The system image still contains
dexpreopt artifacts for the full set of boot class path libraries
(both libcore and framework); the libcore part will be removed and
boot image extension will be used in a follow-up CL.
Since this is specific to the ART apex and makes no sense for other
apexes, the implementation adds a boolean flag "is ART apex" rather
than a new apex module property.
Build rules for the new set of dexpreopt artifacts are created using
a new variant of the global boot image config. Previously we had two
variants: "default" (for the system image) and "apex" (for the
JIT-zygote experiment). This patch adds a third "art" variant.
Bug: 143594594
Bug: 143593500
Test: m
Test: m com.android.art deapexer \
&& find $ANDROID_BUILD_TOP -type f -name 'com.android.art.*.apex \
| xargs deapexer | grep boot \
Expect to find javalib/$ARCH/boot*.{art,oat,vdex} files.
Test: m art/build/apex/runtests.sh
Change-Id: Ib37acaec8401bd23c8d547dadf773565406ef448
62c7829595c0df53e96addcd347c11ac01012eee introduced the new stem
property to java modules, but it wasn't propagated to Make. Fixing the
problem.
This change also fixes a problem that (module name) == (file name) is
assumed in dexpreopt_config.go, which no longer is the case. A mutator
runs to build a map from module name to its stem. The map is then used
when filling up the file paths in the bootImageConfig struct.
Bug: 139391334
Bug: 143494499
Test: m
Test: BootImageProfileTest
Change-Id: Idbc894f877692401471130de6cbfe5e0dd129da9
This reverts commit d5df949385.
Bug: 143594594
Bug: 143593500
Reason for revert: Some builds are failing.
Change-Id: I69986b472bce39266095e526fcd7ef5f48ece85e
Exempt-From-Owner-Approval: Going back to green.
This patch adds dexpreopt files for the libore part of the
bootclasspath to the ART apex.
Since this is specific to the ART apex and makes not sense for other
apexes, the patch does not add a new module property, but only a
boolean flag denoting that this is an ART apex.
Dexpreopt artifacts packaged into the ART apex differ from those that
are packaged in the system image: it inludes only the libcore part of
bootclasspath jars, but not the framework part. When the boot image
extension is implementd, dexpreopt artifacts for the libcore jars will
be removed from the system image (but for now they are both in the
apex and in the system image).
Build rules for the new set of dexpreopt artifacts are created using
a new variant of the global boot image config. Previously we had two
variants: "default" (for the system image) and "apex" (for the
JIT-zygote experiment). This patch adds the third "libcore" variant.
Test: m
Test: m com.android.art deapexer \
&& find $ANDROID_BUILD_TOP -type f -name 'com.android.art.*.apex \
| xargs deapexer | grep boot \
Expect to find dexpreopt/$ARCH/boot-art*.{art,oat,vdex} files.
Test: m art/build/apex/runtests.sh
Change-Id: I353ef90304bc5e18c3055ea379b3b223e5c38948
Both default and apex configs are used for dexpreopting bootclasspath
jars. The difference between the two configs is in the naming (default
paths contain "boot", and apex paths contain "apex"). Another
difference is that apex config does not have a zip archive.
Test: m
Test: `find $ANDROID_BUILD_TOP/out -name '*.art' | sort`
returns the same list of files before and after the patch
Change-Id: I5b2e8d83ab94fd0b1b3d4dc3f0db243ef70bfb08
Translated second architectures now go in NativeBridgeArch instead
of DeviceSecondaryArch.
This reapplies I568046330abc002d4eed582cb999b62a5eaba790 with
ctx.Config().HasMulitlibConflict() added to fix the NDK build,
which has arm64, arm, x86_64, and x86 architectures enabled.
Test: m checkbuild
Test: OUT_DIR=out_ndk build/soong/scripts/build-ndk-prebuilts.sh
Test: no change to build.ninja or Android-aosp_cf_x86_phone.mk
Change-Id: Iadcafbd64bfb9579ae7c86914927c43a062b0c8e
Instead of just depending on the main .art file (boot.art, etc), also
expose the dependencies to the .oat/.vdex files (boot.oat/boot.vdex),
and all of the module files that get implicitly loading (boot-ext.*,
boot-framework.*, etc)
This is necessary for RBE, where the rule only gets the files that it
depends upon.
Test: treehugger
Test: build a system image with RBE
Change-Id: I0c7051f18582f1891d3398b46763b1521e4326c8
David Srbecky