java_sdk_libraries can be part of non-updatable modules. Those modules
might have a need to expose @TestApis that are only used in CTS tests.
This change adds an ability for them to do so by introducing
all-non-updatable-modules-test-stubs, and adding it to the
android_test_stubs_current.
Note that this change doesn't allow updatable modules to contribute to
test API stubs, since the list of the modules that can contribute to
test APIs stubs is hardcoded in the non_updatable_modules constant.
Bug: 261004711
Test: m
Change-Id: I9d17f49702bd64f5718b445f14b203c146bc6794
Since framework-virtualization is part of a non-updatable APEX module,
it should still be allowed to compile against unstable APIs. However,
the current setup of all-framework-module-impl prevents that, since the
all-framework-module-lib target compiles against module_sdk.
This change works around this by introducing the
updatable-framework-module-impl target which builds against
module_current SDK, and includes all updatable modules.
The non-updatable modules are then statically linked into the
all-framework-module-impl target, which builds against hidden APIs.
Bug: 243512044
Test: builds
Change-Id: I253aa8dcd7c9b109e023a44128ce08ec8f2b4d33
Soong modules compiled against the module or system server sdks
should use the api_versions.xml for their respective sdk, but
currently they use the public-filtered api database. Add module
and system server sdk build targets to be used later.
Right now they're unused. I'm adding them first so that they
can be built on the build server, and then we can import them
into prebuilts/sdk, as some builds require the api files to be
prebuilt.
Bug: 193460475
Test: m api-versions-xml-module-filtered api-versions-xml-system-server-filtered
Change-Id: I668a878a470125ed3ecf79435713c27c4dd92b0a
Setup scaffold for the Health Connect system service.
This service will provide system APIs to read and write
health data.
Bug: 249321392
CTS-Coverage-Bug: 248508112
Test: atest android.healthconnect.cts
Change-Id: I503c24a039c37d09895fc4f73a1de1a13eeb72b0
They're already triggered by some other dependency for "full"
builds, but checkapi is expected to check all the APIs.
Test: m checkapi (with breaking change)
Change-Id: Ib9378bd6b6c43c7166309901f516c22e25e9ff4a
This is going to be disted instead of the monolithic one being
used currently.
Bug: 235140934
Test: m sdk-annotations{,-system}.zip and diff; manual spot checking
Test: m sdk dist && diff out/dist/system-data/annotations.zip with this
Change-Id: I9874f88e933a8b804a73638e6bac7a9d312c7c9f
It's clearer to define the module in Android.bp, and keep
our custom Go code to the minimal. The only thing the go
code really needs to do is create a "all module annotations"
module. This matches the pattern of the other modules here (the
pattern was invented after sdk-annotations.zip was first
migrated).
Bug: 235140934
Test: m sdk-annotations.zip before/after (no diffs)
Change-Id: Iae246081bcf4e5177d1da98c2e01c702fb349a22
These two databases are (nearly) identical but the latter is generated
in a much more efficient way.
The diffs are very minor and it's not clear to me which versions is more
correct than the other, though I'm fairly confident they don't matter.
https://paste.googleplex.com/5567994005553152
Droidstubs now support using the api-versions.xml from another
droidstubs module, so reuse the one from api_versions_public
in framework-doc-stubs.
Bug: 187398174
Test: diff api-versions.xml
Test: diff stubs of framework-doc-stubs
Change-Id: I774be9097e97d6b180fe54d799c94515780be6ec
When disting into the apistubs/... dir (the "new" path),
the merged api txts are called android.txt rather than
current.txt, to align with all the other <module>.txt.
Also add a new dist goal to build just these files into a
convenient location.
Test: m api_txt dist
Change-Id: I762763cc42b497e00277a8871ef62b0a11423e35
A bit more context for the next person looking into improving this
check (it's not straightforward).
Test: No
Change-Id: Ie389bc10dcc307a996dc3a7fad55405fe12a09b9
