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)
(cherry picked from commit 77590a8263)
The framework-media java_sdk_library is currently api_only for legacy
reasons. This change allows it to also build the framework-media.impl
library by making the following changes:
* Adds impl_only_static_libs to allow the implementation to statically
include other libraries, something no other java_sdk_library has
needed to do.
* Passes the apex_availability property through to the impl library so
it can be statically included in the updatable-media which is what is
included in the apex, again for legacy reasons.
Bug: 190807367
Bug: 229932396
Test: m com.android.media media-module-sdk
# Compare before and after this change (and corresponding change
# to updatable-media/framework-media.
Merged-In: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
Change-Id: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
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).
Change-Id: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
The framework-media java_sdk_library is currently api_only for legacy
reasons. This change allows it to also build the framework-media.impl
library by making the following changes:
* Adds impl_only_static_libs to allow the implementation to statically
include other libraries, something no other java_sdk_library has
needed to do.
* Passes the apex_availability property through to the impl library so
it can be statically included in the updatable-media which is what is
included in the apex, again for legacy reasons.
Bug: 190807367
Bug: 229932396
Test: m com.android.media media-module-sdk
# Compare before and after this change (and corresponding change
# to updatable-media/framework-media.
Change-Id: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
* changes:
Do not propagate strict updatability linting to libcore/
Create allowlist to skip strict updatability lint check
Propagate strict_updatability_linting to transitive deps of updatable apexes
Export LintDepSetsIntf from java package
Migrate from ints to Strings so we can pass codenames. Otherwise we
can't use these attributes representing a release in progress until that
release is finalized. I.e. if release T is in progress, we don't get the
correct behaviour if we use "T" in those attributes
Bug: 191978330
Test: m nothing
Change-Id: I35389da0a01549ba2f820f5e5b78f6ea88c2aea1
Make this consistent with how code names are used in the rest of Soong.
Bug: 204763318
Test: m nothing
Change-Id: I1f2f40310df9d619db6aaaad3ed7339bb5e79194
This interface will be used in the apex package to propagate
strict_updatability_linting to transitive deps of mainline code
Test: In build/soong, go test ./java
Bug: 182349282
Change-Id: I30151217e843e4e9fe82db572a066918414ed3a0
Marks the `scopeProperties.AnnotationsZip` property as only being
supported on T builds and above.
Bug: 204763318
Test: m nothing
Change-Id: Ie59396287c08da77a6a1f15d4be202429e011e17
Adds support for traversing into a field that is of type:
map[...]*struct{...}
This is needed to allow java_sdk_library to mark scope specific
properties, e.g. public.annotations as being target build release
specific.
It was necessary to change the Scope field from:
Scope map[*apiScope]scopeProperties
to:
Scope map[*apiScope]*scopeProperties
That is because there is no way in go to change the field of a struct
value of a map. i.e. you cannot do the following, not even using
reflection:
Scope[apiScopePublic].AnnotationsZip = nil
Bug: 204763318
Test: m nothing
Change-Id: Id103f70f55d4202971321ef4925cbec4b55f8136
Revert submission 1944928-default-java11
Reason for revert: Post-submit failures
Reverted Changes:
Ia9a0aa2a4:Setting Java 11 as the default version
Ibf5d10521:Setting Java 11 as the default version
Fixes: 215504708
Fixes: 215502091
Fixes: 215502091
Change-Id: I2f9866deff41406aede24758f6eda5e5808c7f29
Soong has enough information to build the license metadata files
without resorting to the fixups required in Make.
Bug: 207445310
Test: m checkbuild
Change-Id: I8e74108376162b8fdb87ba098ebe94350aa1f7c4
Inidividual boot or system server jars may have higher min_sdk_version
than the contianing apex, since the runtime respects the values of
min/max_sdk_version; e.g. runtime would not load a boot jar with
higher min_sdk_version. This allows shipping new boot jars via apexes
that target older platforms.
Bug: 190818041
Test: presubmit
Change-Id: I08ec0b4463a17bc8265b948fe09da55eb4e52ac3
In a follow up, apex would expect that any module that implements
ModuleWithMinSdkVersionCheck to have performed appropate checks on
min_sdk_version, to allow relaxing some of the existing conditions.
This change moves the responsibility of checking min_sdk_version
of java_sdk_library to java_sdk_library itself.
Bug: 205923322
Test: presubmit
Change-Id: I79b5a1fc34098fff60221e416db6e6e69e01f531
Previously it would write min_device_sdk whereas the correct name should
be min-device-sdk. This happened for all shared libs attributes.
Test: m nothing
Test: manually installed an apex with a shared lib and made sure PM used
the attributes as expected
Bug: 191978330
Change-Id: Iecf7edd6bae98c7af908d3f320f10ae4973d0396
Merged-In: Iecf7edd6bae98c7af908d3f320f10ae4973d0396
(cherry picked from commit bde653e5fd)
Perform consistency checks as per http://go/updatable-shared-libraries
These include:
* no attribute can specified can be less than T
* max-device-sdk can't be less than min-device-sdk
* min and max-device-sdk need to be at least the module's
min_sdk_version
* using on-bootclasspath-before implies that the module's
min_sdk_version is at least T or the library has min-device-sdk of at
least T
Test: m nothing
Bug: 191978330
Change-Id: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
Merged-In: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
(cherry picked from commit f9e584dd20)
We are expanding PackageManager's supported attributes and this change
enables the developer to define them in the .bp file.
Test: m nothing
Bug: 191978330
Change-Id: I01d579190fb585662086a7fc456f3b33cb89fb57
Merged-In: I01d579190fb585662086a7fc456f3b33cb89fb57
(cherry picked from commit 826863c8e0)
We're not sure what formatting is applied to this but it sure
isn't markdown.
Fixes: 204572072
Test: Build and compare docs
Change-Id: Ib023f0cb490a7c7c5605d426ce5e70a7130d5162
* changes:
Consolidate the code to resolve a deapexer module dependency.
Propagate the dex jar path as an OptionalPath which is either valid or invalid with a message.
Historically, this file was used by the `--updatable-bcp-packages-file`
flag for dex2oat. The flag is no longer needed and is being deprecated.
Unfortunately, we cannot remove `permitted_packages` and all the code
related to it because we still need it for checking the module
compatibility with Q and R.
Bug: 200241946
Test: m nothing
Change-Id: Ie3be54fd47a847ba0caf627d12da76b415d99466
It will get more logic in upcoming CLs.
Add a property to DeapexerInfo for the APEX name, for use in error
messages.
Test: m nothing
Bug: 192006406
Change-Id: I957f3df8b34543a38cde38768dac93e78132d672
invalid with a message.
This will allow propagating any error from the deapexer module for
prebuilt APEXes to the location where the dex jars get used. It's only
at those points that we can raise errors about not being able to
extract files from the deapexer modules if they are invalid, and this
way we avoid encoding knowledge there about why they may be invalid.
To keep the refactoring limited it intentionally does not change any of
the existing logic for when dexJarFiles are set or not (non-nil vs nil
prior to this change), although there may be opportunity to use this
for more conditions when dex jars aren't available.
The refactoring is also not extended to
dexpreopt.ClassLoaderContextMap.
Test: m nothing
Bug: 192006406
Change-Id: I68986dccd9a9b3fee4d24caa1947ea17a36caedc
The annotations zip file is produced by the "main" sdk build and is
primarily consumed by android studio.
In order to support building the main SDK without requiring the sources
of all modules, we are adding module SDK artifacts that allows
reconstructing these outputs. The annotations zip contains XML files
which should be fairly easy to merge from all the individual parts.
Bug: 187397779
Test: unit tests in this CL
Test: m sdkextensions-sdk and inspect output
Change-Id: I955cae720e6f1382936836ee1d8fb11003f51b7d
This arg provides the ability to pass sources to the metalava
invocations that are part of a java_sdk_library without affecting
the runtime library.
This is useful in various scenarios, e.g.: when javadoc in some source
files affects the metalava behavior. For example, the javadoc-generation
javadoc tags @paramDoc, @returnDoc etc. Passing these as a library does
not work because class files do not contain javadoc.
Bug: 186197911
Test: manually inspect module stub src for doc enhancements
Merged-In: I2ce98f891283514e1896c52d9335550c1f5435fb
Change-Id: I2ce98f891283514e1896c52d9335550c1f5435fb
Similar to the previous CL, but for jars from prebuilts.
Test: manual - 1. Patch aosp/1818020 and aosp/1810840.
2. m SOONG_CONFIG_art_module_source_build=false com.android.art
Bug: 194150908
Change-Id: Idc0c73a78045a602ad3a91cb5071d291bd611015
Replaces the BottomUpMutatorContext parameter with a new
SdkDependencyContext type that extends BottomUpMutatorContext. This is
to allow the sdk to pass additional information to the implementations
of that method to allow the behavior to be more finely tuned.
Bug: 195754365
Test: m nothing
Change-Id: I69c6d2c523934eb67d7a7e6c55c241e9b8a81773
Previously, the java_import and java_sdk_library_import modules did not
make their permitted_packages available to the rule that generates the
updatable-bcp-packages.txt file. This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Change-Id: If0706e4551a331b48d383123088e63924dded48b
Previously, permitted_packages were not copied to the sdk snapshot.
This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Change-Id: I4560987f746f78c0ae706058195b6db4bea438aa
Even though actual installed module path is the same as source module,
it uses impl's one.
Bug: 188179858
Bug: 193082464
Test: compare dexpreopt_config.zip files from
1. TARGET_BUILD_UNBUNDLED_IMAGE=true m dexpreopt_config_zip
2. m dexpreopt_config_zip
(note that m clean should run between steps)
Test: build aosp_cf_x86_64_phone, launch_cvd, and then
adb wait-for-device \
&& adb root \
&& adb logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C 1
and then check if there is no message.
Change-Id: I34ffd9a2d214a6614c2befc35b2beec003cfcd25
Previously, if a bootclasspath_fragment had both a java_sdk_library
module and one of its components in stub_libs properties they would be
treated as separate modules instead of simply different APIs from the
same module. That would result in them both providing stub dex jars to
"hiddenapi list" which would fail because it found duplicate
definitions of the same class.
e.g. Specifying something like this:
api: {
stub_libs: [
"art.module.public.api",
],
},
core_platform_api: {
stub_libs: [
"art.module.public.api.stubs.module_lib",
],
},
would cause "hiddenapi list" to fail because it would have been passed
paths to two dex jars (actually the same dex jar but that does not
matter) each of which defined the same class, e.g. java.lang.Object.
This change treats the "art.module.public.api.stubs.module_lib" and
"art.module.public.api" modules as being the same for the purposes of
hidden API processing.
Bug: 192446466
Test: m nothing
Change-Id: I9de96337f64f26e24cff040d4bbed9eecc67b1ed
Previously, a java_sdk_library with shared_library = true would create
a variation per APEX because it depends on an sdkLibraryXml module
which generates a file containing the APEX name. However, a shared
java_sdk_library_import would create a merged APEX variation. The
inconsistent variations caused failures in sdkDepsReplaceMutator.
This change ensures that both java_sdk_library and
java_sdk_library_import create an APEX specific variation when their
shared_library property is true.
Bug: 190499958
Test: m nothing
- ran the above command after modifying the test to reproduce the
problem and then after fixing to verify that it fixed the problem.
Change-Id: Iee81776a8569db3e871c40cbde14d248dfeb56e4
Previously, an sdk snapshot could contain the following:
* A java_sdk_library_import module, e.g. "foo" which creates component
modules "foo.stubs", etc.
* A corresponding versioned module, e.g. "sdk_foo@current" which
created component modules "sdk_foo@current.stubs", etc.
* An internal (to the sdk snapshot) java_import for one of "foo"'s
components, e.g. "sdk_foo.stubs"
* A corresponding versioned module, e.g. "sdk_foo.stubs@current".
That causes a few problems:
1. The "foo.stubs" is duplicated.
2. The names of the components created by the versioned
java_sdk_library_import are invalid, as they append the component's
suffix to the version and not the name before the version.
The latter causes problems when building against prebuilts and fixing
that causes the generated snapshot to be invalid because it contains
duplicate definitions of the "sdk_foo.stubs@current" module. One
explicitly in the Android.bp file and one created by the
"sdk_foo@current" module.
Removing the duplicates from the snapshot causes errors as the name
generated by the snapshot for the component module, i.e.
"sdk_foo.stubs@current" does not match the name generated by the
"sdk_foo@current", i.e. "sdk_foo@current.stubs".
This change fixes them together.
Bug: 179354495
Test: m nothing
Merged-In: I515f235fe21755b5275af12366e96c24c94c0273
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
(cherry picked from commit a1aa7387f7)
The commonSdkLibraryAndImportModule defines the methods that a module
which embeds the commonToSdkLibraryAndImport struct need to provide.
Bug: 179354495
Test: m nothing
Change-Id: I7a469ae03ea5c19922200284da08a9ae38a46751
Uses the apex relative path to the file as the identifier that is used
to obtain the path to the corresponding file extracted from the apex.
That is instead of a special constructed string id.
Bug: 177892522
Test: m nothing
Change-Id: I5dc77c8fb272bac289b8891d1eac801e541af1f5
Removes the special case in createDeapexerModuleIfNeeded for handling
java libraries and just get the Import and SdkLibraryImport module
types to implement RequiredFilesFromPrebuiltApex instead.
Bug: 177892522
Test: m nothing
Change-Id: I5cc341b5b4168b8eb196f72273a00d498de6856f
The owner property is no longer used, the dist subdirectory is determined
by the dist_group property.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: Id6d997eef05f6511070677974219674f248cb754
Change the default dist_group from "android" to "unknown" to prevent
accidentally including java_sdk_library stubs that do not set
dist_group or owner in the public SDK.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I9aae2a16254ac1a8d444acfa63bc571d1ef4b045
Reusing the owner property is confusing, especially when the property is
required on every java_sdk_library module. Create a new dist_group property
to use instead.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I9e62c703a95d6b63cafa60bffb1b37ba85388593
