If set to true, preprocessed indicates that the prebuilt apk is
installable as is and does not need any further processing (e.g.
zipaligning, signing).
Test: app_test.go
Bug: 155412211
Change-Id: If0c27c1e340c1bdb270064f636dc6bf33a0fc949
Previously, all java_sdk_library instances were assumed to be usable as
shared libraries, i.e. referenced from <uses-library> in Android
manifest. However, that was not true for any instances that specified
api_only: true and will not be true for many of the new Android
modules.
One consequence of this assumption is that use of one of the api_only
instances could (but fortunately does not appear to) have lead to an
invalid library being referenced in an app's manifest which would
prevent the app from loading. That would have been done automatically
by the implicit sdk library tracking and manifest fixing mechanism and
there would have been nothing a developer could have done about it.
Changes:
1) Prevents api_only instances from participating in the automatic
tracking which will prevent them from being added to Android
manifests and breaking apps.
2) Add a new shared_library property that can have the same effect as
api_only while still creating a runtime implementation library.
3) Renamed commonProperties to commonSdkLibraryProperties to
disambiguate it from the ModuleBase.commonProperties field.
4) Extracts requiresRuntimeImplementationLibrary() to remove duplicate
code accessing the Api_only property.
5) Tests for the api_only and shared_library behaviours.
Test: m nothing - added tests, tests broke, fixed code, tests passed.
Bug: 156723295
Merged-In: Iccf509e808d5ff53522188541a4c54d8f9ada93c
Change-Id: Iccf509e808d5ff53522188541a4c54d8f9ada93c
(cherry picked from commit dfa131e673)
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
Merged-In: Ia99def91e9b74d2ed0a777de04b476c00ea0393d
Change-Id: Ia99def91e9b74d2ed0a777de04b476c00ea0393d
(cherry picked from commit 859fe961b0)
The stubs header jar is optimized for use as a dependency for others
to use. It only changes if there is a significant difference in the
externals of the classes, i.e. anything that a library being compiled
against depends upon. So changes to implementations of method or the
addition/removal of private methods, fields will have no impact.
As there is no benefit in returning the implementation of the stubs
jar this change removes it. The implementation is still used when
taking a snapshot as the header jar is an internal build artefact
that is not suitable for long term snapshot.
Bug: 155164730
Test: m droid
Merged-In: If91b4d106683f23788547c537228c58be2867174
Change-Id: If91b4d106683f23788547c537228c58be2867174
(cherry picked from commit 23970f4285)
Previously, in order to access say the public stubs source jar it was
necessary to directly reference the module by name. This change adds
support for accessing them indirectly via tags.
Test: nothing
Bug: 155164730
Merged-In: Id6d76e56c7b46944b2d2a44a2163fb05a5b03de9
Change-Id: Id6d76e56c7b46944b2d2a44a2163fb05a5b03de9
(cherry picked from commit 46dc45aba9)
The scopePaths struct is used by both java_sdk_library and its prebuilt
but was not populated in the same way. This change addresses those
discrepancies in preparation for a follow up change which will allow
access to some of those fields through OutputFileProvider.
Changes:
* Document the scopePaths field and struct.
* Switch those fields that may not be fully populated from Paths to
OptionalPath to make that 100% clear and protect against unchecked
use.
* Switch java_sdk_library_import to use the dependency extraction
mechanism driven by the dependency tag. This should actually have
been part of the change that added that mechanism.
* Only create prebuilt_stubs_sources if sources have been provided.
* Add dependencies from java_sdk_library_import on its stubs source
child modules if sources have been provided. That will ensure the
stubsSrcJar field is updated.
* Updates current/removedApiFilePath if provided for the scope in
java_sdk_library_import.
* Extracts ApiStubsSrcProvider from ApiStubsProvider to allow it to
be implemented by PrebuiltStubsSources so that it can provide access
to the stubs src jar that it creates.
Test: m nothing
Bug: 148080325
Bug: 155164730
Merged-In: Ic5bf884b2b1e79841843e7c3b4642796ecd49f5d
Change-Id: Ic5bf884b2b1e79841843e7c3b4642796ecd49f5d
(cherry picked from commit 0f8faffdc0)
Previously, when using sdk_version: "module_current" any direct
reference to an sdk library would use the public not module-lib stubs.
This change corrects that.
Prior to the addition of the module-lib api scope almost all
java_sdk_library instances supported all the scopes to which a request
for jars could be redirected, i.e. public, system and test. The
exceptions to that are a few special instances that were used with
sdk_version: "none" and so were either caught by the java_sdk_library
special cases or dropped through to public.
The addition of module-lib, plus the flexible control over which scopes
are generated means that is no longer true. It is possible for a
java_sdk_library to be requested for a scope it does not have which
would have resulted in an empty set of paths being returned leading to
confusing compilation errors.
To avoid that this change also adds support for using the inheritance
hierarchy defined by the apiScope.extends field to fall back to the
closest available surface.
Test: m nothing
Bug: 155164730
Merged-In: I6aab75a772433ee0a36b6f1758a4aec4be2f9a49
Change-Id: I6aab75a772433ee0a36b6f1758a4aec4be2f9a49
(cherry picked from commit 803a9565cd)
The java_sdk_library and java_sdk_library_import redirect a request for
header and implementation jars to broadly the same place although the
java_sdk_library does have some special code that is mixed in with the
common code.
This change separates the java_sdk_library special code from the common
code and moves the common code into its own method for use by both
module types. That makes the special behavior clearer and ensures the
common behavior remains consistent in future.
Test: m nothing
Bug: 155164730
Merged-In: I53e41a18792488aefd6a886c587559e90b3c4fde
Change-Id: I53e41a18792488aefd6a886c587559e90b3c4fde
(cherry picked from commit b05d4295de)
This turns out retention of Nullable annotations, which is almost
certainly what every user wants. Also add the "stub-annotations" lib to
the stub libs property, to make sure the nullability annotations
resolve properly.
Bug: 157010342
Test: m
Change-Id: I905144add4ef6f85445eedd1ba5169445f6005e0
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)
As far as I can tell, annotations_enabled does not require use of
merge_annotations_dir (although it may have done in the past).
Bug: 157010342
Test: m
Change-Id: I6705522774203b4566f58679bbc2f0c17422c1dd
Previously, all java_sdk_library instances were assumed to be usable as
shared libraries, i.e. referenced from <uses-library> in Android
manifest. However, that was not true for any instances that specified
api_only: true and will not be true for many of the new Android
modules.
One consequence of this assumption is that use of one of the api_only
instances could (but fortunately does not appear to) have lead to an
invalid library being referenced in an app's manifest which would
prevent the app from loading. That would have been done automatically
by the implicit sdk library tracking and manifest fixing mechanism and
there would have been nothing a developer could have done about it.
Changes:
1) Prevents api_only instances from participating in the automatic
tracking which will prevent them from being added to Android
manifests and breaking apps.
2) Add a new shared_library property that can have the same effect as
api_only while still creating a runtime implementation library.
3) Renamed commonProperties to commonSdkLibraryProperties to
disambiguate it from the ModuleBase.commonProperties field.
4) Extracts requiresRuntimeImplementationLibrary() to remove duplicate
code accessing the Api_only property.
5) Tests for the api_only and shared_library behaviours.
Test: m nothing - added tests, tests broke, fixed code, tests passed.
Bug: 156723295
Change-Id: Iccf509e808d5ff53522188541a4c54d8f9ada93c
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
The test was written with the assumption that the build OS is
Linux, which is not always the case (the test was broken on Darwin).
Test: m nothing (on Linux host)
Bug: 157192627
Change-Id: I6ae3deed7a3342f4526528f29ce0a299d24b464b
