Remote android sdk toolchain implementation

[mgalindo-sc]

Implements the rules to fetch the android sdk components from a remote host. The implementation roughly follows the same structure used by rules_java in repositories.bzl. Allowing the specification of multiple SDK repositories and registering them as toolchains with platform constraints using the exec_compatible_with attribute. This means there may be multiple Android toolchains and repositories available during a build specified not only by the API level but also by the platform. E.g. android-sdk-35-macos, android-sdk-35-linux, etc. At the moment, there are several places that assume there is only one Android SDK repository, namely @androidsk. In order to not break the existing callsites (e.g. toolchain.bzl) and remain backwards compatible, an additional synthetic repository @AndroidSDK is created to alias to the current platform toolchain in the same manner as java_toolchain_alias.

The client interface remains mostly the same but instead of defining android_sdk_repository register_android_sdks is used passing a list of remote_android_sdks

SDKS = [
    remote_android_sdk(
        name = "remote_android_sdk_{}_macos".format(API_LEVEL),
        api_level = API_LEVEL,
        build_tools_version = BUILD_TOOLS_VERSION,
        exec_compatible_with = ["@platforms//os:macos"],
        build_tools = sdk_package(
            url = "...",
            sha256 = "76bf668fe037b1a69197e298ddae5633d4d7f0f41af7ed17e537c80c1ed8a6f3",
            add_prefix = BUILD_TOOLS_VERSION,
            strip_prefix = VERSION_PREFIX",
        ),
        cmdline_tools = sdk_package(
            url = "...",
            add_prefix = "latest",
            strip_prefix = "cmdline-tools",
        ),
        emulator = sdk_package(
            url = "...",
            sha256 = "5a24aa86d306e6381706ef219376bd165d989bc6d47e0ec59e2bff11c6bfbd90",
            strip_prefix = "emulator",
        ),
        ndk = sdk_package(
            url = "...",
            sha256 = "5851115c6fc4cce26bc320295b52da240665d7ff89bda2f5d5af1887582f5c48",
        ),
        platform_tools = sdk_package(
            url = "...",
            sha256 = "fd3415495a016d0b25678380a6c48dc909c27e9ab3a7783e4bd572e6fa3a8a9c",
            strip_prefix = "platform-tools",
        ),
        platforms = sdk_package(
            url = "...",
            sha256 = "ec20a0a65704e1b2554f8e3eebf588ef260569673c848c01aff2e29c28734cf4",
        ),
    ),
    remote_android_sdk(
        name = "remote_android_sdk_{}_linux".format(API_LEVEL),
        api_level = API_LEVEL,
        build_tools_version = BUILD_TOOLS_VERSION,
        exec_compatible_with = ["@platforms//os:linux"],
        ...,
    ),
]

register_android_sdks(SDKS)

[ted-xie]

Thank you for the PR! The proposed remote_android_sdk rule looks promising and will solve headaches for a lot of users.

The first comment I have is that PRs to the contrib directory should be isolated to just the contrib directory if possible. I meant to write a "contrib guide" for that directory but never got around to it (I may do so, now that we have real contributions there). The reason for the split is for both technical and idealogical reasons: we have separate mechanisms for ingesting contrib vs "regular" PRs, and we want to minimize if not completley eliminate references across the contrib boundary.

[ted-xie]

Also, does this supercede #416?

[ahumesky]

Providing the URL directly does seem to sidestep the issues that were brought up with previous solutions to downloading the SDK, so I think we can go forward with this approach.

[mgalindo-sc]

Also, does this supercede #416?

yes this superceds #416 -

[mgalindo-sc]

Also, does this supercede #416?

I see.This technically could live in the main directory but put it under contrib to not conflict with the current androidsdk repository implementation. If we are ok with having two distinct repo rules the current one and the remote one I could move it there.