The name of the sdk library will be used in source vs prebuilt
selection. For soong modules that are not dynamically created from a
java_sdk_library, the value will be nil.
Bug: 308174768
Test: TH
Change-Id: Ic7e9889f00c6184992b663a7124967bb0794d475
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
Currently, there is no build action ensuring that the API text files are
up to date, unless a user runs `m checkapi` or `m update-api`. This
means that the user must run `m update-api` after making a change that
modifies api surface(s), so that the API text file reflects the local
change. This adds additional layer of action to developers, and it is
not guaranteed that the developer will always run `m update-api` after
making an api surface-affecting changes.
To prevent such mistake, this change adds droidstub-level api check as
validation for from-text stub generation. With this change, the build
will fail if the API text file is not up to date and the user must run
`m update-api` when making api surface-affecting local changes.
The validation is done by adding all droidstubs modules associated with
the java_api_contributions passed to java_api_library via
`api_contributions` as dependency and setting the current api timestamp
files as the validations for the from-text stubs generating build rule.
The full api surface libraries will not run the validations to avoid
circular dependency. However, all java_sdk_library generated
java_api_library modules will run validations, mapped to the droidstubs
in the same api domaion.
If the user sets the environment variable `DISABLE_STUB_VALIDATION=true`, validation
actions are not run. Validation actions run by default.
Test: m nothing --build-from-text-stub and run ninja query to verify `check_current_api.timestamp`s are listed as validation \
DISABLE_STUB_VALIDATION=true m nothing --build-from-text-stub and run ninja query to verify that validation actions are not added
Bug: 288624417
Change-Id: I329e6438fe8f3ac30d8c6a971d57853ed6b0d150
java_api_library modules generated from java_sdk_library get
full_api_surface_stubs corresponding to the api surface that the module
contributes to. However, modules generated from java_sdk_library where
sdk_version is none should not depend on the full api surface stub jar.
Test: m --build-from-text-stub
Bug: 288624417
Change-Id: I7edda3e6a40f739e805e8719b8d366da765a6933
System_modules property provides the jars passed as bootclasspath when
compiling the stubs in the java_api_library where its creating
java_sdk_library's sdk_version is none, as the jars will not be provided
from the full_surface_stub_libs but compiled by itself in the child
change.
The jar provided by the system_modules will also be passed to metalava
to resolve hierarchy coming from outer dependencies.
Test: m --build-from-text-stub
Bug: 288624417
Change-Id: I8f3b89efa24bceb070d7a37fae3c7334dd7f0868
With api_files property being removed from java_api_library, all api
files are passed to java_api_library via java_api_contribution, which
provide api_surface information. Instead of relying on the naming
convention of the api files, java_api_library can utilize this
information to sort the api files from narrower api scope to the wider
api scope.
Test: m --build-from-text-stub
Bug: 295429988
Change-Id: Idd832778833c072c6b7e9d1f775533e5f4e2af00
This no-op refactoring facilitates some upcoming functional changes for
"bp2build allowlist v2". The work requires that the bp2build conversion
mutator be changed from a TopDown mutator to a BottomUp mutator.
Refactoring all bp2build-related methods so that they use Bp2buildMutatorContext
makes it easier to make this functional change without touching tens of
files and multiple projects.
Bug: 285631638
Test: m bp2build
Change-Id: I3d1ef3064146e959c6f0dc315350fc9764bf2bd2
Test: go test bp2build conversion tests
Test: enable modules build from prebuilt and m nothing
Bug: 300640274
Change-Id: I8c015aec546d052bef6c42869e12db4e87d39780
This change modifies sdk_library_import so that it directly creates
java_api_contribution per api scope. The module creates api_contribution
module for api scopes where the api file is specified.
Test: m nothing && MODULE_BUILD_FROM_SOURCE=false m nothing
--build-from-text-stub and inspect ninja dependency of java_api_library
Bug: 300175323
Change-Id: I74be3b4f1efef7f7d1cb8bd7b6c893b9cef0f370
java_sdk_library generates stub java_library module which compiles the
stub generated from either source or txt files, which is toggled based
on the build configuration. The java_api_library/java_library module
that compiles the stubs should not be directly accessible to the modules
outside of the sdk_library module scope, thus modify their visibility as
private.
Test: m nothing
Bug: 299373105
Change-Id: Ia4a08bf6e65c521814c82f54ea43cc8d367834e3
Since full_api_surface_libs extract class files instead of srcjar file,
full_api_surface_stub can be replace with android_*_stubs_current,
instead of the api_library android_*_stubs_current.from-text.
Functionally, the class files of the two modules are identical (in
from-text stub build), but depending on the from-text java_api_library
leads to missing dependency errors in partial branches (especially ART
branches). To resolve this problem, make sdk_library generated
api_library depend on the missing dependency handled
android_*_stubs_current.
Since android_module_lib_stubs_current.from-text does not have its
from-source equivalent, this can remain as dependency as the module is
moved to build/soong in aosp/2674196
Test: m (default to from-text stub build)
Bug: 274805756
Change-Id: Ic8bbd25252e5f9f1dc7c059ce6b00a951188985d
legacy.i18n.module.platform.api, stable.i18n.module.platform.api and
conscrypt.module.platform.api contributes to api surfaces, but the
corresponding stub libraries were being generated from source during
from-text stub build. This discrepancy may lead to hiddenapi failure.
Thus, enable these modules to be built from txt files during from-text
stub build.
Test: m
Bug: 274805756
Change-Id: I940dc8484b210bb8aea57ead1055983be7cdf5ec
Currently, stub java files are extracted from srcjar file provided from
dep_api_srcs in java_api_library module generated in java_sdk_library
per api scope. However, compiling the java files may lead to difference
in the content of the generated class files even if the stub java files
are equivalent, as javac may arbitrarily add overridden methods. Thus,
create a stub jar file instead of creating a stub srcjar file and
compiling it, in order to guarantee stub jar files content equivalence
and thus enable hiddenapi during from-text stub build.
Note that this change does not fully resolve differences between the
full api surface csv and the per sdk_library csv. Instead, it removes
the difference caused by methods arbitrarily added by javac.
This change also renames dep_api_srcs to full_api_surface_stubs to be
more intuitive.
Test: rebase on top of aosp/2617274 and `m --build-from-text-stub`
Bug: 275570206
Change-Id: I22b6d56624633681f5c3b000370b5782655c7b8d
Metalava no longer looks for common typos. It relies on the code
analyzers that run on Gerrit to detect them.
Bug: 288072162
Test: m checkapi
Change-Id: I08eca8008af39ebe69442db419ebd3d3378aa0de
This also changes the expectation of ConvertWithBp2build. Each
implementation must either create one or more Bazel target modules, or
mark the module as unconvertible (with a specific reason).
Manually verified no runtime hit in AOSP
In AOSP, the metrics file size increases from 252K to 1.6M
This changes some effective module counts in bp2build metrics:
- Removes "package" modules from the module count list in
metrics, as these will not be converted like regular modules.
- Counts Handcrafted modules as being "unconverted", as bp2build is not
responsible for them.
Bug: 285631638
Test: Verified generated BUILD.bazel files are bit-for-bit identical
with this change
Test: Manually verified one case of each implemented reasonType
Change-Id: I308dd451d8f28379b15671dae9f931bd0446f5c1
Rename java_library created inside sdk_library with the ".from-source"
suffix, and set it as static lib of the top level java_library, which
gets java_api_library instead as static lib during from-text stub build.
Test: m nothing && m nothing --build-from-text-stub
Bug: 286446015
Change-Id: I32e8ea264987e9f9df05e462292bd54e45074912
This change enables java_sdk_library to generate java_api_library
modules per api surface, so that from-text stubs can be generated per
api domain scope. This module is only created when
`--build-from-text-stub` flag is passed during build.
Test: enable disabled modules in java/core-libraries/TxtStubLibraries.bp then m art.module.public.api.stubs.from-text --build-from-text-stub
Bug: 276957733
Change-Id: Ic1ead15b3d0bcb921ca8d31bcaeeb4cd9ee8715c
Merged-In: Ic1ead15b3d0bcb921ca8d31bcaeeb4cd9ee8715c
Hiddenapi processing uses the stub libraries to determine the api
surface boundaries. Use JavaLibraryName function to redirect the usage
of stubs from .txt files based on config.
This should be a no-op for now.
Bug: 271443071
Test: go test ./java
Change-Id: I1ed3ab2485c903bc57f627dc1acf1a3fbc0a3c4d
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
min_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 min_sdk_version in bp
files
Will do a similar cleanup for targetSdkVersion and maxSdkVersion in a
followup CL
Test: m nothing
Test: no change in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: Ie6ae7e267d093c5e4787e82685daaca1021d202e
* changes:
Use the profiles in the APEX to dexpreopt system server jars.
Add tests for the ignored "profile_guided: true" property.
Output dex_preopt to SDK snapshot.
After this change, if "profile_guided: true" is set, profile-guided
compilation will be enabled for the jar and the ".prof" file next to
the jar in the APEX ("javalib/<name>.jar.prof") will be used as the
profile when dexpreopting for the prebuilt APEX.
Bug: 241823638
Test: m nothing
Test: -
1. (on internal master) Patch aosp/2426453.
2. Build the APEX bundle and the module SDK of com.android.wifi
3. (on tm-dev) Patch this CL and aosp/2141972.
4. Copy the APEX bundle and the module SDK built on step 2 to the
source tree
5. Disable hiddenapi check
6. lunch cf_x86_64_phone-userdebug && m MODULE_BUILD_FROM_SOURCE=false com.google.android.wifi
7. cat out/soong/.intermediates/prebuilts/module_sdk/Wifi/current/prebuilt_service-wifi/android_common_com.android.wifi/dexpreopt/oat/x86_64/javalib.invocation
8. See the profile being used.
Change-Id: I55a5a295e9c5d6f0564afb139c5fb7da91ab8cae
This is needed to determine whether we need to deapex the profile or
not.
Bug: 241823638
Test: m nothing
Test: -
1. Patch ag/20582608 PS2.
2. TARGET_BUILD_APPS=com.android.wifi packages/modules/common/build/mainline_modules_sdks.sh
3. See the `dex_preopt` property being written.
Change-Id: I05177388c24be1ab315247ea85e7e3a8600cebd3
Only public, system, test, module_lib and system_server are
converted in order to generate api_fingerprint.txt in Bazel.
Test: java_sdk_library_conversion_test.go and TH
Bug: 266973526
Change-Id: I67a00806165e5afad3876b6cd5cdbc6b0dd65d8b
Currently, droidstubs module create java_api_contribution module, but
when a java_sdk_library module dynamically creates a droidstubs module,
java_api_contribution is not created as the hook inside droidstubs get
lost. Therefore, call hook inside sdk_library after creating the
droidstubs module.
Test: m
Change-Id: I68bf1d796f6f9a6f81011ae35e4991b6ed1421ea
Context
- droidstubs module are either generated from the java_sdk_library
module or defined in the bp files.
- Since droidstubs module contains API text file property,
java_api_contribution module can by dynamically created from
droidstubs.
Implementation
- Add `api_surface` property in droidstubs module. This property is
either inherited from the java_sdk_library or written in the module
definition in the bp file.
- Add defaultable hook in droidstubs module to generate the child
java_api_contribution module.
Test: m
Change-Id: Ica43d65614723c623cd0c155266f9844e69e5d5e
That method was provided to allow a java_sdk_library_import that was
part of a versioned sdk snapshot to create the name of its component
modules consistent with the way in which modules were named within the
sdk snapshot. As versioned sdk snapshots have all been removed this is
no longer necessary.
Bug: 260237150
Test: m nothing
Change-Id: Iee35abd6d210d9a33dfd8ef2f9c77a53329fda24
In some cases the java_sdk_library needs to compile against hidden
platform APIs, in order to do so it needs to add impl_only_libs
dependency on the framework library, and set the sdk_version property to
the "core_*" one (e.g. core_platform).
However, if this java_sdk_library depends on the Android SDK in it's
stable API surface, then the setup above will break the stubs srcs
generation, as it uses the sdk_version of the java_sdk_library (e.g.
core_platform), which doesn't have symbols from the Android SDK.
This chage solves the problem by propagating the stub_only_libs to the
invocation that generates the stub sources. It allows the
java_sdk_libraries to add a stub_only_libs dependency on the
android_module_lib_stubs_current stubs library to fix their stubs build.
For more context see another change in this topic:
https://android-review.git.corp.google.com/c/platform/packages/modules/Virtualization/+/2310569
Bug: 243512044
Test: builds
Test: m nothing
Change-Id: Id745cfb2789901672561050c1c3f8bb163922379
Previously, a java module with sdk_version: "system_server_current",
would only be able to access the system server or public API of a
java_sdk_library. This change allows it to access the system server,
module lib, system and public APIs in that order.
The apiScope structs define the characteristics of each of the
different API scopes used as required by the java_sdk_library. They are
organized into a hierarchy which is used for two different purposes.
The first purpose is to define an extension hierachy. If scope X
extends Y then X provides a superset of all API elements (classes,
fields, methods, etc) provided by Y. That is reflected in the fact that
the .txt file for X would be a delta on the .txt file for Y. So, system
extends public and so system_current.txt only contains additional API
elements to add to current.txt.
The second purpose is when a java_sdk_library/import is asked to
provide a specific API scope. e.g. a library that has:
sdk_version: "module_current"
will ask each of the SDK libraries it depends upon for a module-lib
API. However, not all of them will provide an API for that scope. In
that case it will find the closest suitable API scope.
Previously, it did that by traversing up the API extension until it
found an API scope that it did provide and return that. As
system_server_current extended the public API that meant that a library
which has:
sdk_version: "system_server_current"
would provide a system server API if available, and if not fall
straight back to public. That meant that the library could not access
system or module-lib APIs even though it is running in the system
server which should be able to access all APIs.
One way to fix this would have been to just have system server API
scope extend module-lib but that would have had a number of nasty
side effects:
* It would have created a significant overhead as every module that
provides a system server API would also have to provide a module-lib
and system API, along with their corresponding .txt files.
* Each existing java_sdk_library that provided a system server API
would need those .txt files created.
* Generating sdk snapshots for older releases would have been more
complicated.
* It would have confused developers.
All of that would be unnecessary because the system server API scope is
intended to be provided by libraries that are used solely by the system
server so there is no point in them providing anything other than a
system server API.
So, instead a separate access hierarchy was added which is the same as
the extension hierarchy for all existing scopes except for the
system server scope, which instead of just being able to access the
public API will be able to access the module-lib scope, which can in
turn access system and it can in turn access public.
That achieves what we want which is a library that is loaded into the
system server to be able to access all API scopes.
Bug: 204176972
Test: m nothing
Change-Id: I854df63fcaeba32afbc1eb0d1a501238022673d0
Previously, only the prefer property was copied from the
java_sdk_library_import module to its child modules which meant that if
the use_source_config_var property was used to control the prefer
property that the child modules would never be used. That can cause
build breakages when building against prebuilts as some parts of the
build will use prebuilt files from java_sdk_library_import and some
will use source files from the corresponding java_sdk_library.
This change copies the use_source_config_var property too.
It also adds tests to verify that dependencies on child modules of a
java_sdk_library use the prebuilt child modules of the corresponding
java_sdk_library_import. That revealed a bug with the handling of stub
sources where the prefer property was set after creating the module
which has also been fixed.
Bug: 249192297
Test: m nothing
# Cherry pick into branch broken by previous behavior and make
# sure that it fixes it.
Change-Id: I5719c257f8457bcb2238bc7965215512a20f1095
The API finalization process for platform releases copies various files
from the apistubs/ dist directory into prebuilts/sdk/<n>/... Having
them use the same name in both places makes that process simpler. For
most modules the name of the file is derived from the name of the
module by appending a suffix but unfortunately, for some modules that
does not work. e.g. the conscrypt.txt file is produced by the
conscrypt.module.public.api module. The dist_stem property was added to
java_sdk_library to allow the stem name of the file to differ from the
module name.
The API finalization process for extension APIs does something similar
as it extracts various files from the snapshots and copies them into
the appropriate extension API specific directory in
prebuilts/sdk/extensions/<n>. Instead of copying files from the
apistubs/ dist directory (which is not built for trains) it copies them
from sdk snapshots that are built as part of the train.
Previously, the sdk snapshot used to derive the name of the files
within the snapshot from the name of the module, it ignored the
dist_stem property. This change causes it to use the dist_stem property
to make it consistent with the apistubs/ dist directory naming.
The file name is created in
sdkLibrarySdkMemberProperties.AddPropertyToSet() which does not have
access to the dist_stem property. So, it has to be supplied in the
sdkLibrarySdkMemberProperties instance in the new Stem property.
Bug: 248258460
Test: m nothing
BUILD_NUMBER=fixed packages/modules/common/build/mainline_modules_sdks.sh --build-release=latest
# Ran the previous command before and after and make sure that the
# conscrypt, art and icu sdk snapshots use the dist_stem value but
# none of the other snapshots are affected.
Change-Id: Ied52003de63dcdb86a252a39bb8781f85d51a6ff
This applies to updatability attributes of shared libraries.
Bug: 235318264
Test: atest UpdatableSharedLibsTest
Change-Id: Id2c2b769a99ca1debb5d8525e46d37698ef2fc6c
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
The Q and R runtimes can handle Q/R flags but not S flags. So, this
change verifies that any library that can run on Q/R
(min_sdk_version <= R) by adding --max-hiddenapi-level=max-target-r
to the "hiddenapi encode" command. That will cause a failure if any
S+ flags are found in the flags to encode.
Bug: 172453495
Test: m droid && launch_cvd
Cherry pick changes in https://r.android.com/q/topic:max-target-s
Add @UnsupportedAppUsage maxTargetSdk=S in classes in framework-permission (for r/q)
and framework-permission-s (nominally for S+). I had to incresed the min_sdk_version
in the latter to 31 (S) as it was still set at 30 (R).
Merged-In: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
Change-Id: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
(cherry picked from commit 09817d66de)
Bug: 230846030
Test: m nothing
# Cherry pick into build with prebuilts enabled to verify.
Merged-In: I5ac9b1cdd2fc61efbc988e84556202ff6cd57146
Change-Id: I5ac9b1cdd2fc61efbc988e84556202ff6cd57146
(cherry picked from commit 1e940d5b44)
