With the recent build changes to support generating mainlin module sdk
with flagged apis, the build no longer depends on the values of these
product variables in exposing the flagged apis, but these are determined
by the aconfig flags. Given that these variables are no longer used,
this change removes these variables and the variables dependent code.
Test: m nothing --no-skip-soong-tests
Bug: 320515715
Change-Id: I6af94da73cc7fc7ffce670928aad81cec5d383b4
System property was removed in
https://r8-review.git.corp.google.com/c/r8/+/82140, as the
system property com.android.tools.r8.emitRecordAnnotationsInDex
is the only system property for not desugaring records.
Test: Existing
Fixes: b/316501817
Change-Id: I057a18c9e02a99365e910d3128890fd481e93541
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Use --revert-annotation instead of --hide-annotation
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Use --revert-annotation instead of --hide-annotation
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Bug: 314196587
Test: ./gradlew
Change-Id: Ic97f29dd2b9f598ba0851f5f622c2a2724f18037
Remove the ConvertWithBp2build implementations from all the module
types, along with the related code.
Bug: 315353489
Test: m blueprint_tests
Change-Id: I212672286686a318893bc7348ddd5a5ec51e77a7
Use EXPERIMENTAL_USE_OPENJDK21_TOOLCHAIN=true to build with OpenJDK 21
while still targeting java language version 17.
Bug: 313924276
Test: m EXPERIMENTAL_USE_OPENJDK21_TOOLCHAIN=true
Change-Id: Idc892bb7519e597f1e280ca0765c1a281bb29955
This will prevent future breakages of this kind, so reenable the check.
Bug: 223382732
Test: m checkapi
Change-Id: I5e67ed45e3a78b90de6884a0d7b0b1c91d58b6f5
jdk9 and jdk11 are no longer used, remove ANDROID_JAVA9_HOME and
ANDROID_JAVA11_HOME.
Bug: 221270882
Test: treehugger
Change-Id: Iad566bff21055c5e2acd62642ccd579507e21fef
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
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
The size was increased for D8 in an earlier change, but is more
critical for R8. Match the D8 configuration.
Bug: 241220562,283888124
Test: m
Change-Id: I3b98bf6098f2196c87a97f6c8f7308d9299170d8
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
Instead, move them to R8Wrapper. Having all of these R8-specific flags
in a single location, bundled within the R8 repo, is easier to maintain.
This should be a no-op for generated code.
Test: m + validate identical dex output
Change-Id: Ibdeecef8ca5d311d353dd623c73fab608ccd2681
While this does increase dex size for optimized targets by limiting the
scope of class merging, it also
1) improves actionability of unretraced stack frames
2) improves accountability for size increases
3) tends to decrease compiled code sizes for impacted targets
4) marginally (~1%) decreases RSS
Improvements in tooling should mitigate (1) and (2), and more targeted
use of @NeverInline can mitigate (3). Until such time, the pros seem to
outweigh the cons, so we enable the policy as a temporary measure.
Bug: 264916934
Test: m
Change-Id: Id63a17955692b75b16c42d9c85b55bae409c0da4
ag/19500070 causes errorprone to fail with out of memory errors.
Also in aosp/2215048 the regular javac heap sized was increased
to 4096MB, so the errorprone heap size wasn't any larger anymore.
Bug: 240473481
Test: m RUN_ERROR_PRONE=true SystemUIGoogleScreenshotTestsLib on internal master
Change-Id: Ie6bdce9f2e7620c076213f4c3313960fd537967b
Revert submission 2164342-use-jdk17
Reason for revert: DroidMonitor-triggered revert due to breakage b/250426490
Reverted Changes:
Ib1a24e7ea:Update path for libjli.so
I3375bd4e4:Use the toolchain from JDK 17
I9183e5511:Use the toolchain from JDK 17
Change-Id: I28fc32290dd337b7d44bb98bc52956ee84f01aaa
This adds a new flag to the optimize section to allow invoking the resource shrinker
Bug: 246217952
Test: m
Change-Id: I2e7851af1189db2a6adf6f9f9f444a1d7f3a8d60
Standalone D8 invocations tend to be shorter-lived than R8 invocations
that involve deeper layers of bytecode optimization. Introduce a
separate set of JVM flags to pass to D8 invocations which limit the
runtime JIT tiering, reducing overall compile times and significantly
reducing total CPU consumption for D8 build workloads.
Representative incremental build times with this change:
* real 6m1.388s
* user 63m32.412s
and without:
* real 6m30.624s
* user 79m12.626s
Bug: 205303544
Test: time m
Change-Id: Ic568a4316325c6a4e0da41ffebbb07f0c5f7e8e3
Kotlin's jvm-abi-gen plugin can generate header jars similar to the
turbine output for java sources, which can be used to avoid recompiling
downstream modules when the ABI hasn't changed. Unlike turbine, the
plugin runs as part of the main kotlinc invocation, so it doesn't allow
the downstream modules to start compiling any sooner.
A future possible optimization is to use turbine to compile the kapt
stubs, at least for the kotlin+annotation processor modules that already
generate them, which would allow compiling downstream modules before
invoking kotlinc or javac, as well as invoking kotlinc and javac in
parallel with each other.
Bug: 222095735
Test: TestKotlin
Test: m SystemUI
Change-Id: Ib1bb2ecea47c851a108a26f9ed4f827f289d1321
Pass -Didea.plugins.compatible.build=999.SNAPSHOT to kotlinc and kapt
to prevent it from reading /tmp/build.txt and failing with an obscure
exception:
exception: java.lang.ExceptionInInitializerError
at com.intellij.openapi.util.BuildNumber.currentVersion(BuildNumber.java:297)
...
Bug: 222162908
Test: m metalava with /tmp/build.txt present
Change-Id: I5faced4a2e94561ce3aa37bfaacf5bd7d988a4f0
Use EXPERIMENTAL_USE_OPENJDK17_TOOLCHAIN=true to build with OpenJDK 17
while still targeting java language version 11.
Bug: 219098645
Test: m EXPERIMENTAL_USE_OPENJDK17_TOOLCHAIN=true
Change-Id: I89fb04ecde4dbd1e102098f316692624dd67f8a2
javac is generally a short-lived JVM invocation that doesn't greatly
benefit from deep JIT tiering. As such, favor faster startup time
by limiting to tier 1 JIT for javac execution. This should greatly
reduce overall CPU usage from Java compilation for an arbitrary
Android build (~20%), and deliver a small but modest improvement in
overall Java build times (~5%).
Representative incremental build times with this change:
* real 18m3.507s
* user 563m4.838s
and without:
* real 19m11.909s
* user 751m27.790s
Follow-up changes will apply similar flags for other short-lived JVM
build commands.
Bug: 205303544
Test: m
Change-Id: Ic6315b976063f4330902930a6cf5e5cb394c554c
Java binaries and cc binaries are in the same directory again, the
separate method can be removed.
Bug: 204136549
Test: m checkbuild
Change-Id: I2e7ca82448aba5c7e54d3c3c376fe14a953ef4af
cc binaries are moving from out/soong/host/linux-x86/bin to
out/host/linux-86/bin first, to be followed by java binaries.
Temporarily add a method that gets the java binary path while
it is different from the cc binary path.
Bug: 204136549
Test: m checkbuild
Change-Id: I04a7e741436da6be68078f23d074870413a5bb5e
This reverts commit 29c294b2cf.
The deadlock in R8 was fixed, and the timeout causes problems when
RBE is enabled and the R8 action gets stuck in a queue for 30
minutes.
Test: checkbuild
Change-Id: Ia0c3826aea3288e9db3bdbd4955e1e16c0a38fe3
R8 processes are sometimes hanging on the build servers. Wrap R8 with
run_with_timeout to dump the stacks with jstack and kill the process
after 30 minutes. Switch from running with the r8-compat-proguard
shell script to running the jar directly so that jstack gets the pid
of the java process.
Bug: 181095653
Test: m checkbuild
Test: m NetworkStackNextIntegrationTests
Test: m USE_RBE=true RBE_R8=true RBE_R8_EXEC_STRATEGY=remote NetworkStackNextIntegrationTests
Change-Id: If6996bd8eb39c7a8453d79e825004339c009ade2
