Previously, an []android.Module was converted to an []hiddenAPIModule
that was then used to retrieve boot dex jars. That was ok when
obtaining the dex jar files from source modules for
bootclasspath_fragment but does not work well for other use cases as
it would require doing that conversion in multiple places.
This change pushes the use of hiddenAPIModule down to the methods that
retrieve information from it which makes the methods more flexible and
easier to reuse.
Bug: 177892522
Test: m nothing
Change-Id: Ib84aaf03d8f5a63b48232036fe4589646fc23352
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
This will export some hidden api related types and fields so they can
be used from outside the java package. This is needed to allow a follow
up change to move the TestPlatformBootclasspath_Fragments from the java
to the apex package.
Bug: 179354495
Test: m nothing
Change-Id: Ib69eea9d79cc83b8e3fc29919a29f071e1ec17b5
Previously, the hidden API flags generated for a bootclasspath_fragment
did not include removed API members. That was because it did not supply
a file containing the dex signatures of the removed API members.
The monolithic hidden API processing uses combined-removed-dex which is
the output of a genrule that takes as input the *removed.txt files from
all the APIs and uses metalava to construct the dex signatures file.
This change does the equivalent for the *removed.txt files for the APIs
provided by a bootclasspath_fragment and then passes them to the rule
that generates the final all-flags.csv.
Bug: 179354495
Test: - Update packages/modules/RuntimeI18N to enable hidden API
processing.
m out/soong/hiddenapi/hiddenapi-flags.csv
- Before this change that fails as the flags generated for the
i18n-bootclasspath-fragment differ from the monolithic flags.
After this change that passes.
- Verify that this change does not change any of the monolithic
hidden API files.
m com.android.i18n
- Verify that the apex file before and after this change are byte
for byte identical.
Change-Id: I6a21edb8a5231666e3f35b2c99a8687f36dd98fd
Encapsulating the information needed by hidden API processing in a
struct makes it easy to add additional information in future and allows
the code to populate that struct from various different sources to be
grouped together.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Change-Id: I53805737dff36a3ae87aca5aad51cf46ae1361fe
The hiddenAPIFlagFileInfo was being used for both the input and output
of bootclasspath_fragment and platform_bootclasspath and also to pass
information around to various hidden API rule methods. Supporting
multiple different uses in this way made it hard to reason about.
This change creates a separate structure for use by the
platform_bootclasspath. Follow up changes will split out other
functionality into separate types.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Change-Id: Ia5c5f65ae5645486c42819c669a8601588217f88
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
The AlwaysUsePrebuiltSdks() causes all java_sdk_library_import modules
to be preferred over the source, i.e. as if they had prefer: true set.
That interacts badly with the work that is being done to integrate the
bootclasspath_fragment/platform_bootclasspath modules into the build.
It would work fine once that integration has been completed but in the
interim it causes problems. e.g. it does not cause a problem in AOSP
because those java_sdk_library_import modules that are affected have
already been integrated into the build properly.
Unfortunately, internally that is not the case because there are
java_sdk_library/java_sdk_library_import modules that still need to
be updated.
Before the java_sdk_library_import can be safely preferred each
java_sdk_library/java_sdk_library_import module that contributes to the
bootclasspath must:
* Be in the contents of matching bootclasspath_fragment and
prebuilt_bootclasspath_fragment modules.
* Have an apex and one of a prebuilt_apex/apex_set that contains the
dex implementation jar and lists the prebuilt_bootclasspath_fragment
name in its exported_bootclasspath_fragments property.
Safely preferred in this context means that the whole build will
continue to work rather than the current situation which is that only
some of the build will work and some will fail if an attempt is
actually made to build it.
Unfortunately, many java_sdk_library_import modules are missing:
* The prebuilt_bootclasspath_fragment.
* The exported_bootclasspath_fragments property on the
prebuilt_apex/apex_set that contains them.
Together these cause the following symptoms:
1. The java_sdk_library_import does not have a dex implementation jar.
2. The java_sdk_library_import does not have a myapex variant.
These workarounds will avoid Soong reporting build failures. However,
the build will still fail if an attempt is made to build anything
produced by the platform-bootclasspath, e.g. hidden API processing or
a system image.
Bug: 188505921
Bug: 179354495
Test: m TARGET_BUILD_APPS=Calendar
Change-Id: I3226e21cd6a7f9e4d6bbe94e54129ac5e1d4c679
Merged-In: I3226e21cd6a7f9e4d6bbe94e54129ac5e1d4c679
.. in preparation for the upcoming change. This change doesn't alter any
behavior.
InApexes is a misleading name. People expects that it has the list of
soong module names of the APEXes that a module is part of. So, for
example, `core-oj` is a part of both `com.android.art` and
`com.google.android.art`. However, in reality, that's not true. The
field has `com.android.art` only. This is because the two APEXes
(android and Google) have the same apex name which is `com.android.art`.
That apex name is used in various places like the `apex_available` and
allows us to keep using the same name regardless of whether the APEX is
overridden or not.
However, this is causing problems in some cases where the exact list of
soong module names is required. The upcoming change will add a new field
to handle the case and the new field actually will get the name
'InApexes'. So, the existing field is renamed to a less misleading name
`InApexVariants`.
Bug: 180325915
Test: m nothing
Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436
Previously, the monolithic hidden API files, e.g. hiddenapi-index.csv
file, were generated in two steps. First, each module created its own
files using the information in its class jars. Then, the monolithic
files were created by merging those module specific files into a larger
file.
This change switches to generating the monolithic files directly from
the class jar files and bypassing the intermediate files.
In order to ensure that this change did not change the monolithic files
it is necessary for the hiddenapi-metadata.csv to go through a
reformatting step. Hopefully, this will be able to be removed in a
follow up change.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I5a78e747516014b7c0f402a4b4431b14be6a84b2
A java_sdk_library specified in the bootclasspath_fragment contents
must be providing APIs for the bootclasspath_fragment and so must be
treated as if they were specified in the stub_libs. This avoids having
to specify them in both contents and stub_libs.
Bug: 179354495
Test: m nothing
Change-Id: I535065ee1a79b439e2676f35e06a75d4626adcaf
This change adds support for generating the hidden API flags for the
contents of a bootclasspath_fragment. Currently, it will only work for
the art-bootclasspath-fragment as it has no support for creating
dependencies between bootclasspath_fragment modules which will be
needed for handling any other bootclasspath_fragment.
The hidden API flag generation added by this change is completely
separate to the normal hidden API processing and is not as yet encoded
in dex jars so will have no effect on the runtime.
The generated files are provided for use by other modules and copied
into the sdk snapshot. That is needed to allow the build to verify that
the hidden API flags generated by the individual bootclasspath_fragment
modules are consistent with the flags generated for the whole
bootclasspath, whether building from source or prebuilts.
Bug: 179354495
Test: m art-module-sdk
m out/soong/.intermediates/art/build/boot/art-bootclasspath-fragment/android_common_apex10000/modular-hiddenapi/all-flags.csv
m out/soong/hiddenapi/hiddenapi-flags.csv
- test that the former file is a subset of the latter and that
where they overlap they are identical.
Change-Id: Ie27303e2960953db1b7abe95510e3bca4411b09a
Moves the building of boot images from the dexpreopt_bootjars singleton
to the bootclasspath_fragment and platform_bootclasspath.
The art boot image is generated by the art-bootclasspath-fragment
module and the framework boot image by the platform-bootclasspath
module.
This does temporarly duplicate the generation of an identical boot
profile for each image. As part of the work to modularize the boot
image profile each image will have its own custom default boot profile.
Bug: 177892522
Bug: 186455808
Test: m droid and TreeHugger
Change-Id: I23cf05ec7648749b21c7cf6fcba282b46649a981
The art dex files are copied in the bootclasspath_fragment and the
non-updatable and updatable dex files are copied in the
platform_bootclasspath.
Bug: 177892522
Test: m nothing
Change-Id: I5d3d533d1a7a9f8e7ae20c12eb33029a898a2cd6
- Adds all required details for bootclasspath_fragment to implement
classpath_fragment.
- Keeps the actual boot jars in platform-bootclasspath to begin with.
- Makes sure to put the file in apex/etc/classpath on device. Note that
for platform versions of classpath fragment AndroidMkEntries perform
the installation, while for APEXes it must be plumbed via apex.go.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I6101ebdf5b8bcbe95c0b7ce21f3f67a2685aef50
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
Boot jars are different to system server jars at build level, due to
added complexity of dexpreopt. As a logical separation add a new
classpath fragment type and split existing classpaths.proto generation
into relevant pieces.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I88bec09fc920166ffd0092faef980754ddeb6593
Maintain compatibility with previous behavior by ignoring dex_import
during hidden API processing.
Bug: 179354495
Test: m nothing
Change-Id: I976b02129bf981b7b61dce233567d6f89e04f92d
The previous attempt, which simply skipped the hidden API processing
altogether when unbundled builds were enabled failed when attempting to
build module snapshots as while they enabled an unbundled build they
actually need the hidden API processing to be performed.
This change just checks whether missing dependencies are allowed and if
so it fakes up any missing files so that the build will only fail if
they are not present AND they are used.
Bug: 186695448
Bug: 185828824
Test: tapas Calendar
m -j60
Change-Id: Ie13fed05af0aba51f45f6791fce944d0e4285037
The getBootImageJar function will be removed once the boot image
creation has been moved to the platform_bootclasspath and
bootclasspath_fragment module types. However, the consistency checks
that it performs are still useful so this change moves them out
first.
The ART boot image related checks are now performed in the
bootclasspath_fragment module type. A previous change accidentally
disabled the checks when the contents property was not empty which has
been fixed. Also, the error messages have been tweaked to make it clear
that the art-bootclasspath-fragment is now the source of truth as to
its contents not the configuration.
The framework boot image related checks are now performed in the
platform_bootclasspath module type.
Initially, this change included an extra check to make sure that
UpdatableBootJars comes from updatable APEXes but that broke because
framework-wifi and framework-tethering are not currently marked as
updatable in AOSP.
Bug: 177892522
Test: m nothing
Change-Id: I80fb600fa2c7cec4566b3461c6a33c4c6f0743f4
Bug: 179354495
Test: rm out/soong/make_vars*
m nothing
grep INTERNAL_PLATFORM_HIDDENAPI_FLAGS out/soong/make_vars*
- make sure it is still out/soong/hiddenapi/hiddenapi-flags.csv
Change-Id: I86e56512a9a2091f446bad25294d41ea1f4341ee
This is needed in order to allow it to implement MakeVars so it can
create make variables just like the dexpreopt_bootjars and hiddenapi
singletons currently do.
Bug: 177892522
Bug: 179354495
Test: m nothing
Change-Id: Ida5bf8abeecde531e1f6430151650065445804ac
Bug: 177892522
Test: m oat-dump-boot
- test output to make sure that this change does not change the
generated files, at least no more than no changes do as the
output from this rule is not deterministic. See b/186459873.
Change-Id: Ib2b4203d9bb1fd0ee9443aee4e58b54b38b491cf
Changes generateUpdatableBcpPackagesRule to use ModuleContext instead
of SingletonContext and moves the call from dexpreoptBootJar's
GenerateSingletonBuildActions method to platform_bootclasspath's
GenerateAndroidBuildActions.
Bug: 177892522
Test: lunch art_module_arm64
m out/soong/module_arm64/dex_bootjars/updatable-bcp-packages.txt
- make sure it is not affected by this change
Change-Id: I9741ae1eb9573cafe12dd7a17dc1d8449b224dc8
Bug: 177892522
Test: lunch art_module_arm64
m out/soong/module_arm64/dex_bootjars/updatable-bcp-packages.txt
- make sure it is not affected by this change
Change-Id: I3d35f1664cbbaba5df3f5809859dd9815a26d05d
Trades having to traverse a module's direct dependencies multiple times
for reusable code. While at the minute the amount of duplicated code is
small (checking a tag and appending to a list) follow up changes will
modify the gatherApexModulePairDepsWithTag module to improve error
reporting greatly increasing the benefit of deduping.
The cost of traversing a module's direct dependencies is very small as
there will be only a very few dependencies.
Bug: 177892522
Test: m nothing
Change-Id: I16389102abd8038e1bfa52b63f4153bdf92ff553
Changes bootFrameworkProfileRule to use ModuleContext instead of
SingletonContext and moves the call from dexpreoptBootJar's
GenerateSingletonBuildActions method to platform_bootclasspath's
GenerateAndroidBuildActions.
Changing the context also allows the code to switch from
bootFrameworkProfileRule to GetGlobalSoongConfig.
Also extracts the shouldBuildBootImages function so it can be used by
platform_bootclasspath to preserve the existing behavior.
Bug: 177892522
Test: m droid
Change-Id: I30d3ca10be7f84348ad3aa9cc984dd15b8f6f4e9
The BootImageInfo is used to populate an apex. A platform_bootclasspath
module cannot be part of an apex so does not need to provide one.
Bug: 177892522
Test: m nothing
Change-Id: I1e1c4962d9d8106a12af80107c4c35828f54ff81
Adds a BootclasspathDepsMutator that is currently only implemented by
the platform_bootclasspath but which can be implemented by
bootclasspath_fragment too.
Bug: 177892522
Test: m nothing
Change-Id: Ibe35854281004d6e40bf1f797144fb582e8c08b9
The platform_bootclasspath and bootclasspath_fragment modules provide
different capabilities but are related and so have some common
functionality. This change moves some platform_bootclasspath code that
will be of use for bootclasspath_fragment in future into a separate
file.
Bug: 177892522
Test: m nothing
Change-Id: I827b85e33d16155fcc920d553100c9e99267dc4e
As part of that this change:
* Moves code that will be common to platform_bootclasspath and
bootclasspath_fragment from hiddenapi_singleton.go into
hiddenapi_modular.go.
* Fixes the tests in hiddenapi_singleton_test.go but intentionally
does not rename them or move them into a more appropriate place so
as to make it easier to see the differences. A TODO has been added
and these will be cleaned up in a follow up change.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I680e4dab2e6bdf4a655fa9f255c195175904667e
Aggregates hidden API flag files from the bootclasspath_fragments which
will allow the hidden API flag files in frameworks/base/boot/hiddenapi
to be modularized and moved to the appropriate repo.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
also verified that changes to the fragment provided files do
affect the monolithic files.
Change-Id: Ifce14c9ef24c58c7ab1085475d85b61cfbfefecd
This change moves the monolithic hidden API index file creation rule
from the hiddenAPISingleton into the platform_bootclasspath.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ib25be3618e30a83dc2929a18062eb58eefdabefb
This change moves the monolithic hidden API index file creation rule
from the hiddenAPIIndexSingleton into the platform_bootclasspath. It
also moves the corresponding test from java/hiddenapi_singleton_test.go
to java/platform_bootclasspath_test.go.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ia295d0f7ae9b51ea816f16921aa42339ed91704e
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
Checks to make sure that every module that is part of the platform
bootclasspath has been initialized property for hidden API processing.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ic4368963f2011784b537b8aebf5ef97ea22b2db5
As part of the work to modularize the hiddenAPI processing the
generation of the monolithic hidden API index file needs to be moved
to the platform_bootclasspath module type. Doing that broke the
TestBootDexJarsFromSourcesAndPrebuilts tests which checks the inputs to
the rule that creates that file. Fixing that required added a
platform_bootclasspath module to the test fixture for those tests which
highlighted an issue with the prebuilt_apex module.
Previously, when the prebuilt_apex created apex variants it would use
its own name as the apex variant name, even when that name included the
prebuilt_ prefix. That broke the platform_bootclasspath logic as it was
looking for apex variants for "myapex" but the only ones available were
"prebuilt_myapex".
This change ensures that it always uses the unprefixed name and fixes
the TestNoUpdatableJarsInBootImage to match. This also adds some
improved error reporting in platform_bootclasspath which helped debug
this problem.
Bug: 177892522
Test: m nothing
Change-Id: I3e88b5cec767f77dcc0e94b3ae38b499d07eadf0
Previously attempting to use m UNSAFE_DISABLE_HIDDENAPI_FLAGS would
cause a build failure.
It is necessary when UNSAFE_DISABLE_HIDDENAPI_FLAGS=true to create
empty files for the monolithic files so that those usages which are not
protected by the build flag, e.g. in dists or CTS tests like
CtsHiddenApiBlocklistTestApiTestCases do not cause ninja failures due
to reliance on a file that does not exist and has no rule to create it.
Bug: 177892522
Test: m nothing
m UNSAFE_DISABLE_HIDDENAPI_FLAGS=true CtsHiddenApiBlocklistTestApiTestCases
Change-Id: I05d0b3680dbc0b5b7c7c0d792550faf848829647
Change https://r.android.com/1673266 introduced some code that does
nothing. This change removes that.
Bug: 177892522
Test: m nothing
Change-Id: I349b17c7fe7e2f68a807dab43a4300da7fe0ad4d
Makes the monolithic hidden API files accessible from the
platform_bootclasspath so they can be output to the dist build target
and used by other modules, e.g. by doing something like this:
java_resources: [
":platform-bootclasspath{hiddenapi-flags.csv}",
],
It makes the paths relative to the out/soong/hiddenapi directory rather
than the out/soong directory to make them easier to use in the
java_resources property without changing the structure of the APK.
Without that attempting to use them in a java_resources property will
result in them being copied to a hiddenapi/ within the APK instead of
being used at the top level as existing APKs like
CtsHiddenApiBlocklistTestApiTestCases expect.
Bug: 177892522
Test: m nothing
Change-Id: I829412fc7d25411e0c2e0713d0d219a18f4af2ee
