Currently, there is no build action ensuring that the API text files are
up to date, unless a user runs `m checkapi` or `m update-api`. This
means that the user must run `m update-api` after making a change that
modifies api surface(s), so that the API text file reflects the local
change. This adds additional layer of action to developers, and it is
not guaranteed that the developer will always run `m update-api` after
making an api surface-affecting changes.
To prevent such mistake, this change adds droidstub-level api check as
validation for from-text stub generation. With this change, the build
will fail if the API text file is not up to date and the user must run
`m update-api` when making api surface-affecting local changes.
The validation is done by adding all droidstubs modules associated with
the java_api_contributions passed to java_api_library via
`api_contributions` as dependency and setting the current api timestamp
files as the validations for the from-text stubs generating build rule.
The full api surface libraries will not run the validations to avoid
circular dependency. However, all java_sdk_library generated
java_api_library modules will run validations, mapped to the droidstubs
in the same api domaion.
If the user sets the environment variable `DISABLE_STUB_VALIDATION=true`, validation
actions are not run. Validation actions run by default.
Test: m nothing --build-from-text-stub and run ninja query to verify `check_current_api.timestamp`s are listed as validation \
DISABLE_STUB_VALIDATION=true m nothing --build-from-text-stub and run ninja query to verify that validation actions are not added
Bug: 288624417
Change-Id: I329e6438fe8f3ac30d8c6a971d57853ed6b0d150
java_api_library modules generated from java_sdk_library get
full_api_surface_stubs corresponding to the api surface that the module
contributes to. However, modules generated from java_sdk_library where
sdk_version is none should not depend on the full api surface stub jar.
Test: m --build-from-text-stub
Bug: 288624417
Change-Id: I7edda3e6a40f739e805e8719b8d366da765a6933
When building with use_resource_processor: true R.jar files from
shared andoid_library dependencies need to be added to the classpath
so that the generated R classes can be referenced.
Bug: 294256649
Test: m DocumentsUIPerfTests
Change-Id: I30a6bddc3f378ecf58f142f94049e67ba33a47e3
JDK17 is the default java version, adding these props conditionally
openjdk9 is no longer relevant
Test: CI
Change-Id: I5d80fd22f474cedf389d1e295620cfc17bc327a0
Hiddenapi takes a single widest api scope stub dex jar as an input, as
the tool does not support handling duplicate classes passed as inputs.
A problem regarding this is that the test and module lib api surfaces do
not strictly have a subset/superset relationship, unlike other api
surfaces.
This has not become a problem for stubs generated from source
files as the stubs contain all methods in the source files, but became a
problem for stubs genereated from text files as the stubs only contain
the methods that are essential for compilation of the stubs and its
reverse dependencies, and there were cases where the hiddenapi flags are
not properly propagated to the subclasses.
To resolve this problem, a java_api_library module that provides the
union of the test and the module lib api surfaces was introcudes. Since
hiddenapi_modular currently defines the module lib api surface to be a
wider api scope over the test api scope, the new module can be passed as
input to hiddenapi over the module lib non updatable stub module to
resolve the problem.
Test: enable hiddenapi for from-text stub build && ENABLE_HIDDENAPI_FLAGS=true m --build-from-text-stub
Bug: 191644675
Bug: 275570206
Change-Id: I9a230ec5082c52ed866f29b0748814f2cf10279b
Currently in Soong testing suite, the only method for testing module
dependency is CheckModuleDependencies(...), which comapares for the
exact module dependencies. This change adds the method
CheckModuleDependency(...) which enables checking the dependency between
two modules, instead of comparing for all dependencies of an interested
module.
Test: m nothing
Bug: 288624417
Change-Id: I804d35979ddc24b0134671e326c1d37615ec4190
Previously, only the essential java_api_library and
java_api_contribution modules were being added to the template bp file
for testing purpose. However, since the child change aosp/2640275
adds droidstubs that generates the java_api_contribution as the
dependency of the java_api_library modules, not adding the droidstubs
modules to the template bp file will lead to missing dependency errors
in Soong test cases that tests the from-text generation &
java_api_library functionality.
To prevent this, this change adds the droidstubs modules instead of the
auto generated java_api_contribution modules to the template bp file to
more closely align with the real life behavior.
Test: m nothing
Bug: 288624417
Change-Id: I6a25e2f6c5f1281e96eca15aa5eec7417635df3f
Bug: 279960392
Test: CI and m --skip-soong-tests TARGET_PRODUCT=aosp_x86_64 EMMA_INSTRUMENT=true CLANG_COVERAGE=true NATIVE_COVERAGE_PATHS="external/cronet" mts
Change-Id: I4489ed725aee6097e6e340f5f6d06ecaf1c64222
System_modules property provides the jars passed as bootclasspath when
compiling the stubs in the java_api_library where its creating
java_sdk_library's sdk_version is none, as the jars will not be provided
from the full_surface_stub_libs but compiled by itself in the child
change.
The jar provided by the system_modules will also be passed to metalava
to resolve hierarchy coming from outer dependencies.
Test: m --build-from-text-stub
Bug: 288624417
Change-Id: I8f3b89efa24bceb070d7a37fae3c7334dd7f0868
