The Android Workgroup is hosting another bi-weekly meeting 2026-07-15T16:00:00Z→2026-07-15T17:00:00Z. The workgroup meetings are free for anyone interested to join. Feel free to chime in, or just listen to the topics and discussions.
Post any topics you'd like to discuss here or on the Swift Open Source Slack.
As a heads up, I won't be present at the meeting as I'm in Tokyo. I'm looking for someone else to lead it.
One topic we definitely need to hit: the second beta of the upcoming Android LTS NDK 30 was just released, the first NDK release, since the stable NDK 28 we currently use in non-6.3 CI, that is able to build the C++ interoperability library and some other components in the Swift SDK for Android. Those interim NDK releases, like 29, were not building the SDK because of a C++ modularity issue that is now fixed in the NDK 30 sysroot.
How and when we switch the CI for the upcoming 6.4 release to LTS NDK 30 has been debated so far, we need to make a decision soon.
More topics:
The upcoming Swift 6.4 release switches to the swift-build backend in SwiftPM by default, which is a significant change from the current SwiftPM. Currently, SwiftPM 6.3 has basically no Android-specific build logic, treating it as just another Unix platform, to which we added a few toolset customizations in the Android SDK bundle and an install shell script to work around its holes in configuring an external C/C++ SDK and clang resource directory. Swift-build, by contrast, disables toolsets for Android and adds a bunch of Android-specific build logic directly, both configuring Android and fixing those SDK holes internally. We need to carefully go over all that and fix anything not done well, so I will lay out what my code review found. Further, we need to find out what the plan is from the @build-and-packaging-workgroup, ie more platform-specific logic like this baked into swift-build itself going forward or more general cross-platform mechanisms like the SDK bundle flags and toolsets used up till now.
Android CI has been a bit less green than I'd like lately, as new pulls keep breaking a few tests here and there. We need to discuss better ways to maintain it.
Regardless of that ongoing maintenance, the core CI setup is in good shape, with the non-executable compiler validation suite running on official CI since late last year, replacing the long-running community Android CI that did the same for seven years prior. To finally expand it to running the executable tests and the remaining corelibs like Foundation and libTesting as part of the official snapshot bundle CI (I just added some PR testing of libTesting with the snapshot bundles/toolchains and will do the same with Foundation next) will require nested virtualization enabled in the official CI. In the meantime, I'm setting up unofficial GitHub CI to do this testing in the Android emulator, so we should discuss these plans for expanded testing.
Here are the notes from the just-finished meeting:
After laying out the past NDK release and support timelines, we discussed the versioning change that will be needed and the two tests that now fail. The next LTS NDK 30 has been way delayed, so we decided to set up additional CI runs with the currently working NDK 30 beta 2 and decide based on that forthcoming CI data.
We dove into a handful of choices swift-build makes in its Android-specific build logic, and there was some consternation about some of them, which I will raise at the build workgroup meeting tomorrow.
I asked for more people to chip in on keeping the Android CI green, and if we could have pre-merge Android testing on compiler pulls. Mishal asked to file an issue for the latter and we'll look at how much CI time it adds before deciding.
There was general agreement that expanding CI testing with the Android emulator is needed. I will do it with unofficial GitHub runs for now, and migrate it to official CI when that is ready.