Make sure we select the proper API level number for the REL
platform version when generating the classpath protos
Bug: 231272086
Test: build + boot emulator
Change-Id: Ib3b711dc05dd6136a68e6de414d806687a849bc9
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
The kapt rule uses kotlincFlags but was not using kotlincDeps,
causing the rule to get the -Xplugin argument on the compose
compiler plugin jar, but not have a dependency on it.
Bug: 231222079
Test: TestKotlinCompose
Change-Id: I4c2cf30fb7d8cad4eededa29f67f4ffd459caa41
(cherry picked from commit 08b0a1cd79)
Merged-In: I4c2cf30fb7d8cad4eededa29f67f4ffd459caa41
(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
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.
Change-Id: Ic95cf11a05f59b67e623474ed3dd9be6b4442c42
The kapt rule uses kotlincFlags but was not using kotlincDeps,
causing the rule to get the -Xplugin argument on the compose
compiler plugin jar, but not have a dependency on it.
Bug: 231222079
Test: TestKotlinCompose
Change-Id: I4c2cf30fb7d8cad4eededa29f67f4ffd459caa41
- Making newapi disabled by default will ensure that this lint check
does not run on the platform. This prevents noisy lint warnings like b/228956345#1
- This lint check will continue to be enforced on the transitive deps of
apexes, since lint.strict_updatability_linting will be true for those
Soong modules
Test: TH
Test: m
out/soong/.intermediates/frameworks/base/services/core/services.core.unboosted/android_common/lint/lint-report.xml
// file no longer contains "Call requires API level ..." warning
Bug: 228956345
Merged-In: I8ef3137394011fb679a1129f80f6351fb05a4eff
Change-Id: I8ef3137394011fb679a1129f80f6351fb05a4eff
(cherry picked from commit 397e910835)
- 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
Merged-In: Ic408857db7760d912ef4694d2ed72c0b7106eb04
Change-Id: Ic408857db7760d912ef4694d2ed72c0b7106eb04
(cherry picked from commit ba7e532a11)
The Q and R runtimes can handle Q/R flags but not S flags. So, this
change verifies that any library that can run on Q/R
(min_sdk_version <= R) by adding --max-hiddenapi-level=max-target-r
to the "hiddenapi encode" command. That will cause a failure if any
S+ flags are found in the flags to encode.
Bug: 172453495
Test: m droid && launch_cvd
Cherry pick changes in https://r.android.com/q/topic:max-target-s
Add @UnsupportedAppUsage maxTargetSdk=S in classes in framework-permission (for r/q)
and framework-permission-s (nominally for S+). I had to incresed the min_sdk_version
in the latter to 31 (S) as it was still set at 30 (R).
Merged-In: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
Change-Id: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
(cherry picked from commit 09817d66de)
Bug: 230846030
Test: m nothing
# Cherry pick into build with prebuilts enabled to verify.
Merged-In: I5ac9b1cdd2fc61efbc988e84556202ff6cd57146
Change-Id: I5ac9b1cdd2fc61efbc988e84556202ff6cd57146
(cherry picked from commit 1e940d5b44)
This CL also converts `external/rappor` (which already set `java_version` to `1.7`) to be bazelable to testify the changes.
Results from `b build //external/rappor && cat bazel-bin/external/rappor/librappor.jar-0.params`: https://paste.googleplex.com/5518725462622208.
Test: go test ./bp2build/...
Bug: 227618664
Change-Id: I8d370d4639f70fba51e6de6ceb7bcb5ace9ccd91
(cherry picked from commit 77590a8263)
The framework-media java_sdk_library is currently api_only for legacy
reasons. This change allows it to also build the framework-media.impl
library by making the following changes:
* Adds impl_only_static_libs to allow the implementation to statically
include other libraries, something no other java_sdk_library has
needed to do.
* Passes the apex_availability property through to the impl library so
it can be statically included in the updatable-media which is what is
included in the apex, again for legacy reasons.
Bug: 190807367
Bug: 229932396
Test: m com.android.media media-module-sdk
# Compare before and after this change (and corresponding change
# to updatable-media/framework-media.
Merged-In: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
Change-Id: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
The Q and R runtimes can handle Q/R flags but not S flags. So, this
change verifies that any library that can run on Q/R
(min_sdk_version <= R) by adding --max-hiddenapi-level=max-target-r
to the "hiddenapi encode" command. That will cause a failure if any
S+ flags are found in the flags to encode.
Bug: 172453495
Test: m droid && launch_cvd
Cherry pick changes in https://r.android.com/q/topic:max-target-s
Add @UnsupportedAppUsage maxTargetSdk=S in classes in framework-permission (for r/q)
and framework-permission-s (nominally for S+). I had to incresed the min_sdk_version
in the latter to 31 (S) as it was still set at 30 (R).
Change-Id: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
The framework-media java_sdk_library is currently api_only for legacy
reasons. This change allows it to also build the framework-media.impl
library by making the following changes:
* Adds impl_only_static_libs to allow the implementation to statically
include other libraries, something no other java_sdk_library has
needed to do.
* Passes the apex_availability property through to the impl library so
it can be statically included in the updatable-media which is what is
included in the apex, again for legacy reasons.
Bug: 190807367
Bug: 229932396
Test: m com.android.media media-module-sdk
# Compare before and after this change (and corresponding change
# to updatable-media/framework-media.
Change-Id: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
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
