Support cross-compiling to Android with a Swift SDK

Add `swift.android_sdk`, which downloads the swift.org Android Swift SDK bundle
and defines a Swift toolchain targeting {aarch64,x86_64}-unknown-linux-android.
`swift_binary(linkshared = True)` produces a JNI lib<name>.so whose entry points
are written entirely in Swift; examples/cross_compilation builds one.

rules_swift does not fetch or manage the Android NDK. C/C++ compilation and
linking go through a separately registered Android C++ cc toolchain (e.g.
@androidndk//:all from hermetic_android_toolchains), and the Swift toolchain
reads that toolchain's sysroot at analysis time. Register one alongside the
Swift toolchain.

A few NDK-integration details handled in the Swift toolchain rule:
- rules_android_ndk's CcToolchainInfo.sysroot reports the clang dir, not the
  sysroot, so we derive the sysroot from the toolchain's files.
- The Swift link action drives the NDK clang directly and bypasses the cc
  toolchain's sysroot/runtime-lib link features, so for Android we add --sysroot
  and stage libc++_shared.so (which the NDK clang links by default) into the
  link ourselves.
- select_android_runtime_lib selects libc++_shared.so from the resolved cc
  toolchain for APK packaging.

Verified end to end: //examples/cross_compilation:libSwiftJNI.so builds a real
aarch64 Android .so linked through @androidndk, and a downstream app packages it
into a working APK alongside libc++_shared.so.

Author: AttilaTheFun

.bazelci/presubmit.yml

@@ -62,6 +62,20 @@ tasks:
     bazel: last_green
     <<: *mac_common
 
+  macos_cross_compilation:
+    name: "Cross-compilation (Android)"
+    platform: macos_arm64
+    xcode_version: "26.2"
+    bazel: latest
+    # The //examples/cross_compilation targets are tagged `manual` (they fetch
+    # the Swift SDK bundle and the NDK), so they are excluded from the
+    # `//examples/...` wildcard the other tasks build. List them explicitly here
+    # so the Swift-SDK cross-compilation toolchains are exercised in CI.
+    # Build-only: the trivial JNI library exercises the link path, while runtime
+    # behavior is covered downstream by real consumers.
+    build_targets:
+      - "//examples/cross_compilation:libSwiftJNI.so"
+
   macos_latest_shell_scripts:
     name: "macOS shell tests"
     platform: macos_arm64

.bazelrc

@@ -22,6 +22,12 @@ build --worker_sandboxing
 
 build --enable_platform_specific_config
 
+# Accept the Android NDK/SDK licenses for hermetic_android_toolchains' @androidndk
+# (the Android cc toolchain used by //examples/cross_compilation). Only consulted
+# when those repositories are fetched.
+common --repo_env=ACCEPTED_ANDROID_NDK_LICENSE_VERSION=r27c
+common --repo_env=ACCEPTED_ANDROID_SDK_LICENSE_VERSION=35
+
 common:linux --repo_env=CC=clang
 build:linux --cxxopt='-std=c++17' --host_cxxopt='-std=c++17'
 common:linux --//test:apple_build_tests=False

MODULE.bazel

@@ -82,7 +82,10 @@ use_repo(system_sdk, "system_sdk")
 swift = use_extension("//swift:extensions.bzl", "swift", dev_dependency = True)
 swift.toolchain(
     name = "swift_toolchain",
-    swift_version = "6.3",
+    swift_version = "6.3.2",
+)
+swift.android_sdk(
+    toolchain_name = "swift_toolchain",
 )
 use_repo(
     swift,
@@ -110,6 +113,47 @@ register_toolchains(
     dev_dependency = True,
 )
 
+register_toolchains(
+    # Android Swift SDK toolchains used by //examples/cross_compilation. As with
+    # the embedded toolchains above, we register only the host platforms used by
+    # CI rather than `@swift_toolchain//:all`, because rules_swift cannot yet
+    # auto-select a Linux distribution and `:all` would make the host/exec
+    # toolchain ambiguous across distros. A consumer that builds on a single host
+    # platform can simply register `@swift_toolchain//:all`. The Android C/C++
+    # toolchain comes from `@androidndk//:all` (registered below), not here.
+    "@swift_toolchain//:swift_toolchain_android_aarch64_ubuntu22.04",
+    "@swift_toolchain//:swift_toolchain_android_aarch64_ubuntu22.04-aarch64",
+    "@swift_toolchain//:swift_toolchain_android_aarch64_xcode",
+    "@swift_toolchain//:swift_toolchain_android_x86_64_ubuntu22.04",
+    "@swift_toolchain//:swift_toolchain_android_x86_64_ubuntu22.04-aarch64",
+    "@swift_toolchain//:swift_toolchain_android_x86_64_xcode",
+    dev_dependency = True,
+)
+
+# The Android C/C++ cc toolchains for the cross-compile. rules_swift's Swift
+# Android toolchain links through these and reads the sysroot from them.
+bazel_dep(name = "hermetic_android_toolchains", version = "0.1.1", dev_dependency = True)
+
+android_ndk = use_extension(
+    "@hermetic_android_toolchains//:extensions.bzl",
+    "android",
+    dev_dependency = True,
+)
+android_ndk.sdk(
+    build_tools_version = "35.0.0",
+    version = "35",
+)
+android_ndk.ndk(
+    api_level = 28,
+    version = "r27c",
+)
+use_repo(android_ndk, "androidndk")
+
+register_toolchains(
+    "@androidndk//:all",
+    dev_dependency = True,
+)
+
 # Dev dependencies
 bazel_dep(name = "bazel_skylib_gazelle_plugin", version = "1.5.0", dev_dependency = True)
 bazel_dep(name = "gazelle", version = "0.46.0", dev_dependency = True)

doc/standalone_toolchain.md

@@ -146,6 +146,109 @@ bazel run @rules_swift//tools/swift-releases -- list \
     main-snapshot-2024-08-01 --platform xcode --platform ubuntu22.04
 ```
 
+## Cross-compiling to Android with a Swift SDK
+
+swift.org publishes "Swift SDK" artifact bundles (the bundles consumed by
+`swift sdk install`) that let the host compiler cross-compile for platforms it
+cannot target by itself. The `swift` extension can download the Android SDK and
+define matching Swift and C/C++ toolchains, so plain `swift_library` and
+`swift_binary` targets build for `{aarch64,x86_64}-unknown-linux-android` under
+`--platforms`.
+
+Add the `android_sdk` tag, referencing the `toolchain` tag by name (the Swift
+module format is not stable across compiler versions, so the SDK is always
+downloaded for exactly the toolchain's version):
+
+```bzl
+swift.toolchain(
+    name = "swift_toolchain",
+    swift_version = "6.3.2",
+)
+
+swift.android_sdk(toolchain_name = "swift_toolchain")
+
+# rules_swift provides only the Swift toolchain; register an Android C/C++ cc
+# toolchain too (it also provides the sysroot the Swift compiler reads). For
+# example, @androidndk//:all from hermetic_android_toolchains:
+android = use_extension("@hermetic_android_toolchains//:extensions.bzl", "android")
+android.sdk(version = "35", build_tools_version = "35.0.0")
+android.ndk(version = "r27c", api_level = 28)
+use_repo(android, "androidndk")
+
+register_toolchains(
+    "@swift_toolchain//:swift_toolchain_android_aarch64_xcode",
+    "@swift_toolchain//:swift_toolchain_android_x86_64_xcode",
+    "@androidndk//:all",
+)
+```
+
+If you build on a single host platform you can register everything the
+extension generates in one line instead of listing the matrix:
+
+```bzl
+register_toolchains("@swift_toolchain//:all")
+```
+
+Avoid `:all` when you configure multiple Linux distributions, for the same
+reason the standalone host toolchains are registered explicitly: rules_swift
+cannot yet auto-select a distribution, so `:all` would make the host/exec
+toolchain ambiguous across them.
+
+Then build with a platform carrying the matching constraints:
+
+```bzl
+platform(
+    name = "android-aarch64",
+    constraint_values = [
+        "@platforms//cpu:aarch64",
+        "@platforms//os:android",
+    ],
+)
+```
+
+```sh
+bazel build //my:binary --platforms=//:android-aarch64
+```
+
+See `examples/cross_compilation` for a complete example, including building
+through a platform transition.
+
+### JNI shared libraries
+
+A plain `swift_binary` links an ordinary executable. To produce a JNI library
+loadable with `System.loadLibrary`, set `linkshared = True`: it produces
+`lib<name>.so`. Export functions with `@_cdecl`; the Android Swift SDK's
+`Android` module provides the JNI types, so the entry points can be written
+entirely in Swift. A `swift_binary(linkshared = True)` may depend on ordinary
+`swift_library` targets (linked statically), so the JNI entry point and the
+shared business logic stay in separate libraries.
+`examples/cross_compilation/android_app` shows the Kotlin app that loads the JNI
+library.
+
+Details worth knowing:
+
+* The Swift standard library is linked statically from the SDK.
+* Android binaries link against the NDK's `libc++_shared.so`, which must be
+  packaged with the application. Select it from the registered Android cc
+  toolchain with `select_android_runtime_lib` from
+  `@rules_swift//swift/toolchains:android_runtime_lib.bzl` (build it under the
+  Android platform so the cc toolchain resolves).
+* rules_swift does not fetch the Android NDK; the registered Android cc toolchain
+  (e.g. `@androidndk//:all`) provides clang, the linker, and the sysroot, and the
+  Swift toolchain reads that toolchain's sysroot at analysis time.
+* Checksums for the SDK bundles are bundled for a curated list of releases (see
+  `swift/internal/extensions/swift_sdk_releases.bzl`); for other releases, pass
+  `sha256` explicitly.
+
+### Coexistence with `rules_apple`
+
+A common setup cross-compiles to Android *and* builds the same app's Apple
+targets with `rules_apple`. The two resolve together cleanly: this line of
+`rules_swift` is `compatibility_level = 3` (the same as released `rules_swift`
+3.x), so a current `rules_apple` release works alongside it. Bazel keeps the
+higher of each shared transitive dependency (`apple_support`, `rules_cc`), which
+are backward compatible, so no extra pinning is required.
+
 ## Using the extension from a non-root module
 
 The extension is intended for the root module — it fails if a non-root

examples/cross_compilation/BUILD.bazel

@@ -0,0 +1,45 @@
+load("//examples/embedded:transition.bzl", "transition_binary")
+load("//swift:swift.bzl", "swift_binary", "swift_library")
+
+package(default_visibility = ["//visibility:public"])
+
+# The platform covered by the Android Swift SDK toolchain registered by this
+# repository's dev `MODULE.bazel` (via the `swift` extension's `android_sdk`
+# tag). Build the targets below with `--platforms` set to this.
+platform(
+    name = "android-aarch64",
+    constraint_values = [
+        "@platforms//cpu:aarch64",
+        "@platforms//os:android",
+    ],
+)
+
+# A plain library dependency, compiled for whichever platform depends on it,
+# demonstrating that a normal `swift_library` is reused unchanged across targets.
+swift_library(
+    name = "Greeter",
+    srcs = ["Sources/Greeter/Greeter.swift"],
+    module_name = "Greeter",
+    tags = ["manual"],
+)
+
+# ---------------------------------------------------------------------------
+# Android: a JNI shared library, loaded by Kotlin via `System.loadLibrary`.
+# ---------------------------------------------------------------------------
+
+# `linkshared` produces `libSwiftJNI.so`. The JNI entry point is written in
+# Swift (it `import`s the SDK's `Android` module for the JNI types) and calls
+# into the `Greeter` library. See `android_app/` for the APK that loads it.
+swift_binary(
+    name = "SwiftJNI",
+    srcs = ["Sources/SwiftJNI/SwiftJNI.swift"],
+    linkshared = True,
+    tags = ["manual"],
+    deps = [":Greeter"],
+)
+
+transition_binary(
+    name = "libSwiftJNI.so",
+    binary = ":SwiftJNI",
+    platform = ":android-aarch64",
+)

examples/cross_compilation/README.md

@@ -0,0 +1,55 @@
+# Cross-compilation example (Android)
+
+Builds plain `swift_library` / `swift_binary` targets for Android using the
+Swift SDK toolchain registered by this repository's `MODULE.bazel` (via the
+`swift` extension's `android_sdk` tag). See `doc/standalone_toolchain.md` for the
+toolchain setup.
+
+All targets are tagged `manual` because they download the Swift SDK bundle and
+require the Android cc toolchain to be registered.
+
+### The Android C/C++ toolchain
+
+rules_swift provides only the Swift Android toolchain; C/C++ compilation and
+linking (and the NDK sysroot the Swift compiler reads) come from a separately
+registered Android cc toolchain. This example uses `@androidndk//:all` from
+keith's
+[`hermetic_android_toolchains`](https://github.com/keith/hermetic_android_toolchains),
+wired in this repository's `MODULE.bazel`:
+
+```starlark
+android = use_extension("@hermetic_android_toolchains//:extensions.bzl", "android")
+android.sdk(version = "35", build_tools_version = "35.0.0")
+android.ndk(version = "r27c", api_level = 28)
+use_repo(android, "androidndk")
+register_toolchains("@androidndk//:all")
+```
+
+Any rules_android_ndk-based Android cc toolchain works the same way. To package
+the NDK's `libc++_shared.so` into an APK, use the `select_android_runtime_lib`
+rule from `@rules_swift//swift/toolchains:android_runtime_lib.bzl` (it reads the
+resolved cc toolchain); see `android_app/README.md`.
+
+## Targets
+
+| Target | Output | Demonstrates |
+|---|---|---|
+| `:Greeter` | `.swiftmodule` + `.a` | A normal `swift_library` reused across targets |
+| `:libSwiftJNI.so` | `libSwiftJNI.so` | An Android **JNI shared library** (`swift_binary(linkshared)`) that calls `:Greeter` |
+
+```sh
+# Android JNI shared library:
+bazel build //examples/cross_compilation:libSwiftJNI.so
+```
+
+`:libSwiftJNI.so` builds `:SwiftJNI` under the `:android-aarch64` platform; you
+can equivalently pass `--platforms=//examples/cross_compilation:android-aarch64`
+on the command line.
+
+## Android app
+
+`android_app/` contains the Kotlin app (and a documented packaging recipe) that
+loads `libSwiftJNI.so` and calls into it, completing the
+Kotlin → Swift (JNI `.so`) → Swift library chain. Packaging an APK uses
+`rules_android` + an Android SDK in the consuming module; see
+`android_app/README.md`.

examples/cross_compilation/Sources/Greeter/Greeter.swift

@@ -0,0 +1,14 @@
+/// A plain `swift_library` used as a normal dependency of the Android JNI
+/// entry point. Nothing in here is platform-specific; it is compiled for
+/// whichever platform the depending target is built for.
+public struct Greeter {
+  private let subject: String
+
+  public init(subject: String) {
+    self.subject = subject
+  }
+
+  public func greeting() -> String {
+    return "Hello from Swift, \(subject)!"
+  }
+}

examples/cross_compilation/Sources/SwiftJNI/SwiftJNI.swift

@@ -0,0 +1,24 @@
+import Android
+import Greeter
+
+// The JNI entry point, written entirely in Swift. `import Android` provides the
+// JNI types (`JNIEnv`, `jclass`, `jstring`, ...) from the Android Swift SDK, so
+// no C shim is needed. `@_cdecl` gives the function the exact symbol name JNI
+// looks up: `Java_<package>_<class>_<method>`, with `.`/`_` escaped per the JNI
+// spec. It is the Kotlin-callable native implementation of:
+//
+//   package com.example.swiftjni
+//   class NativeBridge { external fun greetingFromSwift(): String }
+//
+// and it delegates to the `Greeter` `swift_library` (a normal dependency),
+// completing the Kotlin -> Swift (JNI .so) -> Swift library call chain.
+@_cdecl("Java_com_example_swiftjni_NativeBridge_greetingFromSwift")
+public func greetingFromSwift(
+  _ env: UnsafeMutablePointer<JNIEnv?>,
+  _ clazz: jclass
+) -> jstring? {
+  let message = Greeter(subject: "Android").greeting()
+  return message.withCString { cString in
+    env.pointee!.pointee.NewStringUTF(env, cString)
+  }
+}

examples/cross_compilation/android_app/AndroidManifest.xml

@@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="utf-8"?>
+<manifest xmlns:android="http://schemas.android.com/apk/res/android"
+    package="com.example.swiftjni">
+
+    <uses-sdk
+        android:minSdkVersion="28"
+        android:targetSdkVersion="34" />
+
+    <application android:label="Swift JNI Example">
+        <activity
+            android:name=".MainActivity"
+            android:exported="true">
+            <intent-filter>
+                <action android:name="android.intent.action.MAIN" />
+                <category android:name="android.intent.category.LAUNCHER" />
+            </intent-filter>
+        </activity>
+    </application>
+</manifest>