When sdk_version is unset, the build with fail with Bazel because
private APIs are do not build with Bazel at this time.
This instead prevents migrating the relevant target to Bazel in bp2build
Test: go tests
Change-Id: I31dabcf143de7933706d1b734ef21467a01b65e9
This change provides support for prebuilt incremental platform API (i.e.
API changes associated with a QPR, as opposed to a major dessert
releas).
This feature is provided via the existing prebuilt_apis module with the
introduction of a new attribute:
allow_incremental_platform_api
While typical platform prebuilt APIs are presumed to be under a
directory structure that follows the pattern:
<version>/<scope>/<module>.jar
<version>/<scope>/api/<module>.txt
Where <version> is limited to a single integer signifying the API level.
For modules where allow_incremental_platform_api is set to 'true' (false
by default) the pattern is the same, however <version> is presumed to be
of the form MM.m, where MM aligns with the existing API level and m
signifies the incremental release (e.g. QPR).
Bug: b/280790094
Test: platform build check with both incremental & non-incremental API
cd build/soong && go test ./java
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:eee6995093485497bc29cdce01c2a86765ffb4eb)
Change-Id: I67e293006ccfa210d0dcc0a294db894632f1b6cb
Targets with the special level 10000 are compiled using the current
platform SDK level. They are also compiled as a "platform build" which
will disable features such as API modeling and method backports.
Bug: 295591477
Test: manual inspection of the updated build commands
Change-Id: Ifda8859396b33dde4c46a9b212ddb855b012bf07
The proto_library(s) created for include_dirs will be added to
transitive_deps
This also fixes an existing bug for java_library containing .protos in
srcs via filegroups.
```
java_library {
name: "foo",
srcs: ["foo.proto", "foo_filegroup"],
}
```
At ToT, foo_filegroup was missing from the equivalent proto_library in
bp2build workspace.
Bug: 285140726
Test: allowlisted pandora-proto-java and built that
Change-Id: I2657d8cdef2e47434bc3e0d09a074c8e27299afc
Flag for java_library modules to build just the Turbine headers and
skip building an impl jar.
Test: go test java
Bug: 289776578
Change-Id: Iad0babf951710476bc32df93c25d17065a14ab84
Not having them before was just being conservative, and now libs at
least is needed.
Bug: 293195086
Test: m
Change-Id: Ieaa66d11fc983751fd302a21e17802748a535fa7
Add a property to export proguard flags files for libs dependencies.
Currently only proguard flags files from static deps are propagated up
to reverse dependencies, but it is necessary sometimes to have flags
from libs dependencies also be propagated.
Bug: 289087274
Test: go test ./java
Change-Id: Ic0aa22b086792bf322041aa5780db6c4f4eb2770
Revert submission 2713677-revert-2655262-move_java_api_libraries-JTESUMBERD
Reason for revert: Initial revert was created to resolve build breakage, but the breakage was caused because not all CLs included in the topic were being included in the build, and was not a problem of the CLs itself.
Reverted changes: /q/submissionid:2713677-revert-2655262-move_java_api_libraries-JTESUMBERD
Merged-In: If66b5bba719bb389a69f2353d2218a89b2b96b90
Change-Id: I879c9d3fb7427cfeff45fff423d4d536548e766f
This change moves java_api_library modules that were previously defined
in build/orchestrator closer to where their from-source equivalents are
defined.
Test: m (default to from-text stub build)
Bug: 274805756
Merged-In: If66b5bba719bb389a69f2353d2218a89b2b96b90
Change-Id: If66b5bba719bb389a69f2353d2218a89b2b96b90
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
`Previous_api` is used to migrate nullness information in metalava (i.e.
convert @Nullable and @NonNull to @RecentlyNullable and @RecentlyNonNull
for some methods). The input is required to generate loosely equivalent
from-text stubs.
Test: m && compare nullness annotations between from-source stubs and from-text stubs
Bug: 293962901
Change-Id: Ic7a0868415fdb2c65d0d472e527fe73280b7651d
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
This change enables scopeOrderedSourceFileNames to be not computed
everytime when the function is called, but instead is computed once.
Test: m
Bug: 295429988
Change-Id: I33846cdb7a750e44e45049dbd342aa6ab8b70c4c
That will allow the format of a file to be changed by simply modifying
the signature format in the current API file (e.g. from `2.0` to `3.0`)
and then running `m update-api` and it will just update the current API
file (and the corresponding removed API file).
Bug: 295577788
Test: m checkapi && m update-api
# Also did as described above and modified the
# `libcore/api/current.txt` file from `2.0` to `3.0` and ran
# `m update-api` and checked that only that file and the
# corresponding `removed.text` file was changed.
Change-Id: I20c9bc151677502cf09b0c06fb442fd385caccdd
Recent changes in metalava (aosp/2704325) enforces api files passed as
inputs to generate stubs from txt to be sorted in the order from the
narrower api scope to the wider api scope. In order to comply with this
change, all api files passed as inputs to metalava invocations need to
be sorted in the respective order.
Test: m out/soong/.intermediates/packages/modules/IPsec/tests/cts/CtsIkeTestCases/android_common/e10894d3da5db41239526c9048962355/javac/CtsIkeTestCases.jar --build-from-text-stub --skip-soong-tests (Failing module from incorrect class hierarchy when building from text stub)
Bug: 295429988
Change-Id: I1eb1f4bf8fa34fd7dc8a0e4c04aa056258a975c5
Metalava has not differentiated between bootclasspath and classpath for
years so this change replaces the use of the two deprecated single
hyphen options with `--classpath`.
Bug: 295136054
Test: m checkapi
Change-Id: I3ab20b76a60cab66a27784b7d87a069813d19835
`-encoding` and `-source` have been deprecated in metalava.
`-encoding` actually does nothing apart from check to make sure that
the value is `utf-8` (in some case). Metalava always uses `utf-8`.
`-source` has been deprecated in favor of `--java-source` as metalava
also can consume kotlin and it has its own `--kotlin-source` option.
Bug: 295136054
Test: ./gradlew
Change-Id: I08e6931958f40022d65d417360e32b72a1d70444
When using resource processor the R.class files are generated
directly, and the R.java files generated by aapt2 are unused. These
files can huge, reaching 500 MB for some modules and 76 GB across
all modules for a checkbuild on internal main. They will be deleted
after zipping into srcjars after Ie5143e1e4b36ca1f4e45b001d79aca5379063517,
but we can skip generating them completely for modules where resource
processor is used.
Bug: 284023594
Bug: 294285775
Test: m checkbuild
Change-Id: If5e3fd1d25c6c7860898776ecdd392be8850c17c
The R.java files generated by aapt2 are unused after they are zipped
into srcjars. These files can huge, reaching 500 MB for some modules
and 76 GB across all modules for a checkbuild on internal main.
Delete the R.java files after after zipping them into srcjars.
Bug: 294285775
Test: m checkbuild
Change-Id: Ie5143e1e4b36ca1f4e45b001d79aca5379063517
This is attempt 3 at landing this change. Prior attempts were
reverted due to downstream test breakages not in presubmit.
Those issues have been resolved, and additional manual heavy
presubmit tests were run to ensure stability.
Observed APK savings: ~24MB
This reverts commit a2ab93666d.
Reason for revert: Fixed SdkSandboxManagerTest by preserving
existing R8 compat mode for the aosp variant of SdkSandbox target.
Bug: 215530220
Bug: 293177283
Test: atest SdkSandboxManagerTests && \
atest SdkSandboxStorageHostTest && \
atest SdkSandboxLifecycleHostTest
Change-Id: If5636638875b6f67e0cc0ba4fd253a8d99d8db1d
If the android_app has the use_embedded_native_libs flag
all its JNIs must be stored with the store compression method.
The logic to add JNIs from ARR is as follows:
1) Extract JNI libs from AAR
2) Store JNI libs with deflate
3) Merge deflated JNI libs with APK
This process produces a bogus APK that won't be loaded by the
framework if the use_embedded_native_libs is set as the resulting
APK will have all its merged entries stored as deflate.
To solve the problem in case we merge JNIs with an app requiring
uncompressed JNI we add an extra step to ensure they're compressed
using the store method.
Test: m, verify apk using jni_extract has stored libs
Change-Id: Ic31d47f15412171b5898dd0e2a554cb6bf93293b
