The wrappers are fairly rote and ought to be non-controversial, and so this is a logical place where the Swift Android community might benefit from collaborating in a single place rather than every project developing their own parochial equivalents.
We would be interested in hearing feedback from various folk that have low-level Android platform integration requirements about whether this package might fit their needs.
I would also like to explore whether a project like this ought to be "promoted" to living in the swiftlang org, or if it is OK to leave it in the unofficial swift-android-sdk collaboration org that we've been using for various Android-related projects.
I’m prototyping a Swift rewrite of a cross-platform (Apple/Android/Linux) C++ codebase, and we’ll definitely be needing something like this for the Android integration. I can’t comment in detail because I’m not an Android developer, but I know our existing code uses a lot of NDK stuff as well as JNI.
If using JNI, I’d recommend GitHub - PureSwift/Android: Swift library for Android · GitHub which is just Swift-Java generated code for the Android SDK. If you just use Native Activity and don’t use JNI itself much, then Swift-Java and swift-android-native should be enough. I’d also recommend taking a look at Skip https://skip.dev for SwiftUI on Android.
When you start using Swift on Android, you inevitably run into a whole set of questions: how to log to logcat, how to get the OS or app version, how to integrate assets, how to obtain the Java VM pointer, how to interact with Android’s main thread, etc.
Having a “reference” library like this is extremely useful. On one hand, it saves you from building your own little homemade setup with JNI and other cool things. But more importantly, it helps you understand what’s possible and find the answers you’re looking for. Just by reading the README here, I’ve already learned things I wish I had known from the start ;-)
Whether it should be part of swiftlang.org or not is open for discussion. But at the very least, we should make sure people know that such a resource exists, just like the examples in swift-android-examples or other key resources, whether they’re official, semi-official or third-party.
Bit late to the discussion, but I think we should have an official package like this.
We'll want to spend time on reviewing and finetuning API if this specific implementation is to stay. I think, like with SwiftNIO, it's hard to do a major once the ecosystem starts depending on it given it's so core for end users.