Android: push trunk back to API 24, stop rebuilding corelibs for the linux host, and update trunk CI to NDK 28c in preparation for the upcoming LTS NDK 30 release

[finagolfin]

The Android workgroup agreed on pushing the CI and SDK back to be built against API 24, so this pull does so for trunk alone, as we're still waiting on a pull for 6.3, swiftlang/swift-corelibs-foundation#5398.

I also added some flags to avoid rebuilding some corelibs for the linux host, as we currently invoke build_script once for each Android arch, and that script deletes and rebuilds the previously built corelibs by default each time, so this makes sure we don't do that.

The real solution is to add a build flag to avoid building the corelibs for the host altogether when building cross-compilation toolchains like this, so I'm working on a handful of pulls for that and to slim down the number of repos checked out for these SDK builds, but this pull will do in the meantime.

What does the CI team think about adding some github CI for these Android pulls, so we can check them before merging? I'm working on an external github CI, swift-android-sdk#19, that will run much more often than this official CI and alert me to problems much more quickly, but that wouldn't be as useful for new contributors that would have to find that repo first.

Also, it would be good if we could add some compiler caching to this official Android CI and set it up so it runs on every compiler pull before merging, though this new Android CI job would not be required to pass yet for those pulls to be merged.

[finagolfin]

Rebased and updated this to NDK 28c for trunk, looking into a fix for the duplicated swiftmodules next, #510, but found the reason.

[finagolfin]

Alright, @shahmishal, this is ready to go: it gets the NDK matching on trunk CI, as we already updated it to NDK 28c for the Windows CI in swiftlang/swift#87774, and updates to building trunk against API 24, as is planned on Windows CI next in swiftlang/swift#86957.

The disabled tests are a temporary hack for NDK 28 alone till we get this CI building on NDK 29 next, after we track down and fix the modularization error in that new NDK shown in swiftlang/swift#85365, where some of these tests will pass again with a newer NDK lld. In other words, we'll whittle away these local source changes in this Android build script in the coming weeks and months.

[finagolfin]

I'll fix the duplicated swiftmodules in separate pulls, which will need to be done for 6.3 also.

[shahmishal]

Are we using API 28 on release/6.3 with this change and API 24 on main?

[finagolfin]

Yes, this pull makes no NDK or API changes for 6.3, as we want to run those changes through trunk CI first.

[finagolfin]

@shahmishal, anything holding this up? We've now switched the Windows trunk toolchain CI over to Android API 24 also, and we'd like to keep the various trunk Android CI on the same NDK and API versions, as Saleem says there.

[finagolfin]

@shahmishal, these NDK and API changes have already been made on the Windows trunk snapshot toolchain CI, which both builds and tests the Android SDKs, where they're working fine. Saleem asked that we keep the various trunk Android CI in sync, which is why I'm following up with you on this so quickly.

Please let me know if there is any issue with getting this in.

Also, would it be okay to add @marcprux as a code owner in this repo for this Android CI directory? I'd like to reduce all this Android CI code to calls to build-script and swift-sdk-generator in the coming months, would be better if he could review those changes without being gated on your approval, since I know you're very busy.

[finagolfin]

Rebased and added a build fix commit for the duplicated swiftmodules that appears to work locally, the reasoning for which I explained on the issue tracking it. I will follow up later with proper build-script flags, so that nobody will hit that issue when cross-compiling SDKs.

[shahmishal]

Trying to understand why the Android API is set to 24 for the main branch and 28 for other branches, including release/6.3.

[finagolfin]

Trying to understand why the Android API is set to 24 for the main branch and 28 for other branches, including release/6.3.

Sure, members of the Android workgroup decided to start compiling the trunk Android SDK against API 24 on the CI first, then maybe the release/6.3 branch afterwards.

@marcprux, as the Android release manager, can you confirm that is where we left it?

[marcprux]

IIRC (and as discussed at #509), we wanted to see if main CI passed with 24, and then once any remaining API-24-specific PRs were cherry-picked to the 6.3 branch (like swiftlang/swift-corelibs-foundation#5398; @madsodgaard, are there any more?) and we all concurred with the change, switch the 6.3 branch to API 24.

[shahmishal]

Thanks!

[madsodgaard]

IIRC (and as discussed at #509), we wanted to see if main CI passed with 24, and then once any remaining API-24-specific PRs were cherry-picked to the 6.3 branch (like swiftlang/swift-corelibs-foundation#5398; @madsodgaard, are there any more?) and we all concurred with the change, switch the 6.3 branch to API 24.

Nope, all changes are in 6.3 branches

[finagolfin]

@justice-adams-apple, I checked the CI log after this pull and it looks like the official Android CI script sets the NDK and API version manually outside build-docker, so these changed defaults are unused.

Can you change the NDK to 28c and Android API to 24 on the trunk Android and PR CI? We'd like the trunk Android CI to match and these changes have been made on Windows already, swiftlang/swift#87774 and swiftlang/swift#86957.

I think you are also manually applying the three source changes from build-docker here in your CI script, so these five tests won't be disabled either. Don't worry about adding that change to your CI script too, I will just disable those tests in the compiler source repo itself.

[Dolfik1]

Hey, now that main snapshots are already building against API 24 (confirmed in the 2026-05-17-a snapshot) and all the necessary changes have been cherry-picked to the 6.4 branches, are there any plans to backport the API 24 switch to release/6.3 as well? Would be great to have them aligned before 6.4 ships.