Revert submission 1946769-boot-image-flip-b211973309
Reason for revert: Broke golem
Reverted Changes:
I80ffd9160:Remove the primary boot image from the ART APEX.
I45aaa5984:Remove the primary boot image from the ART APEX.
Change-Id: I9167a12cb158ede140dd44dc4458b0770c858379
After this change, `bootImageConfig.installDirOnDevice` can be set to a
path outside of the APEX, in which case, the boot image will not be
installed in the APEX. Instead, it will be installed to the given path
by Make.
This is a no-op change. Current behavior is not affected.
Bug: 211973309
Test: m nothing
Test: -
1. m com.android.art
2. See the boot image still being installed in the ART APEX.
Test: -
1. Change `installDirOnDevice` of the ART boot image config to
`system/framework`.
2. See the boot image being installed in `/system/framework/<arch>`.
Change-Id: Ib13b17cc9e94dc5754c9b51b04df3307323b8783
We will need the profile when we generate the primary boot image on
device.
Bug: 203492478
Test: Run `banchan com.android.art x86_64 && m` and see
`$ANDROID_PRODUCT_OUT/apex/com.android.art/etc/boot-image.prof`.
Test: Run `lunch aosp_cf_x86_64_phone-userdebug && m` and see both
`$ANDROID_PRODUCT_OUT/apex/com.android.art/etc/boot-image.prof` and
`$ANDROID_PRODUCT_OUT/system/etc/boot-image.prof`, in different
sizes.
Test: Start Cuttlefish with the built image and see both
`/apex/com.android.art/etc/boot-image.prof` and
`/system/etc/boot-image.prof` on device.
Change-Id: Id879dc49b234133dfbb9563814328661a1f4a6c0
Note that ART apex boot jars and core-icu4j are exceptions here as they
are not part of ApexBootJars. ART apex boot jars are defined in their
own variable, while core-icu4j is treated as a regular non-updatable
boot jar.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I3cea3d82ef521655a1a5ffa8cae2258ab9d08bfc
Replace the android.BuildOs constant with Config.BuildOS so that it
can vary based on the product config.
Bug: 190084016
Test: all Soong tests
Change-Id: Ia67f872d8b2ab788747a22e3a9659dc21c9775cd
Previously, copyBootJarsToPredefinedLocations relied on all its
parameters having the same length and the same order. That made it
quite fragile as changes to one of the parameters without corresponding
changes to the other would cause failures. It also combined the
retrieval of the boot dex jars from the modules, handling of missing
boot dex jar files and the generation of the rules to copy the files.
This change separates the retrieval of boot dex jars and handling of
missing files from the copying of those files while at the same time
making the function less fragile by replacing the three ordered
parameters with two maps that shared common keys.
Bug: 179354495
Test: m nothing
Change-Id: Idbcd24a7e8af89f7895a20aeddc58502dcbaad03
Previously, when building a framework boot image variant it added an
implicit dependency onto the first file in the primary boot image
variant to ensure that the primary boot image variant files that the
dex2oat command needs have been created. That works when generating
from source as in that case all the files for a boot image variant are
created by a single command. However, it does not work for prebuilts as
each prebuilt file will be copied into the required location by
separate copy commands.
This change adds all the files that the dex2oat command uses implicitly
when building an extension boot image as implicit dependencies.
Bug: 177892522
Test: m SOONG_CONFIG_art_module_source_build=false droid
- the previous command only works in combination with a number of
other build changes.
Change-Id: I183748fd17f8f3003890675b8c6bb9fcab331443
To avoid duplicates on *CLASSPATH environ variables at runtime, remove
split entries from platform-*classpath, i.e. all updatable jars that
have their own classpath fragments should not appear in the
platform-*classpath's classpaths.proto config.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: Id2759ab8e106cc183e695bf3509a6ab60ab0ef2a
Merged-In: Id2759ab8e106cc183e695bf3509a6ab60ab0ef2a
For running dex2oat on the target_files, the paths should be use the
device install path instead of the path starting with $(OUT).
So add usesTargetFiles option and basePath option which indicates
extracted path. With those options, the path is replaced with
$(basePath)/$(device path)
And also, add DexPreoptImageDeviceLocations in the config which refers
to the boot image path(without arch) on the device. Because
DexPreoptImage related device path was missing.
Bug: 158843648
Test: dexpreopt_gen -usesTargetFiles -basePath (extract path) and then
check if paths in the generated shell script are based on on-device
path.
Change-Id: I9667fadbf3b7c6f770e0d1bcbee5d67c1ecd8a3d
Each specific classpath_fragment module knows what jars must be part
of the corresponding classpaths.proto config.
Note that bootclasspath_fragment does not implement classpath_fragment
yet, thus all boot jars and all system server jars go into corresponding
platform classpaths.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I6a8c7b0a5d17d62e790a441b8e2c5c1a816e7f30
Add 'host' into the name of fields regarding path on the host side to
distinguish between paths on the device(which will be added in the
following commit), and paths on the host.
Bug: 158843648
Test: build and flash, and then
adb wait-for-device \
&& adb -s $S root \
&& adb -s $S logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C 1
Change-Id: Ib2645ed51591ba2f4b726c115b401ad2bd6675da
Consistent with plumbing of boot jars. SystemServerJars only support /system/framework/ jars.
Bug: 180105615, 155630745
Test: m && launch_cvd
Change-Id: I58b005b7c4103c8e250090e995b1d9b2f9ed4a76
They were used to generate export values for BOOTCLASSPATH and friends;
which are now generated by derive_classpath service based on proto
configs at runtime.
Bug: 180105615
Test: m && launch_cvd; presubmit / DeviceBootTest
Change-Id: Ifbf3f076a00e084d47a48180a4286fc53e610c5d
Instead of embedding "raw" values from PRODUCT_*_CLASSPATH variables
into /etc/classpath, encode them into classpaths.proto binary format.
Existing platform_bootclasspath{} module is used to generate the whole
monolithic config to begin with. Later, the config will be split
among individual bootclasspath_fragment and
systemserverclasspath_fragment modules.
Bug: 180105615
Test: m && launch_cvd
Change-Id: Ia66f521f8976ff78a62ecf91131d26db21064de7
This CL handles updatable boot jars in the same hacky way as we handle
non-updatable boot jars: it creates a set of predefined paths to the dex
jars in a global config, then traverses all modules in a singleton
context, finds updatable boot jars and adds copy rules from these jars
to the predefined paths. A proper way would be to register dependencies
of the dexpreopted modules on the boot jars and extracting paths to dex
files by walking these dependencies.
Bug: 178467404
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Test: added new Soong test
Change-Id: I87f764109315f79315d73bf43799b70eb010fc0b
By making the Append and RemoveList methods return a new list instead
of modifying the existing list it makes the ConfiguredJarList usages
easier to reason about and safer to use, especially considering that
they are primarily used in global configuration.
Added some tests for Append/RemoveList to ensure that they work and
do not modify the original or result in newly created lists sharing
storage with the original which would lead to corruption.
Bug: 171756871
Bug: 171479578
Test: m nothing
EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m nothing
Change-Id: I541c4686ecdd45c6a0c8b1c93fedf0fcd5952e2b
By making the Append and RemoveList methods return a new list instead
of modifying the existing list it makes the ConfiguredJarList usages
easier to reason about and safer to use, especially considering that
they are primarily used in global configuration.
Bug: 171479578
Test: m nothing
Change-Id: I102c4fb42f0c54e4ed299d2921fbf5efeb6e99b9
Free up the directory $(PRODUCT_OUT)/apex/com.android.art for the
release ART APEX. Without this we'll get conflicting install paths in
make.
Test: build/soong/soong_ui.bash --make-mode \
TARGET_PRODUCT=sdk_x86_64 TARGET_BUILD_VARIANT=userdebug nothing
with http://r.android.com/q/topic:release-apex-rename+author:mast
present to rename the ART release APEX to com.android.art.
Test: Build & boot on CF
Test: apct/device_boot_test and asit/perf/boottime_test on
blueline_jitzygote-userdebug
Test: avd/avd_boot_health_check on cf_x86_phone-userdebug_coverage_art
Bug: 169639321
Change-Id: I0b263d5922d438834e5c804e55f69a2a1421ab73
Merged-In: I0b263d5922d438834e5c804e55f69a2a1421ab73
With the addition of apexes and /system_ext some of the bootclasspath
and system server jars have moved from /system to the new locations.
This has been implemented by using lists of colon-separated strings
called "apex-jar pairs" (although "apex" was misleading as it could
refer to "platform" or "system_ext", not necessarily a real apex).
Using the colon-separated string representation is inconvenient, as it
requires splitting and reassembling the list components many times,
which harms performance and makes error handling difficult. Therefore
this patch refactors the colon-separated lists into a struct that
hides the implementation details.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: Id248ce639a267076294f4d4d73971da2f2f77208
This is a follow-up for https://r.android.com/1292915, which introduced
two-column format for the components of the boot jar list. This CL
fixes build failure for the coverage build.
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true
Change-Id: Ib8b156bf81943fe07084cbce5e7e9bf70e759a5d
The first component is the apex name, or a special name "platform"
if the boot jar is a platform jar rather than a part of some apex.
This is a prerequisite change for moving core-icu4j to a separate
com.android.i18n apex.
Old one-column format is still supported, but all unqualified
components of PRODUCT_BOOT_JARS get "platform:" prepended to them
after reading the product makefiles.
Test: aosp_walleye-userdebug boots
Bug: 138994281
Change-Id: Ic229159fdcdaf6182210a53b63850a389dd786fc
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
