java_sdk_library generates stub java_library module which compiles the
stub generated from either source or txt files, which is toggled based
on the build configuration. The java_api_library/java_library module
that compiles the stubs should not be directly accessible to the modules
outside of the sdk_library module scope, thus modify their visibility as
private.
Test: m nothing
Bug: 299373105
Change-Id: Ia4a08bf6e65c521814c82f54ea43cc8d367834e3
Since full_api_surface_libs extract class files instead of srcjar file,
full_api_surface_stub can be replace with android_*_stubs_current,
instead of the api_library android_*_stubs_current.from-text.
Functionally, the class files of the two modules are identical (in
from-text stub build), but depending on the from-text java_api_library
leads to missing dependency errors in partial branches (especially ART
branches). To resolve this problem, make sdk_library generated
api_library depend on the missing dependency handled
android_*_stubs_current.
Since android_module_lib_stubs_current.from-text does not have its
from-source equivalent, this can remain as dependency as the module is
moved to build/soong in aosp/2674196
Test: m (default to from-text stub build)
Bug: 274805756
Change-Id: Ic8bbd25252e5f9f1dc7c059ce6b00a951188985d
Currently, stub java files are extracted from srcjar file provided from
dep_api_srcs in java_api_library module generated in java_sdk_library
per api scope. However, compiling the java files may lead to difference
in the content of the generated class files even if the stub java files
are equivalent, as javac may arbitrarily add overridden methods. Thus,
create a stub jar file instead of creating a stub srcjar file and
compiling it, in order to guarantee stub jar files content equivalence
and thus enable hiddenapi during from-text stub build.
Note that this change does not fully resolve differences between the
full api surface csv and the per sdk_library csv. Instead, it removes
the difference caused by methods arbitrarily added by javac.
This change also renames dep_api_srcs to full_api_surface_stubs to be
more intuitive.
Test: rebase on top of aosp/2617274 and `m --build-from-text-stub`
Bug: 275570206
Change-Id: I22b6d56624633681f5c3b000370b5782655c7b8d
Rename java_library created inside sdk_library with the ".from-source"
suffix, and set it as static lib of the top level java_library, which
gets java_api_library instead as static lib during from-text stub build.
Test: m nothing && m nothing --build-from-text-stub
Bug: 286446015
Change-Id: I32e8ea264987e9f9df05e462292bd54e45074912
This change enables java_sdk_library to generate java_api_library
modules per api surface, so that from-text stubs can be generated per
api domain scope. This module is only created when
`--build-from-text-stub` flag is passed during build.
Test: enable disabled modules in java/core-libraries/TxtStubLibraries.bp then m art.module.public.api.stubs.from-text --build-from-text-stub
Bug: 276957733
Change-Id: Ic1ead15b3d0bcb921ca8d31bcaeeb4cd9ee8715c
Merged-In: Ic1ead15b3d0bcb921ca8d31bcaeeb4cd9ee8715c
Currently, droidstubs module create java_api_contribution module, but
when a java_sdk_library module dynamically creates a droidstubs module,
java_api_contribution is not created as the hook inside droidstubs get
lost. Therefore, call hook inside sdk_library after creating the
droidstubs module.
Test: m
Change-Id: I68bf1d796f6f9a6f81011ae35e4991b6ed1421ea
In some cases the java_sdk_library needs to compile against hidden
platform APIs, in order to do so it needs to add impl_only_libs
dependency on the framework library, and set the sdk_version property to
the "core_*" one (e.g. core_platform).
However, if this java_sdk_library depends on the Android SDK in it's
stable API surface, then the setup above will break the stubs srcs
generation, as it uses the sdk_version of the java_sdk_library (e.g.
core_platform), which doesn't have symbols from the Android SDK.
This chage solves the problem by propagating the stub_only_libs to the
invocation that generates the stub sources. It allows the
java_sdk_libraries to add a stub_only_libs dependency on the
android_module_lib_stubs_current stubs library to fix their stubs build.
For more context see another change in this topic:
https://android-review.git.corp.google.com/c/platform/packages/modules/Virtualization/+/2310569
Bug: 243512044
Test: builds
Test: m nothing
Change-Id: Id745cfb2789901672561050c1c3f8bb163922379
Previously, a java module with sdk_version: "system_server_current",
would only be able to access the system server or public API of a
java_sdk_library. This change allows it to access the system server,
module lib, system and public APIs in that order.
The apiScope structs define the characteristics of each of the
different API scopes used as required by the java_sdk_library. They are
organized into a hierarchy which is used for two different purposes.
The first purpose is to define an extension hierachy. If scope X
extends Y then X provides a superset of all API elements (classes,
fields, methods, etc) provided by Y. That is reflected in the fact that
the .txt file for X would be a delta on the .txt file for Y. So, system
extends public and so system_current.txt only contains additional API
elements to add to current.txt.
The second purpose is when a java_sdk_library/import is asked to
provide a specific API scope. e.g. a library that has:
sdk_version: "module_current"
will ask each of the SDK libraries it depends upon for a module-lib
API. However, not all of them will provide an API for that scope. In
that case it will find the closest suitable API scope.
Previously, it did that by traversing up the API extension until it
found an API scope that it did provide and return that. As
system_server_current extended the public API that meant that a library
which has:
sdk_version: "system_server_current"
would provide a system server API if available, and if not fall
straight back to public. That meant that the library could not access
system or module-lib APIs even though it is running in the system
server which should be able to access all APIs.
One way to fix this would have been to just have system server API
scope extend module-lib but that would have had a number of nasty
side effects:
* It would have created a significant overhead as every module that
provides a system server API would also have to provide a module-lib
and system API, along with their corresponding .txt files.
* Each existing java_sdk_library that provided a system server API
would need those .txt files created.
* Generating sdk snapshots for older releases would have been more
complicated.
* It would have confused developers.
All of that would be unnecessary because the system server API scope is
intended to be provided by libraries that are used solely by the system
server so there is no point in them providing anything other than a
system server API.
So, instead a separate access hierarchy was added which is the same as
the extension hierarchy for all existing scopes except for the
system server scope, which instead of just being able to access the
public API will be able to access the module-lib scope, which can in
turn access system and it can in turn access public.
That achieves what we want which is a library that is loaded into the
system server to be able to access all API scopes.
Bug: 204176972
Test: m nothing
Change-Id: I854df63fcaeba32afbc1eb0d1a501238022673d0
Previously, only the prefer property was copied from the
java_sdk_library_import module to its child modules which meant that if
the use_source_config_var property was used to control the prefer
property that the child modules would never be used. That can cause
build breakages when building against prebuilts as some parts of the
build will use prebuilt files from java_sdk_library_import and some
will use source files from the corresponding java_sdk_library.
This change copies the use_source_config_var property too.
It also adds tests to verify that dependencies on child modules of a
java_sdk_library use the prebuilt child modules of the corresponding
java_sdk_library_import. That revealed a bug with the handling of stub
sources where the prefer property was set after creating the module
which has also been fixed.
Bug: 249192297
Test: m nothing
# Cherry pick into branch broken by previous behavior and make
# sure that it fixes it.
Change-Id: I5719c257f8457bcb2238bc7965215512a20f1095
Previously the SDK info file only contained basic common information
about each member. This change adds support for each member to
provide custom information to add to the info file.
It uses that mechanism to add the following:
* "dist_stem"
* "scopes" object containing:
* for each scope a:
"<scope>" object containing:
* "current_api" - the path within the snapshot for the API's .txt
file.
* "removed_api" - the path within the snapshot for the removed
API's .txt file.
* "latest_api" - the path within the build to the latest finalized
API .txt file.
* "latest_removed_api" - the path within the build to the latest
finalized removed API .txt file.
In order to access the latest API files it was necessary to add and
resolve dependencies on the module that makes them available. In order
to do that safely the code for creating the names of the modules was
refactored to avoid duplicating the name creation logic.
Bug: 204763318
Test: m nothing
Change-Id: Ica68abbd2b2c7c2b2b7877b502f96cc89f06fd68
Migrate from ints to Strings so we can pass codenames. Otherwise we
can't use these attributes representing a release in progress until that
release is finalized. I.e. if release T is in progress, we don't get the
correct behaviour if we use "T" in those attributes
Bug: 191978330
Test: m nothing
Change-Id: I35389da0a01549ba2f820f5e5b78f6ea88c2aea1
In a follow up, apex would expect that any module that implements
ModuleWithMinSdkVersionCheck to have performed appropate checks on
min_sdk_version, to allow relaxing some of the existing conditions.
This change moves the responsibility of checking min_sdk_version
of java_sdk_library to java_sdk_library itself.
Bug: 205923322
Test: presubmit
Change-Id: I79b5a1fc34098fff60221e416db6e6e69e01f531
Previously it would write min_device_sdk whereas the correct name should
be min-device-sdk. This happened for all shared libs attributes.
Test: m nothing
Test: manually installed an apex with a shared lib and made sure PM used
the attributes as expected
Bug: 191978330
Change-Id: Iecf7edd6bae98c7af908d3f320f10ae4973d0396
Merged-In: Iecf7edd6bae98c7af908d3f320f10ae4973d0396
(cherry picked from commit bde653e5fd)
Perform consistency checks as per http://go/updatable-shared-libraries
These include:
* no attribute can specified can be less than T
* max-device-sdk can't be less than min-device-sdk
* min and max-device-sdk need to be at least the module's
min_sdk_version
* using on-bootclasspath-before implies that the module's
min_sdk_version is at least T or the library has min-device-sdk of at
least T
Test: m nothing
Bug: 191978330
Change-Id: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
Merged-In: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
(cherry picked from commit f9e584dd20)
We are expanding PackageManager's supported attributes and this change
enables the developer to define them in the .bp file.
Test: m nothing
Bug: 191978330
Change-Id: I01d579190fb585662086a7fc456f3b33cb89fb57
Merged-In: I01d579190fb585662086a7fc456f3b33cb89fb57
(cherry picked from commit 826863c8e0)
The annotations zip file is produced by the "main" sdk build and is
primarily consumed by android studio.
In order to support building the main SDK without requiring the sources
of all modules, we are adding module SDK artifacts that allows
reconstructing these outputs. The annotations zip contains XML files
which should be fairly easy to merge from all the individual parts.
Bug: 187397779
Test: unit tests in this CL
Test: m sdkextensions-sdk and inspect output
Change-Id: I955cae720e6f1382936836ee1d8fb11003f51b7d
Similar to the previous CL, but for jars from prebuilts.
Test: manual - 1. Patch aosp/1818020 and aosp/1810840.
2. m SOONG_CONFIG_art_module_source_build=false com.android.art
Bug: 194150908
Change-Id: Idc0c73a78045a602ad3a91cb5071d291bd611015
Automatically add `uses_libs`/`optional_uses_libs` properties specified
in `java_library` modules to the apps that transitively depend on these
libraries.
Note that a library may choose to specify its <uses-library> deps as
either optional or required. If this is not the right choice for an app,
it should be able to override it by specifying its own `uses_libs`/
`optional_uses_libs` properties.
Add Soong tests to cover the new cases.
Bug: 196377222
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: I601f3e2830ed9699b78d911966ee70812d32b4f6
Previously manifest_fixer used a naive way to distiniguish optional libs
from required ones: it checked if a library is on the list of optional
compatibility libraries. This works for compatibility libs, but not for
other libs.
Now we properly track optionality through all stages of the build,
starting with the addition of the library as a dependency (here's where
the `uses_libs`/`optional_uses_libs` distinction kicks in), store it in
dependency tag and propagate to class loader context, and from there to
the manifest_fixer.
The tests have been updated accordingly.
Bug: 196377222
Test: lunch bertha_x86_64-userdebug && m droid dist cts mts
Change-Id: I3631ce59ebe47116ce7a9b3d33a86f636846ef0f
When this file was initially created by extracting the test from the
java_test.go file it was not added to Android.bp file so was not being
built and tested as it should. That lead to a recent change that left
it unable to compile. This change corrects both those issues.
Bug: 186723288
Bug: 179354495
Test: m nothing
Change-Id: I06f32bb572f57b6df3c772f1d9d21fe323fbf353
Previously, an sdk snapshot could contain the following:
* A java_sdk_library_import module, e.g. "foo" which creates component
modules "foo.stubs", etc.
* A corresponding versioned module, e.g. "sdk_foo@current" which
created component modules "sdk_foo@current.stubs", etc.
* An internal (to the sdk snapshot) java_import for one of "foo"'s
components, e.g. "sdk_foo.stubs"
* A corresponding versioned module, e.g. "sdk_foo.stubs@current".
That causes a few problems:
1. The "foo.stubs" is duplicated.
2. The names of the components created by the versioned
java_sdk_library_import are invalid, as they append the component's
suffix to the version and not the name before the version.
The latter causes problems when building against prebuilts and fixing
that causes the generated snapshot to be invalid because it contains
duplicate definitions of the "sdk_foo.stubs@current" module. One
explicitly in the Android.bp file and one created by the
"sdk_foo@current" module.
Removing the duplicates from the snapshot causes errors as the name
generated by the snapshot for the component module, i.e.
"sdk_foo.stubs@current" does not match the name generated by the
"sdk_foo@current", i.e. "sdk_foo@current.stubs".
This change fixes them together.
Bug: 179354495
Test: m nothing
Merged-In: I515f235fe21755b5275af12366e96c24c94c0273
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
(cherry picked from commit a1aa7387f7)
Use FixtureWithLastReleaseApis to create the necessary files instead
of disabling the check with unsafe_ignore_missing_latest_api.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I162b0f68eec596274f8d98dca9d3f0500ab13f5d
The owner property is no longer used, the dist subdirectory is determined
by the dist_group property.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: Id6d997eef05f6511070677974219674f248cb754
Change the default dist_group from "android" to "unknown" to prevent
accidentally including java_sdk_library stubs that do not set
dist_group or owner in the public SDK.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I9aae2a16254ac1a8d444acfa63bc571d1ef4b045
Reusing the owner property is confusing, especially when the property is
required on every java_sdk_library module. Create a new dist_group property
to use instead.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I9e62c703a95d6b63cafa60bffb1b37ba85388593
