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
Change-Id: Ic5bf884b2b1e79841843e7c3b4642796ecd49f5d
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
Change-Id: I6aab75a772433ee0a36b6f1758a4aec4be2f9a49
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
Change-Id: I53e41a18792488aefd6a886c587559e90b3c4fde
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
Change-Id: I84f294c6f02d5089055130c63f5fb0538a1f21b9
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.
Change-Id: I8c985b50cb6b6c019b33a4652de482ded689fee4
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
Change-Id: I7dbafd7164d5da600ca45c39a7f93a5a40027a1f
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
Change-Id: I5881e5ee7c2169c30f544882344a60a602dae917
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
Change-Id: Ic859a61de155b3e582c17f6ab5e9298f5f4e709a
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
Change-Id: I966e82b8ae67624da168e05f5a2b062b832cb8cd
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
Change-Id: I708657661188ea4a14a4dd8c6bc4b46237bbe5e0
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
Change-Id: I9be9aab07252b491ab292b8847138a93b487cf53
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
Change-Id: Iea7d59852d7aeb503120acf3c44e08eb0d9d07b9
Adds api_lint.enabled property to control whether API linting should be
performed.
Test: m checkapi
Bug: 156126315
Change-Id: I87ca5a942228cf6af1a9939f0334d6fc46c39a63
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
Change-Id: I4e1861ea67f441f2948a0d7d7053ab0b1169955f
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
Change-Id: Iffdd9f191ff0d74646356ac577560cc38efdd790
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
Change-Id: Ic99b7333730ed8b918d8af72ae7bd6a851c2093a
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
Change-Id: I7769af6823badca8715a270f86cf53b4e954b7df
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
Change-Id: I7539d89618b61f6b9d1a4b60cc3f9614b157f0d9
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
Change-Id: Ic6f90eb4449338e549878f64e8119e286b9aa549
@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
Merged-In: Ib3f671493f1d230116bec51b884e8072643b10d4
(cherry picked from commit 6bf8e415a50826a378cc58aba87854f52c9f1d32)
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
Change-Id: I7bc54dc4ad12a7d6c7503111d1322ee35c56d713
There are no known usages of these variables, and many have been
incorrectly set for a long time.
Also convert the <module> phony for api txt to androidmk.
Bug: 152479829
Test: m
Change-Id: Iff355041d88eb59ac47dd19a03e993cf1ce3927e
Minor refactoring of checkMergeZip(string) -> checkMergeZips(...string)
to allow testing of multiple merge zips.
Bug: 153443117
Test: m nothing
Change-Id: I8db00f611ced15f8476ba16f2834a72e8c913596
Makes it easier to add new api scopes by generating a struct with a
field for each scope.
Bug: 153443117
Test: m nothing
Change-Id: Iec77a858d2c851d99e56568b89cb30aa3ff2a244
Added droidstubsArgs field to the apiscope structure to avoid
switching on api scope type.
Bug: 153443117
Test: m nothing
Change-Id: I96f0eb033d44c6a74787ba7f1523799b05a58092
The java_sdk_library code used to create droiddoc and now it creates
droidstubs but it still referenced droiddoc internally. This change
removed all the remaining references except the ones that are visible
externally.
Bug: 153443117
Test: m nothing
Change-Id: Ie883eb4590f9c091d4149d7b17d7d3d91b1b5c6a
Reuse the generic Dist support instead of writing
custom mk rules for it. Use the new Tag support to
grab the classes.jar instead of the dexed jar.
Bug: 152618077
Test: m sdk dist
Change-Id: Id893d52cc24b66e6bd900b5062a59f3820000bcd
Merged-In: Id893d52cc24b66e6bd900b5062a59f3820000bcd
(cherry picked from commit 6bb8810c8e)
Checking apex_available was missing some corner cases.
For example, the deps of share deps of cc_library modules are missed
while those from cc_library_shared are correctly tracked.
This was due to..
* calling DepIsInSameApex in WalkDeps: both work fine separately, but
when they are used together, it fails to work. It's due to how WalkDeps
works. (We might fix this bug too risky since it is used very widely)
* incorrect receiver for DepIsInSameApex in apex_deps mutator: receiver
is supposed to be parent, but child was used before. Interestingly lots
of deps are within the same group of module types(cc to cc, java to
java), it has worked. (note that receiver's DepIsInSameApex
implementation can be different).
This change fixes them by..
* walkPayloadDeps is now relying on ApexVariation, which is calculated
correctly by TopDown apex_deps mutator.
* use correct receiver for DepIsInSameApex in apex_deps mutator, which
requires for java.SdkLibrary to override the method and for
java.Library/Import to use passed dep instead of receiver to check its
membership of sdk.
Bug: 151071238
Test: build/boot
Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
This change fixes a regression that was introduced with
I597bccbb177b6b6320c3a3edeff467243230d384. With the change, the content
of the permissions XML file for a java_sdk_library was determined before
the java_sdk_library is mutated for an APEX. As a result, the file path
to the implementation jar library was always set to
/system/framework/*.jar regardless of whether the java_sdk_library is
part of an APEX or not.
This change fixes the problem, by creating the permissions XML file via
a new module type. The content of the xml file is determined after the
xml file is mutated for APEXes.
Bug: 149600642
Test: m
Change-Id: Id21f8d8285df49b0b3be1daf0f101f2bc978eeb0
Previously, the .docs suffix was used for droidstubs internal modules
that generate the stubs source. The name was confusing so this change
replaces the suffix with .stubs.source to clarify the purpose of those
modules.
Bug: 148080325
Test: m droid
Change-Id: I9d7a2ab19e4a331b515408912ac8f7e8b0e1b35d
Previously a java_sdk_library_import module did not replace the
corresponding java_sdk_library module, even when it was marked as
prefer=true. That is because the java_sdk_library_import had an empty
set of sources. However, the stubs modules that are created by the
java_sdk_library_import did override the stubs modules created by the
corresponding java_sdk_library module.
That created inconsistent behavior between the cases where only the
prebuilt is available and both source and prebuilt are available and
the prebuilt is preferred. e.g. assume a java_sdk_library/import module
called SDKLIB.
When both prebuilt and source modules are available for SDKLIB then
even if the prebuilt is preferred then any dependencies on the
SDKLIB module would use the source module.
This change fixes that inconsisteny by making the array of sources
non-empty.
Bug: 148080325
Test: m droid && TARGET_BUILD_APPS=Camera2 m
Change-Id: I25395e020393921735ada20c5492f27f1260f6c5
When building java.lang classes it is necessary to compile them using
patch_module: "java.base". This change causes patch_module to be passed
through to the java_library created to compile the stubs to allow this
to be used to generate stubs for java.lang.
Test: m droid
Change-Id: I7c27953a5d782eeedd7f25e849ab444d28e28228
Previously, a java_sdk_library called "SDKLIB" would create a
prebuilt_etc module called "SDKLIB.xml" which installs the generated
XML permission file to /etc/permissions/SDKLIB.xml. That module
depended on the java_sdk_library "SDKLIB" to generate the XML file
as one of its outputs by specifying srcs: [":SDKLIB{.xml}"].
If the java_sdk_library is replaced by a prebuilt then the SDKLIB.xml
module expects the prebuilt to provide the XML permissions file which
it doesn't because that is an implementation detail and so the build
breaks.
A couple of alternative approaches were looked at to fix this. One was
to have the logic that replaced the source module with the prebuilt to
inform the source module that it was being replaced so it could disable
its created module. That lead to a dependency cycle where
SDKLIB -> SDKLIB.xml -> SDKLIB{.xml}
Another solution was to mark dependency tags in such a way that the
prebuilt could automatically identify and disable the SDKLIB.xml
module. Similar to how the visibility code will ignore dependencies
that are tagged with ExcludeFromVisibilityEnforcementTag. That became
very convoluted.
Instead the java_sdk_library was changed so that it was not responsible
for creating the XML permissions file. Instead it created a genrule
called "gen-SDKLIB.xml" to create it and then "SDKLIB.xml" depended on
that. The java_sdk_library also depended on the genrule to make the XML
permissions file available for APEX and testing.
Some refactoring of the APEX code and tests was necessary because they
had knowledge of the internal implementation of java_sdk_library. The
refactoring insulates them a little better from those details.
Bug: 148080325
Test: m droid && TARGET_BUILD_APPS=Camera2 m
Change-Id: I597bccbb177b6b6320c3a3edeff467243230d384
Previously, the java_sdk_library had special support for disabling the
stubs library when the build was configured to use prebuilts for sdks,
e.g. in an unbundled app build. That caused the prebuilt version of the
stubs library to be used instead. The disabling was done irrespective
of whether a prebuilt was available which prevents java_sdk_library
from being used in situations when prebuilts are not available, e.g.
when they have not been created yet.
This change moves the logic into tha java_sdk_library_import and
leverages the existing prebuilt/prefer mechanism to ensure that the
prebuilt version is used when required.
* Adds a ForcePrefer() method to Prebuilt to allow a module to forcibly
set the value of the prefer property.
* Sets prefer true on the java_sdk_library_import and the stubs modules
it creates when the prebuilt version should be used.
* Refactors PrebuiltJars for use by both java_sdk_library and
java_sdk_library_import as they both need to provide access to
prebuilts for previously released versions of the library.
* Removes disabling logic from java_sdk_library.
This will probably require some additional java_sdk_library_import
modules to be added to prebuilts/sdk/current/Android.bp.
Bug: 148080325
Test: m droid && TARGET_BUILD_APPS=Camera2 m
Change-Id: I0b5f751e82a2179a967ae64ca03dc9b9e7665c16
Previously, when a library that used a numeric sdk version also
referenced a java_sdk_library it would use the current version of its
API. That was dangerous as there is an expectation that an app building
against a numbered version will also be targeted at that version and
so building against a later version of the API could hide runtime
incompatibilities.
This change will use prebuilt versions of the java_sdk_library's api
when being built for a numbered sdk version.
Bug: 148080325
Test: m droid
Change-Id: I3fd416553950785a443c1702e495a96debc33331
