ANDROID_PUBLIC_STUBS currently has multiple usages in the build, in
multiple .mk files.
Instead of modifying the current functionality of ANDROID_PUBLIC_STUBS
by replacing its value from "android_stubs_current" to
"android_stubs_current_exportable", this change introduces
ANDROID_PUBLIC_EXPORTABLE_STUBS, which evaluates to
"android_stubs_current_exportable" and used only when generating the
`full_target` in `development/build/Android.mk`.
Test: patch in git_main, lunch aosp_arm-ap31-eng && m sdk dist && inspect android.jar outputs
Bug: 323261972
Change-Id: Ic2b03a5a4afdefb459d89f8104916446599eaf31
This change modifies the dependencies of the hiddenapi to always depend
on the exportable stubs, instead of the currently utilized everything
stubs.
To support this, the full api surface exportable stubs are defined in a
separate change at the `frameworks/base` project. Note that the full api
surface exportable stubs are only used for the hiddenapi purpose, and
`sdk_version` continues to utilize the currently existing everything
stubs.
Currently, this feature is hidden behind the build flag
"RELEASE_HIDDEN_API_EXPORTABLE_STUBS". This feature will be fully
enabled once metalava fully supports handling of the flagged apis.
Test: ENABLE_HIDDENAPI_FLAGS=true m
Bug: 317426356
Change-Id: I109b7cd27b20ceffcdf1766ab8106b0c276be2b3
https://android-review.git.corp.google.com/q/topic:limit_systemsdk
introduced a new check for preventing the use of system SDKs above 34
from Java modules in the vendor partition.
As this may break some unprepared targets, introduce
BUILD_BROKEN_DONT_CHECK_SYSTEMSDK as a temporary escape hatch.
This flag will be deleted eventually.
Bug: 314011075
Test: Add BUILD_BROKEN_DONT_CHECK_SYSTEMSDK := true to BoardConfig.mk
Change-Id: Id7901f85c221bc03fa1c15ef15dbec14b783a79a
This change disallows Java modules in the vendor partition to use System
SDK that is newer than API level 34; 34 is the latest allowed.
Background 1: with Trunk Stable, the system/vendor interface is released
at Q2 whereas the system/app interface is released at Q3. In other
words, at Q2, the APIs which will be added to the system SDK at Q3 are
not available. Since the system/vendor interface (which is fronzen at
Q2) is what the modules in the vendor partition will be building
against, they can't and shouldn't use those new APIs that will be added
in the future (Q3). Using those APIs is risky because there's a chance
that those APIs get removed or changed between Q2 and Q3. For example,
2024 Q2 is technically still Android U, not Android V.
Background 2: The use of Java APIs in the vendor partition had many
issues. Most significantly, those "vendor" Java apps are categorized as
part of the system partition because all Java app processes require
access to platform internal libraries that are prohibited to vendor
processes. Furthermore, since the Project Treble, the vendor partition
was re-purposed to a partition to host SoC-dependent bits - usually
HALs. Implementing HALs in Java has never been officially supported and
has had many loop holes.
We'd like to use both background 1 and 2 as a chance to disallow any
Java code in the vendor partition. However, since there are already some
Java modules in the partition, we can't suddenly ban it. The deprecation
will be made gradually, and this CL is the start.
Note that sdk_version: "current" or "system_current" is automatically
overridden into 34 or system_34. This is to prevent sudden breakage of
vendor modules that have been targetting the latest (i.e. current) API
level. They will however fail if they use APIs newer than API level 34.
Bug: 314011075
Test: m blueprint_tests
Change-Id: I59f5ac15ce9ac2ff7cc89e9c110169359077c37c
Provides SdkTestCore/test_core_current sdk_version for non-updatable
modules that have their test scope dependent on test apis from
framework-minus-apex.
Ignore-AOSP-First: Change in topic with internal-first projects
Bug: 289776578
Test: m checkapi | go test ./java
Merged-In: Iba3213e8c34ea75ac9dd8532a95ef62fb5455e6c
Change-Id: Iba3213e8c34ea75ac9dd8532a95ef62fb5455e6c
Since the name of the java_library generated from sdk_library per api
scope does not depend on the build configuration anymore, all
dependency switching "magic" via android.JavaApiLibraryName() can be
removed.
This change also removes from-text-build-specific test cases, as those
test cases depend on build configurations.
Test: m nothing && m nothing --build-from-text-stub
Bug: 287340610
Change-Id: I3bac35259e0cbaa16432a46cb2b128951c9bc075
This change cleans up references to android.JavaApiLibraryName() so that
rdeps link against "android_*_stubs_current" instead of
"android_*_stubs_current.from-text".
Bug: 284995489
Test: m
Change-Id: Ibdf33b15981317c43e468dbc1657229d54bbd226
Use JavaApiLibraryName function to redirect the usage
of core platform api stubs from .txt files based on config.
Test: m --build-from-text-stub
Change-Id: I926a0a455fed301ba4ff9dfa509d4dbbbd076029
Modify the visibility of defaultJavaLibraryName() to export it so that
it can be accessed from another package. This is essential for use case
when identical JavaApiLibraryName() has to be returned regardless of
config.
Test: m
Change-Id: Iefa1b3eb18a0d2717284608c825f488e7ae73df0
The "FromText" suffix is an implementation detail. Having this suffix in
the name can be also confusing because in certain settings (e.g. when
not run with --build-stub-from-text) it returns the name of the stub
module generated from source files
Test: go build ./java
Change-Id: I68678ddfaa3d68c8e1a945632e7512b5de33d9af
Context
- from-text android.jar files are built using Metalava, and these can be
utilized in `decodeSdkDep` so that any modules that depends on APIs
can be compiled using from-text android.jars
- This change removes dependency on source java files when compiling
stub android.jar files
Implementation
- Modify java_api_library module to create system modules using the
generated android.jar
- Replace modules in decodeSdkDep to link against java_api_library
modules
- Add --build-from-text-stub flag to hide the feature behind a flag
Test: m --build-from-text-stub
Bug: 271154441
Change-Id: I104df595edc65c0006820d5ae5b15f1fb167e190
max_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid max_sdk_version in bp
files
Bug: 208456999
Test: no change in ninja file (this should be a no-op)
Test: TH
Change-Id: I304b5ad802bde200137d8e225182828dfd6f7227
target_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid target_sdk_version in bp
files
Test: m nothing
Test: no change in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: I3c19245e29184bd9e5660ad8981966f64dfa9424
This relands aosp/2457063. The original change broke T and U since those
branches still contain soong modules of type (kind+level). Those soong
modules have been cleaned up now
Test: Used go/abtd to test T and U branches with this change
Bug: 208456999
Change-Id: I0ef7933c055f88cb512a02108f1173e51156ef1c
This relands aosp/2457062. The original CL was submitted as part of a
stack that broke tm and udc. Those branches still contain soong modules
with min_sdk_version of type (kind+level).
Bug: 208456999
Test: m nothing on tm and udc (via go/abtd)
Change-Id: I10e8bea59cd5914d36b2c9539ee1556e55b82e53
This relands aosp/2470068. The original CL was submitted as part of a
stack that broke tm and udc. Those branches still contain soong modules
with min_sdk_version of type (kind+level).
Test: m nothing on tm and udc (via go/abtd)
Bug: 208456999
Change-Id: I8e013ec10530372f70f0ab0505b7eebeee2b360b
build/make has several hardcoded references to these modules. In
preparation for switching between stubs generated from .txt files,
export these module names to Make. This prevents duplication of stub
selection logic in multiple places.
Test: TH
Change-Id: I5b1ef27aaea269d60aa7953787ea10d1b2a793f2
These hardcoded refs will need to be updated when we start using .txt
stub equivalent (single-tree/multi-tree). Instead of strewing this logic
all over the codebase, create a helper function that contains the
replacement logic. All other places should call this helper function
instead of calculating the name of .txt equivalent soong module by
itself.
(Will do a similar cleanup in build/make)
Test: no change in ninja file
Change-Id: I6bf999eb4aeaba6ac2a44b9016bae4ec8c79ce19
Currently it would return the default one even if the requested one is
an active sdk.
Bug: 270609292
Test: go test ./java
Test: built `rkpdapp` locally in internal and verified that its
targetSdkVersion is U and V
Test: TH
Change-Id: Idb03ff4786ff87fb7911bf31205941618a662404
This creates a new API surface for the APIs provided by ART to compile
other API domains (e.g. this contains LambdaMetaFactory). The scope of
this API surface is restricted to compile-time. Unlike the other API
surfaces (e.g. public) whose APIs will exist on device in the form of
implementation libraries, these classes are not guaranteed to exist on
device.
This also updates the naming convention map used in Multi-tree API
export
Bug: 261244752
Test: TH
Change-Id: I164714d68618a3c289bac1a695958e36fdbbda5d
- The converter runs for api_bp2build, not bp2build workspace
- Since droidstubs is an internal module created by java_sdk_library,
the conversion encompasses the latter as well
- Since droidstubs do not have an api_surface attribute, this conversion
uses naming convention to infer the api_surface represented by the api
file e.g. *stubs.source -> publicapi, *stubs.source.system -> systemapi)
- Also adds an SdkIntraCore enum to represent the API surface provided
by one core module to another
There is also ongoing work to check in java_api_contribution modules in
Soong. Once we have that, we can update this converter to operate on
that module type instead
Test: go test ./bp2build
Change-Id: Ia85828e04c738d9ffcc524856d7c3034ee29bbf9
If max_sdk_version is included in Android.bp that value will now be
propagated to manifest_fixer.py. This value will then be used to
override any maxSdkVersion attribute set on permission or
uses-permission tags in the android manifest if maxSdkVersion="-1".
Bug: 223902327
Test: add max_sdk_version to Android.bp for test app
Test: create permission in test app manifest with maxSdkVersion="-1"
Test: run test to check maxSdkVersion=max_sdk_version
Change-Id: Ic533ef2a41b9ecc9ee68c69399026df47ee945b7
Previously, the tests only covered checking the sdk dependencies added
when using a prebuilt current (public) and system SDKs, i.e. with
sdk_version set to "current_30" or "system_30". This change adds tests
to cover other APIs, e.g. "test_30", "module_30" and
"system_server_30". It adds tests for "module" and "system-server" up
to API level 32 as following changes will give them different behavior
as API levels less than or equal to 31 do not have a separate
core-for-system-modules.jar file for the module-lib API.
Bug: 204189791
Test: m nothing
Change-Id: I585a88615439a24abf75250114a86113b5f5da57
If sdk_version is set to "", it means the module is built with the
in-development version of the platform APIs. "core_platform" means the
in-development version of the core Java APIs. In both cases, the API
level (i.e. which version to use) is the in-development version.
Bug: 1663140
Test: m
Change-Id: Ia184190341223e9ac12710a8bb3a25004fd4f539
Previously, SdkSpec was constructed only from the user string. It didn't
make use of the Config struct where information about the latest stable
SDK version, etc. is recorded. As a result, the build system couldn't
check if the sdk version "current" is referring to the in-development
(i.e. not-yet-frozen) SDK version or the latest stable version.
"current" was always assumed to be in-development (IsPreview() returns
true) even when Platform_sdk_final == true.
As the first step for fixing that, this change requires
android.EarlyModuleContext to be passed when constructing SdkSpec from
the user string.
In the following changes, "current" will be mapped to either
FutureApiLevel (10000) or one of the FinalApiLevels() depending on
whether the platform SDK was finalized or not.
Bug: 175678607
Test: m
Change-Id: Ifea12ebf147ecccf12e7266dd382819806571543
SdkSpec.Version was an int type. Now it becomes ApiLevel type which
is a better abstraction of the version (or api level).
Bug: 1655587
Test: m
Change-Id: I4d67b9b9eae45f653b6af4f5b73da9e091b3dfab
... in preparation for making the handling of sdk versions consistent
across java and cc modules.
Bug: 175678607
Test: m
Change-Id: I598f0454bce9b7320621022115412fbe97403945
