android_test defaults to using R8, but with shrinking, optimization and
obfuscation disabled, eliminating most of the benefits of R8. Instead,
use D8 by default, improving build performance and avoiding any other
issues that may arise in test-specific code related to whole-program R8
execution. An initial audit shows that android_test targets that *do*
enable shrinking or optimization also explicitly opt in to R8.
A follow-up CL will do the same for android_test_helper_app, but that
requires some additional auditing of downstream targets.
Bug: 192032291
Test: m + presubmit
Change-Id: I5b14a0986dde210f241a77c3a93daacf9e53d667
Refactor notices to support notices for multiple modules.
Enforce visibility and handle missing dependencies.
Bug: 213388645
Change-Id: Id6a81987f087419ad37d0cce57a71e8a7c4cd6e0
AndroidApp had its own HideFromMake method and flag that shadowed
the one in ModuleBase. This caused performOverrideMutator to set the
AndroidApp flag, but ModuleBase.skipInstall to read the ModuleBase
flag, resulting in a conflicting install rule being created. Remove
AndroidApp's HideFromMake in favor of the ModuleBase one.
Bug: 232788722
Test: TestOverrideAndroidAppWithPrebuilt
Change-Id: I8c0dfcb50ff4dc1e4d0574f150b10d79908f46aa
Move overrides attribute from appProperties to overridableAppProperties
Bug: 220029162
Test: m
Change-Id: I6f527df3173f142311734333ad37018c83d5e279
Merged-In: I6f527df3173f142311734333ad37018c83d5e279
(cherry picked from commit a2ce78f80d)
- Update apex_info (a topdown mutator) so that it sets updatable=true on
apps of updatable apexes
- Write a unit test that tests different combinations of
updatable/non-updatable apks-in-apexes
- Update an existing unit test that asserts a different error
Test: go test ./java
Test: m nothing (in internal)
Bug: 209409604
Change-Id: Ie8881b857afcec44addf27fc360c5b8abf726bd2
With aosp/1640364, all variants of a cc_* module use min_sdk_version as
the version part of the clang triple. Therefore, checking
min_sdk_version of jni_libs should be sufficient to ensure that there is
no unintended access to symbols in newer Android versions
Test: go test ./java
Test: TH
Bug: 155209650
Bug: 209409604
Change-Id: I6c064f8a6ea12c8aa40165a9063380306a180c9b
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
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
Getting the first certificate will panic if there are no certificates,
which can happen when AllowMissingDependencies is set and the
certificate property is a module reference to a missing module.
Only get the first certificate if the list is not nil.
Bug: 228379411
Test: TestAppMissingCertificateAllowMissingDependencies
Change-Id: I046d75dbbd4f21f4a2b6851f558e430e9879fcff
Previously we were only generating used-by API-coverage for APEX modules.
This change adds support for APK-only modules such as NetworkStack and DocumentsUI.
Bug: b/216313756
Forrest Run: https://android-build.googleplex.com/builds/abtd/run/L10800000953846781
Test: TARGET_BUILD_VARIANT=userdebug PRODUCT=mainline_modules_x86 ./vendor/google/build/build_unbundled_coverage_mainline_module.sh -j16
Change-Id: Id17e4a55c2a52e9903632a654e778f8d54982dfc
Merged-In: Id17e4a55c2a52e9903632a654e778f8d54982dfc
(cherry picked from commit 56d75785bd)
Switch from generate-notice-files.py and mergenotice.py to htmlnotice.
Bug: 151177513
Bug: 213388645
Bug: 210912771
Test: m droid dist reportmissinglicenses
Change-Id: I6cac049d24f35ec358c6f341a04f4ba6161703bf
In Soong, java_library can specify static_deps which are dependencies
that get aggregated into the final jar (akin to static linking). This is
useful because it allows dependencies higher up in the chain to compile
against the APIs exported by transitive dependencies. Bazel does not
support this functionality directly, but it can be emulated via the
exports attribute which makes any targets listed in the attribute public
to targets further up the chain.
Bug: 217236083
Bug: 219908977
Test: b build //external/error_prone:error_prone_core
Test: b build //external/bouncycastle:bouncycastle-host
Test: b build --platforms=//build/bazel/platforms:linux_x86
//prebuilts/sdk/tools/jetifier/jetifier-standalone:jetifier
Change-Id: I2867e3f816de720a6f4bd9ff7a847d1b0c2da2d6
The android_app certificate property can be converted to the
@android_rules debug_signing_keys attribute in Bazel after converting
the .pk8/.pem key pairs to a JKS keystore in Starlark.
Test: b build -s //frameworks/base/tests/appwidgets/AppWidgetHostTest
and verify includes SignApk action with generated keystore
Bug: 194133023
Change-Id: I2c4276f94a7856fc68a7674e89742f887dca31b4
A number of tests in the cts/tests/signature/api-check check for the
accessibility of classes from the android.test.base,
android.test.runner and android.test.mock libraries. Some tests expect
to find the classes other do not. Unfortunately, the tests use
libraries, specifically compatibility-device-util-axt, that depend on
the android.test... libraries which causes Soong to implicitly add
<uses-library> entries to the manifest so that they will be accessible
at runtime. That causes the tests that do not expect to find the
classes to fail.
Bug: 209607558
Test: m nothing
Change-Id: I54c194ab23d5a70df790ece3fe98f2b3d6a1c1f6
