We might want to base this on https://github.com/marketplace/actions/swift-android-action, which supports building and testing on both Linux and macOS (Intel) hosts, as well as caching the SDK, host toolchain, and emulator.

The SDK is currently downloaded from a mirror of https://github.com/finagolfin/swift-android-sdk/releases, but adding a step to optionally build it from source would be a possibility, at least for Linux.

Fine by me, if you've done the work already and want to submit it here.

if you've done the work already [...]

Well, I wouldn't quite say that, yet :). Getting this working would essentially require mashing your SDK build step (sdks.yml#L109) into a pre-build step of swift-android-action's action.yml#L154. This could be optimized somewhat, since the SDK bundle that is produced could just contain the host architecture (rather than each of aarch64, x86_64, and armv7, as your general SDK release includes).

I'm wondering a few things:

1. Where do we get the patches that you apply? Or do we envision that this will only work with a Swift source checkout that doesn't need any Android patches?
2. Why do you propose excluding the external libraries that get-packages-and-swift-source.swift fetches? We might be able to do without FoundationXML and FoundationNetworking, but could we have a useful SDK without ICU?
3. Would the caller of the workflow be expected to specify a specific tag parameter (like swift-DEVELOPMENT-SNAPSHOT-2025-01-10-a), or would it be swift-DEVELOPMENT-SNAPSHOT-latest, and the script would dynamically fetch the most recent tag?
4. None of this would work on macOS until the build-script is capable of cross-compiling the Android SDK. But I think we can live with that.

This could be optimized somewhat, since the SDK bundle that is produced could just contain the host architecture (rather than each of aarch64, x86_64, and armv7, as your general SDK release includes).

More than that, it wouldn't have to be a bundle, but just an Android SDK with a destination config file for this workflow.

Where do we get the patches that you apply?

In this repo? Or directly in the workflow script if external patch files won't work somehow. I just checked and my current SDK build only has to patch 8-9 lines in 6.1/6.2 for Android, and I'm about to upstream those too.

Why do you propose excluding the external libraries that get-packages-and-swift-source.swift fetches?

Cutting down the dependency tree further, that's all.

We might be able to do without FoundationXML and FoundationNetworking, but could we have a useful SDK without ICU?

Um, libicu's already been removed as an external dependency, 😃 so I'd just use the swift-foundation-icu package instead.

Would the caller of the workflow be expected to specify a specific tag parameter (like swift-DEVELOPMENT-SNAPSHOT-2025-01-10-a), or would it be swift-DEVELOPMENT-SNAPSHOT-latest, and the script would dynamically fetch the most recent tag?

Both shouldn't be hard.

None of this would work on macOS until the build-script is capable of cross-compiling the Android SDK.

That's been working for awhile: I think you had it working through llbuild too, which is more than the SDK needs. Of course, there may have been regressions since, but I expect to look into and figure that out soon.