Expose SDK and NDK installations for Gradle and other local tools

[DoDoENT]

This adds public labels that downstream Bazel modules can use to export the locations of the downloaded Android SDK and NDK to local build tools, including Gradle and Android Studio.

At Microblink, we use Bazel to build and test C++ code, while our Android developers prefer Android Studio and Gradle for app development. The Android development experience does not yet have feature parity across these workflows. Sharing Bazel's NDK lets the Gradle builds use the same native toolchain as our Bazel C++ tests, with its version managed in one place.

The SDK and NDK can be consumed independently. Our app workflow uses Android Studio's SDK and CMake installation together with Bazel's NDK. Exporting the Bazel-managed SDK is also useful for projects whose requirements are covered by its configured packages; this does not add CMake or turn the installation into an SDK Manager-managed SDK.

The changes are:

• Expose @androidndk//:ndk_root and @androidsdk//:sdk_root as single-file markers, with platform-selecting aliases. A downstream executable can resolve the marker's physical parent directory at bazel run time and write the path to a properties file consumed by Gradle.
• Present the SDK through a conventional directory layout using symlinks to the existing downloads. Generate platform package.xml metadata when absent so Gradle can discover decimal API levels such as 37.0.
• Expose @androidndk//:all_files, including the clang and sysroot subpackages, for consumers that need the complete file set.
• Document host-platform selection, runfiles/symlink resolution, and the lifetime and local-only nature of the exported paths. Extend the existing label regression test to cover the new labels.

The properties-file generator remains a downstream concern. These labels provide the installation discovery interface; consumers choose their property names and SDK/NDK integration independently. Exported machine-local paths are generated at runtime and must be refreshed after version or cache changes.

Validation:

• bazel test //tests:valid_labels_build_test --lockfile_mode=off on macOS.
• Buildifier formatting checks and lint for the changed Starlark implementation, plus git diff --check.
• Downstream Bazel module integration tests for separate SDK and NDK exporters, including manifest-only runfiles and paths containing spaces/apostrophes.
• A Gradle/AGP smoke project consuming the exported SDK and NDK successfully assembled an Android library.
• The developer confirmed that the real development app works with Android Studio's SDK/CMake and the Bazel-managed NDK. Broader QA testing is pending.

The downstream integration tests and Gradle projects are outside this repository; the label regression coverage is included here.

This contribution comes from a hybrid Bazel/Gradle workflow. Feedback on whether this local integration interface fits the project's scope, and on the shape of the public labels, is welcome.

AI disclosure: the entire implementation was generated by AI (OpenAI Codex), including the code, documentation, and test changes. The PR description was also written by Codex. The development-app validation above was performed by the developer; broader QA validation remains pending.

[DoDoENT]

@keith, would you be interested in receiving a contribution like this?

A similar change was also accepted into rules_android_ndk, although this change here does not require the change mentioned in rules_android_ndk (I also tested with 0.1.5).