Previously, the code copied the current.txt file to both the
current_api and removed_api properties. This change copies the
removed.txt file to the removed_api property instead.
Bug: 157980685
Test: m nothing
Change-Id: Iad34e91051da43222d22c240c16f50887c43d73e
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
Change-Id: I33c7323f2389b44ed49cebe517ae2cce349117f1
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
Change-Id: Id2acc3cafb71d1e90d4fdc9c0c70a73983355e0f
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
Change-Id: Ifc4799feb4ada9dec8021efc13fe6a953bf2edd3
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
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
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
Change-Id: Ib7c544b48dfb53bad3e15f9f73f71bd05cff9b49
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 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
Change-Id: If91b4d106683f23788547c537228c58be2867174
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
Change-Id: Id6d76e56c7b46944b2d2a44a2163fb05a5b03de9
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
The legacy usages have all been updated so the legacy properties
can be safely removed. The Libs property is kept so it can be used to
specify properties common to all scopes.
Bug: 148080325
Test: m droid
TARGET_BUILD_APPS=Camera2 m
Change-Id: I252ebbedbb463db3c7346e86d86b5880eea76fe9
Previously, the java_sdk_library_import only exposed the public stubs.
This change adds support for exposing system and test stubs too by adding
separate structures for public, system and test scopes. The existing
properties are kept for legacy reasons (and because libs can be common
across the differents scopes).
It extracts some code that is common to both sdk library and sdk
library import.
The legacy support will be removed in a future change once all existing
usages have been switched over.
Bug: 148080325
Test: m droid
TARGET_BUILD_APPS=Camera2 m
Change-Id: I0b26cc8af9ee044437ff3b80c1eca611816b9386
When building a library against sdk_version: system_current it uses the
system stubs of any java_sdk_library that it references. Previously,
when building against sdk_version: test_current this used the public
stubs of any java_sdk_library. This change causes it to use the
test stubs instead to be consistent with the handling of system and
public.
Bug: 148080325
Test: updated the test
ran m nothing which failed as expected
fixed the code
ran m nothing again which succeeded
Change-Id: I58ec5bd243701c5a5c75664e2bb615ce7b2f2441
The java_sdk_library duplicated a lot of code related to api scopes and
also did a lot of switching on apiScope. This change eliminates that
duplication and switching by converting apiScope from an enum to a
structure containing api scope specific information.
It associates dependencies with corresponding scope by using a
scopeDependencyTag that contains a reference to the associated
apiScope.
Tested by:
1) Running the command below without the changes.
2) 'mv out/dist/apistubs $ANDROID_BUILD_TOP'
3) Applying these changes.
4) Running the command again.
5) Verifying that the out/dist/apistubs was identical to before the
change using 'meld out/dist/apistubs $ANDROID_BUILD_TOP/apistubs'
Bug: 148080325
Test: m TARGET_PRODUCT=sdk TARGET_BUILD_VARIANT=userdebug dist sdk
m droid
Change-Id: I0de3268b12254122e94ca83d09309b06ca2f9dbe
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
The properties are just passed through to the java_import module that
it creates to import the stubs so could be used if set. However, none
of the current usages of java_sdk_library_import actually set them and
it is not clear why the following would ever be set on
java_sdk_library_import:
* installable
* exclude_files
* exclude_dirs
The above properties look as though they were simply copied from the
ImportProperties struct.
The libs property is also unused but it seems as though it should be
used to improve compatibility with the source module. e.g.
the source module for android.test.runner has android.test.base and
android.test.mock in its libs. However, the prebuilt version of it
does not.
Bug: 148080325
Test: m nothing
Change-Id: I710e3962b2e34b2b0cc81685d07d4948cef4e6ad
Unbundled builds set AllowMissingDependencies and attempt to use
prebuilts for some jars. Delay the errors for missing jars for
modules with invalid sdk_version values in unbundled builds so
that they only block the build if those modules are built.
Also fix some error messages to show the original sdk_version
value.
Bug: 146513037
Test: m TARGET_BUILD_APPS=Camera2
Change-Id: I1812ef6dc80895f7a2162a8bdbf2c5067755e9a0
Make LoadHookContext embed a new EarlyModuleContext instead of
BaseModuleContext to reduce its API surface in preparation for
moving it to run during parsing instead of mutators.
Test: m checkbuild
Change-Id: I1cd3ff3b636e7e24991a9184d7521903473e505a
Most modules will be providing their implementations via APEX and so do
not need to create an implementation shared library as part of this.
Adds an api_only property which will:
* Prevent the creation of the implementation library.
* Prevent the creation of the .xml file needed at runtime to make
the shared library available.
* Prevent the library being added to the list of java sdk libraries
used by make to handle installation.
Bug: 145998881
Test: m checkbuild
Change-Id: Ida5e46a81aa5b0a041882d90d5f362ec79fdddb2
For modules that provide API surfaces in addition to the standard
current, test and system it is useful to be able to specify the
directory containing the api's .txt files to make it easy to create
multiple API surfaces from within the same Android.bp file. e.g. This
is useful for conscrypt, icu and libcore to manage their intra core
and core platform APIs.
Bug: 145998881
Test: m checkbuild
Change-Id: I753631d9b6993fbf30019fef5c052a9429e519de
If api_packages is not set then will try and generate stubs from all
the source packages.
Bug: 145998881
Test: m checkbuild
Change-Id: Ic9d7f82bb34c4b960a2f17614d7f64ddd13ad8b0
If the library does not provide system and test APIs then do not
generate/require corresponding .txt files.
Bug: 145998881
Test: m checkbuild
Change-Id: I21cfdb0b63fd575e8c8c63ea2b436e0c4aa8f3fc
The createDocs(...) method was obviously named because it created a
droiddocs target that generated the stubs source but it now creates a
droidstubs target so the name was misleading.
Bug: 145998881
Test: m checkbuild
Change-Id: I7419b0a01ee87ecb2b396e4817e5e88a88a8b7b6
Permission XML file for java_sdk_library is generated by
java_sdk_library itself now.
And, build rule is switched to android.WriteFile since "echo -e" is
not supported from build server. (-e is printed to output)
Bug: 145474221
Test: m com.android.cronet and check its permissions xml file
also, m org.chromium.net.cronet.xml (created dynamically)
Change-Id: Iffb119151c49bc4fe6c4386fa267cca193f37dbc
When a java_sdk_library module is added, both impl jar and permission
xml files are packaged together.
For example, when a java_sdk_library "foo" is listed, following two
entries will be in an APEX package.
/javalibs/foo.jar
/etc/permissions/foo.xml
Bug: 145474221
Test: m com.android.cronet
deapexer list com.android.cronet.apex
Change-Id: If5883c02255e9309f20810b1532d3fbe73bf4e95
AndroidMkEntries now returns multiple AndroidMkEntires so that a module
can emit multiple Make modules if needed.
Bug: 128708192
Test: m
Change-Id: I56b6f76d22943b80329951c5acb80a1b932441ad
The system_ext partition was created. So if java_sdk_library module is
installed to system_ext partition, .xml and .jar install path must be
changed to system_ext.
Bug: 143440787
Test: add system_ext_specific to java_sdk_module && make -j && check
system_ext parition
Change-Id: Ie0d0df426d4aa96ac89eb4215e7376eea3f03f54
Reduce the boilerplate required to call CreateModule by taking an
android.ModuleFactory instead of a blueprint.ModuleFactory.
Test: m checkbuild
Change-Id: I1259d2dd3f7893b5319c333bc180727ac40f9e91
This change migrates some of AndroidMk()s in java/androidmk.go to
AndroidMkEntries(), mainly focusing on deduping test-related helper
funcs.
Test: Soong tests
Test: Built a system image
Test: Manual inspection of diffs
Change-Id: I7810085521600d9ea2df078837688ade41c04825
They are no longer used. Sources are provided via filegroup.
Also removing the SrcDependency interface as it is no longer used.
Bug: 135922046
Test: m
Merged-In: I81f9614d20fbdd2f7d18340d6dbdb592e7acde06
(cherry picked from commit fa21cba64a)
Change-Id: I81f9614d20fbdd2f7d18340d6dbdb592e7acde06
This change removes srcs_lib_whitelist_dirs which was used to let
droiddoc to know the base directories for the AIDL/Java source files.
Instead, the base directories are given via the path property of the
filegroup modules.
This change also includes a fix that the base directories from all
filegroup modules listed in srcs are used as the import paths for the
AIDL compiler. This removes the need to have aidl.[local_]include_dirs.
Bug: 70046217
Test: m
Exempt-From-Owner-Approval: Approved internally
Merged-In: I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2
(cherry picked from commit f79334d95c)
Change-Id: I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2
This change fixes two problems:
1) the prebuilt apexes are force disabled for the unbundled builds
because we need to build the modules from the source then
2) the dependencies from an sdk_library module to
*.stubs.{public|system|tests} are not added for the unbundled build
because the stubs modules are disabled.
Bug: 137282010
Test: unbundled mainline builds are successful
Test: build com.android.media and inspect the jar file to see if
hiddenapi flags are there
$ cd out/dist/mainline_modules_arm
$ unzip com.android.media.apex apex_payload.img
$ mkdir -p mnt
$ sudo mount -o ro,loop apex_payload.img mnt
$ dexdump2 mnt/javalib/updatable-media.jar | grep hiddenapi
shows results
Change-Id: I2c00af07aac4a15770d3acab011a36e2e4803bfc
Corrects an error message that refers to no_standard_libs.
Removes any tests that use no_standard_libs:true where possible as
there are duplicate tests for sdk_version:"none". Otherwise, switches
them over to use sdk_version:"none".
The androidmk mapping from LOCAL_NO_STANDARD_LIBRARIES to
no_standard_libs has also been removed. There was little point in
updating the tool to map it through to sdk_version:"none" as there are
only a couple of places where it is used, in art's test running mk
targets and in some unbundled packages to work around some limitation
in .mk based build.
Bug: 134566750
Test: m droid
Change-Id: I6413c9b1fe3e63b93753a6a017d2981e32b7e013
Where possible this duplicates any tests that use no_standard_libs:true
with ones that use sdk_version:"none". If not possible (e.g. in the
default targets included in java/testing.go) it switches some to use
sdk_version:"none" to ensure that there is no regression in the
behavior of no_standard_libs:true.
Follow up changes will switch all usages of no_standard_libs:true over
to use sdk_version:"none" at which point no_standard_libs will be
removed.
Bug: 134566750
Test: m droid
Change-Id: I5f0fd3daa980f6b223abe454cba7f25a97a39d7a
Previously, different parts of the build used different sources of
information about the SDK (i.e. the default libraries) against which
a Java module aimed at the device was built. Some used the sdk_version
property, others used the no_standard_libs or no_framework_libs, some
used a combination of all three.
That lead to inconsistent handling in the code, e.g. some parts treated
no_standard_libs: true as implying no_framework_libs: true and others
did not, and also in the build files, e.g. some modules specified
no_framework_libs: true and sdk_version: "system_current" which makes
no sense, or no_standard_libs: true and sdk_version: "core_current"
which are inconsistent.
This is the first step in a refactoring to simplify the sdk selection
process by replacing the no_standard_libs/no_framework_libs properties
with some extra options for the sdk_version property. This change
consists of:
1) Extra functions sdkContext to access the no_standard_libs and
no_framework_libs properties.
2) Extra field/functions in sdkDep to store and access the value of
no_standard_libs/no_framework_libs.
3) Changes to decodeSdkDep(...) to pass the values of the no_...
properties through to the returned sdkDep.
4) Change all code that accesses the no_... properties directly to
call decodeSdkDep(...) to get an sdkDep object and then accessing
the values of the no_... properties from there.
The accessor functions on sdkDep are called has...() rather than
no...() as most callers of the methods invert the value anyway and
!no...() is harder to reason about than has...().
The hasFrameworkLibs() function returns true if and only if
no_standard_libs and no_framework_libs are false. That is consistent
with all but one usage of the no_framework_libs property and that is
not affected by it.
Bug: 134566750
Test: m droid
Change-Id: I196e3304e8bd802fb154e897397b0dd337f868e2
Exempt-From-Owner-Approval: Colin has already given +2 modulo some
minor nits and this blocking other changes.
blueprint.BaseModuleContext is the set of methods available to all
module-specific calls (GenerateBuildActions or mutators). The
android package split the same functionality across baseContext (nee
androidBaseContext), BaseModuleContext, and BaseContext.
Consolidate all of them into android.BaseModuleContext.
Test: m checkbuild
Change-Id: I2d7f5c56fd4424032cb93edff6dc730ff33e4f1e
For the sysprop apis, we don't need dist. So the No_dist property is
added for it.
Bug: 132448761
Test: m -j dist
Change-Id: I51c6a6b87ab9dc90b6825c0d4d414e958dd7b265
Use codename.fingerprint format for targetSdkVersion if it is unset
in the manifest and UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true.
Test: manual
Bug: 130541924
Change-Id: I4e3b1274cc32038b00b292dc6d67559eb320e9e4
Add java_sdk_library_import for use when a java_sdk_library may
be used by unbundled branches that do not have the project that
contains the original java_sdk_library module.
Bug: 130287656
Test: m checkbuild
Change-Id: I62df4bccc0da95ed6c8b31dab8f2c32cc3215e9e
Paul Duffin