[FR] Support disabling top-level library linking

[ted-xie]

Currently, when the NDK rules are used in conjunction with the regular Android rules (rules_android), the default behavior is to link all cc_library deps into one single .so file that gets packaged into the APK. Some users have requested the ability to disable the top-level linking, i.e. to have disparate .so files corresponding to each cc_library.

To support this, we'd need something like this in the NDK rules themselves.

[trybka]

To clarify, the ndk_cc_toolchain would need a new feature declaration, somewhere around here: https://github.com/bazelbuild/rules_android_ndk/blob/7e9abc68cf9d8016c8cfbe52ed3b1f8e68edbaad/ndk_cc_toolchain_config.bzl#L601

It would look like this:

        # Disable fallback native deps linking in android binary rule implementation.
        feature(
            name = "disable_fallback_native_deps_linking",
        ),

and then users could set it in a bazelrc (e.g. with --features=disable_fallback_native_deps_linking) or mark it enabled = True in their own NDK cc toolchain.

[ted-xie]

Hm I think it's not quite so simple. I have a draft PR in https://github.com/bazelbuild/rules_android_ndk/pull/111 that doesn't quite work as expected:

• I added the feature() with enabled = False by default, then built my app with --features=disable_fallback_native_deps_linking, and the .so files were still built as top-level APK artifacts.
• Forcing enabled = True in the toolchain definition and then rebuilding yields an APK with no .so files at all

Looking at the rules_android native linking code linked above, the linker helper function returns None if disable_fallback_native_deps_linking is enabled -- this means that downstream packaging steps are no longer aware of any native library deps.

[trybka]

Hm I think it's not quite so simple. I have a draft PR in #111 that doesn't quite work as expected:

I agree it's not quite so simple. I think the rules are missing something preventing --features= from working.

• I added the feature() with enabled = False by default, then built my app with --features=disable_fallback_native_deps_linking, and the .so files were still built as top-level APK artifacts.
• Forcing enabled = True in the toolchain definition and then rebuilding yields an APK with no .so files at all

Interesting. I think the rules might be missing this line: requested_features = ctx.features, around here

Looking at the rules_android native linking code linked above, the linker helper function returns None if disable_fallback_native_deps_linking is enabled -- this means that downstream packaging steps are no longer aware of any native library deps.

It's true that it won't link anything on its own--that's expected. Presumably the sample app you used only has deps on cc_library and doesn't use cc_binary(linkshared=1) to gather the C++ deps.

The collection of linkshared cc_binary should happen here.