Support standalone target without requiring Flutter SDK

[mahesh-hegde]

Status Quo:

Flutter SDK is needed even if we are using dart command only - due to the way package:jni is packaged.

In theory it is possible to comment out flutter-specific parts and use the same module from standalone and flutter targets. But due to problems with pub, we are not able to do it. pub#3563.

There are 2 parts where we need the flutter features.

• The initialization plugin: JniPlugin.Java, android only.
• FFI asset bundling: ffiPlugin: true directive, all flutter targets.

Proposed Design:

There should be 2 packages, package:jni and package:flutter_jni_interface

The latter doesn't need to be touched by user code, apart from being included in pubspec. Latter being a flutter-specific plugin, it handles initializing android JNI behind the scenes, or packaging the DLL.

Open questions:

• This doesn't probably solve the FFI plugin packaging problem. - Because as I am aware, ffiPlugin expects native code at src/.
  • Can flutter_jni_interface be nested in package:jni? This will change latter's native source path to flutter_jni_interface/src. But only our setup scripts need to be changed to accommodate this.

Disadvantages:

• Flutter users will have to add 2 packages instead of 1.

cc: @dcharkes

[dcharkes]

The packaging issue will be solved by:

• ☂️ [vm/ffi] Build hooks & Code assets sdk#50565

When the packaging issue is solved, can we suffice with a Dart-only implementation? Or are we hooking into some Flutter specific things in Java/Kotlin code for some registering the JVM on startup?

[mahesh-hegde]

(replying from email really messes up markup)

are we hooking into some Flutter specific things in Java/Kotlin code for some registering the JVM on startup

Yes. We have to load the native library from JniPlugin.java and register JVM, application context etc..

Assuming the ffiPlugin requirement is resolved, we might be able to split the library into two parts, but in a different way.

• package:jni
• package: android_jni_interface (android plugin).

This has the tradeoff of enabling standalone SDK, but projects targetting android need to add both dependencies.

[HosseinYousefi]

This is a good idea, however it's not a priority for now. The number one use case of package:jni is going to be for Flutter Android.

[dcharkes]

Note from discussion with @HosseinYousefi:

We also have Java code in package:jni, so converting that to use native assets and making it a non-Flutter package will break the Java code on Flutter. In order to make Java code work in Dart standalone and Flutter, build.dart needs to report jars or Java source code and Flutter will need to pick that up. So the first version of native assets will not enable using it in package:jni now that package:jni has Java code (PortProxy).