Build a new target *.latest.version which will contain a text file
containing the last finalized version.
Bug: 242316893
Test: atest prebuilt_apis_test
Change-Id: I41fa91c9ec273f342b7807c66c4d65ba13260124
Always use the latest extension as the latest API, regardless of
the current base extension version. This makes it so that we can
bump the base in master without changing which txt is considered
latest.
Also extend the error check to apply more widely (which caught an
error in the extension 3 finalization).
Bug: 228017107
Test: m checkapi (with api break & bumped base)
Test: prebuilt_apis_test.go
Change-Id: Ia10eb41ff500c566736f0d29a29984a99386bb6f
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
This makes it possible to pass an extensions_dir containing finalized
module APIs to prebuilt_apis. The extension versions are compared to the
api level versions to figure out what the "latest" finalized API is for
each module. This is done using the base_sdk_extension_version, such
that any extension higher than than base_sdk_extension_version is
assumed to be finalized after any of the existing api level versions.
Bug: 220086085
Test: prebuilt_apis_test.go
Test: existing module in prebuilts/sdk
Change-Id: Ib792f84202d436f594ba5e8716c6a187f9cd60dc
Improve code re-use and improve the names and data types of various vars
and functions. This makes it easier to extend it for the new use-case of
also supporting sdk extension versions on top of the current api level
versions.
This change is intended to be a noop.
Bug: 220086085
Test: m nothing (existing soong tests)
Change-Id: Icf4b320285f791e3b335f71f3c8b1ac52129dbc9
Previously, system modules were only created for the public API scope.
This change creates them for any API scope as long as its directory has
a core-for-system-modules.jar.
It does that by hooking into the existing logic for creating a
java_import for all jars in the API directories and creating a
java_system_modules for every core-for-system-modules.jar file. That
avoids the need for extra path globs.
Test: m droid
m sdk_public_current_system_modules
- works as expected.
m sdk_module-lib_current_system_modules
- fails with missing target as expected.
touch prebuilts/sdk/current/module-lib/core-for-system-modules.jar
m sdk_module-lib_current_system_modules
- fails with invalid jar file as expected.
Bug: 204189791
Change-Id: I27a264941009e03439d5d847dab14a7b4f6f119f
incompatibilities.txt doesn't exist anymore, only
"<module>-incompatibilities.txt". Clean up the associated logic that
mapped incompatibilities.txt to android-incompatibilities.txt.
Bug: 178171189
Test: m
Change-Id: I61eeb5dcc82770fa2af356bad11b7205551d6d83
Previously it was creating a java_system_modules which worked fine
because apart from the prebuilt nature the two are functionally
identical. However a follow up change will differentiate between them
which would break this code.
Bug: 182402568
Test: m nothing
Change-Id: Ifc13ce31235494e338d730c61a99d8887c5a2c5b
Set baseline_file properties of droidstubs generated in sdk_libary.go to
incompatibilities modules auto-generated by prebuilt_api. This requires
prebuilt_api to generate the modules whether next_api_dir is set or not.
Test: TreeHugger
Bug: 180123247
Change-Id: I690604a8a54e9d9419f072a28a0c0e7734abbd85
filegroups have the unfortunate limitation that they don't create phony
targets for building them in a convenient way. Also, having a single
output file fits better with the genrule concept.
Test: m framework-sdkextensions.api.public.latest
Change-Id: I229410658b04403ff1ff6abd4116a65aaa02b83b
Incompatibilities are a bit special in that we only ever want to use
the "latest" if it is for a non-finalized SDK.
Add a new argument, next_api_dir, and use only those files to create
"latest incompatibilities". Create empty incompatibilities for all
modules not in next_api_dir.
Bug: 178171189
Test: m
Change-Id: I727a52e3a45a5e607c6176d481b40fbf495c6eb0
This allows setting the prebuilt sdk's generated java_imports
sdk_version to "none".
Test: go tests
Test: m
Bug: 160455085
Change-Id: Id24aca811f0f09692971e63418da6685d8351737
Remove old TODO setting sdk_version to "current" as the associated bug
appears to have been fixed.
Test: m checkapi
Change-Id: I7737fbd17d2f54fc4578e04d07875b4b8d408ef9
Prebuilt SDKs >=30 now contain core-for-system-modules.jar,
convert them to system modules and use them when compiling against
the SDK to allow using javac -source 1.9 -target 1.9.
Bug: 117069453
Test: TestClasspath
Change-Id: Iebadad5980b952ed91c3ffd56cff1ce1827d3247
Merged-In: Iebadad5980b952ed91c3ffd56cff1ce1827d3247
This makes prebuilt_sdk look for and create modules in the module-lib
and system-server subdirs too, e.g.:
framework-wifi.api.module-lib.latest
Bug: 149293194
Test: follow-up change
Change-Id: Idbded6b633315034e669e9c5dd2bd30725d5c76b
Merged-In: Idbded6b633315034e669e9c5dd2bd30725d5c76b
An attempt to reference one of the prebuilt modules directly from an
Android.bp file highlighted a bug. The prebuilt_apis module used a
mutator to create filegroup and java_import modules for a set of api
versions. That mutator ran after the "prebuilts" mutator which handled
the renaming of prebuilt modules when the matching source module was
not present. That meant that the only way to reference the module was
by explicitly adding the prefix "prebuilt_".
This change fixed that bug by creating the modules in a load hook rather
that a mutator. This ensures that the prebuilt modules are present well
before the "prebuilts" mutator is run. Removing the mutator also removes
an unnecessary traversal of the whole dependency tree.
It also updated the documentation to explain that it creates
java_import modules as well as the filegroup modules.
(cherry picked from 47f6315f01)
Bug: 153649372
Test: m droid
Change-Id: Id44dce8ca9968ae903345df6ef1c4f1be9cb76c5
Merged-In: Id44dce8ca9968ae903345df6ef1c4f1be9cb76c5
Reduce the boilerplate required to call CreateModule by taking an
android.ModuleFactory instead of a blueprint.ModuleFactory.
Test: m checkbuild
Change-Id: I1259d2dd3f7893b5319c333bc180727ac40f9e91
The logic of getting latest api version has problem that we don't
guarantee $(module_name).latest is latest api txt file. So change this
logic to get the latest api txt file.
Test: make -j40
Change-Id: Ibbd8475061fc76169a4c94dcf148fece45b9a41d
A newly introduced sysprop_library soong module will generate a
java_sdk_library and a cc_library from .sysprop description files.
Both Java modules and C++ modules can link against sysprop_library
module, thus giving consistency for using generated sysprop API.
As Java controls accessibility of Internal / System properties with
@hide and @SystemApi, 2 different header files will be created. And
build system will selectively expose depending on the property owner
and the place where the client libraries go into.
Bug: 80125326
Bug: 122170616
Test: 1) Create sysprop_library module.
Test: 2) Create empty txt files under prebuilts/sdk.
Test: 3) Create api directory, make update-api, and see changes.
Test: 4) Try to link against sysprop_library with various clients.
Test: 5) Soc_specific, Device_specific, Product_specific, recovery flags
work as intended.
Change-Id: I78dc5780ccfbb4b69e5c61dec26b94e92d43c333
Add an empty DepsMutator to ModuleBase so it doesn't have to be
implemented on every module that doesn't need it.
Test: all soong tests
Change-Id: I545a832a0dbf27386d3080377a75ea482cd9ce59
To support core library, "Openjdk9", "No_standard_libs" and metalava
properties are added to java_sdk_library.
If core_lib is true, dist paths are changed to
apistubs/core/....
impl library name is changed to {module_name}.jar instead of
{module_name}.impl.jar
Bug: 110404779
Test: m -j
Change-Id: Ieb6248ea714b4260333d8bf61573d4f3413f7f24
Merged-In: Ieb6248ea714b4260333d8bf61573d4f3413f7f24
(cherry picked from commit af4907fed7)
The soong connect the prebuilt library according to LOCAL_SDK_VERSION.
But some sdk libraries has diffrent version policy with
LOCAL_SDK_VERSION. For this, we need to support direct link to the
prebuilt library instead of creating a new LOCAL_XXX_SDK_VERSION. So,
The base module name is used as the prefix for the prebuilt module name.
Remove the empty file check to support the absence of a prebuilt
library and add api_dirs property
Bug:77577799
Test: make -j
Change-Id: I1086977d26e4ddfd62e290637126d44e1b248bac
When the sdk_version or LOCAL_SDK_VERSION is not current or
TARGET_BUILD_APPS is not null, module will use the prebuilt
libraries. For this, prebuilt libraries are supported in
prebuilt_api.go
Bug:77577799
Test: make -j
Test: make -j TARGET_BUILD_APPS='camera2_stubs_test'
and check intermediates files
Change-Id: I9540c1d1a7a030bcc599b77df8d101529b12b3bf
droiddoc now supports apicheck. java_sdk_library uses it to
automatically perform apichecks against the not-yet-release API and
the latest-released API.
A module type prebuilt_apis is added. It finds api txt files and creates
filegroup modules so that it can be referenced from java_sdk_library
across the module boundary.
Bug: 77575606
Test: m -j
Test: m -j checkapi
Test: m -j update-api
Change-Id: I0ba859972eac060296e1df2e71c4e047392d4877