examples: a runnable Android APK example (Kotlin → Swift JNI → Swift) - #4
Merged
Merged
Conversation
…Swift) The cross_compilation example previously built only the JNI .so and documented (in prose) how a downstream module would package it into an APK. Replace that recipe with a real, building android_binary that runs on a device/emulator and shows the Swift greeting on screen — a far more compelling demonstration of integrating Swift into an Android app. It's packaged the real-world way, with rules_android (android_binary) and rules_kotlin (kt_android_library). The one rules_swift-specific detail: the swift_binary(linkshared) .so arrives via DefaultInfo (not CcInfo), so it's wrapped in a cc_library to feed android_binary's per-ABI native split; libc++ is selected via select_android_runtime_lib the same way. rules_android/rules_kotlin/rules_java/rules_jvm_external are all dev_dependency deps (with a pinned Maven lock and the hermetic @AndroidSDK), so consumers of rules_swift are unaffected. CI builds the APK via a build_test under --config=android_example (scoped flags; the rest of the build is untouched). Claude-Session: https://claude.ai/code/session_01SmG1kqA3qB4WsLGU2xavuJ
AttilaTheFun
added a commit
that referenced
this pull request
Jun 25, 2026
Owner
Author
|
Auto-resolved as merged: the example commit is now folded into the base Android PR (bazelbuild#1818), whose description carries the emulator screenshot. Nothing further needed here. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes the Android example actually runnable instead of building only the JNI
.sowith a prose packaging recipe. It's now a realandroid_binary(built withrules_android+rules_kotlin) that loadslibSwiftJNI.soand shows"Hello from Swift, Android!" on screen — verified on an emulator:
This is the application half of the chain end-to-end:
MainActivity.kt → NativeBridge.greetingFromSwift()(Kotlin, JNI) →libSwiftJNI.so(swift_binary(linkshared),@_cdecl) →Greeter(
swift_library).What's here
examples/cross_compilation/android_app/BUILD.bazel(new):android_binary+kt_android_library, the twocc_library.sowrappers,select_android_runtime_lib/transition_binaryfor libc++, and abuild_test. Everything taggedmanual(kept out of the//examples/...wildcard, like the rest of
cross_compilation).macos_cross_compilationtask gains--config=android_exampleand theapp_build_test.The one rules_swift-specific detail
swift_binary(linkshared = True)exposes its.soviaDefaultInfo, notCcInfo, so it can't go straight intoandroid_binary.deps. Wrapping it in acc_library(a prebuilt.soinsrcsbecomes aCcInfodynamic library) letsandroid_binary's per-ABI native split collect it intolib/arm64-v8a/.libc++_shared.sogoes in the same way viaselect_android_runtime_lib.Dependency weight (the open question)
rules_android/rules_kotlin/rules_java/rules_jvm_externalare alldev_dependency = True(pinned Maven lock at//:rules_android_maven_install.json,hermetic
@androidsdkfromhermetic_android_toolchains— no local SDK), soconsumers of
rules_swiftare unaffected.protobufstays at 34 (no conflict).The rules_android flags live behind a scoped
--config=android_exampleso therest of the build is untouched.
Totally fine if this is too heavy to live in
rules_swift— it can drop back tothe
.so+ recipe, or move to a standalone example repo. Opening it as aseparate commit on top of the Android PR so the delta is easy to see.
(Screenshot lives on the
assets/android-example-screenshotbranch, not in this PR's diff.)