Since OtherModuleHasProvider will be deprecated soon, replace it with OtherModuleProvider
Test: go build ./java
Change-Id: I79736e44d85bc6e8c97f08ebf783b40533a3e6ae
Generating boot image requires a .prof file provided by the ART apex.
When building with prebuilts, this comes via the
prebuilt_bootclasspath_fragment module, which acts as a shim for
prebuilt_apex/apex_set. If we have multiple prebuilt apexes in the tree,
this shim becomes 1:many. This CL prepares dex_bootjars to select the
right .prof file when multiple prebuilts exist.
Implementation details
- Update deps mutator of dex_bootjars to create a dep on
all_apex_contributions. The latter contains information about which
apex is selected in a specific release configuration. dex_bootjars
will create a dependency on the selected apex in a postdeps phase
mutator.
- All apex module types (apex, prebuilt_apex and apex_set) will set a
provider that contains info about the location of the .prof file on
host
- dex_bootjars will access the provider of the selected apex to get the
location of the .prof file
This CL does not drop the old mechanism to get the .prof file (i.e. by
creating a dep on {prebuilt_}bootclasspath_fragment). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
Bug: 308790457
Test: Added a unit test that checks that the right .prof is selected
when multiple prebuilts exists
Change-Id: I40fdb21416c46bed32f6ff187ce5153711ec2c69
Convert all of the callers of OtherModuleProvider/OtherModuleHasProvider
to use the type-safe android.OtherModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: Id77f514d68761a262d9ea830a601dbed804bbbe5
OnlyPreoptBootImageAndSystemServer was for making the eng build faster.
This change makes it even faster.
Bug: 309011617
Test: Presubmit
Change-Id: If9001e99593b57deafa7b56f0ca6b3d4d80f56d3
We had hardcoded logic to override "framework-minus-apex", but we need
to override more jars, so this CL adds a general solution for this.
Bug: 290583827
Test: m nothing
Change-Id: I211ebda7aa2803886ab6e6d081d26327665e49a6
In the past, dexpreopt for boot jars was very inflexible, and it was
incredibly hard to make a change that is as simple as adding a jar to a
boot image. Boot image generation was handled by
"platform_bootclasspath" and "bootclasspath_fragment" separately. This
caused not only code duplication but also the inflexiblity as such a
design did not fit today's use cases, where a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. The design casued a huge
maintenance burden as any change to the boot image cost multi-week
efforts.
In recent years, efforts have been made to improve this a bit by a bit.
This change is another step towards making dexpreopt reasonable.
After this change, all boot images are generated by "dex_bootjars",
which is in build/soong and is therefore available on both the full
source tree and the thin manifest (master-art). The change decouples
profile generation/extraction from boot image generation. Profiles for
mainline modules are still handled by "bootclasspath_fragment"
because they need to be packed into APEXes when building mainline
modules and extracted from APEXes whem building the system image from
prebuilt modules. Boot images are not handled by
"bootclasspath_fragment" anymore.
Bug: 290583827
Test: m (all existing tests are still passing)
Test: Manually checked that the boot images are exactly the same as
before.
Change-Id: Ib5a5f401bee334ffcab5c26618e0c8888b84575a
* changes:
Change the profile path on host.
Extract duplicate code to common helper functions.
Fix dumpOatRules.
Remove Modules() from BootclasspathFragmentApexContentInfo.
Fix some tests for dexpreopt and remove unnecessary tests.
This is to decouple profile generation from image configs. A boot image
profile is either for a mainline module or for the platform, which is
orthogonal to boot images.
Bug: 290583827
Test: m nothing
Change-Id: I0918f2fa945a2af1839f1a08ecede331c64d0317
Also, fall back to using a default name for the dexpreopt directory if
we are not building for Android.
Bug: 290583827
Test: m nothing
Change-Id: I3fc6ff9142a2dcdf995796f75891b242fe2848d0
This method generates a build rule that runs oatdump for debugging
purposes.
- Pass "--runtime-arg -Xgc:CMC" to oatdump if UFFD GC is enabled.
- Build the phony name from the image name to avoid conflicts when using
this method for multiple boot images.
Bug: 290583827
Test: m dump-oat-boot
Change-Id: I7adc97cb85b571486b78f173fb80ff7da2c4bfe4
These two fields never do what they are described to do. This CL unifies
them to avoid the confusion.
Bug: 280440941
Test: m
Change-Id: I3652d73a50832a2e494d9f5cae750f5fc38293b4
We don't need this anymore because we are going to compile ART jars and
framework jars together.
Bug: 280776428
Test: m
Change-Id: I070157530449a1bb5779e25984c367df3dde7b36
As-is, dexpreopt config and bootjar is in the dir including
DeviceName(). It causes unnecessary dexpreopt invocation when target is
changed repeatly. To avoid it, rename dir to common name.
Bug: 278833696
Test: m
Change-Id: I2818d9ae09e6c22ca6989cc8efdb70b470ec502c
This fixes the Golem regression caused by aosp/2453067. On Golem, the
profile disabled and dex2oat uses the default "speed" compiler filter.
Bug: 269230245
Test: art/tools/golem/build-target.sh --machine-type=android-armv8 --golem=art-interpreter
Change-Id: I4fc0dbf9eac8839f7bacd264ddab177956ddd58e
After this change, the dependency hierachy can be arbitrarily deep. For
example, you can have one boot image that extends another boot image
that extends yet another boot image.
Bug: 269230245
Test: m
Change-Id: I096d0b57bda36b982ecc97378647f9c59071a3bf
After this change, the compiler filter can be specified by the option,
and profiles will not be used if the compiler filter is not
a profile-guided one.
This change also allows preloadedClassesFile to be empty.
Bug: 269230245
Test: m
Change-Id: I65e6b7209d2f0510bcc784a62623ab402b7f96bb
This change is a no-op change. It doesn't enable userfaultfd GC by
default. ENABLE_UFFD_GC=true can be passed to the build system to enable
userfaultfd GC for testing purposes.
Bug: 242553398
Test: -
1. lunch aosp_oriole-userdebug
2. ENABLE_UFFD_GC=true m
3. See "--runtime-arg -Xgc:CMC" in .invocation files.
Change-Id: I789b49a71b9604fd41bf1ef77d0ac5bac4cbdf25
Previously, in a build containing source and prebuilt art
bootclasspath_fragments, the bootImageVariant.licenseMetadataFile was
set twice with the source always being set after the prebuilt and
so winning.
This change only sets bootImageVariant.licenseMetadataFile for the
active module so it will use the prebuilt's license file if that is
preferred.
Bug: 245956352
Test: m nothing
Change-Id: I948c7e5123169452f67c85ad98c4bbdb90a5d2de
The use of this field to return information from buildBootImageVariant
up the call stack to one of the callers resulted in data races being
detected. This change simply passes the deviceInstalls up the call
stack.
Bug: 245956352
Test: m nothing
go test -race ./sdk/... -run TestSnapshotWithBootclasspathFragment_ImageName -test.count 100
# Run the previous command without this change and sometimes it
# shows the data race around deviceInstalls. When run with this
# change it reports no data races.
Change-Id: I3c73920dcb17a6c89a63c6a9c3a0bb049a98a690
The use of this field to return information from bootImageProfileRule
up the call stack to one of the users resulted in data races being
detected. This change simply returns the profile path back up the call
stack.
Bug: 245956352
Test: m nothing
go test -race ./sdk/... -run TestSnapshotWithBootclasspathFragment_ImageName -test.count 100
# Run the previous command without this change and sometimes it
# shows the data race around profilePathOnHost. With this change
# that data race is not reported. Although there is still another
# data race.
Change-Id: I03b09e514cc94f2a6c9d5117d3b2f130cc2e4f5b
Add warnings to the structs to explain how they are supposed to be used
and deprecate fields that are used incorrectly.
Bug: 245956352
Test: m nothing
Change-Id: I090698287b96fd37102b88beb5d7252977bddc54
In that file, we can list methods which we want to compile but that our
boot image profiling implementation did not cover.
Test: m
Bug: 235557326
Change-Id: I839727c231a09b9208d00f3205996f2add8779bd
Track the license metadata file of the module used to dexpreopt
bootjars and pass it to Make.
Bug: 224612665
Test: m alllicensemetadata reportmissinglicenses
Change-Id: I8466c3d8edf7dc44976c2a343bd38799c6617db2
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
It is the default, and hence unnecessary to pass explicitly. This
allows some other compiler filter to be passed through BootFlags.
Test: m out/host/linux-x86/apex/art_boot_images/javalib/x86_64/boot.oat
on master-art and check that it doesn't change
Test: m droid
on master and check that
out/soong/.intermediates/art/build/apex/com.android.art/android_common_com.android.art_image/image.apex/javalib/x86_64/boot.oat
and out/target/product/vsoc_x86_64/system/framework/x86_64/boot-framework.oat
are identical.
Bug: 174746397
Change-Id: Ie281e55aaa641d5fd8dcc5c7e201c7870cc934c1
Historically, this file was used by the `--updatable-bcp-packages-file`
flag for dex2oat. The flag is no longer needed and is being deprecated.
Unfortunately, we cannot remove `permitted_packages` and all the code
related to it because we still need it for checking the module
compatibility with Q and R.
Bug: 200241946
Test: m nothing
Change-Id: Ie3be54fd47a847ba0caf627d12da76b415d99466
Soong checks that every module part of a bootclass_fragment provides a
dex boot jar file, even if the module is not a dependency of vendor.img
Using AllowMissingDepdencies() to skip this check allows vendors to be
more aggressive in removing projects from their source tree
Test: In build/soong, run go test ./...
Test: m nothing
Bug: 196306898
Bug: 192616764
Change-Id: I78b062afdc19a6a3251aa8552230f3fcf334b6fb
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
