-
Notifications
You must be signed in to change notification settings - Fork 86
Conversation
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
commented
Nov 10, 2025
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
commented
Nov 10, 2025
Also, does this supercede #416?
ahumesky
commented
Nov 11, 2025
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
commented
Nov 17, 2025
mgalindo-sc
commented
Nov 17, 2025
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.
keith
commented
Jun 23, 2026
I created a separate project for this, please try it out and let me know how it goes! https://github.com/keith/hermetic_android_toolchains
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_repositoryregister_android_sdksis used passing a list ofremote_android_sdks