| Age | Commit message (Collapse) | Author |
|---|
|
Remove a usage of ApexInfo.InApexVariants by collecting the libraryToApex
and apexToFragment mappings while collecting the fragments and passing
them into CreateClasspathElements.
Bug: 372543712
Test: CreateClasspathElementTest
Change-Id: I03adc821b04bc01828f075f25bbb8124505859a7
|
|
When the apex mutator moves to using an info struct instead of a simple
string it becomes difficult to add a dependency directly on the apex
variation of a module, as that would require constructing a matching
ApexInfo to locate it. Simplify adding the dependency by adding it
on the apex instead, and then traversing from the apex to the desired
module inside the apex.
This causes a few changes in behaviors that require updating tests to
match.
When AlwaysUsePrebuiltSdks is set, the previous behavior was to use
the fragment and its dependencies from the source module for the
platform bootclasspath. Since the fragment is now found by traversing
from the apex, and the prebuilt apex is preferred, the fragment from
the prebuilt will now be found instead.
prebuilt_bootclasspath lists fragments in apexes that it depends on.
Previously it would depend on the apex variant of the fragment, which
then allowed the fragment to be replaced by the variant from an
override apex that set apex_name. Now it always depends on the original
apex to find the fragment.
Test: go test ./...
Bug: 372543712
Change-Id: I1a92ff461d4706cf68a0b8b37e53dea412efb8bf
|
|
Move the prebuilt mutators from postdeps to predeps mutators. This
ensures that the decisions on whether the source or prebuilt will
be used can be made earlier, which simplifies the apex and dexpreopt
code, allowing it to directly depend on the correct module.
This requires some mutators that previously ran before the prebuilt
mutator and now run after the prebuilt mutator be aware of prebuilts.
In particular, the cc.linkageTransitionMutator and
rust.libraryTransitionMutator now have to manually disable prebuilts
when they don't produce a static or shared variant that the source
module produces, and some mutators have to ignore PrebuiltDepTag
dependencies when propagating transitions.
The apexTransitionMutator also needs to temporarily use an interface
on the dependency tag to correctly resolve some dependencies that
exist before the apex variation is created onto the correct variation.
This will shortly be replaced with depending on the apex itself instead,
and then walking the dependencies of the apex to find the necessary
module.
Bug: 372543712
Test: go test ./...
Change-Id: If125ea981be87673bae3bd0a7e3b2c16c337e8f7
|
|
All mutators are parallel by default, remove the explicit Parallel()
calls.
Bug: 372540665
Test: all soong tests pass
Flag: EXEMPT refactor
Change-Id: I41e3a71bd13c75b7fceae91b1c4cfe678ab62df2
|
|
To replace soong config module types with selects.
Bug: 342006386
Test: m nothing --no-skip-soong-tests
Change-Id: I76394c0c8e2bc98ec03a3a9d8cff0ba2af4ab0d1
|
|
This allows using select statements with it.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I6f3efaaa3d82505e38a91ee4ba0e18e404360191
Merged-In: If355d24506e3f117d27b21442a6c02bca3402dc7
|
|
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
|
|
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
|
|
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
|
|
necessary.
#codehealth
Test: m nothing
Bug: 179354495
Change-Id: Iaddf163e69b52cef82d522311e81bef9bdb4aa8d
|
|
Previously, the hidden API processing used SdkKind to identify the API
scopes, e.g. public, system, etc. that are of interest for hidden API
processing. Unfortunately, there is a mismatch between the SdkKind and
what hidden API processing needs. e.g. SdkKind includes values that are
not used by hidden API processing and hidden API processing needs
additional API scope specific information not provided by SdkKind. The
apiScope struct used in sdk_library.go is also not a suitable
representation for similar reasons.
This change adds the HiddenAPIScope (following a similar approach as
apiScope) that rectifies that and uses it as a replacement for SdkKind
in most parts of the hidden API processing. The SdkKind is still used
for retrieving information from java_sdk_library[_import] modules.
Follow up changes will extend the HiddenAPIScope with more information.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that this change has no effect on the generated flags.
Change-Id: I97968f58535121652852b8d25217aa288afd2bfd
|
|
Adds support for printing a PropertySet that has a property whose value
is an array of structs.
Bug: 179354495
Test: m nothing
m conscrypt-module-sdk
- check generated Android.bp file
Change-Id: I71be04188465610bcbea4d3c9a5e8204171a1eeb
|
|
Previously, the bootclasspathApiInfo was only used for tests and follow
up changes will need to provide the stub dex jars. This change moves
the stubJarsByKind into HiddenAPIInfo and removes bootclasspathApiInfo
and the corresponding provider.
Bug: 179354495
Test: m nothing
Change-Id: I5459c56de561c053ed671dc9d5cb3ee4820c0ee8
|
|
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
|
|
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
|
|
Change https://r.android.com/1672245 added support to treat
system_ext:foo in the boot jars configuration the same as platform:foo,
at least for dexpreopt_bootjars.go's getBootJar.
This change replicates that mechanism in platform_bootclasspath and as
that now handles hidden API processing also made a similar change in
the isModuleInConfiguredList function.
Bug: 177892522
Bug: 154976937
Test: m nothing
Change-Id: I105f4fbaa3b0355b013b7c5618d218d888faefb6
|
|
The hidden API processing needs access to dex stub jars for the API
scopes provided by the bootclasspath_fragment so that it can mark the
corresponding dex members as being part of that API. This change adds
the ability to specify the modules that provide those jars, resolve the
modules to dex jar stubs and make them available for other modules and
tests to use.
While the stubs are only needed for hidden API at the moment these were
not added to the hidden_api properties section as there are other parts
of the build that may need to access the stubs in future, e.g. api
fingerprint and aidl generation.
The stubs properties can be affected by coverage as when coverage is
enabled the jacoco-stubs needs adding to the list, just like how
jacocoagent is added to the contents.
Bug: 177892522
Test: m nothing
Change-Id: I31097d1ca45c84adeba4cbb38f693698cb289e99
|
|
The code that has been removed triggers in many cases when it should
not, e.g. an unknown module on the bootclasspath. The code was
originally added to try and ensure that if the attempt to add useful
error messages failed it would help debug the issue. However, it ended
up just creating more failures.
If this does become an issue then this will be revisited.
Bug: 177892522
Test: Add an unknown module to PRODUCT_BOOT_JARS
m SOONG_ALLOW_MISSING_DEPENDENCIES=true
Change-Id: I08dbd4b29d301f3f1f78a0fb396687062b47deb8
|
|
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
|