The Android community workgroup met earlier today and I wanted to provide a summary of the SDK packaging & build system specific discussion points we talked about and consensus we reached (though the ultimate plan of record could of course still change and involve other stakeholders):
Work is ongoing to remove the "vendored" NDK from the Swift Android SDK, and instead move to require that to be provided by the user. This is because it allows users to use a newer NDK than the one the Swift Android SDK was built with, and because it avoids any potential issues around limitations on redistributing the Android NDK itself.
In the short term, a script or installation instructions would need to be provided with the Swift Android SDK to link it with an Android NDK already on the end user's system, either by creating a symlink from the Swift SDK directory, or mutating swift-sdk.json via swift sdk configure to point directly at the NDK path, as well as to copy in swiftrt.o (as a temporary workaround for a bug).
When Swift Package Manager is performing builds with the new Swift Build backend, the manual NDK setup step can be eliminated by relying on Swift Build's existing dedicated support for the Android NDK. Currently, Swift Build automatically discovers the NDK at its default installation path (~/Library/Android/Sdk/ndk/$version on macOS, and so on) and should also respect the standard ANDROID_NDK_ROOT environment variable as an override.
On Windows, we would like for the Swift Android target to be distributed as part of the Swift for Windows installer, just like the Windows target is today. On macOS and Linux, the distribution can be as a Swift SDK. (@compnerd feel free to expand on the reasoning behind this point and why it differs for Windows vs macOS/Linux)
We would like for the Swift for Windows installer to additionally provide the Swift Android runtime libraries as one or more .aar files to fit in with platform conventions for library distribution, for users who may be using other build systems like Gradle. This is similar to how we distribute .msm files for the Swift Windows runtime libraries as part of the Windows installer today.
distribution in enterprise environments is often automated via SCCM
installation via MSI is properly tracked in the system
the installation can register the SDK with the system allowing enumeration (similar to how Xcode functions)
It can allow for additional automation using system tools
That doesn't mean that users cannot use other means to acquire the SDK, but it would preclude that from being detected and switched between. Effectively, it prevents use of tools like tcrun (GitHub - compnerd/tcrun) to allow easy switching and management of SDKs/toolchains.
I don't think there're real obstacles that prevent us from removing non-native targets from the toolchain installation. We could (and had better) distribute them as Swift SDKs packaged into MSI (instead of pure artifact bundles). The toolchain installer can still use a "download and install side by side" strategy if we want to ease the adoption and retain the current installation experience.
ADDITION: If possible, we can let SwiftPM learn how to package and sign an MSI installer from an artifactbundle, so that we can have aligned SDK installation experience across all the platforms.
SwiftPM's involvement here will be interesting. We really need to get cleaner at how we manage Swift SDKs. In other circles, e.g. embedded, we're talking about having Swift SDKs defined by packages and managed like other packages, i.e. versioned, able to store in a package registry, etc. That's a longer term view that we still have to work out a lot of the details. So while I understand the immediate needs, I look forward on working with the Android team so see how we can fit the Android SDK into this paradigm, once we better understand what we need.
Yes, distributing them as MSIs separately is absolutely an option. I think that it does complicate things to have to do multiple builds though. To do the download and install side-by-side strategy, we would need to continue to do what I stated - the chain cannot be modified at runtime.
Thanks for the write-up, @jakepetroules. On the macOS and Linux front, I've updated the Android SDK build PR to create the post-install script that we discussed to get the NDK linked into the SDK.
I think this build covers all the must-haves (no external binary library dependencies, no included NDK), so I've marker the PR as ready for review. I'm hoping we can get this .artifactbundle available on swift.org as soon as possible, as @mishal_shahrequested.