Questions about GoNativeActivity.java and build.gradle (implementing camera support for Android)

[Gys]

I am trying to implement camera support. For Android this is much harder than expected (also because I have absolutely no knowledge of java).

I read https://fynelabs.com/2024/03/01/running-native-android-code-in-a-fyne-app/ and then some. I more or less have an idea of what JNI is and that is what I use as much as possible. However, it seems JNI only is not enough.

I found two ways to implement camera support for Android.

1. Create an Intent to use the camera and wait for the response.

This seems the easiest option. Does not require user permission, no dependencies and works nicely. Android will pass back the result and I want to store the data in a file which path will be passed back to Go. I got this working, except for the actual saving into the file. That is normally done in the Intent result processing.

My problem:

Processing the result of an Intent needs a modification of GoNativeActivity.java as far as I found. The GoNativeActivity.java has a onActivityResult function which should process the result or at least point back to any JNI code for doing that. This function is also used by Fyne itself for processing Intent results.

I tried modifying GoNativeActivity.java to see if I am correct, but I cannot get changes of it into my app. Even deleting the contents of the file and rebuilding the fyne tool does not matter. I am totally lost here. How does Fyne integrate this file into binaries?

2. Access the camera directly.

This is probably more difficult because permission from the user must be asked. I got some code to access the camera, but it fails because dependencies are needed. Dependencies that normally are added to build.gradle. But there is no build.gradle in the Fyne package?

[andydotxyz]

What you need to know for 1 is that the java is part of the app bootloading and so is not in the main code but actually injected by the packager - after you modify the .java file you have to generate the Android .dex blob which is done by running the generator inside cmd/fyne/internal/mobile/gendex/. Then this change must be compiled into the replacement fyne binary which then should be used to package your app.

For 2 the concept of dependencies is very vague - we'd need to know more. Accessing the camera directly should not require more libraries than opening an intent with a request, as this is all baked into the core Android system.
There is no build.gradle because we use the go dependency system for Go code.

[Gys]

More details for 2:

The Intent opens another app (for example the existing camera app) and therefore does not need any local API drivers (or something) I imagine.

Using the camera starts with:

...
// Get the ProcessCameraProvider instance
jclass processCameraProviderClass = (*env)->FindClass(env, "androidx/camera/lifecycle/ProcessCameraProvider");
jmethodID getInstanceMethod = (*env)->GetStaticMethodID(env, processCameraProviderClass, "getInstance", "(Landroid/content/Context;)Landroidx/camera/lifecycle/ProcessCameraProvider;");
jobject cameraProviderFuture = (*env)->CallStaticObjectMethod(env, processCameraProviderClass, getInstanceMethod, context);
...

The runtime error refers to that driver / API / package:

JNI DETECTED ERROR IN APPLICATION: JNI GetStaticMethodID called with pending exception java.lang.ClassNotFoundException: Didn't find class "androidx.camera.lifecycle.ProcessCameraProvider" on path: DexPathList[[directory "."],nativeLibraryDirectories=[/system/lib, /system_ext/lib, /system/lib, /system_ext/lib]]

From what I found it needs something like this in build.gradle:

dependencies {
    // ...
    implementation 'androidx.camera:camera-core:1.0.0'
    implementation 'androidx.camera:camera-camera2:1.0.0'
    implementation 'androidx.camera:camera-lifecycle:1.0.0'
    // ...
}

[andydotxyz]

Oh the android-x thing. I forgot that they split out into a load of "official extensions".
We should probably find a way to add that into the standard set of supported items. I guess as part of up-streaming it.
As you're using JNI you don't need the API to be present to compile - so as long as the app knows to request it at runtime that should be fine...