Add an Android workflow, for Swift packages to build the Android SDK and test against

[finagolfin]

I've had requests for an Android workflow, both using my unofficial SDK, finagolfin/swift-android-sdk#127, and for whenever an official Android SDK is available. Rather than waiting for an official Android SDK first, I thought I could put together an Android workflow here that builds the Android SDK from source on first use, then uses it to cross-compile that Swift package that invoked this workflow on its CI and run its tests in the Android emulator, before finally caching the freshly-built Android SDK on that Swift package's CI for subsequent test runs.

Here are some further details:

• I'd start off with Swift 6.1 only, building from the latest snapshot tag, then add other release branches later.
• linux-only for build host initially, add macOS later
• I currently download some pre-compiled libraries for Android from another OSS project for my SDK bundle supporting Android API 24: a backported posix_spawn() wrapper to Android API 24 and libcurl/libxml2 for Foundation. I'd simply require Android API 28, when posix_spawn() was added to Android, and remove FoundationNetworking and FoundationXML support for this workflow, looking into ways to add those back later, so no such external libraries would be required for this workflow.
• I'd simply use an existing external Android emulator workflow, as I do on my Android CI. We could look into removing that external dependency later, if wanted.
• Once an official Android SDK is available, we could make that the default, and make this fresh build an alternate option for those who want it.

@FranzBusch or @shahmishal, let me know if you'd be okay with adding such an Android workflow here, will put together a pull if so.

[marcprux]

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.

[finagolfin]

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

[marcprux]

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.

[finagolfin]

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.