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
Change-Id: Iba3213e8c34ea75ac9dd8532a95ef62fb5455e6c
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
Re-enable ForegroundServiceType and MutableImplicitPendingIntent,
which have been fixed in udc-dev-plus-aosp and downstream.
Bug: 294098365
Test: treehugger
Ignore-AOSP-First: re-enabling checks that fail in AOSP
Change-Id: Ifa581e8d346cf7e70387d6aa3135203d6a7d621b
`-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
For SystemUIGoogle this is a 2.3 MB reduction (17* of resources arsc) and for Traceur it is a 500k reduction (22% of resources.arsc)
Bug: 294016857
Test: Existing
Ignore-AOSP-First: The resource system support for this is not in AOSP yet
Change-Id: I513078406494ad354c255afa0e829cbe10a9b07a
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
javac produces a directory containing class files, which is then zipped
with soong_zip into a jar file. The class files are never used outside
of the rule, so delete them after zipping them. This should save 19 GB
of disk space in checkbuilds.
Do the same for kotlinc/classes directories for consistency.
Bug: 293352015
Test: treehugger
Change-Id: Id1e889cfbee47eab552a5bb27134fa4b3b4c4d14
The R.Java files generated by aapt2 link --no-static-lib-packages
cause scaling problems by combining all resources into every package
listed in a dependencies' AndroidManifest.xml file. For SystemUI-core
this results in 74 R.java files, each with 76k lines, and takes 20
seconds to compile in javac.
Both AGP and Bazel have workarounds for this that avoid using the
R.java files generated by aapt2, instead generating more efficient
R.class files directly based on the R.txt file.
Bazel uses the ResourceProcessorBusyBox tool that is already present
in our tree to process the resources. Reuse the same tool in Soong
to create the R.jar.
The more efficient R.class files require modifiying source files
that use incorrect packages to refer to resources.
Bug: 284023594
Test: TestAndroidResourceProcessor
Change-Id: I026073b40dabcfdb10e5d7a52e9348205b0e9a66
Merged-In: I026073b40dabcfdb10e5d7a52e9348205b0e9a66
