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
This change removes the field and the code that uses it which is
effectively dead code as it only does something when the list is not
empty and a previous change removed the only code that added a Path to
this list.
Bug: 201753898
Test: m nothing
Change-Id: I67c74ad2a3b115fd3b20b3b416f45b92c749749c
Previously, the permitted package check was designed to only be run
when building checkbuild. Although, that appears to now be broken.
This change uses a Validation dependency to ensure that the package
check is performed whenever the output file of a java_library is built
as part of the build. The package check runs in parallel with any other
rules that depend on the file.
Bug: 201753898
Test: - change the permitted_packages property in
frameworks/base/test-mock so that the package check will fail.
m out/soong/.intermediates/frameworks/base/test-mock/android.test.mock/android_common/package-check.stamp
- as expected the package check failed.
m droid
- as expected the package check did not fail.
# Made these changes then:
m droid
- as expected the package check now failed.
Change-Id: Id38fe280c79e5505ee4555b845c6da2ae6747bc4
invalid with a message.
This will allow propagating any error from the deapexer module for
prebuilt APEXes to the location where the dex jars get used. It's only
at those points that we can raise errors about not being able to
extract files from the deapexer modules if they are invalid, and this
way we avoid encoding knowledge there about why they may be invalid.
To keep the refactoring limited it intentionally does not change any of
the existing logic for when dexJarFiles are set or not (non-nil vs nil
prior to this change), although there may be opportunity to use this
for more conditions when dex jars aren't available.
The refactoring is also not extended to
dexpreopt.ClassLoaderContextMap.
Test: m nothing
Bug: 192006406
Change-Id: I68986dccd9a9b3fee4d24caa1947ea17a36caedc
