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
The Modules() method was for the ART boot image in the ART APEX. It's no
longer needed because we don't install the ART boot image in the ART
APEX anymore.
Bug: 290583827
Test: m nothing
Change-Id: I674a5fa1ed18908413a64129df5947c7d26e638e
Since the name of the java_library generated from sdk_library per api
scope does not depend on the build configuration anymore, all
dependency switching "magic" via android.JavaApiLibraryName() can be
removed.
This change also removes from-text-build-specific test cases, as those
test cases depend on build configurations.
Test: m nothing && m nothing --build-from-text-stub
Bug: 287340610
Change-Id: I3bac35259e0cbaa16432a46cb2b128951c9bc075
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
Hiddenapi processing uses the stub libraries to determine the api
surface boundaries. Use JavaLibraryName function to redirect the usage
of stubs from .txt files based on config.
This should be a no-op for now.
Bug: 271443071
Test: go test ./java
Change-Id: I1ed3ab2485c903bc57f627dc1acf1a3fbc0a3c4d
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
Previously, as all versioned sdk snapshots have been removed from
Android.bp files this method would always return false. This change
effectively replaces all calls to it with false, and then optimizes
away any unused code.
Bug: 260237150
Test: m nothing
Change-Id: I1b717ee8345e807bd888451f6e7e3c3a0d391ee2
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
This reverts commit ff9b6faba2.
Reason for revert: No longer needed
Bug: 194063708
Test: m nothing
Change-Id: Ic2f6761c9a0a00a612724cb429f002a16522e53f
When an sdk snapshot is targeted at release X then it cannot include
bootclasspath fragment libraries which are not present in that build as
otherwise it causes build failures. It should also not include any
unsupported libraries, i.e. libraries that cannot work on that release.
This change causes sdk snapshot to exclude libraries that have a
min_sdk_version > target build release
It also ensures that hidden API flags do not include any information
from excluded libraries.
Bug: 240406019
Test: BUILD_NUMBER=fixed packages/modules/common/build/mainline_modules_sdks.sh
# Ran the previous command with and without this change to make
# sure that this change excludes framework-connectivity-t library from the
# tethering sdk snapshot for S, including from the hidden API flag files.
Change-Id: I57969b85a12e9e5a3fc76c055b260cec5d5f7d7f
Previously, the sdk snapshot and platform_bootclasspath both used the
HiddenAPIInfo/Provider to retrieve the hidden API related information
they needed. This change separates them by adding a new
HiddenAPIInfoForSdk/Provider that is used to provide the information
needed by the sdk snapshot. This allows a follow up change to generate
different information for the sdk and for the platform depending on the
target build release of the sdk snapshot.
Bug: 240406019
Test: packages/modules/common/build/mainline_modules_sdks.sh
# Ran the previous command with and without this change to make
# sure that this change does not change the sdk snapshot
# contents.
Change-Id: I30cea6cf8dae1be467b7063430d6197e5baa684b
Previously, the rules for encoding hidden API flags into dex files were
generated in the hiddenAPIRulesForBootclasspathFragment alongside the
rules for creating the hidden API flag files.
This change separates the encoding from the generation of the flags.
This will allow a follow up change to generate API flags for the sdk
snapshot separately without affecting the encoded dex files.
Bug: 240406019
Test: m nothing
Change-Id: I3ab3ff5780e7b2e322665d3ea15f1438f2e403bd
Previously, hidden API properties were only allowed on
bootclasspath_fragment and platform_bootclasspath module types. This
change allows them to be specified on java_sdk_library modules too. It
involves the following changes:
1. Add the properties to the java.Module.
2. Populate and provide a HiddenAPIPropertyInfo struct from
java_sdk_library modules.
3. Modify bootclasspath_fragment to merge information gathered from its
content libraries as if it was specified on the fragment itself.
Bug: 240406019
Test: m nothing
packages/modules/common/build/mainline_modules_sdks.sh
# Ran the previous command with and without this change to make
# sure that this change does not change the sdk snapshot
# contents.
Change-Id: I64eb71c2039ddc14cf380689d0cec7ec221f5b88
All usages of HiddenAPIFlagFileProperties use it as the type of a
Hidden_api field. This change pushes the field inside the struct and
just embeds the struct inside the structs that need it making it
simpler and more consistent with how the HiddenApiPackageProperties
struct is used.
This is extracted as a separate change as while the change is simple
it does affect a lot of lines. Keeping it separate makes it easier to
review the changes.
Bug: 240406019
Test: packages/modules/common/build/mainline_modules_sdks.sh
# Ran the previous command with and without this change to make
# sure that this change does not change the sdk snapshot
# contents.
Change-Id: I664453029574ef68dc5712f7bf137a1a6e78e864
In preparation for adding hidden API properties to individual
java_sdk_library modules this change refactors the handling of that
information.
1. Renames HiddenApiPackageProperties to HiddenAPIPackageProperties
to be consistent with other similar structs.
2. Creates a new HiddenAPIPropertyInfo struct to be used to provide
property derived information from one module to another. It includes
both flag files as well as the information about which packages are
used.
3. The HiddenAPIPropertyInfo is embedded within the existing
HiddenAPIFlagInput in place of the existing flag files field.
4. The fields in the HiddenAPIPropertyInfo struct are populated from
the HiddenAPI*Properties structs.
5. Access to package information is retrieved from the info struct
instead of directly from the properties. That means that no changes
will be needed to this code when info from other modules is merged
into the struct in a follow up change.
Bug: 240406019
Test: packages/modules/common/build/mainline_modules_sdks.sh
# Ran the previous command with and without this change to make
# sure that this change does not change the sdk snapshot
# contents.
Change-Id: I773279a4b621bcc3c40e3bfe193f2c7b0caeccd6
Specifying an apex in the apexes propety will cause all the
*classpath_fragments that are contents of the APEX to be automatically
added as members of the sdk and appear in the snapshot.
The purpose of this change is to dedup the APEX and sdk definitions and
try and avoid some of the issues that we have been finding while
attempting to build against the prebuilts.
Two tests, one each for bootclasspath_fragment and
systemserverclasspath_fragment, have been refactored to compare the
output when adding the *fragment to the sdk directly of via the APEX.
That ensures switching to use the APEX will not change the sdk snapshot
unless it was previously missing a *fragment.
There was also a slight difference in where the hidden API flags were
copied from. That should have no impact on the output as the flags are
identical.
The sdk snapshot generation needed some tweaks to avoid generating a
prebuilt for the APEX.
Bug: 232401814
Test: m nothing
Change-Id: I7aaf16a3a0ab4bebf97765d1484215cc008dc4b8
Previously, the split_packages, single_packages and package_prefixes
properties were all optional and the split_packages defaulted to ["*"].
As that value conflicted with the other package properties that meant
that split_packages always had to be specified even if it was to just
set it to an empty array.
This change requires at least one of them to be specified and defaults
split_packages to an empty list which means it is not required,
although it can be helpful to make that explicit.
Bug: 194063708
Test: m nothing
Change-Id: I5a4c2d68e72e39f5c4a2441326dfce8685fc8ff2
Treats bootclasspath_fragment modules that have not yet been converted
to test modules as if they were test modules. This is a temporary work
around to ease the migration to bootclasspath_fragment_test modules and
is expected to be reverted.
Bug: 194063708
Test: m nothing
Change-Id: I093fbec4e926719b644c64ebfc63f9e3070e28db
This is needed to allow the behavior of the bootclasspath_fragment to
be tweaked for test fragments.
Bug: 194063708
Test: m nothing
Change-Id: Iee5c09d5b580d088ba081d95a788dbde883078ed
Needed to allow change https://r.android.com/2089503 to be reapplied.
Bug: 232106778
Test: Apply the change and then run
m EMMA_INSTRUMENT=true nothing
Change-Id: I92d19c51cc828295ba13951e65911db707f0f2ba
Previously, the bootclasspath_fragment's hidden_api.split_packages and
hidden_api.package_prefixes properties did not specify an exhaustive
set of packages that were provided by the fragment. They excluded
packages which were either not split or which could not be used as a
package prefix because it would match sub-packages provided by other
bootclasspath modules.
This change adds the hidden_api.single_packages list to specify those
additional packages and then uses that information to verify that any
bootclasspath_fragment that specifies at least one of split_packages,
single_packages or package_prefixes properties only contains classes
from a package that matches one of those properties. That will
prevent a module from accidentally including unexpected classes, such
as might happen when statically including a common utility library.
It also adds coverage specific versions of the properties as additional
packages are added to the art-bootclasspath-fragment when building
coverage builds.
Bug: 194063708
Test: atest signature_patterns_test
m out/soong/hiddenapi/hiddenapi-flags.csv
m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true out/soong/hiddenapi/hiddenapi-flags.csv
# Breaks without corresponding change to add android.system to
# the art-bootclasspath-fragment.
/usr/bin/pylint --rcfile $ANDROID_BUILD_TOP/tools/repohooks/tools/pylintrc scripts/hiddenapi/signature_patterns*.py
pyformat -s 4 --force_quote_type single -i scripts/hiddenapi/signature_patterns*.py
Change-Id: Iddf6c59cd4dc8c36dde7943a9840ccef5794b320
Make this consistent with how code names are used in the rest of Soong.
Bug: 204763318
Test: m nothing
Change-Id: I1f2f40310df9d619db6aaaad3ed7339bb5e79194
This change is similar to aosp/1947127, but for prebuilts.
After this change, if `bootImageConfig.installDirOnDevice` is set to a
path outside of the APEX, the build system will build a boot image from
the dex files and the profile extracted from the prebuilt APEX.
Otherwise, it keeps the current behavior: extracting the boot image from
the prebuilt APEX.
This is a no-op change. Current behavior is not affected.
Bug: 211973309
Test: m nothing
Test: -
On internal master:
1. Patch aosp/1947128.
2. Patch ag/16743847 and ag/16746804.
3. m SOONG_CONFIG_art_module_source_build=false com.google.android.art
4. See the boot image being installed in `/system/framework/<arch>`.
Change-Id: I24ca525309fecaf3ab7a67960fbf118cd00ecd1d
Same pattern used for com.android.sdkext / test_framework-sdkextensions
Test: m nothing
Test: also tried this with related CLs that make use of this
functionality
Bug: 195732042
Change-Id: I5adfb0e8650e2e262bf646e56b29965798d0a42f
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
