Skip to content

Conversation

@gferon
Copy link
Contributor

@gferon gferon commented Sep 19, 2023

The rule now ignores ANDROID_NDK_HOME and defaults to downloading the r25c NDK for the current platform (failing if the platform is not supported).

One can specify three new attributes:

  • version to select the NDK to download
  • base_url if you don't want to use https://dl.google.com/android/repository
  • sha256sums to add checksums for (yet) unsupported NDK releases

Also:

  • Specify the template files labels in repository_ctx to avoid the rule implementation function from being restarted (this wasn't so visible with the local install)
  • Use default in attribute for api_version
  • Remove the call to native.register_toolchains() since this will register the NDK as the default C++ toolchain, which shouldn't be the default assumption.

TODO:

  • Provide labels via ctx attributes to avoid the rule restarting multiple times

Closes #44

@gferon
Copy link
Contributor Author

gferon commented Sep 20, 2023

This is ready to review and 🚀 - we're using it as-is in our workspace and everything works nicely.

@ahumesky
Copy link
Collaborator

ahumesky commented Oct 6, 2023

Thanks, I'm asking internally whether we can have such a feature in rules_android, since the download pages for the NDK (and SDK fwiw) present Terms and Conditions that you have to accept before downloading.

@gferon
Copy link
Contributor Author

gferon commented Oct 8, 2023

Fair point, I guess that could be a problem. However, if this is required, we could maybe think of introducing a feature that users need to toggle once per host or something like that?

EDIT: another idea is to add a flag something_read_eula and set it to False in the examples.

@gferon
Copy link
Contributor Author

gferon commented Oct 24, 2023

One more data point if that helps: I just noticed that the flutter command downloads Android SDK modules, and accepts licenses automatically by default.

@marcushultman
Copy link

Any chance this will land anytime soon? This seem to close #2 too.

@ted-xie
Copy link
Collaborator

ted-xie commented Jan 28, 2025

One more data point if that helps: I just noticed that the flutter command downloads Android SDK modules, and accepts licenses automatically by default.

This is surprising to me, but doesn't affect our (the Bazel team)'s position on this issue -- we don't want to set the precedent of allowing users to bypass agreeing to EULAs. We did end up asking internally, and the advice was to not pursue this feature.

@DoDoENT
Copy link

DoDoENT commented Jul 25, 2025

This is surprising to me, but doesn't affect our (the Bazel team)'s position on this issue -- we don't want to set the precedent of allowing users to bypass agreeing to EULAs. We did end up asking internally, and the advice was to not pursue this feature.

Would it be possible to accept the EULA once, save the fact that it's accepted into a file, and then allow rule-based downloads? AFAIK, the Android SDK Tools on headless machines take a similar approach.

Also, I'm new to Bazel, so I don't know if it's possible, but maybe some repository rules could have the ability to pause and prompt a user to accept a license or enter the username/password/MFA code needed for download (e.g., also to download specific Xcode from xcodereleases.com).

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.

Adding downloading of NDK inside Bazel

5 participants