Dexpreopt files use RuleBuilder.Install() that installs the file from
Make. By calling PackageFile, this information is also shared to
soong PackagingSpec.
Bug: 339314890
Test: See if .prof, .bprof, and vdex files are installed with
"m aosp_cf_system_x86_64"
Change-Id: I42167603ecfd4334e4f35602bdf03a21846fc798
This allows using select statements with it.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I6f3efaaa3d82505e38a91ee4ba0e18e404360191
Merged-In: If355d24506e3f117d27b21442a6c02bca3402dc7
There are a couple of instances in apex/ and java/ that rely on the naming
convention that the jars exported by prebuilt apexes follow the name of
the java_sdk_library_import, minus the prebuilt_ prefix. With muliple
module sdk prebuilts in trunk stable, this naming convention might not
be valid. Use `source_module_name` instead.
```
prebuilt_sscp_fragment {name: "", contents: ["service-foo.v2"]}
java_import {name: "service-foo.v2", source_module_name: "service-foo"},
```
We should use service-foo and not service-foo.v2 because
1. The prebuilt apex contains service-foo.dex
2. PRODUCT_*JARS will contain service-foo and not service-foo.v2
For clarity, this CL does not drop the current mechanism where prebuilt bcp
fragments create a dependency edge to prebuilt java or java_sdk_library
imports. There is still some discussion around whether we can remove
that completely (b/320711431). If we were to do that, then the
Android.bp files will become
```
prebuilt_sscp_fragment {name: "", contents: ["service-foo"]}
```
Bug: 322175508
Test: Added a unit test
Test: In internal, lunch cf_x86_64_only_phone-next-userdebug && m
nothing # .ninja files identical
Test: In internal, created a parallel set of v2 prebuilts of
java_sdk_library_import and prebuilt_bcp_fragments for adservices && m
nothing # build passes
Change-Id: Ia899d75e826fa1a559368d706eaa65835f748d40
How it works:
1. build/make/core/Makefile generates a txt file with the kernel
version, which is taken from an explicit BOARD_KERNEL_VERSION value,
or extracted from the kernel image on the source tree, or extracted
from the kernel image extracted from the prebuilt boot.img.
The file is saved at
$ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt.
2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to
be determined by the kernel version, build/make/core/Makefile copies
kernel_version.txt to
out/soong/dexpreopt/kernel_version_for_uffd_gc.txt.
3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to
out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an
explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py,
which reads kernel_version_for_uffd_gc.txt and determines the flag
accordingly.
4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt.
5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on
the same logic.
Bug: 321751629
Bug: 319554951
Bug: 318763448
Bug: 319648491
Test: m --no-skip-soong-tests nothing
Test: atest uffd_gc_utils_test
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no
UFFD support -
1. Check the existence of `-Xgc:CMC` in
out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation
(dex2oat invocation for a boot image)
2. Check the existence of `-Xgc:CMC` in
out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation
(dex2oat invocation for an app defined in .bp)
3. Check the existence of `-Xgc:CMC` in
$ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation
(dex2oat invocation for an app defined in .mk)
4. Check the value of ro.dalvik.vm.enable_uffd_gc in
$ANDROID_PRODUCT_OUT/product/etc/build.prop
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with
UFFD support, and do the steps above.
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps
above.
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps
above.
Change-Id: I035ad32233e49e2a30ce11f6c7c318a648511ef8
Move fields in bootImageConfig that are written during
GenerateAndroidBuildActions into a provider to avoid a data race.
Test: go test -race ./...
Change-Id: I0d6783530843889b96f32d748bda7824493d2e32
hiddenapi processing require boot jars from apexes to determine the full
set of methods available at runtime.
When building with prebuilts, this comes via
java_import/java_sdk_library_import, which acts as a hook for
prebuilt_apex/apex_set. If we have multiple apexes in the tree, this
hook becomes 1:many. This CL prepares platform_bootclasspath to select the right
deapexerd .jar files when mutliple prebuilts exist.
Implementation details
- Create a dependency edge from platform_bootclasspath to
all_apex_contributions (DepsMutator)
- For every boot jar, query all_apex_contributions to get the path to
dexjar file (GenerateAndroidBuildActions)
Some other important details
- This CL does not drop the old mechanism to get the dex file (i.e. by
creating a dep on java_library). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
- This CL has a functional change when building with source apexes. At
ToT, the unecoded hiddenapi dex jar is used for package check and
generating the monolithic stub file. After this change, the hiddenapi
encoded file will be used for these operations.
This should be fine since the
package and dex signature do not change across the encoded and
unencoded dex file. In fact, we already have a split today. When
building with prebuilts, we use the encoded dex file. When building
with source, we use the unecoded dex file.
Test: Added a unit test
Test: Manual testing in internal described below
- lunch cf_x86_64_phone-next-userdebug
- flagged com.google.android.adservices using apex_contributions
- aninja -t commands out/soong/hiddenapi/hiddenapi-stubs-flags.txt # no
diff before and after
Bug: 308790777
Change-Id: I72c70f0ae1b587679203ea254c9c12a48e7aa782
hiddenapi and dexpreopt require boot and system server jars from apexes.
When building with prebuilts, this comes via
java_import/java_sdk_library_import, which acts as a hook for
prebuilt_apex/apex_set. If we have multiple apexes in the tree, this
hook becomes 1:many. This CL prepares dex_bootjars to select the right
deapexerd .jar files when mutliple prebuilts exist.
Implementation details
- Update prebuilt module types (prebuilt_apex/apex_set) and source
apexes to set a map of
library name to dex jar path on host.
- dex_bootjars will access the path of the .dex jar on host via the
provider. These then
copied/installed to the right locations.
This CL does not drop the old mechanism to get the dex file (i.e. by
creating a dep on java_library). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
Bug: 308790457
Test: git_master-art-host:art-gtest https://android-build.corp.google.com/builds/abtd/run/L21500030000926533
Test: git_main:art_standalone_dexpreopt_tests https://android-build.corp.google.com/builds/abtd/run/L99000030000891212
Test: Added a unit test that checks that the right .jar is selected
when multiple prebuilts exists
Change-Id: I6ef94135b9303a35135810930af4b641df13a583
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
