Currently the product variable that is controlled by
APEX_GLOBAL_MIN_SDK_VERSION_OVERRIDE only overrides apexes, but it
doesn't apply to android_apps. This commit allows android_apps which set
updatable: true in their Android.bp to have their min_sdk_version be
overriden by this product variable.
Bug: 295311875
Test: go test
Change-Id: If3cb82a17cae4553b577dd1a4637ee13c3c95302
These options are unnecessary because:
* `--format` and `--api-overloaded-method-order` only affects the
generation of signature files which this does not do.
Also changed the build rule description to differentiate from the
usual metalava command to make it easier to find in the ninja file.
Bug: 296115567
Test: m --build-from-text-stub
Change-Id: I7986cba00c364282ddc436d2e69bfb66eda46436
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
When targetSdk is >= 30, the system verifies that you use a valid
signature V2+ certificate. Uncompressing ndk/dex files or aligning
the zip file will break a signature V2, so these apks should really
just set preprocessed: true.
Fixes: 185811447
Test: Presubmits
Change-Id: Id89c42bcd5b5daa6eda1716bff4023423298036b
This is attempt 4 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 74a5c2ec76.
Reason for revert: Fixed ManagedProvisioningTests
Bug: 215530220
Change-Id: I223228a345fa1a3bad52fb3e91c744107e04fc07
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
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
This is prep work to add additional special handling for genrule
generated headers as there will be similar partitioning for those
headers.
Test: go test soong tests
Change-Id: Ib63e7e4f7554b2b7b7bc78b2825b20c05403216a
Non-priviledged apps can have compressed dex files.
See go/gms-uncompressed-jni-slides
Bug: 185811447
Test: Presubmits
Change-Id: I14f70fb9286bce132e451a0c930333455517cdc3
If a header jar couldn't be built (for example when an API generating
annoation processor is in use) the implementation jar is reused as the
header jar. If the implementation jar contains an annotation processor
listed in META-INF/services/javax.annotation.processing.Processor then
later javac executions with the implementation jar in the classpath
could attempt to run the annotation processors unexpectedly. Remove
the META-INF/services directory when using an implementation jar as
a header jar.
Bug: 290933559
Test: builds
Change-Id: I40d48644bc5a09a9564dc2c4b38f627edd00fcf8
Currently, java_library.stem property is not correctly reflected in the
output jar name in java_library when the module specifies
java_resource_dirs property. This change fixes the unexpected behavior
so that setting the stem property behaves as expected.
Test: go test ./java && m
Bug: 285843207
Change-Id: I0941fcea83c92f4c42ae415aa6ad9125da5cf57b
Instead of rolling assets and manifests up through each static lib,
provide them as a DepSet. This will help with the next patch, which
needs to pass all the transitive manifests and R.txt files together.
This relands Id8b3aa2bed3771e82ab6bde192c9b43baa38b54c with a fix
to include additional manifests from dependencies in the final
manifest merger.
Test: app_test.go
Test: TestManifestMerger
Change-Id: Ied0a6cfee2f18e87188db145b9411d4a903ab6c9
Add a test for the manifest merger command line that would have prevented
b/291252863.
Bug: 291252863
Test: TestManifestMerger
Change-Id: I8c025efe7ccb06ad97b405e2927a4df07f9d3f27
* changes:
Add a Make variable to determine ART boot image jars for testing.
Add a Make variable that overrides configured jar locations.
Refactor dexpreopt for boot jars to make it flexible to config changes.
We had hardcoded logic to override "framework-minus-apex", but we need
to override more jars, so this CL adds a general solution for this.
Bug: 290583827
Test: m nothing
Change-Id: I211ebda7aa2803886ab6e6d081d26327665e49a6
In the past, dexpreopt for boot jars was very inflexible, and it was
incredibly hard to make a change that is as simple as adding a jar to a
boot image. Boot image generation was handled by
"platform_bootclasspath" and "bootclasspath_fragment" separately. This
caused not only code duplication but also the inflexiblity as such a
design did not fit today's use cases, where a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. The design casued a huge
maintenance burden as any change to the boot image cost multi-week
efforts.
In recent years, efforts have been made to improve this a bit by a bit.
This change is another step towards making dexpreopt reasonable.
After this change, all boot images are generated by "dex_bootjars",
which is in build/soong and is therefore available on both the full
source tree and the thin manifest (master-art). The change decouples
profile generation/extraction from boot image generation. Profiles for
mainline modules are still handled by "bootclasspath_fragment"
because they need to be packed into APEXes when building mainline
modules and extracted from APEXes whem building the system image from
prebuilt modules. Boot images are not handled by
"bootclasspath_fragment" anymore.
Bug: 290583827
Test: m (all existing tests are still passing)
Test: Manually checked that the boot images are exactly the same as
before.
Change-Id: Ib5a5f401bee334ffcab5c26618e0c8888b84575a
The Java compiler may generate sources when processing annotations.
These sources are currently not included in the IDE project model, which
results in unresolved symbols when using Hilt and other annotation
processors. These sources are not passed to the Java compiler for
compilation, so they cannot be handled like other Java module sources.
This change archives the generated sources and appends them to the
existing srcjar list in module_bp_java_deps.json.
Test: go test .
Test: Verified that module_bp_java_deps.json contained srcjar entry
Test: with path/to/android_common/javac/anno.srcjar.
Test: Verified that IntelliJ can resolve generated symbols after
Test: invoking aidegen.
Change-Id: I6a3011f9140fd25f785178baee0cd6074ad94600
metalava no longer prints an ASCII banner, and has removed its
--no-banner argument. Update all call sites accordingly.
Test: presubmit
Bug: 286023667
Change-Id: I61cf5f1125dfbd93496e6a59eb1ea62886b32046
* changes:
Change the profile path on host.
Extract duplicate code to common helper functions.
Fix dumpOatRules.
Remove Modules() from BootclasspathFragmentApexContentInfo.
Fix some tests for dexpreopt and remove unnecessary tests.
This is to decouple profile generation from image configs. A boot image
profile is either for a mainline module or for the platform, which is
orthogonal to boot images.
Bug: 290583827
Test: m nothing
Change-Id: I0918f2fa945a2af1839f1a08ecede331c64d0317
Also, fall back to using a default name for the dexpreopt directory if
we are not building for Android.
Bug: 290583827
Test: m nothing
Change-Id: I3fc6ff9142a2dcdf995796f75891b242fe2848d0
Instead of rolling assets and manifests up through each static lib,
provide them as a DepSet. This will help with the next patch, which
needs to pass all the transitive manifests and R.txt files together.
Test: app_test.go
Change-Id: Id8b3aa2bed3771e82ab6bde192c9b43baa38b54c
This method generates a build rule that runs oatdump for debugging
purposes.
- Pass "--runtime-arg -Xgc:CMC" to oatdump if UFFD GC is enabled.
- Build the phony name from the image name to avoid conflicts when using
this method for multiple boot images.
Bug: 290583827
Test: m dump-oat-boot
Change-Id: I7adc97cb85b571486b78f173fb80ff7da2c4bfe4
The Modules() method was for the ART boot image in the ART APEX. It's no
longer needed because we don't install the ART boot image in the ART
APEX anymore.
Bug: 290583827
Test: m nothing
Change-Id: I674a5fa1ed18908413a64129df5947c7d26e638e
This CL is to prepare for the changes in http://r.android.com/2652081.
See the description of that CL for the reasons.
Some tests were set up in a fragile way and were easy to be broken when
the implementation changes. This CL is a pure test change that fixes
them.
This CL also removes TestNoUpdatableJarsInBootImage. That test checks
what should go to the ART boot image and what should go to the
platform one, which does not apply today because boot images are not
associated with mainline modules anymore: a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. In practice, we have ART jars in
the platform boot image, and we are going to add core-icu4j and
consrypt to the ART boot image, which is now for testing only.
Bug: 290583827
Test: m nothing
Change-Id: I22c45cbf6f853b030b68edb51197854e9c53a02e
android_app_import and android_test_import modules with processed: true
and skip_preprocessed_apk_checks are used directly from the source tree.
If the source file name doesn t match the module name and the file is
used as test data it can result in the wrong filename being used. Copy
the source file to an output file with the correct name first.
Bug: 290376750
Test: m CtsAppSecurityHostTestCases
Change-Id: I4a6dd1c5e48db7085ea41035def31f0844948a46
Add a test for the aapt2 resource processing code that will be affected
by the resource processor feature in a subsequent CL.
Test: TestAndroidResourceProcessor
Change-Id: I39712853f7bbfb7963f1b71e234d039d5ccaae53
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
Starting from aosp/2594905, dexpreopt depends on
`$PRODUCT_OUT/product_packages.txt`. When PRODUCT_PACKAGES changes,
dexpreopt has to rerun for all apps. This is not ideal.
After this change, dexpreopt uses a per-app product_packages.txt that is
filtered by the app's dependencies, and it uses `rsync --checksum` to
prevent the file's mtime from being changed if the contents don't change.
This avoids unnecessary dexpreopt reruns.
Bug: 288218403
Test: m
Test: Change PRODUCT_PACKAGES and see no dexpreopt reruns.
Change-Id: I5788a9ee987dfd0abfd7d91cbcef748452290004
This provides significant size savings over the default compatibility
mode, roughly ~20MB in aggregate for a recent Pixel build. Targets can opt out using `proguard_compatibility = true`.
Future work will enable for all targets, not just apps, but this
incremental change yields the most benefit.
Bug: 215530220
Test: m + presubmit
Change-Id: I52a9b27ebe71835849e200e23ae2a250eaf1bbe1
The conversion of FirstUniqueStrings to be implemented on top of the
generic firstUnique accidentally used a different threshold to switch
from the list implementation to the map implementation. Modify the
threshold of firstUnique to match the old value from FirstUniqueStrings
now that it doesn't have the reflection overhead. While we're at it,
also make firstUnique make a copy of the list, and make FirstUniqueStrings
a pure wrapper around firstUnique.
Test: BenchmarkFirstUniqueStrings
Change-Id: Icc2febea663142c508ff2e4be65a8a68121631d5
APKs expect JNI libs in the libs folder to be stored uncompressed, so we
should not compress libs that we extract from the AAR.
Bug: 280339573
Test: m AiWallpapers before this change &&
compare to AiWallpapers with ag/22948656
Change-Id: I63baa3763bc01c74d8df9b0b3e035ea50c31904c
Use Go's generics for DepSets so they don't require a type-specific
wrapper and reflection.
Test: depsets_test.go
Change-Id: I22ba0b7d680d37d2cd05230b0f560d166c4dd20b
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
The resourceshrinker command prints an info log for successful runs,
which we don't really need to surface in build output. Suppress stdout
for such invocations; errors will surface through stderr.
Bug: 202959019
Test: m + compare log output
Change-Id: I08ed465bb7e3a0fa8d5e967d858f6739b5ef7fad
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
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
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
I suspect this was accidentally committed. We shouldn't just printf such
a statement every build analysis.
Test: Presubmits
Change-Id: If5ee66ce1b366f28254cd1bfdcaed9e085a60094
Also applied this feature to kotlinc since it needs both java and kt files.
Test: local test and presubmits
Bug: 287071909
Change-Id: I28c725b03115aef47055448cb75412980015da15
Also add unit tests for the rest of device_config
Bug: 283475679
Test: m nothing (soong unit tests)
Change-Id: Iee18a1f2f2cbb23e8c8d84c54e903b32be29a693
Revert submission 2615972-b-270335653-doclava-search-imports
Reason for revert: DroidMonitor: Potential culprit for Bug 286398320 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted
Reverted changes: /q/submissionid:2615972-b-270335653-doclava-search-imports
Change-Id: Ibc3bdb301110b564e1427432a1b530e07bb840cd
This change adds bp2build converter for platform_compat_config module
type and its corresponding test case.
Bug: 269202028
Test: bp2build unit tests
Change-Id: I17d560c8f0e725efe69e151685d003c3dcb11f2f
To support stem, cc libraries will be generated in
<pacakge_name>/<label.name>. Update RUNPATH of java binaries so that it
can find its jni deps
Test: bp2build
Test: TH
Bug: 240563612
Change-Id: Ia2f70f0424a8526ee35856225c1a8cd1067a8570
This change cleans up references to android.JavaApiLibraryName() so that
rdeps link against "android_*_stubs_current" instead of
"android_*_stubs_current.from-text".
Bug: 284995489
Test: m
Change-Id: Ibdf33b15981317c43e468dbc1657229d54bbd226
