Previously, SdkSpec was constructed only from the user string. It didn't
make use of the Config struct where information about the latest stable
SDK version, etc. is recorded. As a result, the build system couldn't
check if the sdk version "current" is referring to the in-development
(i.e. not-yet-frozen) SDK version or the latest stable version.
"current" was always assumed to be in-development (IsPreview() returns
true) even when Platform_sdk_final == true.
As the first step for fixing that, this change requires
android.EarlyModuleContext to be passed when constructing SdkSpec from
the user string.
In the following changes, "current" will be mapped to either
FutureApiLevel (10000) or one of the FinalApiLevels() depending on
whether the platform SDK was finalized or not.
Bug: 175678607
Test: m
Change-Id: Ifea12ebf147ecccf12e7266dd382819806571543
... in preparation for making the handling of sdk versions consistent
across java and cc modules.
Bug: 175678607
Test: m
Change-Id: I598f0454bce9b7320621022115412fbe97403945
This adds the registration of the mutator to the existing register...
method which will include it in PrepareForTestWithJavaBuildComponents.
Bug: 182885307
Test: m nothing
Change-Id: I6cea716a3ff4d8abdb80543b7e0ddf22246ffa30
Export information about java dependencies through a Provider
instead of accessing the module directly.
Test: java_test.go
Test: no changes to build.ninja
Change-Id: Ifc5d566bf6f6ebc0ad399e948effaa1ef6a22876
Previously CLC construction was scattered across different module types
and dependency tags. This CL moves all logic to one function, which
handles all special cases. This will allow to simplify CLC API and
reduce the number of different ways in which CLC is constructed.
Previously some of the cases failed early (at the time when a library is
added to CLC) if the build/install paths were unknown. Other cases did
not fail early, but were validated later before CLC was used. Late
failures are necessary because some of the libraries with unknown paths
still have to be processed by manifest_fixer (which doesn't need library
paths), but they do not use dexpreopt (which needs library paths). This
CL removes the early failures (all paths are still validated later).
The CLC tests do not fail because they use a private method that toggles
the "strict" flag (that enforces early/late failure mode) manually in
the method call.
The CL also makes a functional change in the way CLC is constructed for
component libraries that have an OptionalImplicitSdkLibrary(), or
libraries that are disguised as SDK libraries via `provides_uses_lib`.
Previously such a component/disguised library X was added to its own CLC
as a sibling element of X's own <uses-library> dependencies, which
created incorrect CLC structure. Now this is handled by addCLCFromDep,
when X is processed as dependency and added as a top-level CLC element
with its sub-CLC properly nested under it.
Bug: 132357300
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I6a512209b87b81d785875f10f76b21c81b2ed579
We had a dependency on each file in the asset directories, but that
wouldn't cause aapt2 to run if a file was removed. Add a dependency
on a file that contains the list of files in the asset directories.
Fixes: 172867096
Test: m CarrierConfig && rm packages/apps/CarrierConfig/assets/carrier_config_no_sim.xml && m CarrierConfig
Change-Id: I35f3b85355fa890a3e95eaa6458a21466b6930e4
If some Java library/app depends on an SDK component library (e.g. stubs
library), then it transitively depends on the SDK library itself
(because the component library has a dependency on its SDK library).
Previously having this transitive dependency resulted in adding the SDK
library to the <uses-library> dependencies of the library/app. However,
this doesn't make sense if the app has a *static* dependency on the
component library. This patch stops adding <uses-library> dependency in
that case.
Bug: 132357300
Test: m nothing
Test: added new Soong test that would previously fail with an error:
invalid build path for <uses-library> "fred"
Change-Id: I697a65e461037c95ec56b6c321afa4ec52ccbbec
This patch reworks the approach introduced in
https://r.android.com/1450819. That patch based the decision which
libraries should be added to the manifest <uses-library> tags by the
manifest_fixer on the "shared" status of the library.
That approach is incorrect for two reasons:
- It doesn't make sense to have a non-shared library in class loader
context ("shared" libraries are those specified in
frameworks/base/data/etc/platform.xml, and they are the only ones
that PackageManager knows about).
- It doesn't make sense to add anything but the top-level of the
class loader context tree to the manifest, because this part of the
tree is flattened to a sequence, and PackageManager cannot restore
it to the previous tree shape (there is an information loss).
This patch removes the "shared" bit of information from class loader
context elements and assumes that all libraries that end up in class
loader context are shared. Consequently, only the top-level libraries
should be passed to manifest_fixer.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Bug: 168686456
Change-Id: I902690f0f38f1047fa79cf6ccbe956077eceaab0
hilt_android requires seven separate annotation processors, which
is only feasible to support using exported_plugins to avoid having
to list all seven in every module that uses it. Unfortunately they
all set generates_api: true. Turbine is already disabled for modules
that directly use a plugin that sets generates_api: true, because
turbine doesn't run annotation processors. Also add support for
disabling turbine if a module transitively uses a plugin that
generates APIs via exported_plugins.
Bug: 173397767
Test: TestExportedPlugins
Change-Id: If70354a3dd67efb4ce88bc9c934d41ccb6241b28
When adding a subcontext in a class loader context tree, there are two
possible cases: 1) the root of the subcontext is itself a <uses-library>
and should be present as a node in the tree, or 2) the root is not a
<uses-library>, but some of its dependencies are -- in that case they
should be disconnected from the root, and the resulting forrest should
be added at the top-level.
Example:
1) C is a <uses-library>:
A
├── B
└── C
├── D
└── E
└── F
2) C is not a <uses-library>:
A
├── B
├── D
└── E
└── F
Before the patch subcontexts for transitive dependencies were added
before the subcontext for the direct dependency (even if it was a
<uses-library>, resulting in case-2 hierarchy when case-1 should have
been used. Previosuly this didn't matter because class loader context
was a flat set of libraries, but now it matters because class loader
context is a tree.
This patch changes the order in which libraries are added, so that
direct dependencies are added before transitive ones. The context adding
method now accepts an "implicit root" parameter, so that when adding
transitive dependencies it can check if the corresponding direct
dependency is a <uses-library> and already present in the context.
Partially constructed class loader context is now propagated top-down
into aapt.buildActions, so that the method can use existing part of the
context to decide where the missing part should be connected.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I649aff9e27494306885a4f4fc90226c399636b57
The old representation consisted of a list of libraries (UsesLibraries),
a list of optional libraries (OptionalUsesLibraries) and a mapping from
library name to its build/install paths (LibraryPaths). The separation
into lists and map was necessary because of special handling of
compatibility libraries, which is now unified with normal libraries.
The new representation is a mapping from target SDK version to a tree
structure ClassLoaderContext. Each node of the tree represents a library
and contains library name, build/install paths and a slice of
subcontexts for dependencies. The same library may occur in the tree
multiple times in case it is a dependency of multiple libraries. The
order in which libraries are added matters (the resulting tree shape may
be different).
Test results have to be updated, as the resulting <uses-library> list is
reodered (previously it was a sorted list of map keys, and now it is
formed by a depth-first preorder traversal of the class loader tree).
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Bug: 168686456
Change-Id: I11be8cd2967f004fd58753d7c5fb99fed179cd63
If an android_library has a proguard flag file, that
file should also be used when compiling apps with the
library.
Fixes: 171425221
Test: New unit test in app_test.go, and manually
With this change, users don't need to figure out which libraries
actually hold the resources to be overlaid when targetting apps with a
core lib dependency (e.g. Settings, SystemUI).
Fixes: 169898727
Test: app_test.go
Change-Id: I3c3b9dc0a377b1828db1199858a73d080a173205
A global variant was used to store the global mapping between
modules and APEXes. Replace it with storing pointers to APEX
contents inside each module so that they can query the contents
of any APEXes they belong to.
Bug: 146393795
Test: all Soong tests
Test: single line change to build.ninja host install dependency ordering
Test: no Android-${TARGET_PRODUCT}.mk, make_vars-${TARGET_PRODUCT}.mk or late-${TARGET_PRODUCT}.mk
Change-Id: Id2d7b73ea27f8c3b41d30820bdd86b65c539bfa4
The test case I removed is invalid. The codename has had its int
assigned, but the config claims it is not final.
If this ever does need to be supported it's just a matter of making
sure the Q -> 29 mapping (or whatever) in the finalized codenames map
in android/api_levels.go.
Test: treehugger
Bug: http://b/154667674
Change-Id: I4f42ec2fd4a37750519ee3937938a1c65b6bb1e8
Extend usesLibraryProperties with a boolean is_uses_lib property and
move these properties from java.AndroidApp to java.Module to allow
java.Library modules set the new propery and be recognized as
<uses-library> by Soong.
Bug: 132357300
Test: lunch cf_x86_phone-userdebug && m
Change-Id: I01cd5e0da3dd543c1c0597249d37d0914b213ca7
For some dependencies, like stubs, the SDK library may not be found at
build time (either because the implementation library is not among the
dependencies of the dexpreopted module, or because it's part of a
prebuilt, or because it's missing from the build altogether). In such
cases dexpreopt is useless, because dex2oat does not have access to the
full classpath (unless the &-classpath is used). Therefore do not
dexpreopt in such cases.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: If289088cfd103011ccb16165e95a97b30fd31b81
Previously only the names were collected, and later used in the
manifest_fixer to add missing <uses-library> entries to the manifest.
Now we also need to collect build-time and on-device paths, to be used
in class loader context for dexpreopt. This commit only collects paths,
but does not pass them to dexpreopt yet.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I34b229ee68f16ba215ba03770feadb4d890ec2bf
AARs can provide extra classes in the libs/ directory that should
be treated the same as classes.jar, merge them into a single jar
when extracting the AAR.
Bug: 162892721
Test: m androidx.appsearch_appsearch
Change-Id: I92bf46f47ce5f3dce16c42197c15ed256304fda2
Instead of UnbundledBuild, use AlwaysUsePrebuiltSdks
to determine if java modules needs to be built against prebuilt sdks.
And rename UnbundledBuildUsePrebuiltSdks to AlwaysUsePrebuiltSdks to
express its behavior more correctly.(It can be orthgonal to "Unbundled")
Bug: 160390776
Test: TARGET_BUILD_UNBUNDLED_IMAGE=true m vendorimage
Change-Id: I0be7265c1959d8774c295372cd7a9250169f6df9
We put reproducible timestamps in zip files so that the artifacts
are consistent, but that leads to old timestamps in the output
directory if they are unzipped as part of the build. Use
unzip -DD when unzipping to update the timestamps.
Bug: 161015009
Test: touch -d 2020-01-01 ref; find $OUT/system -not -newer ref
Change-Id: I70407a627cb070e24be510faa6a774e3d9eae3a8
Enforce min_sdk_version for every payload dependency of updatable
APEX/APKs.
android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion
for every transitive dependency from APEX/APK modules to see if it
meets the min_sdk_version requirements.
The common implementation for apex/android_app is provided in
android/apex.go.
Bug: 145796956
Bug: 152655956
Bug: 153333044
Test: m nothing
Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
Add a rule that runs Android lint on each java and android module
and produces reports in xml, html and text formats.
Bug: 153485543
Test: m out/soong/.intermediates/packages/apps/Settings/Settings-core/android_common/lint-report.html
Change-Id: I5a530975b73ba767fef45b257d4f9ec901a19fcb
Use a method to add the properties that are present on all java modules.
Bug: 153485543
Test: m checkbuild
Change-Id: I7803b15eb0de810c8ab8d4b9acf2511935a26fb6
Test: lunch aosp_cf_x86_phone-userdebug && m
Test: Cherry-pick in internal master and check that on-device path to
com.google.android.dialer.support.jar now is on /product partition
(as it should be) and not on /system:
$ oatdump \
--instruction-set=x86 \
--oat-file=out/target/product/vsoc_x86/product/priv-app/GoogleDialer/oat/x86/GoogleDialer.odex \
| grep '^classpath' \
| grep -o '[^[]*com.google.android.dialer.support.jar'
/product/framework/com.google.android.dialer.support.jar
Bug: 132357300
Change-Id: Idf279ac713b9b29ff3a29f1b072bc1d57f48db26
This reverts commit b0dc851ff4.
Reason for revert: relanding original change. Build failures were
caused by a race with another CL: https://r.android.com/1320920
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: Ic9016582dae7773b4d4f84a63425f1ef7a5d061f
This is a prerequisite change before adding DexJarInstallPath.
Test: lunch aosp_cf_phone-userdebug && m
Change-Id: I033e08b8bb06c0a844a6bbbfcdc48ce33e9c95cf
The android_library module type can be used within an android_app that
can itself be added to an apex but android_library does not call
android.InitApexModule(module) and so it does not support apex variants
and so is treated as if it cannot be part of an APEX even though it
actually is.
Now, android_library supports AEPX variants.
Due to this change, the whilelist for apex_available got bigger.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 156978407
Test: m
Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6
Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6
(cherry picked from commit bd133b1bdc)
The build tracks the java_sdk_library/_import modules that are
referenced by libraries so that it can ensure that any Android app that
includes code that depends on one of those modules has the appropriate
<uses-library> entry in their manifest.
Unfortunately, there were a couple of issues with that:
1) It only tracks direct references to the java_sdk_library module
itself, e.g. android.test.mock. Direct references to the stubs
module, e.g. android.test.mock.stubs were not tracked. Making it
possible for Android apps to reference libraries which would not be
available at runtime.
2) The logic for determining whether something was a java_sdk_library
was repeated in a number of places making it difficult to allow
java_sdk_library/_import instances to determine whether they should
be treated as an Android shared library.
3) It tracks (and could use) even those java_sdk_library instances
which do not represent a shared library, e.g. the ones that set
api_only: true. While this change will simplifty fixing that the
actual issue will be fixed in a follow up change.
Changes:
* Added EmbeddableSdkLibraryComponent and embedded it into
java_sdk_library/_import, java_library and java_import. It provides
the common code to minimize duplication. It contains an
SdkLibraryToImplicitlyTrack field that if set will cause any
references to the containing module to add the SdkLibraryParent to
the list of implicit sdk libraries being tracked.
* Changed code that assumed that anything that implemented
SdkLibraryDependency required tracking to use the
OptionalImplicitSdkLibrary() method to get the optional name of the
sdk library to track. That will allow a follow up change to return
nil from that method to exclude an sdk library from being tracked.
* Moved SdkLibraryDependency from java.go to sdk_library.go as that is
a better place for it to be.
* Changed the stubs java_library/java_import creation code to initialize
the SdkLibraryToImplicitlyTrack field with the name of the creating
module.
* Initialized the SdkLibraryToImplicitlyTrack field in the
java_sdk_library/_import so that direct references to them will be
tracked too.
* Added tests to verify that direct access to the .stubs child of both
java_sdk_library and java_sdk_library_import are tracked properly.
Test: atest CtsProviderTestCases - which relies on android.test.mock
being implicitly tracked to verify that I had not broken
anything. Used aapt2 dump badging to read the manifest.
m nothing - to run the new tests which failed before fixing the
code.
Bug: 156723295
Change-Id: Ia99def91e9b74d2ed0a777de04b476c00ea0393d
Unit test: go test ./... -test.v -run TestOverrideAndroidApp
Unit test: python manifest_fixer_test.py
BUG: 148198056
Change-Id: Ib5ff235d2a93e88b86aec1c0b16327ea938a094d
Rename the two prefix-in-list funcs so that their usages are clearer.
Also find and replace all the code that essentially does either.
This introduces additional loops in some places, but I think the added
readability and simplicity outweighs the performance degradation, which
should be negligible anyway.
Test: m nothing
Test: TreeHugger
Change-Id: I37e2276ca0c815105ed0031f23c0b1264b480e4f
The value format that sdk_version (and min_sdk_version, etc.) can have
has consistently evolved and is quite complicated. Furthermore, with the
Mainline module effort, we are expected to have more sdk_versions like
'module-app-current', 'module-lib-current', etc.
The goal of this change is to abstract the various sdk versions, which
are currently represented in string and is parsed in various places,
into a type called sdkSpec, so that adding new sdk veresions becomes
easier than before.
The sdk_version string is now parsed in only one place 'SdkSpecFrom', in
which it is converted into the sdkSpec struct. The struct type provides
several methods that again converts sdkSpec into context-specific
information such as the effective version number, etc.
Bug: 146757305
Bug: 147879031
Test: m
Change-Id: I252f3706544f00ea71c61c23460f07561dd28ab0
