NDK Version for 6.3 and CI
- Should we bump our NDK from 27 to 28 in order to be able to support availability annotations for everyone?
- It would be nice if we could just always recommend LTS NDKs, but NDK 30 (the next LTS) is unlikely to be available in the Swift 6.3 timeframe; there's no directive or precedent that says we must only use LTS releases
- @compnerd raised concerns about trying to update to NDK 28 this late in the Swift 6.3 process
- @marcprux pointed out that users can always "bring their own NDK" and drop it into the local Swift SDK for Android install, but others identify this as dangerous due to lack of ABI compatibility; safest to to use the same NDK that was used to build the modules included in the SDK
- @Finagolfin offered to try getting NDK into the main CI to identify whether there are issued, and if everything goes smoothly, consider getting it into 6.3
- @compnerd raises concerns about insufficient time/resources for testing against Windows in the near term
- @marcprux mentions that there is already a divergence between Windows NDK (27c) versus macOS/Linux NDK (27d), so there's no hard and fast requirement that they are exactly the same, but everyone agrees that it would be best if they were all synchronized
- All agree that we will need to upgrade the NDK someday; first step is to shake out any problems in main CI
Android Vision Document
- Vision document is ready to move out of Android workgroup
- @marcprux will submit it to @platform-steering-group for an initial feedback cycle, and then post it as a pitch to Evolution - Swift Forums
Swift PR testing
- the CI team just added a PR trigger on the main compiler repo only: @swift-ci test android
- we need to roll that out as a mandatory to build but not pass CI for all the corelibs repos, before Android can go Tier 1, according to PSG
- we discussed if we should roll that out with nightly compiler/SDK snapshots or fresh compiler builds, as Windows often does
Adding Android workgroup members
- Android workgroup membership should be expanded with new people, and existing membership should be pruned
- What is the official process? None yet; under discussion in other steering groups
- For the time being, will just invite some people and submit PR against swift-org-website/_data/android-workgroup/members.yml at main · swiftlang/swift-org-website · GitHub as well as request @android-workgroup forums list be upated.
- It would be nice if someone from Google could be invited to join calls and perhaps become workgroup members. @compnerd suggests looking at who is an active member of Rust language workgroups and seeing if they are interested in Swift
Android API 24 and 23 support
- @madsodgaard has gotten PRs necessary for Android API 24 support into main, waiting on cherry-picking PRs for 6.3 branch. Mentions that feedback cycle can be slow.
- Proposed that we add an Android-specific
_FilePointer(or_AndroidFilePointer) typealias to Android module that ease the incompatibility between file pointer types between NDK 23- and 24+. All agreed that would be good
Shared BoringSSL repository
- @compnerd raises concerns about different BoringSSL versions being built everywhere (swift-nio, swift-crypto, Static Linux SDK, Android SDK, maybe more), suggests proposing top-level
swift-toolchain-boringssl. All agreed that this could help keep them all in sync
Options for Android UI
- @gregorio raises issue of no unified UI solution for Android, mentions wasted effort on many different incompatible projects
- @marcprux mentions that we explicitly exclude UI recommendations from the purview of Android workgroup, but says that could change over time
- Ran out of time to discuss topic adequately; deferred to offline discussion and/or next workgroup meeting