Skip to content

Add Android build support#4

Merged
colemancda merged 9 commits into
masterfrom
feature/android
Jul 14, 2026
Merged

Add Android build support#4
colemancda merged 9 commits into
masterfrom
feature/android

Conversation

@colemancda

@colemancda colemancda commented Jul 14, 2026

Copy link
Copy Markdown
Member

Summary

  • Force the embedded SQLite (SQLiteSwiftCSQLite) trait so SQLite.swift doesn't require a system libsqlite3, which Android lacks
  • Pin the local toolchain to Swift 6.3.2 to match the published Android SDK artifact bundle
  • Add an Android CI job that installs the matching NDK and Swift Android SDK, then builds debug/release for aarch64-unknown-linux-android28

Test plan

  • swift build --swift-sdk aarch64-unknown-linux-android28 -c debug succeeds locally, producing aarch64 ELF objects
  • swift build --swift-sdk aarch64-unknown-linux-android28 -c release succeeds locally
  • swift build --swift-sdk aarch64-unknown-linux-android28 --build-tests succeeds locally
  • CI Android job passes on GitHub Actions

Android has no system libsqlite3, so force the SQLiteSwiftCSQLite
trait instead of relying on SQLite.swift's os(Linux)-only default.
The published Android Swift SDK artifact bundle is built against
6.3.2; a newer host compiler can't import its precompiled modules.
Installs the matching NDK and Swift Android SDK artifact bundle on
a macOS runner, then builds debug and release for aarch64-android.
Nested virtualization for the emulator isn't available on the
macOS runner used for the build job, so this runs on ubuntu-latest
via the swift-android-action, pinned to the same SDK artifact
bundle already used for building.
…puts

swift-actions/setup-swift doesn't yet recognize 6.3.2 on macOS, so
install it directly with swiftly instead. Also drop custom-sdk-url
without installed-sdk on the emulator test job, which the action
rejects; its default resolution already fetches the same official
6.3.2 android-sdk artifact bundle.
The action builds tests with plain 'swift build', which doesn't
enable testability for release builds, breaking the @testable
imports in CoreModelSQLiteTests. Debug-only matches how swift test
is normally used for @testable suites.
macOS and Linux keep SQLite.swift's own default trait for the
platform (system SQLite on Apple, embedded on Linux); Android is
the only target that needs the embedded copy forced, detected via
the TARGET_OS_ANDROID env var set when cross-compiling.
…uild

The iOS job builds for the simulator platform and runs the test
suite against a dynamically selected available iPhone simulator,
so it doesn't depend on any particular simulator name existing on
the runner image. The Android job now exports TARGET_OS_ANDROID=1
so Package.swift picks the embedded SQLite trait.
Xcode's explicit-module build system was caching the Release
CoreModelSQLite module without testability even on a clean
DerivedData, breaking @testable import; ENABLE_TESTABILITY=YES
forces it regardless of configuration. Also point the plain Build
step at the device platform instead of the simulator so it can't
collide with the Test step's simulator DerivedData.
@colemancda colemancda merged commit 12207b9 into master Jul 14, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant