Unnecessary NDK requirement for apps that do not use native libs

[erikkerber]

android_binary builds will fail if ANDROID_NDK_HOME / android_ndk_repository aren't set even if it does not rely on native libs.

The implicit CC toolchain dependency originates here, and is unconditionally used for processing in native_libs.bzl

I was able to get our app to build without setting the NDK by butchering the toolchain code out, more or less, but a more elegant optionality would be great.

[ahumesky]

The example app does not rely on native libs and does not define and android_ndk_repository:
https://github.com/bazelbuild/rules_android/blob/b461ef6ca17a72a6737ee8490b1fdc5bca6509ac/examples/basicapp/MODULE.bazel
https://github.com/bazelbuild/rules_android/blob/main/examples/basicapp/WORKSPACE

The example app is simple (by design), is there something missing that can trigger this without depending on native libs? Does your app have a dependency on something with native libs?

There is a PR in rules_android_ndk that would allow setting an android_ndk_repository without an actual NDK present to stub out the NDK: bazelbuild/rules_android_ndk#63 but that is stalled due to bandwidth (and really that's somewhat of a workaround vs actually not depending on the NDK or NDK CC toolchain and related machinery when you don't really need it).

[erikkerber]

Thanks for pointing that out in the sample app. It was a good hint for me to reproduce this.

I can reproduce in the sample app by setting the platform:

bazel build java/com/basicapp:basic_app --android_platforms=@rules_android//:arm64-v8a

Late my time so I can't dig all the way down—but I think when setting the platforms, the transition moves away from the host (where the CC toolchain is resolved using host?) to an Android platform (where the CC toolchain is not found?)