apex_set takes an .apks file that contains a set of prebuilt apexes with
different configurations. It uses extract_apks to select and install the
best matching one for the current target.
Bug: 153456259
Test: apex_test.go
Test: com.android.media.apks
Change-Id: I1da8bbcf1611b7c580a0cb225856cbd7029cc0a7
The module_lib scope should be called module-lib in order to pick up
the latest filegroup. Without it the API lint does not use a baseline
and so reports issues with released and unchangeable APIs.
It is also needed for the correct dist path.
Test: m update-api
Bug: 155164730
Change-Id: I7dbafd7164d5da600ca45c39a7f93a5a40027a1f
Vendor JNI libraries already have stable APIs enforced by the VNDK,
they shouldn't use SDK variants.
Bug: 156225490
Test: TestJNISDK
Change-Id: I21ba67e8e9fb05016caf5888129adc1a939545c2
JNI libs for "updatable" APKs or APKs in "updatable" APEXes should set
sdk_version which is equal to or less than APK's min_sdk_version.
In fact, we'd better check if min_sdk_version of JNI libs matches(or is
earlier than) min_sdk_version of the APK. But for now the build system
can't handle sdk_version/min_sdk_version correctly for JNI libs. That's
why sdk_version of JNI libs is enforced to match with min_sdk_version
of APK in this change.
(original commit: 98c4750f39)
Bug: 145796956
Test: m
Change-Id: I08543ccee7dfda0559a1fca108ceb5c28f84943f
Allow the sdk_version against which the stubs for a scope are compiled
to be specified in the module on a per scope basis.
Bug: 155164730
Test: m nothing
Change-Id: I5881e5ee7c2169c30f544882344a60a602dae917
Matches the naming scheme used by the separate manually created modules
that will be replaced by java_sdk_library's automatically created
components. This will simplify conversion to java_sdk_library as it
will allow developers to concentrate on getting the conversion correct
without also having to worry about name changes. It will also allow the
conversions to be parallelized as many of the references to the
components are in places where conflicts are likely.
Test: m nothing
Bug: 155480189
Change-Id: Ic859a61de155b3e582c17f6ab5e9298f5f4e709a
The constants are only used in one place in the code and in the test.
This change switches the test code to use the apiScope methods to
generate the names and then inlines the constants in those methods. It
makes it easier to see the naming convention.
Test: m nothing
Bug: 155480189
Change-Id: I966e82b8ae67624da168e05f5a2b062b832cb8cd
Adds a naming scheme abstraction to which the java_sdk_library/import
will delegate the task of creating the names of their component
modules. The naming scheme can be selected in a module definition but
for now the only supported option is "default".
Test: m nothing
Bug: 155480189
Change-Id: I708657661188ea4a14a4dd8c6bc4b46237bbe5e0
Extracts the child module naming to the commonToSdkLibraryAndImport
struct so it can be reused by both sdk library source and prebuilt.
Also:
* Makes all child module name generation go through the common struct.
* Renames some of the methods to clarify their purpose and improve
consistency.
Test: m nothing
Bug: 155480189
Change-Id: I9be9aab07252b491ab292b8847138a93b487cf53
The API file for a scope represents the differences between the API
provided by that scope and that provided by the scope that it extends.
On the other hand the stubs source for a scope represents the union of
the API provided by the scope and the scope it extends (all the way
back to public).
Unfortunately, while metalava supports this behavior for scopes that
extend public (e.g. system and test) it does not support this behavior
for scopes that extend others, e.g. module_lib which extends system.
This is because it always assumes that the baseline for the API file
is 'public' and so has no way to defined other baselines.
This change works around that by having separate droidstubs modules to
generate the API and stubs sources for scopes that require different
arguments to generate the API and stubs sources.
Test: m checkapi
Bug: 155164730
Change-Id: Iea7d59852d7aeb503120acf3c44e08eb0d9d07b9
