Java modules using SystemAPI can now link against platform owned
sysprop_library with public stub. This allows modules to use platform's
public sysprops (which should be regarded as an API) without any hidden
API usages, if using dynamic linking and boot class path.
This doesn't affect any vendor or odm owned sysprop_library.
Bug: 141246285
Bug: 145167888
Test: m
Change-Id: I99824fb24a75cc8282211c2ad6c6296ae9fca393
Reduce the boilerplate required to call CreateModule by taking an
android.ModuleFactory instead of a blueprint.ModuleFactory.
Test: m checkbuild
Change-Id: I1259d2dd3f7893b5319c333bc180727ac40f9e91
sysprop_library now generates srcjar itself, effectively cutting the
implicit dependency from java module to sysprop module.
Bug: 131637873
Test: m {sysprop_library}-dump-api
Test: m (with no arguments) performs API check
Change-Id: Ia11a744e74b6f733ff0e30d194fbba22505ed644
sysprop_library now checks the API stability itself, cutting dependency
on java_sdk_library. Under the directory {module_dir}/api,
{module_name}-current.txt and {module_name}-latest.txt hold API
signatures.
When sysprop_library is built, or a user run "m {module_name}-check-api"
command, API check is performed. First, current.txt must have exactly
same signature with built sysprop_library module. Second, current.txt
must be compatible with latest.txt.
Build system emits a handy error message to generate/update those API
files, in case of missing or mismatching. Also, a script file for
freezing API files is introduced.
Bug: 131637873
Test: 1) m && boot blueline
Test: 2) m {sysprop_library} performs API check
Test: 3) manual test for check-api, freezing api
Change-Id: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: Ib7ad4f17e82c90da5ef3f80e2ab88c0b53112c60
(cherry picked from commit 093f0eb133)
.sysprop files are intended to be used only with sysprop_library, and we
can prevent build error by specifying dependencies upon CreateModule.
Bug: 131708148
Test: 1) try building sysprop_library module.
Test: 2) see liblog is correctly linked.
Change-Id: I702cedc255ee0b6a30c15e474dd6a88d9607b145
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
Creating new modules in a mutator is dangerous, as other mutators
that need to see the new modules may already have run, in this case
the prebuilts mutator. Move SdkLibraryMutator to a LoadHook instead.
Also moves registering the LoadHook mutator to testing.go so it is
registered for all tests.
Test: m checkbuild
Change-Id: I08bd76a0e6205d2ca27861058067a1562c339eed
Properties can be empty (not nil), and in that case some weird error
messages will happen to be emitted.
Bug: N/A
Test: try to build with api_pacakges: [] and srcs: []
Change-Id: I492077616e742072696265796520737465616b21
This is required for a sysprop module to be used by a module like the
init which is available both in core and recovery variants.
Test: m
Change-Id: I075428289f5bdce26e931ccf3262793ca6e4a0fd
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
