Android support

[marcprux]

As discussed in #83, and now that the Android SDK nightly-6.1 supports Swift Testing (swiftlang/swift-package-manager#8362), this PR adds experimental support for cross-compiling Swift packages for Android and running their tests on an Android emulator. It is only run when the enable_android_checks input is set to true, making it opt-in for now.

It uses swift-android-action to set up the environment and run the tests, which is the same workflow that powers https://swift-everywhere.org and various other Swift CI workflows. This action, in turn, delegates to the reactivecircus/android-emulator-runner workflow to set up and run the emulator based in the inputs passed to the workflow (android_api_level, android_channel, android_profile, and android_target). Support for transferring specific files to the Android emulator (with android_copy_files) and setting custom test environment variables (with android_test_env) enable customization of the test environment (for example, see https://github.com/jpsim/Yams/blob/main/.github/workflows/swiftpm.yml#L146).

This works towards the one of the goals of the Android Workgroup to provide continuous integration support for Android. A successful run of this workflow can be seen at https://github.com/marcprux/swift-algorithms/actions/runs/13838259992

Closes #83.

[marcprux]

@shahmishal There's a pending review for the codeowner "swiftlang/github-workflows-contributors", but I don't know who that group consists of. At yesterday's Android WG meeting, we (myself, @compnerd, @finagolfin, @Joannis, and @andriydruk) discussed how me might get some discussion going around this.

As documented in the action's README, the action will transition to using an official Android SDK build once it is published on swiftlang, but getting something going sooner rather than later will help keep packages building on Android and prevent regressions (like swiftlang/swift-tools-support-core#499, swiftlang/swift-package-manager#8372, and swiftlang/swift-format#963). And the action is already in use by a bunch of popular projects (like Yams, Vapor, GraphQL, and Alamofire), so building on this strong base of projects will help improve the Android coverage for everyone.

[shahmishal]

Thank you for creating a pull request to add Android workflow.

As documented in the action's README, the action will transition to using an official Android SDK build once it is published on swiftlang, but getting something going sooner rather than later will help keep packages building on Android and prevent regressions (like swiftlang/swift-tools-support-core#499, swiftlang/swift-package-manager#8372, and swiftlang/swift-format#963). And the action is already in use by a bunch of popular projects (like Yams, Vapor, GraphQL, and Alamofire), so building on this strong base of projects will help improve the Android coverage for everyone.

Let's work on getting the official Android SDK set up on ci.swift.org and start publishing on swift.org

@marcprux, could you please share the documentation or steps for producing it on Linux? It would be helpful if we could create a Dockerfile that includes the necessary NDKs and tools for building the Android SDK. cc: @finagolfin

@shahmishal There's a pending review for the codeowner "swiftlang/github-workflows-contributors", but I don't know who that group consists of. At yesterday's Android WG meeting, we (myself, @compnerd, @finagolfin, @Joannis, and @andriydruk) discussed how me might get some discussion going around this.

I would be happy to discuss this further in the next Android WG meeting. However, I would like to have the .artifactbundle available on swift.org as soon as possible.

[marcprux]

@marcprux, could you please share the documentation or steps for producing it on Linux?

The SDK that I'm using is built with @finagolfin's actions at https://github.com/finagolfin/swift-android-sdk, which uses scripts, patches, and external libraries built with https://github.com/finagolfin/swift-android-sdk/blob/main/.github/workflows/sdks.yml and https://github.com/finagolfin/swift-android-sdk/blob/main/get-packages-and-swift-source.swift. I grab the nightlies and publish them at https://github.com/skiptools/swift-android-toolchain/releases, which is what the swift-android-action installs and uses.

I would like to have the .artifactbundle available on swift.org as soon as possible.

So would we! We've been discussing the best way to hammer the process into something that can be incorporated into something official.

[finagolfin]

Let's work on getting the official Android SDK set up on ci.swift.org and start publishing on swift.org

@marcprux, could you please share the documentation or steps for producing it on Linux? It would be helpful if we could create a Dockerfile that includes the necessary NDKs and tools for building the Android SDK. cc: @finagolfin

That's great news! I don't think I ever asked about producing an official Android SDK yet, as I simply assumed the first step would be to get it on the official CI and declared an officially supported platform first, which I have delayed setting up as I worked on other issues I felt were more pressing for the upcoming 6.1 release and 6.2 branch.

However, in the meantime, @compnerd told us at the latest community Android WG meeting that TBC has started shipping Android SDKs in the nightly Windows toolchain and they have enabled running non-executable tests from the compiler validation suite for Android on the Windows CI, as can be seen in the meeting notes @Joannis posted this weekend. So since Android is now being tested as part of the official Windows CI, I see no obstacle to moving forward with an official Android SDK also. 😃

If the official Windows toolchain is already shipping official Android SDKs, the fastest way to do this would be to grab those from the Windows toolchain and package them as separate Android SDK bundles also. We discussed this with Saleem at the Android WG meeting, but he said the Windows toolchain does not support separate SDK bundles yet, hence bundling everything together on Windows.

I think it would be a great testament to Swift's cross-platform support and the Windows toolchain specifically if we can produce these official Android SDK bundles initially from Windows. 😸 I will follow that up with pulls to get build-script building Android SDKs on linux and macOS too, so it is easy for people using those platforms to build it themselves and to make sure the official CI notifies us if anything breaks when building SDKs.

@marcprux, do you have time now to get started by looking into simply repackaging the prebuilt Android SDKs from the official nightly Windows toolchain as Android SDK bundles? The first step would be to download those and create an SDK bundle from them locally, then test cross-compiling some packages against it and make sure it works. If it does, you can simply script what you did in the official swift-docker repo too, as Alastair did to produce the static linux SDK, but with much fewer steps since you're just repackaging prebuilt SDKs from the Windows toolchain. I'll join you once 6.1 ships and 6.2 branches.

@shahmishal and @compnerd, let us know what you think of my plan above to get some separate SDK bundles up quickly. I may have missed something, particularly since I've never used the Windows Swift toolchain, so let me know if I did.