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
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
This change sets everything up to do this, but does not actually
enable it. jdesprez will follow up by making a one line change
that actually turns the default to true when he does test
debugging/verification.
Bug: 178498003
Test: build. Relying on @jdesprez for the rest of the verification
Change-Id: I3b1b6b57279dd4f9f7fc559e2d3ad76911b045e8
(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
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
Looks like new versions of the toolchain have an error about mismatching
the definitions used in the stubs with the builtin definitions. Since we
don't care about this when building stubs, ignore it by disabling the
builtin definitions.
Bug: N/A
Test: Build platform with ToT LLVM compiler.
Change-Id: I4e449c5fb96d0d5442fd57a7fea02ba69463324b
By default, rustc will disable color output when it detects that its
stdin isn’t connected to a terminal. However, since we will print the
output to the user’s terminal, it makes sense to override this.
Test: Manually by triggering a compilation error. I ran
* m pdl
* atest --host --no-bazel-mode pdl_inline_tests
* atest pdl_inline_tests
and got useful color output in my terminal in each case.
Change-Id: I8b593d2eb59d13db17a3456e3fb053556fc16f07
Rust test binary depending on native libraries would require them under
lib[64] directory so that the test binary can open them with default
rpath values.
Bug: 204562227
Test: presubmit
Change-Id: I029bb32c4c98fba21bd28e579a9df9f184a7f045
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
