This reverts commit 5d80d895b6.
Reason for revert: The issue that broke the build the first time this was submitted has been fixed in ag/19125702. Also the errorprone build was added to presubmit for changes to these files so we should hopefully catch any other issues at presubmit now: cl/458501206
Change-Id: I80ca08df49c58a1ad70de917822301368d49fc67
Previously, the code would modify the Compile_dex property to set it to
true if the module was part of an APEX as the APEX needs the dex file.
That lost information about whether the Compile_dex property was
specified in the .bp file and also meant that the APEX variant had
different properties to other variants which could result in unexpected
differences in behavior between them.
One of those differences can occur in the sdk snapshot generation code
which uses the Compile_dex property to determined whether to write a
compile_dex property in the generated snapshot. If it uses an APEX
variant then it will always add compile_dex: true but if it used a non
APEX variant then it would depend on the setting of compile_dex in the
source. That leads to the generated snapshot being affected not just
by the set of modules that are included but also how they were
specified.
This change stops modifying the properties and just uses a local
variable to store the updated value. All the other (4) uses of the
Compile_dex property were checked and 1 accesses the property before
it is updated, 2 access the property from a module type (Import) that
does not update the property and the other is in the sdk snapshot
generation code which accesses it after it has been modified but needs
to access the unmodified value.
This is needed for the follow up change that allows an sdk module to
reference an apex to automatically add exportable parts of the apex
contents to the sdk snapshot avoiding duplication which can lead to
errors.
Bug: 232401814
Test: m nothing
Change-Id: Ibc80d93473a266dc9f9900ec1cb175b51460b5e9
Soong made the assumption that any .srcjar was generated source, for
which the lints were not executed. It may not be the case for .srcjar
that are manually created. Run the linter on any .srcjar that has been
provided within the src attribute, but ignore any source generated
.srcjar (such as .proto or .aidl).
Test: m lint-check
Bug: 228774926
Change-Id: If214fb57f54049fce54297ee6bf65d734b3d2e6d
Upgrading dagger uncovers an issue where java-only modules with
kotlin-containing dependencies may see org.jetbrains.annotations.NotNull
annotations. Include the kotlin-annotations in the output jar the
same way kotlin-stdlib is included.
Bug: 227669740
Test: TestKotlin
Change-Id: Ifc33a32b121c1b9a9d1911bdec332264b78b571c
This reverts commit 0b1c70efbc.
The reverted commit was based on the idea that uses-libraries that are
explicitly specified in build files should not be implicitly added to
the manifest, as that would mean that anything added to the build files
will flow to the manifest.
Although this logic is correct, it prevents propagation of
uses-libraries from dependencies, which is wrong: if a library has an
explicit uses-library property in Android.bp, this property is expected
to be propagated to the library's dependencies. Failing to do so would
mean that every user of that library has to add uses-library property to
their build files, which doesn't scale (see b/214255490 for example).
Bug: 214255490
Test: lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd \
&& adb wait-for-device && adb root \
&& adb logcat | grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty output, no errors at boot
Change-Id: I6f420e76a89aa2f37be99f877711736640f2c361
(cherry picked from commit 3953153c9e)
Previously, the .impl library of java_sdk_library modules would end up
with the jacocoagent statically included. That is because their
Instrument flag was set to true when created by their parent. As that
was before the deps were added that meant that they ended up with a
static dependency on jacoagent (at least when UnbundledBuild() was
true).
That was not previously a problem because the .impl files were only
used at build time. However, a recent change to make updatable-media
statically include framework-media.impl (which statically included the
jacocoagent classes) broke the coverage build because the jacocoagent
classes are not in the permitted packages for the updatable-media.
When instrumenting the bootclasspath the jacocoagent library is added
to the art-bootclasspath-fragment.
The jacocoagent should only be statically included in apps, or test
apps. This change adds an extra flag to specify whether the module type
supports statically including the jacocoagent. This is set to true by
apps and test apps but not when the java_sdk_library creates the .impl
java_library preventing it from statically including jacocoagent.
Bug: 230967146
Bug: 229932396
Test: COVERAGE_MODULES=media \
PRODUCT=mainline_modules_x86 \
TARGET_BUILD_APPS=com.google.android.media \
vendor/google/build/build_unbundled_coverage_mainline_module.sh
# Fails without this change, passes with it.
Merged-In: Ic95cf11a05f59b67e623474ed3dd9be6b4442c42
Change-Id: Ic95cf11a05f59b67e623474ed3dd9be6b4442c42
Bug: 215567981
Bug: 204776549
Test: m out/soong/.intermediates/frameworks/base/framework-minus-apex/android_common/lint/lint-report.xml, then check that that file doesn't have any of these warnings
Change-Id: I39aa2228474630c93250bf5833ac6bd9bbadcc7f
This field is provided by the `dexpreopter` struct, which is a part of
`java.Module` and also had an identially named field. This created
confusion when the latter field was not properly copied into the former,
which resulted in not propagating class loader context, e.g. for static
library "androidx.preference_preference". This didn't cause class loader
context mismatch errors at boot previously, because the library didn't
have any uses-library dependencies before a recent prebuilt update.
Bug: 214255490
Test: lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd \
&& adb wait-for-device && adb root \
&& adb logcat | grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty output, no errors at boot
Change-Id: Ib818c5d2934d28817bb7a04b6114ae8b82a5c04d
- NewApi check should be enforced only if min_sdk_version is less than
the compile_sdk_version (the opposite direction should be a different
build-time error)
- Change the datatype of *sdkVersion to android.ApiLevel (from string)
to support version comparisons
Test: go build ./java
Test: no changes in ninja file
Bug: 228956345
Change-Id: Ic408857db7760d912ef4694d2ed72c0b7106eb04
Write `static_libs` and `libs` of Java library and Android app modules to module_bp_java_deps.json. This enables downstream tools to correctly set up the runtime environment. Note that while static libraries don't need to be on the Java classpath these modules could have non-static library dependencies that do need to be present.
Test: m out/soong/module_bp_java_deps.json
Bug: 227538646
Change-Id: I7c4aecb2fb03c890f0d2aaae80e619f6176809ef
This reverts commit c6ef485370.
Reason for revert: Multiple systemui presubmits are broken due to this change
Bug: 228262695
Change-Id: I1efed519c49d8d0583815c7bf2b3801bf0ba12fa
When compling kotlin code with annotation processors we are generating
java stubs for the kotlin sources using kapt, and parsing them in
turbine when running the annotation processors. Passing --output
to turbine will also compile the stubs into a header jar that can
be used as a dependency to javac, allowing the javac and kotlinc
rules to run in parallel. The turbine-apt header jar can't be used
as the header jar for downstream modules as it doesn't contain the
kotlin metadata needed by kotlinc rules, so the kotlinc gen-jvm-abi
plugin output is still used for the module's final header jar.
Test: TestKapt
Bug: 222095735
Change-Id: I82d0900f3dc30f3e3ebd7cab0693dfe741d9b955
Normally turbine is disabled when an api generating annotation processor
is in use because the annotation processors are run in javac, so any
generated api would not be present in the turbine header jar. When
compiling with kotlin and annotation processors, the annotation processors
(including any that generate api) are run in an extra turbine invocation
to generate sources to make the results visible to kotlinc, and so can
also be compiled by the normal turbine invocation. Force turbine enabled
when kotlin sources are present.
Test: m SystemUI
Bug: 222095735
Change-Id: I5fcfe67e46cb4a4e90388f088327488959b6571f
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
r8 gets the static libs in the program jar, it shouldn't also get
them as library jars. Keep a separate classpath for dexing that
includes libs but not static_libs.
Bug: 222468116
Test: m checkbuild
Test: TestD8
Test: TestR8
Change-Id: Icca3393f496cbcadcc633f3b156761e6c145f975
When set to true, this attribute will pass down the
-Wmissing-permission-annotation flag to the aidl compiler. It is
possible to declare a set of exceptions (for a graduable adoption). For
now, only Java is supported.
Test: build having the attribute enabled for frameworks/base
Bug: 220214993
Change-Id: I54350199b4d980aef0050519e3daf1fef616d08c
This commit enables conversions of java_library_static and adds the
static_deps Soong attribute to Bazel deps for all Java libraries.
Currently, Soong handles static dependencies for Java differently, and
Bp2build may need to address that later (see b/217236083).
Bug: 215229742
Test: go test ./bp2build
Change-Id: I4f86780c634dca0a2cfb9294084b14e139cc2375
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
Previously, referencing a prebuilt android_app_import in an
android_test's instrumentation_for property instead of the source
android_app module (e.g. because the prebuilt is preferred) could
result in compilation errors if the android_test sources depended on
classes from the app. That is because while the android_app provides a
classes jar file to be added to the android_test's classpath the
android_app_import does not.
This change reports that situation as an error.
Bug: 207128192
Test: m nothing
Change-Id: I26ea90e7a3f57707fc0c094e0d8b8dc9a9e135ac
override_android_app can set "stem" property to set the APK name.
Bug: 193504286
Test: m (soong test)
Change-Id: I9ad66ea28bd1b030cb2c588d1f070d72e62ab1c7
java_library_host, java_binary_host and cc_library_host_shared so
signapk tool can be built with Bazel.
Test: b build //build/bazel/examples/apex/minimal:build.bazel.examples.apex.minimal
Test: jarsigner -verify -verbose build.bazel.examples.apex.minimal.apex
Bug: 209876137
Bug: 196204358
Bug: 210158864
Bug: 210159074
Bug: 210158872
Change-Id: I855884159d25e69d8f9623792c376da820a1eb4c
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
Artifacts that go into apexes should only be active on certain SDK
versions. There is now a need to upper bound the range to support
expressiong statements like "this jar should only run on platforms
30-31".
Bug: 190818041
Test: presubmit
Change-Id: I6985ebb671841cdd9f0f37f916267ac5ed76e4f4
When compiling without sharding javac will prefer classes built from
source over classes in the classpath. Compiling with sharding puts
the header classes for all the sources onto the classpath, including
the sources that are not part of the current shard. Emulate the
behavior when building without sharding by putting the header jar
first on the classpath so classes are resolved from the rest of
the sources before the real classpath.
Also switch to using the header jar without static libs dependencies
merged in, as those will already be present in the classpath.
Test: m framework-minus-apex
Test: m services.core
Test: TestSharding
Change-Id: Id11b39c15d89ce70da27d746a5c7e6b603c3c0f9
The updated error message is more descriptive about the incompatibility
between platform_apis and sdk_version. Implemented as per the discussion
in b/204447559#17
Test: In build/soong, run go test ./java
Bug: 204447559
Change-Id: I826f0ce47313b337f1754a1b6bc11ce65c837a41
The art tests rely on a dependency existing from
out/host/linux-x86/framework/core-oj-hostdex.jar to
out/host/common/obj/JAVA_LIBRARIES/core-oj-hostdex_intermediates/classes.jar,
override LOCAL_SOONG_INSTALLED_MODULE for the hostdex modules so that
soong_java_prebuilt.mk adds the dependency.
Test: art/tools/buildbot-build.sh --host && art/tools/run-libcore-tests.sh '--mode=host' '--variant=X64' --debug
Change-Id: I9412147fc66d5e5f0dae52d522868a37251f781e
cc/java modules can have .aidl files as srcs. Pass min_sdk_version to
the aidl compiler so that it can check some features against it.
For example, ParcelableHolder AIDL type is available since 31.
Bug: 205338951
Test: soong test && m
Change-Id: I7ecab913e00c9b6a3ce870dacbe9773d2ddb7e93
