Passes the shared_library property through to the snapshot. It does not
optimize away the default value in order to make it easier to invert
the default value in future. The current default value was only chosen
for convenience because most existing usages were already treated as
shared libraries. It would be safer if modules had to opt in to be used
as shared libraries.
Bug: 155164730
Test: m nothing
Merged-In: I33c7323f2389b44ed49cebe517ae2cce349117f1
Change-Id: I33c7323f2389b44ed49cebe517ae2cce349117f1
(cherry picked from commit d7eb1c2a76)
Previously, when a lib that doesn't have sdk_version property set
depends on a java_sdk_library, the impl library was used for linking.
This might be too permissive because the client lib might be using empty
sdk_version because it needed some private APIs from the platform, but
not from the java_sdk_library. This actually happend for some of the CTS
tests. They don't set sdk_version, but were directly depending on
android.test.[base|runner|mock].stubs libraries. If we switch the
references to the stub libraries into the corresponding java_sdk_library
modules (e.g. aandroid.test.[base|runner|mock]), then we would be
allowing private APIs to the CTS tests, which is not good.
To solve this problem, default_to_stub property is introduced. It when set
to true prevents the impl lib from being used for linking. When a module
that doesn't have sdk_version depends on it, the widest API surface that
the java_sdk_library provides is linked instead.
Bug: 157007292
Test: m
Merged-In: Id2acc3cafb71d1e90d4fdc9c0c70a73983355e0f
Change-Id: Id2acc3cafb71d1e90d4fdc9c0c70a73983355e0f
(cherry picked from commit 932cdfeb06)
Most dependencies on java_sdk_library instances (JSL) simply reference
them by name and rely on the build to pick the correct part, impl,
stubs for a specific scope, headers or implementation jars or dex jars.
Generally, the build gets that decision right. If it does not the for
most of the components of the JSL there is a way to reference them
directly. However, that is not true for the implementation library as
that is created the JSL itself.
Access to the implementation library should be avoided as it opens up
the possibility that use will be made of an API that is not tracked and
maintained which could lead to compatibility issues. However, there is
a case where use of the implementation library is required and safe.
That is when it is being used from other libraries within the same APEX
as the JSL. In that case the JSL and its dependencies will be updated
together so compatibility is not an issue.
This change adds a new <module>.impl java_library that compiles the
implementation library in the same way as the JSL itself does. This will
allow the modules that are blocked from converting to JSL because of
this limitation to progress. Initially the library is only for use
for compiling but follow up changes will switch the rest of the build
from using the implementation library created by JSL to the separate
module.
It also adds the ability to give the separate .impl library a more
restrictive visibility than the JSL further limiting misuse.
Bug: 156618935
Test: m droid, flash, atest CtsProviderTestCases - sniff test
tested that it fixes compilation issues with mainline module
Merged-In: Ifc4799feb4ada9dec8021efc13fe6a953bf2edd3
Change-Id: Ifc4799feb4ada9dec8021efc13fe6a953bf2edd3
(cherry picked from commit 5df793011d)
Access to the implementation JARs is restricted to avoid code from
depending on implementation details that could change from one release
to the next which could cause compatibility issues. That is not a
problem when referenced from within the APEX that contains the
java_sdk_library.
As references from within the same APEX often need to access
implementation specific details of the java_sdk_library and doing that
from within the same APEX is safe this change all references to a
java_sdk_library made within the same APEX to use the implementation
jars instead of stub jars.
Bug: 155164730
Test: m droid
Change-Id: If239059690de61683c2ad2d8a0ce2e47286a3637
(cherry picked from commit 9b879594ed)
The implementation jars are not built if api_only: true. In that case
the jar paths must not be exposed implicitly as they will be nil and
they will just be ignored.
This change ensures that stubs are returned when the implementation
jars are not built.
Bug: 155164730
Test: m droid
Change-Id: Ic495982a5dcb2754916260e7d91d921a5da288ae
(cherry picked from commit daaa332827)
The expression !sdkVersion.specified() is equivalent to the following:
!sdkVersion.valid() || sdkVersion.kind == sdkPrivate
That means that the else if clause "sdkVersion.kind == sdkPrivate" will
never be reached so it was removed.
There is also no need to check sdkVersion.valid() as that will already
have been checked, and an error reported, before this code has been
called. Therefore that has been removed.
Bug: 148080325
Test: m nothing
Merged-In: Ib7c544b48dfb53bad3e15f9f73f71bd05cff9b49
Change-Id: Ib7c544b48dfb53bad3e15f9f73f71bd05cff9b49
(cherry picked from commit c91f5d0cc7)
Module stubs compile against module_current, so any module depending on
them had to compile against module_current (or broader) too. Treat them
as the API surface the stubs are for.
Bug: 157010342
Test: m
Change-Id: I49b9082dc1b5afe6c22e94126e574dd8061f0f39
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
(cherry picked from commit dfa131e673)
Change-Id: I06b3444ced00fd7b54068352187684171024c679
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
(cherry picked from commit 859fe961b0)
Change-Id: I760a9ac72856e3a07a497ce40db70c7e70106837
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
(cherry picked from commit 23970f4285)
Change-Id: I8277ec643837514d74cb57ad4f236ceb1f5c6c5b
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
(cherry picked from commit 46dc45aba9)
Change-Id: Icc21caee5b4b1da6f958470bd7bae8a37933f24b
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
(cherry picked from commit 0f8faffdc0)
Change-Id: Ib56ca608d6fc1357d3d89e9c4cfed6ff8da11735
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
(cherry picked from commit 803a9565cd)
Change-Id: I89a0abf4033209f9a104285c990096bc0b4a0255
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
(cherry picked from commit b05d4295de)
Change-Id: Id21cc74d2d37c5a75983fdcd7393f6a37f8872c9
This is in line with the main android stubs (android.jar). I discovered
the difference since we want to merge some java_sdk_libraries into the
android.jar files, but I believe the rationale for compiling it with
version 8 applies to all stubs (we don't want level 9-language features
because some tooling may be stuck with version 8).
Bug: 144149403
Test: presubmit (checkbuild)
Change-Id: I9439ed516dda68ef516ff08d1c6045de3d3c1c0e
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
Fields in embedded structures can be accessed without qualifying them
by the type of the embedded structure.
This reduces the size of follow up changes that switch java_sdk_library
from embedding Library.
Bug: 156618935
Test: m nothing
Merged-In: I84f294c6f02d5089055130c63f5fb0538a1f21b9
Change-Id: I84f294c6f02d5089055130c63f5fb0538a1f21b9
(cherry picked from commit a18abc2a61)
The (Soc/Device/Product/System_ext)_specific are all properties in
ModuleBase.commonProperties. Initially, they were explicitly copied
from the parent to the child. Since then the CreateModule() method
was modified to automatically copy all the commonProperties from the
parent to the child so this code is no longer necessary.
Bug: 156618935
Test: m nothing
checked that it does not change the generated xml permissions
file for a java_sdk_library that sets soc_specific: true and
is in the vendor partition.
Merged-In: I8c985b50cb6b6c019b33a4652de482ded689fee4
Change-Id: I8c985b50cb6b6c019b33a4652de482ded689fee4
(cherry picked from commit 1dbe3ca254)
The module_lib scope should be called module-lib in order to pick up
the latest filegroup. Without it the API lint does not use a baseline
and so reports issues with released and unchangeable APIs.
It is also needed for the correct dist path.
Test: m update-api
Bug: 155164730
Merged-In: I7dbafd7164d5da600ca45c39a7f93a5a40027a1f
Change-Id: I7dbafd7164d5da600ca45c39a7f93a5a40027a1f
(cherry picked from commit 6b836ba566)
Allow the sdk_version against which the stubs for a scope are compiled
to be specified in the module on a per scope basis.
Bug: 155164730
Test: m nothing
Merged-In: I5881e5ee7c2169c30f544882344a60a602dae917
Change-Id: I5881e5ee7c2169c30f544882344a60a602dae917
(cherry picked from commit 87a05a389d)
Matches the naming scheme used by the separate manually created modules
that will be replaced by java_sdk_library's automatically created
components. This will simplify conversion to java_sdk_library as it
will allow developers to concentrate on getting the conversion correct
without also having to worry about name changes. It will also allow the
conversions to be parallelized as many of the references to the
components are in places where conflicts are likely.
Test: m nothing
Bug: 155480189
Merged-In: Ic859a61de155b3e582c17f6ab5e9298f5f4e709a
Change-Id: Ic859a61de155b3e582c17f6ab5e9298f5f4e709a
(cherry picked from commit 6c9c5fc4bc)
The constants are only used in one place in the code and in the test.
This change switches the test code to use the apiScope methods to
generate the names and then inlines the constants in those methods. It
makes it easier to see the naming convention.
Test: m nothing
Bug: 155480189
Merged-In: I966e82b8ae67624da168e05f5a2b062b832cb8cd
Change-Id: I966e82b8ae67624da168e05f5a2b062b832cb8cd
(cherry picked from commit dd9d0740fa)
Adds a naming scheme abstraction to which the java_sdk_library/import
will delegate the task of creating the names of their component
modules. The naming scheme can be selected in a module definition but
for now the only supported option is "default".
Test: m nothing
Bug: 155480189
Merged-In: I708657661188ea4a14a4dd8c6bc4b46237bbe5e0
Change-Id: I708657661188ea4a14a4dd8c6bc4b46237bbe5e0
(cherry picked from commit 1b1e8069ec)
Extracts the child module naming to the commonToSdkLibraryAndImport
struct so it can be reused by both sdk library source and prebuilt.
Also:
* Makes all child module name generation go through the common struct.
* Renames some of the methods to clarify their purpose and improve
consistency.
Test: m nothing
Bug: 155480189
Merged-In: I9be9aab07252b491ab292b8847138a93b487cf53
Change-Id: I9be9aab07252b491ab292b8847138a93b487cf53
(cherry picked from commit c3091c8c19)
The API file for a scope represents the differences between the API
provided by that scope and that provided by the scope that it extends.
On the other hand the stubs source for a scope represents the union of
the API provided by the scope and the scope it extends (all the way
back to public).
Unfortunately, while metalava supports this behavior for scopes that
extend public (e.g. system and test) it does not support this behavior
for scopes that extend others, e.g. module_lib which extends system.
This is because it always assumes that the baseline for the API file
is 'public' and so has no way to defined other baselines.
This change works around that by having separate droidstubs modules to
generate the API and stubs sources for scopes that require different
arguments to generate the API and stubs sources.
Test: m checkapi
Bug: 155164730
Merged-In: Iea7d59852d7aeb503120acf3c44e08eb0d9d07b9
Change-Id: Iea7d59852d7aeb503120acf3c44e08eb0d9d07b9
(cherry picked from commit 0ff08bdb07)
Adds api_lint.enabled property to control whether API linting should be
performed.
Test: m checkapi
Bug: 156126315
Merged-In: I87ca5a942228cf6af1a9939f0334d6fc46c39a63
Change-Id: I87ca5a942228cf6af1a9939f0334d6fc46c39a63
(cherry picked from commit 160fe41c39)
Previously, the information that the java_sdk_library extracted from
its child dependencies was determined purely by the type of the
dependency and whether it had a tag of the appropriate type. The actual
tag itself was ignored. That worked but was a little fragile as it
relied on there being no overlap between the types of the dependencies
or if there was overlap on the order in which the dependencies were
processed and the dependency types were checked to ensure that the
correct information was collected.
This change makes the information that is extracted dependent on the
tag that is used. That makes the behavior much more robust and also
simplifes the follow up change which may get the stubs source and API
files from separate droidstubs invocations.
Changes:
* A func field is added to the scopeDependencyTag that is supplied with
a dependency from which to extract the information and scopePaths
into which the information will be stored.
* Each scopeDependencyTag instance supplies its own function.
* Various items are renamed to more closely reflect what they actually
do. e.g. the apiFileTag is renamed to stubsSourceAndApiTag field
because if provides access to both api file and stubs source.
Test: m checkapi
Bug: 155164730
Merged-In: I4e1861ea67f441f2948a0d7d7053ab0b1169955f
Change-Id: I4e1861ea67f441f2948a0d7d7053ab0b1169955f
(cherry picked from commit c878250d3f)
Metalava apparently normalizes the SystemApi annotation that was
previously used to the form that this change uses so this is
effectively a no-op. However, this does make this code more
self-consistent and also matches the form that is used in the framework
defaults for the mainline modules.
Test: m checkapi
Bug: 155164730
Merged-In: Ic99b7333730ed8b918d8af72ae7bd6a851c2093a
Change-Id: Ic99b7333730ed8b918d8af72ae7bd6a851c2093a
(cherry picked from commit 0d543640d5)
Adds two new properties to specify the visibility of the stubs modules
(source and library) created by the java_sdk_library. Excludes
visibility property from being inherited when creating the module so it
can be properly specified by copying across the relevant property.
Test: m checkapi
Bug: 155164730
Merged-In: Iffdd9f191ff0d74646356ac577560cc38efdd790
Change-Id: Iffdd9f191ff0d74646356ac577560cc38efdd790
(cherry picked from commit 4911a89181)
Adds api scope for the module_lib and adds that to the list of all
all available scopes. The scope is generated if and only if the
api_surfaces property contains "module_lib".
No other changes are needed as the generation of the APIs is completely
driven by the allApiScopes array and the information in its contained
apiScope structures.
Test: m checkapi
Bug: 155164730
Merged-In: I7769af6823badca8715a270f86cf53b4e954b7df
Change-Id: I7769af6823badca8715a270f86cf53b4e954b7df
(cherry picked from commit 8f265b9ab9)
Adds a per scope set of properties that allows explicit control over
the API surfaces generated.
Previously, the term active was used to determine whether it was
generated but that was a little abstract and unclear so has been
replaced by generated.
Test: m nothing
Bug: 155164730
Merged-In: I7539d89618b61f6b9d1a4b60cc3f9614b157f0d9
Change-Id: I7539d89618b61f6b9d1a4b60cc3f9614b157f0d9
(cherry picked from commit 3375e35d99)
Minor refactoring of checkMergeZip(string) -> checkMergeZips(...string)
to allow testing of multiple merge zips.
Bug: 153443117
Test: m nothing
Merged-In: I8db00f611ced15f8476ba16f2834a72e8c913596
Change-Id: I8db00f611ced15f8476ba16f2834a72e8c913596
(cherry picked from commit 3d1248ceb6)
Previously, java_sdk_library used AddLoadHook() to register a hook that
when called would create its child modules. That meant the
java_sdk_library properties that were used to create the child modules,
e.g. sdk_version could not be defaulted because the modules are created
before the defaults are applied.
This change switches java_sdk_library to use the new
SetDefaultableHook() mechanism to register the hook instead of the
AddLoadHook() mechanism.
It also prevents the child modules from being created if the module has
been disabled.
Bug: 155295806
Test: m checkapi
Merged-In: Ic6f90eb4449338e549878f64e8119e286b9aa549
Change-Id: Ic6f90eb4449338e549878f64e8119e286b9aa549
(cherry picked from commit f022920bde)
Needed for follow up changes.
Test: m checkapi
Bug: 155164730
Merged-In: I163223caed38161ce1fa7b96dc3772194c32c3e2
Change-Id: I163223caed38161ce1fa7b96dc3772194c32c3e2
(cherry picked from commit 97b53b83e4)
@TestApi does not have stability requirements, so we shouldn't be
checking its compatibility with the last released version.
This CL removes the expectation that a test-removed.txt is checked in
for each module during finalization.
Bug: 155197156
Test: m (with SDK 30 imported)
Change-Id: Ib3f671493f1d230116bec51b884e8072643b10d4
The stubs source should be generated using the same classpath that is
used to compile the implementation library, i.e. sdk_version,
system_modules and libs/static_libs.
Previously, the sdk_version used to generate the stubs was different.
It provided access to a wider API surface than was necessary. This
change fixes that.
Test: m checkapi
Bug: 155164730
Merged-In: I7bc54dc4ad12a7d6c7503111d1322ee35c56d713
Change-Id: I7bc54dc4ad12a7d6c7503111d1322ee35c56d713
(cherry picked from commit 7b78b4d404)
Not used anymore, as the make variables have been deleted.
Bug: 152479829
Test: m
Change-Id: I1b29ec33951588ab479fc3e14f85e9aa189b971b
Merged-In: I1b29ec33951588ab479fc3e14f85e9aa189b971b
