Add cross-platform NDK repository support by UebelAndre · Pull Request #122 · bazelbuild/rules_android_ndk

UebelAndre · 2026-02-28T02:05:50Z

This change enables workflows where the host Bazel platform differs from the exec platforms via remote execution. When creating a local_repository to an NDK for another platform, the repository rules are now flexible and platform-agnostic enough to support correctly matching foreign exec platforms if explicitly specified.

remote_android_ndk_repository(
    name = "android_ndk_linux",
    anchor = "@local_android_ndk_linux//:BUILD.bazel",
    api_level = 21,
    platform = "linux-x86_64",
    clang_resource_dir = "linux/specific/dir",
)

UebelAndre · 2026-03-19T21:55:53Z

@ted-xie ping here. Some form of this would be helpful and am happy to adjust the design!

ted-xie · 2026-04-07T15:02:20Z

Sorry, I didn't see this until you closed the PR. I had some comments.

ted-xie · 2026-04-07T15:00:27Z

rules.bzl

+    doc = "A repository rule that integrates the Android NDK from a workspace. Uses an anchor label to locate the NDK and requires the host platform and Clang resource directory to be specified. For local NDK installations, use local_android_ndk_repository instead.",
+    implementation = _android_ndk_repository_impl,
+    attrs = _COMMON_ATTR | {
+        "anchor": attr.string(


I'm confused how this is supposed to work. The NDK distributables are separated by platform: https://developer.android.com/ndk/downloads

So how would you be able to have multiple platforms' NDKs installed in the same directory tree?

I'm not sure what you mean. This is a stand-in for the value of ANDROID_NDK_HOME. Could you describe the dependency tree you're referring to?

Let's say you're on a Mac host building for Linux RBE. On your Mac, you'd have a Mac NDK installed. Where would the files for the Linux NDK come from? You'd need to tell the Linux RBE where those are, somehow.

I have installed the Linux NDK to another directory on the Mac to support this

Okay. This would be an important detail to leave in a comment or doc somewhere, since it's not obvious.

On this topic: Can you think of a better way to have an end-to-end test for this feature? Maybe use rules_bazel_integration_test?

Sorry, I didn't have time to address this before you merged (thank you by the way). I've created #128

rules.bzl

ted-xie

I'm kind of wondering if this PR is needed at all. Is it possible to register multiple NDKs in a single main workspace and have Bazel automatically pick the correct NDK based on execution platform?

ted-xie · 2026-04-07T18:01:40Z

rules.bzl

+
+    return _android_ndk_repository_impl(ctx, ndk_path)
+
+local_android_ndk_repository = repository_rule(


Let's just keep this rule name as android_ndk_repository. Same with its impl function at L208.

ted-xie · 2026-04-07T18:03:38Z

rules.bzl

+
+    return _android_ndk_repository_impl(ctx, ndk_path)
+
+remote_android_ndk_repository = repository_rule(


The "remote" part of this rule is kind of inaccurate, since you still have to store the exec configuration's NDK locally. Maybe rename this to "exec_configuration_android_ndk_repository", or something more concise.

Done

I disagree but ultimately do not care. local to me mapped to the fact that the repository rule looked for a path directly on the host where remote referred to another repository. Though as you see they ultimately do the same thing after locating the desired ndk root.

When we say "remote execution", that means a machine that is not the one that launched Bazel.

The "remote" repository as you had originally named it was not remote at all. It would have been confusing terminology for future users of this feature.

ted-xie · 2026-04-07T18:04:26Z

examples/basic/WORKSPACE


 # --SNIP--: Everything below this lines goes into the example WORKSPACE snippet in the release notes.
-load("@rules_android_ndk//:rules.bzl", "android_ndk_repository")
+load("@rules_android_ndk//:rules.bzl", "local_android_ndk_repository")


Please change the loads for local_android_ndk_repository back to android_ndk_repository.

UebelAndre · 2026-04-07T18:17:16Z

I'm kind of wondering if this PR is needed at all. Is it possible to register multiple NDKs in a single main workspace and have Bazel automatically pick the correct NDK based on execution platform?

I would rather the decision be based on the Bazel configuration than some explicit command line flag. I know of no other way to accomplish what you're suggesting what you're suggesting. It's otherwise an easy way for users to run the wrong invocation and run into confusion or for there to be additional infrastructure added to consuming repositories.

ted-xie · 2026-04-08T18:22:35Z

Code looks good. I would have also liked some documentation for this new rule you've introduced, and a real integration test. Please consider those as future work to polish off this feature.

UebelAndre force-pushed the toolchain branch 5 times, most recently from eaafff8 to 4ab8198 Compare February 28, 2026 05:36

Add cross-platform NDK repository support

151b919

UebelAndre force-pushed the toolchain branch from 4ab8198 to 151b919 Compare February 28, 2026 20:27

UebelAndre closed this Apr 6, 2026

ted-xie reopened this Apr 7, 2026

ted-xie reviewed Apr 7, 2026

View reviewed changes

Restored compatibility

57c6f67

UebelAndre requested a review from ted-xie April 7, 2026 15:16

Minor cleanup

4e14f58

ted-xie reviewed Apr 7, 2026

View reviewed changes

UebelAndre added 2 commits April 7, 2026 11:18

PR feedback

8d5e43f

Additional rename

e3a0820

UebelAndre requested a review from ted-xie April 7, 2026 18:21

Deconflict function name

aa46428

ted-xie approved these changes Apr 8, 2026

View reviewed changes

ted-xie merged commit 18ad65e into bazelbuild:main Apr 8, 2026
2 checks passed

UebelAndre mentioned this pull request Apr 8, 2026

Updated internal interface #128

Open


		return _android_ndk_repository_impl(ctx, ndk_path)

		local_android_ndk_repository = repository_rule(


		return _android_ndk_repository_impl(ctx, ndk_path)

		remote_android_ndk_repository = repository_rule(

Conversation

UebelAndre commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

UebelAndre commented Mar 19, 2026

Uh oh!

ted-xie commented Apr 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ted-xie left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

UebelAndre commented Apr 7, 2026

Uh oh!

ted-xie commented Apr 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

UebelAndre commented Feb 28, 2026 •

edited

Loading