Put JNI functions under an interface

[blasten]

Description

Centralize all JNI methods under an interface that doesn't depend on the Android toolchain. This way unit tests can be compiled with the host toolchain.

Related Issues

Fixes flutter/flutter#59031

Tests

I added the following tests: This is about enabling unit tests to be written.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the contributor guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I read and followed the C++, Objective-C, Java style guides for the engine.
• I read the tree hygiene wiki page, which explains my responsibilities.
• I updated/added relevant documentation.
• All existing and new tests are passing.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Did any tests fail when you ran them? Please read handling breaking changes.

• No, no existing tests failed, so this is not a breaking change.
• Yes, this is a breaking change. If not, delete the remainder of this section.
  • I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
  • I got input from the developer relations team, specifically from: Replace with the names of who gave advice
  • I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

[jason-simmons]

Why does this object hold another reference to the same SurfaceTexture held by an AndroidExternalTextureGL instance?

If the goal is to centralize all native->Java calls into one interface, then can the SurfaceTexture reference be passed as an argument instead of duplicating state here?

Or would it make sense to split this into separate JNI wrapper interfaces for FlutterJNI and SurfaceTexture?

[blasten]

The issue is that SurfaceTexture requires the Android toolchain. The idea is that the new interface doesn't require the Android toolchain. I had to downcast jni_facade_ in the constructor, so I can access the method.

Splitting into a separate wrapper is possible if this workaround doesn't look good.

[jason-simmons]

I would prefer moving the SurfaceTexture methods into a separate wrapper

[blasten]

What about we use the texture id (which is int64_t) to lookup the SurfaceTexture in Java? This way, we can keep everything under the same interface. I'm afraid that if we create a separate wrapper, then it may diminish the value of having a centralized interface.

[jason-simmons]

I'm concerned that doing the lookup would add unnecessary overhead to frequently called APIs like UpdateTexImage.

Can the SurfaceTexture JNI invocations and method ID lookups be moved into android_external_texture_gl.cc? That file is already dependent on JNI and OpenGL ES APIs.

[blasten]

What does 19aa4e7 look like?

[jason-simmons]

SGTM - hiding the JNI object reference behind a std::any seems like a reasonable way to go if there is a requirement to make all JNI calls through one interface but that interface can not use JNI types.

[chinmaygarde]

std::any still leads to needing casts in Android code and the loss of readability of the type of the surface texture and its consequences to IDE completions. While there are very real uses of std::any, in this case, it is little more than a glorified raw pointer.

I would much prefer something like the following in a common header.

#if OS_ANDROID
using JavaWeakGlobalRef = fml::jni::JavaObjectWeakGlobalRef;
#else
using JavaWeakGlobalRef = std::nullptr_t;
#endif

This avoid casts, the type is clear and IDE completions all just work.

[blasten]

Done in 8d9d48a

[blasten]

@godofredoc do you know why 6 checks are now canceled (by unknown)?