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
This required the following:
- Adding Platform_base_sdk_extension_version to default soong.variables
- Teaching the symlink tree creation code to understand symlinks
- Making finder.go follow symlinks when requested
Adding yet another knob is unfortunate, but I can't allow that
unconditionally because the Android code base contains a number of
symlinks giving rise to infinite directory trees because they point back
to their parent and this seemed preferable to adding complicated logic
like "follow symlink but if only its fully resolved version does not
point under the source tree".
I could be convinced about the latter, though.
Test: Presubmits.
Change-Id: I453f6b7e5334771f5832c700db00f9d24ed1d82f
Revert submission 1931011-max-target-s
Reason for revert: Seems to cause build breakage
Reverted Changes:
I2b513f93a:Add support to max-target-s to generate_hiddenapi_...
Ifdd7b7a71:Add support for max-target-s
I06d05840e:Add support for max-target-s
Change-Id: I67413a3deda42c503b876727377e932f7e4652e9
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