APIs to compile lambda are part of art's toolchain api surface.
Generating stubs from .txt files allows us to prune the remaining sdk
dependencies on libcore/ that are not api files
Test: m core-lambda-stubs.from-text
(On top of change containing core.current.stubs.from-text
and turning enabled: true)
Change-Id: I0ab8459b9317cb055a434eb635ba06d38da5b92e
Users can pass the jar-file creating module via dep_api_srcs property in
java_api_library to create the jar file not by compiling the stubs
generated from metalava but by extracting and zipping the class files
from the jar file of the input module.
Test: m android-non-updatable.stubs.from-text
Bug: 273381329
Change-Id: Id1b75179111cc7ff45faaff58388db1347bb18e5
* changes:
Create core_platform system modules from .txt files
Create system modules using .txt stubs
Create a defaults module for stripping out annotations
This system module is used to compile conscrypt and icu stubs. These
have migrated to java_sdk_library that set `annotations_enabled: true`
explicitly.
Test: m
Test: TH
Change-Id: I65ceb1fbf0dcdbb3504b69ebce6ca8f0b67e964d
In scope:
- core.current.stubs
- system modules generated for core's public stubs
- system modules generated for core's module_lib stubs
The system modules generated for core_platform api surface will be
handled in aosp/2514755
Test: go build ./java
Change-Id: I34134f79c8ae6e5b218d0b85553de5a748a8cc3f
Create a parallel set of java_system_modules that build using stubs from
.txt files. decodeSdkDep will be updated to use these system modules
behind a flag.
Since stub generation from .txt is not available at ToT yet, these
modules have been marked "enabled: false"
Test: None (will test when the enabled flag is turned on)
Change-Id: Ie9d465f5542a5430f03ba2e0861325011ac8e8c5
Hiddenapi processing uses the stub libraries to determine the api
surface boundaries. Use JavaLibraryName function to redirect the usage
of stubs from .txt files based on config.
This should be a no-op for now.
Bug: 271443071
Test: go test ./java
Change-Id: I1ed3ab2485c903bc57f627dc1acf1a3fbc0a3c4d
Create a parallel set of java_system_modules provided by the SDK. This
parallel set will build using stubs of core libraries generated from
.txt files. Since stub generation from .txt is not available at ToT yet,
these modules have been marked "enabled: false". decodeSdkDep will be
updated to use these systemModules behind a flag.
(Will create java_system_modules for core_platform in a future CL)
Test: None (will test when the enabled flag is turned on)
Change-Id: Idd89d656fcbc87e8698fe05d65a685ade4488546
This reduces code duplication in preparation for checking in a
java_system_modules created using stubs from .txt files
Test: No diff in the 4 java_system_modules
Change-Id: I0a13a0e7bf402cbe8f0dd3942b1f737cc6ac0de7
Context
- from-text android.jar files are built using Metalava, and these can be
utilized in `decodeSdkDep` so that any modules that depends on APIs
can be compiled using from-text android.jars
- This change removes dependency on source java files when compiling
stub android.jar files
Implementation
- Modify java_api_library module to create system modules using the
generated android.jar
- Replace modules in decodeSdkDep to link against java_api_library
modules
- Add --build-from-text-stub flag to hide the feature behind a flag
Test: m --build-from-text-stub
Bug: 271154441
Change-Id: I104df595edc65c0006820d5ae5b15f1fb167e190
Although stubs are not installable on device, we need to compile .dex to
support hiddenapi metadata generation.
Bug: 271443071
Test: Built out/soong/hiddenapi/hiddenapi-stub-flags.txt with
aosp/2487266
(There is still some delta due to missing signatures in child classes)
(Will address them in a followup CL)
Change-Id: Iac1330c449934085a479c487a1489aa1695a75ee
Change-Id: I1baa9c0f45eb8fc93f5c3177389ea5a2b7ca0a0b
max_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid max_sdk_version in bp
files
Bug: 208456999
Test: no change in ninja file (this should be a no-op)
Test: TH
Change-Id: I304b5ad802bde200137d8e225182828dfd6f7227
target_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid target_sdk_version in bp
files
Test: m nothing
Test: no change in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: I3c19245e29184bd9e5660ad8981966f64dfa9424
