Download the NDK in Bazel

[gferon]

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:

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

Closes #44

[gferon]

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

[ahumesky]

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]

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]

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]

Any chance this will land anytime soon? This seem to close https://github.com/bazelbuild/rules_android_ndk/issues/2 too.

[ted-xie]

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.