Add image attachments support using the Android NDK

[grynspan]

This issue tracks adding the equivalent of AttachableAsCGImage when using the Android NDK.

We can likely use the C function AndroidBitmap_compress() but Android's native image type, android.graphics.Bitmap, is a Java class and is only surfaced to Swift as jobject (if at all.) We will probably want to work with the swift-java maintainers here.

[grynspan]

I discussed this a bit with @ktoso and I think this might be a viable plan once the Android toolchain/SDK are more fully realized:

• We expose Attachable API surfaces that take a jobject and the current thread's JNIEnv
• The implementation calls GetObjectClass() and IsAssignableFrom() to validate that the object is an instance of android.graphics.Bitmap
• The implementation calls AndroidBitmap_lockPixels() and AndroidBitmap_compress() to serialize the bitmap

Bonus points if we're able to link to swift-java and if the Android toolchain/SDK includes projections of the various classes from the official Android SDK (like https://github.com/PureSwift/Android, but officially supported), because then we can just take a JavaObject<AndroidGraphicsBitmap> instead of a jobject.

jobject is defined in Android's jni.h as void *, so without additional compiler-side magic it will be imported into Swift as UnsafeMutableRawPointer which is unfortunate; being able to use swift-java here would be better for type safety.

[grynspan]

@finagolfin I suspect this is of interest to you, by the way. 😄

[marcprux]

The way we are currently running tests with the Swift Android SDK is to build the XCTest executable in the same way as Linux, then copy it over to the device and run it with the adb shell run command. This is sufficient for Linux-style Swift package testing, but it isn't going to work once the Android Java SDK needs to be interacted with. There is no ambient JNI environment available to command-line programs, and so the whole of the Android SDK is inaccessible, which includes those parts of the NDK that need initialization via a jobject pointing to some SDK peer class. This impacts many components of the NDK, making them effectively un-testable via Swift testing.

This is an issue we've mused about in the Android Workgroup, but we don't yet have a clear plan. I expect we will need to build the tests as a shared object library (which I raised in the forums a few months ago), generate a test harness app, and then package up the tests in a full-blown Android apk and then launch that as an instrumented test process and then read and handle the results somehow.

So in short, this is going to be a bigger project than just getting a pointer to a JNIEnv.

[finagolfin]

I don't think it's too bad: we can reuse @andriydruk's pure Swift Android sample app as a test app and use it to load both XCTest and libTesting test entry points, then run all the tests we want before exiting. As I mentioned in a couple prior Android workgroup meetings, I have successfully used this approach to run large AOT-compiled native code test suites in the Android app environment, which has slight differences to the CLI environment in addition to the lack of JNI you mention, long before I started using Swift 7 years ago.

However, I was only interested then in testing AoT-compiled non-Swift code and only tested the JNI interop to make sure it worked, but did not exercise JNI much. Obviously, we'll need to exercise JNI much more going forward for our swift-java interop testing, but I suspect the same apk approach I previously used will work well and easily for that. Since I have experience with that apk testing, I will help get that set up, once we have official Swift Android SDK bundle snapshots released.

[marcprux]

Yes, this is more-or-less what Skip is currently doing with our testing support (e.g., see https://github.com/skiptools/skip-integ-demo and https://github.com/skiptools/skip-integ-demo/blob/main/Tests/SkipIntegDemoTests/SkipIntegDemoTests.swift for a demo project that will run JNI-capable tests against the Android emulator in a "real" app environment).

I just wanted to point out that there is going to be more to the effort than simply grabbing the JNIEnv, since unless the testing is taking place in a real Zygote, it won't exist.

[finagolfin]

OK, great that you already got the Swift test apk working, 😺 and I defer to you on setting up the JNI environment fully, as I haven't explored that as much.

[grynspan]

I'll point out that if there's no Java VM, then there's no jobject to pass to Attachment.record() either!

[marcprux]

OK, great that you already got the Swift test apk working, 😺 and I defer to you on setting up the JNI environment fully, as I haven't explored that as much.

Well, it's all pretty tied in with Skip's tooling currently, and teasing them apart is a big task. The first biggest issue is that Skip's JNI infrastructure pre-dates the swift-java project, so getting those two harmonized is likely going to be a prerequisite.

I raised this back in March and we've chatted with @ktoso about it, but now that @madsodgaard's GSoC JNI project has wrapped up and we are (hopefully!) on the verge of an official Swift 6.2 Android SDK release, I'll try to carve out some time to make a concrete proposal about how we can get everyone working together under the same JNI umbrella.