Skip to content

Conversation

@keith
Copy link
Member

@keith keith commented Oct 17, 2024

This has been removed from bazel 8.x, and is included in rules_android
now

This has been removed from bazel 8.x, and is included in rules_android
now
@keith keith requested review from cheister, jin and shs96c as code owners October 17, 2024 18:16

# Remove this once rules_android has rolled out official Bzlmod support
remote_android_extensions = use_extension("@bazel_tools//tools/android:android_extensions.bzl", "remote_android_tools_extensions")
use_repo(remote_android_extensions, "android_gmaven_r8", "android_tools")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure yet if we need to use_repo these still

@shs96c
Copy link
Collaborator

shs96c commented Oct 23, 2024

Those failures look legitimate.

We support "N-2" bazel LTS releases, which once Bazel 8 ships will mean that we want to continue supporting Bazel 6 workspace-based builds. I'm assuming that this change will continue to work with Bazel 6 once we land this?

@ahumesky
Copy link
Contributor

ahumesky commented Oct 25, 2024

The failures in CI are because the Starlark rules in rules_android 0.5.1 rely on the natively-defined Android providers, which are available only with --experimental_google_legacy_api. The upcoming version 0.6.0 of rules_android uses Starlark-defined providers, except for ProguardSpecInfo (because it's in the java rules) which is unguarded from --experimental_google_legacy_api in Bazel 7.4.0 and Bazel 8

I suggest trying this PR with rules_android 0.6.0 when it becomes available.

There's some related discussion around compatibility in
#1270 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants