Expose Flutter Engine address to be used with FFI

[knopp]

Currently, when writing FFI plugins there is no good way to interact with the engine. One options is to write a Flutter plugin, that either stores reference to the engine statically to be used with FFI, or uses platform channels to let the isolate access engine address and then possibly use it through FFI calls. Both of these are problematic, because a) storing reference to engine statically assumes that there's only one engine running b) using platform channels requires asynchronous call to get engine address.

Neither of these workarounds would help us if we want to use FFI inside our embedders, which is something we might want to do in future, i.e. for #150460 or multi-window.

Better solution would be to provide engine handle to the root isolate at startup. Dart code can then pass this value to FFI calls which could then obtain the Flutter engine.

How exactly the engine is obtained depends on the platform.

• iOS, macOS - [FlutterEngine engineForHandle:handle].
• Windows - FlutterDesktopEngineForHandle(handle)
• Linux - fl_engine_for_handle(handle).
• Android - io.flutter.embedding.engine.FlutterEngine.forHandle(handle) (static method).

On dart side this could be accessed from PlatformDispatcher, i.e. PlatformDispatcher.instance.engineHandle. The value would be null for web and custom embedders that don't set the value.

The value would be set through embedder API by the engine and available from isolate start.

[dcharkes]

@HosseinYousefi Would this help with dart-lang/native#1865 (comment) ?

Also @stuartmorgan might have ideas about the interaction between FFI code and the engine.

[HosseinYousefi]

Yes, that's exactly what I need as well!

[stuartmorgan-g]

#110353 has some earlier related discussion, but is focused on the plugin API surface specifically.

There's been some discussion that wasn't captured there about how exactly we would vend things, given that the types are platform-specific. I like this handle proposal; it sidesteps the problems of what types we would use, how we would do generation of shared objects without adding framework dependencies on the *gen packages, and would allow arbitrary embedders to support it by adding a corresponding API to the embedding surface.

[stuartmorgan-g]

Capturing from Discord, Chinmay pointed out that there will be some inherent danger for anyone using this system. E.g., if someone writes a plugin right now against the plugin registry APIs, and then those change, then someone trying to use the plugin with a new version of Flutter will get compilation errors.

If they write equivalent code using FFI generation of the Flutter plugin API surface, getting to the instance via this handle, then if the API surface changes it will instead explode at runtime.

The only way I see to avoid that would be if we did FFI generation as part of the framework, but then we get back to all of the same problems mentioned in my previous comment.

[knopp]

@stuartmorgan, I think the danger mentioned was mostly for my original proposal which would be providing raw engine pointer directly instead of handle. That was probably not the best idea. Using handle instead means that you have to call actual embedder API to get the engine pointer. And if you manage to do that, chances are you are able to call the other engine method safely as well.

Our embedder API is so far has been pretty stable. I would not expect this to change much. Once #163476 and #162935 land (and the new threading model gets enabled by default, which would be the next PR) it should be possible to write a file picker plugin completely in Dart.

[stuartmorgan-g]

Using handle instead means that you have to call actual embedder API to get the engine pointer. And if you manage to do that, chances are you are able to call the other engine method safely as well.

How would one follow from the other? The fact that the static get-engine-from-handle function still exists doesn't mean that the entire public embedding API on that platform is unchanged since the package did FFI generation.

Our embedder API is so far has been pretty stable. I would not expect this to change much.

Sure, but "pretty stable" and formally stable are not the same thing. For plugin-visible APIs in particular we try to be very conservative with breaking changes, because they are potentially very disruptive to the ecosystem, but they do still happen. Android's removal of the v1 embedding APIs, for instance.

Once #163476 and #162935 land (and the new threading model gets enabled by default, which would be the next PR) it should be possible to write a file picker plugin completely in Dart.

And doing so on will (on several platforms) involve a call to a method that we will be deprecating for multi-view support. A native plugin could get deprecation warnings from annotations, and if we do ever remove that deprecated method (unlikely in this particular case, but possible) a native plugin would get a compile-time error. A Dart version, on the other hand, would never get any deprecation warning, and would fail at runtime if we removed the method.

I'm not saying this is a blocker, but it is the case that the Dart version of this code would have pitfalls that the native version does not, and in providing this API we need to recognize that we will be creating new failures modes that will not be obvious to most developers, and we need to consider the consequences.

[HosseinYousefi]

a native plugin would get a compile-time error. A Dart version, on the other hand, would never get any deprecation warning, and would fail at runtime if we removed the method.

We should maintain and ship the generated bindings for Flutter APIs either as a separate package or as part of the SDK to avoid this problem. The *gen tools could generate @Deprecated from the native annotations as well.

[knopp]

Well, yes, that is a downside with FFI and something to keep in mind. Fortunately the API surface is not huge. And for plugins written completely in Dart we would probably want to have official Dart bindings for engine.

[stuartmorgan-g]

We should maintain and ship the generated bindings for Flutter APIs either as a separate package or as part of the SDK to avoid this problem.

That creates a different set of problems, because either way it requires the SDK to exactly pin any dependencies (jni, objective_c, etc.)

[knopp]

We should maintain and ship the generated bindings for Flutter APIs either as a separate package or as part of the SDK to avoid this problem.

That creates a different set of problems, because either way it requires the SDK to exactly pin any dependencies (jni, objective_c, etc.)

I'm not sure I understand why shipping a flutter engine bindings package separately would require the SDK to have dependencies to jni/objective_c?

[HosseinYousefi]

That creates a different set of problems, because either way it requires the SDK to exactly pin any dependencies (jni, objective_c, etc.)

We could expose a dart:ffi type like Pointer<Void> in the framework. The package can have a FlutterEngine flutterEngineFromPointer(Pointer<Void> ptr).

[stuartmorgan-g]

I'm not sure I understand why shipping a flutter engine bindings package separately would require the SDK to have dependencies to jni/objective_c?

Whether it's technically a separate package or not is basically irrelevant here. Packages cannot have upper bounds on the Flutter SDK, so a Flutter-team-maintained bindings package only addresses the stability problem if the Flutter SDK depends on, and pins the exact version of, that package. Otherwise we just move the stability problem from one package to another.

We could expose a dart:ffi type like Pointer<Void> in the framework. The package can have a FlutterEngine flutterEngineFromPointer(Pointer<Void> ptr).

That doesn't address the issue I'm talking about. Any package that uses FFI generation from the non-stable Flutter embedding APIs is, inherently, tied to that version of Flutter (or a compatible version, which we can't predict in advance). Either we enforce that tie, which can only be done with a dependency from the SDK, or we don't in which case a breaking change to the embedding API looks like one of the following

We follow semver in the bindings packages:

1. We regenerate the bindings, which causes breaking changes to the dart version.
2. We release a new major version of the bindings package.
3. No users get it, because all the plugin-like packages using the bindings package have a version constraint that wouldn't allow it.
4. Users get runtime exceptions with new versions of Flutter, exactly as if we had not done the bindings package at all and the individual packages did it instead.

We don't follow semver in the bindings packages:

1. We regenerate the bindings, which causes breaking changes to the dart version.
2. We release a new minor version, in violation of semver.
3. Some users get it and some don't, depending on whether they update all their transitive dependencies
4. Some users get Dart compilation errors, some users get runtime exceptions, so now there are two different failure modes for the same problem and people get even more confused.
   • Some package developers may not understand that not following semver was deliberate and decide to avoid our "mistake" in the future by pinning the bindings package, taking us to a worse version of the semver flow (worse because we can't even reliably get non-breaking changes out to people).

[knopp]

I see. How much of an issue is this in practice though? The biggest change coming is multiwindow, where we're going to add API to get a FlutterView from the engine by viewId. However the original method that assumes single view will still be implemented, return a valid result and possibly print a warning message about being deprecated.

The API surface we need to expose to plugins is pretty small (get engine, get view by Id, and possibly get texture registry). I don't see much potential for major braking changes, at least not in a way where we couldn't maintain compatibility while providing deprecation warnings at least at runtime).

[HosseinYousefi]

Packages cannot have upper bounds on the Flutter SDK

OK, this explains it.

[stuartmorgan-g]

I see. How much of an issue is this in practice though?

Hard to say. I don't expect it to be common certainly, but I don't know how much more disruptive it will be when it does happen due to the failure mode being harder to understand. The compile-time version of this kind of thing is very easy to find matching errors for, for instance, while I expect the runtime version to be much more opaque to the vast majority of developers.

The biggest change coming is multiwindow, where we're going to add API to get a FlutterView from the engine by viewId. However the original method that assumes single view will still be implemented, return a valid result and possibly print a warning message about being deprecated.

Only because this conversation is happening after the Android v1 embedding change, where we had to remove symbols. I'm not saying these things are common, but we have a recent example of a worst-case kind of change happening, so I don't think we should assume they will never happen again.

The API surface we need to expose to plugins is pretty small (get engine, get view by Id, and possibly get texture registry).

If we provide official bindings packages and steer people very strongly toward using them, then the surface is as small as the plugin API surface (which is definitely bigger than what you listed; there are a ton of delegation methods on iOS, activity lifecycle and activity handler result callbacks on Android, etc.)

If we don't, and most developers are doing their own FFI generation, then the effective surface will be the entire embedding API surface, because nothing will indicate to anyone that it shouldn't be.

[knopp]

There are some things (life cycle, platform views) that require writing an actual plugin currently. I don't think we'll be able to implement those in pure dart for a while (and without same changes in the architecture). But there is quite a bit of utility that can be obtained, especially on desktop, with modest API and hopefully reasonably small potential for breaking.

More importantly, getting the engine pointer from FFI is something that's already possible and being done, just with tradeoffs where it either requres asynchronous API or fails with multiple engines.

[dcharkes]

The effective surface will be the entire embedding API surface, because nothing will indicate to anyone that it shouldn't be.

We have addressed this issue in Dart with having dart_api_dl.h which is a subset of dart_api.h. We could take a similar approach for a curated subset for Flutter.

We should maintain and ship the generated bindings for Flutter APIs either as a separate package or as part of the SDK to avoid this problem.

That creates a different set of problems, because either way it requires the SDK to exactly pin any dependencies (jni, objective_c, etc.)

Our thinking for the Dart C API is to ship it as an SDK package (so pinned). dart-lang/native#839 (comment) This package should both have the Dart generated bindings, the C header file, and a version file (dart_version.h).

The failure mode for users using the Dart API should be a Dart compilation error on a breaking change.

The failure mode for users using the C API and the native assets feature depends on what the build hook does:

1. The build hook builds from source: This should lead C compilation error.
2. The build hook downloads a prebuilt binary. In this case the hook should check the dart_version.h to see if it's compatible and otherwise fail. (Omitting to check this in the build would lead to runtime failures.)

I believe ordinary plugins (not using the native assets feature) should also have compilation errors. Is there a case I'm overlooking?

Otherwise we just move the stability problem from one package to another.

I am not sure I understand this. Do you mean that the stability issue shows up as a compile-time error rather than resolution forcing the right version? But pinning package:jni would simply move the compile-time error between the user code and package:jni?

Or do you mean something else?

@jonasfj Has proposed being able specify package incompatibilities after the fact between an SDK and a package if the SDK introduced a breaking change. That would move the compile-time error to a pub resolution error for packages that we own and know are incompatible. (Basically adding a Flutter or Dart SDK upper bound to a package after the fact.)

[stuartmorgan-g]

More importantly, getting the engine pointer from FFI is something that's already possible and being done, just with tradeoffs

It is, but the step from "it is possible" to "we actively encourage it by creating an API just to do that thing" is an important one in terms of what expectations we are setting, and how much responsibility we have to guide people away from pitfalls that the new API might otherwise encourage.

[stuartmorgan-g]

I am not sure I understand this. Do you mean that the stability issue shows up as a compile-time error rather than resolution forcing the right version?

I'm not sure what this question means exactly, given that it's at the end of your description of a proposal to use a pinned package, and the context of the quote you are asking about is that I was explaining why an unpinned package would be problematic.

To summarize my position again:

• If it's in a separate package and that package is not pinned by the SDK in some way, I do not believe it solves any stability problems.
• If it's pinned by the Flutter SDK in some way, then by Flutter policy it would also pin all transitive dependencies. Which would include things like objective_c.

[knopp]

It is, but the step from "it is possible" to "we actively encourage it by creating an API just to do that thing" is an important one in terms of what expectations we are setting, and how much responsibility we have to guide people away from pitfalls that the new API might otherwise encourage.

Right, counterpoint to that is that if somebody can figure out how to call native methods on engine through FFI, they will likely also figure out how to get engine instance, just in a less robust way than what we can provide. So you end up with plugins that fail with multiple engines for example (like package:jni right now).

[stuartmorgan-g]

@jonasf Has proposed being able specify package incompatibilities after the fact between an SDK and a package if the SDK introduced a breaking change. That would move the compile-time error to a pub resolution error for packages that we own and know are incompatible. (Basically adding a Flutter or Dart SDK upper bound to a package after the fact.)

I have requested this in the past, but I haven't seen any indication that it's likely to happen in the foreseeable future; unless that changes we can't plan around it.

[stuartmorgan-g]

just in a less robust way than what we can provide. So you end up with plugins that fail with multiple engines for example

I don't see this as a counterpoint, personally. Making something work better will encourage use relative to the status quo, just as making it easier will encourage use.

[knopp]

I don't see this as a counterpoint, personally. Making something work better will encourage use relative to the status quo, just as making it easier will encourage use.

The way I see it - it's a hypothetical problem (we might break the subset of engine API used in FFI plugins in future in a way where we can't provide backwards compatibility or build failure) versus an actual problem (plugins built against package:jni won't work with multiple engines).

In any case, it seems that this

@jonasf Has proposed being able specify package incompatibilities after the fact between an SDK and a package if the SDK introduced a breaking change. That would move the compile-time error to a pub resolution error for packages that we own and know are incompatible. (Basically adding a Flutter or Dart SDK upper bound to a package after the fact.)

would solve the issue? If, with bit of luck, it happens before the API break.

[dcharkes]

Thanks for the clarification @stuartmorgan!

• If it's in a separate package and that package is not pinned by the SDK in some way, I do not believe it solves any stability problems.

Unpinned could be a working model if we have have the retroactive package incompatibilities feature on pub.

• If it's pinned by the Flutter SDK in some way, then by Flutter policy it would also pin all transitive dependencies. Which would include things like objective_c.

I am not sure I understand this. Wouldn't package:objective_c and package:jni depend on package:flutter_c_api instead of the other way around?

[HosseinYousefi]

I am not sure I understand this. Wouldn't package:objective_c and package:jni depend on package:flutter_c_api instead of the other way around?

I think this is in the case where we choose to expose say a FlutterEngine extends JObject directly from the Flutter SDK or the package.

Edit: I read the original comment again. Yeah, if we're not exposing jni/objc types then there is no need to have dependencies to the packages, we just use dart:ffi types as I alluded to in my comment.

[HosseinYousefi]

So you end up with plugins that fail with multiple engines for example (like package:jni right now).

Before you opening this issue, I planned to have a map from isolate group ids to contexts since each engine will create a different isolate group but it seems like we don't have a Dart_CurrentIsolateGroupDL (although we have Dart_CurrentIsolateGroup)

[knopp]

each engine will create a different isolate group.

Is that the case? I assumed FlutterEngine.spawn will create new engine belonging to same isolate group.

In any case, when the plugin is initialized the isolate is not running (thread local is not set), is it? So I'm not sure how you'd pair to either isolate or isolate group.

[HosseinYousefi]

each engine will create a different isolate group.

Is that the case? I assumed FlutterEngine.spawn will create new engine belonging to same isolate group.

I thought that was the case. Not super familiar with Flutter engine, so you are likely right.

In any case, when the plugin is initialized the isolate is not running (thread local is not set), is it? So I'm not sure how you'd pair to either isolate or isolate group.

Good point. So it seems that we really need the Flutter engine address.

[stuartmorgan-g]

Wouldn't package:objective_c and package:jni depend on package:flutter_c_api instead of the other way around?

You were talking about the Dart C API in your comment. Almost all of the previous discussion in this issue, including the original issue description and including the comment of mine that you pulled out in the first place, is about the Flutter embedding APIs (not embedder.h, the low-level API used to build embeddings, which Flutter app developers should not use). The Flutter iOS and macOS embedding APIs are Obj-C. Android's embedding API is Java. A hypothetical package that provided FFI wrappers for them to address stability concerns—which, again, is what what the discussion that you pulled my comment from was about—would be wrapping Obj-C and Java types.

If you take my comments about a proposal to make packages to wrap Obj-C and Java API surfaces, and place them out of context in a different discussion about wrapping a pure C API, then yes, they don't make sense.

Yeah, if we're not exposing jni/objc types then there is no need to have dependencies to the packages

Let's make this concrete. This and this comprise the macOS embedding API surface, including FlutterEngine.

This comment suggests having third-party package developers calling those APIs from Dart, in their packages.

I pointed out that this would be somewhat dangerous, because they would be shipping generated code for an API surface that is not fully stable, and that resulting failures would be runtime (vs. the traditional plugin model, where the failures are compile time).

This comment proposed that the solution to that could be that "We should maintain and ship the generated bindings for Flutter APIs either as a separate package or as part of the SDK".

An example of a Flutter API that we would need to expose in the proposed Flutter-team-maintained bindings package in order to enable the example of a Dart-only file picker package while solving the runtime stability concern is this method, which returns an NSView. How would that work without exposing any Obj-C types?

[stuartmorgan-g]

The way I see it - it's a hypothetical problem (we might break the subset of engine API used in FFI plugins in future in a way where we can't provide backwards compatibility or build failure) versus an actual problem (plugins built against package:jni won't work with multiple engines).

I don't agree that that's an accurate description of the actual problem. As you said in the initial issue description: "One options is to write a Flutter plugin, that [...] uses platform channels to let the isolate access engine address and then possibly use it through FFI calls." I have built a plugin that does that; it works fine.

I would say that the problem you are trying to solve is that it is currently not possible to build a package that is multi-engine aware using only Dart, and only synchronous calls. It would be nice to enable that, but that's very different than "plugins won't work". And when we are talking about adding APIs to enable new functionality, we need to consider the downsides of the functionality we are creating.

ETA: Since I feel like we're going around in circles on this bit, let me reframe my view on this as a question: what is the use case (not approach to writing plugins, but actual app client user journey) that cannot be addressed with the current technology, and is so time critical that we cannot spend more than a couple of days discussing entirely foreseeable, long term implications of adding this new API--and how we might mitigate them--before landing this?

[knopp]

I don't think I quite get the point. Everything this proposal describes is possible today, is already done today, but with the cost of requiring asynchronous call, which objectively makes the resulting API worse. All the downsides that you are describing already exist. The only change here is a net benefit - allowing to provide synchronous API and not relying on a plugin to capture engine instance.

Yes, if we make this more convenient, chances are more people will use it, but if we don't, people will do it anyway, just badly (like assuming a single engine).

This is not to say that it's not worth addressing the downsides that you are describing.

but that's very different than "plugins won't work"

To fix package:jni without this proposal would require making a breaking change and would make the API objectively worse.

Also writing dart-only plugins was an example. It's not the only purpose of the proposal, or even a primary one for us. For example I'm currently working on an experimental multi-window support in the macOS embedder that does not rely on platform channels. And there are other parts of embedder that would greatly benefit from moving away from platform channels. Though for this usecase the [FlutterEngine engineForId:] might as well be private.

[stuartmorgan-g]

Yes, if we make this more convenient, chances are more people will use it, but if we don't, people will do it anyway, just badly (like assuming a single engine).

Or, if we don't, the vast majority of people will continue to use the technology that we have had for years and that we currently recommend, and which doesn't have that problem. Meanwhile, we spend some time considering what the actual developer journey we want to encourage is, and what else me may need to build in order to have that in place so that when people start using the new thing, they are using it in a way that we think will be good for the long-term health of the ecosystem.

I have a responsibility to consider the long-term impacts of new APIs we expose for the express use of package developers. You don't appear to consider the difference between "sort of possible" and "actively supported and encouraged by the SDK developers" to be a critical one, but I do, and I'm not going to rush approval of a new public API.

To fix package:jni without this proposal would require making a breaking change and would make the API objectively worse.

I'm not sure what this is referring to; could you link to the issue you are talking about?

Though for this usecase the [FlutterEngine engineForId:] might as well be private.

I'm fine with a private version of this landing while we consider the bigger picture of what exposing it publicly should look like.

[knopp]

I'm not sure what this is referring to; could you link to the issue you are talking about?

This is the issue. dart-lang/native#1865

The only way to fix it right now (I can think of) would be to make getApplicationContext() async, which would have a downstream effect, i.e. breaking cronet_http, which would need to make the build method async, which in turn would mean it can no longer be used in HttpClientFactory.

[HosseinYousefi]

For the jni issue, it's also enough if we expose a unique ID for the engine as well (so it's not even a pointer that has access to the engine and no concerns with regards to the API breaking, etc). This way I can keep a map from the engine ID to the respective Context.

[dcharkes]

the Flutter embedding APIs (not embedder.h, the low-level API used to build embeddings, which Flutter app developers should not use). The Flutter iOS and macOS embedding APIs are Obj-C. Android's embedding API is Java.

I see, I wrongly applied my Dart C API knowledge where the API to build embedders is a superset of APIs developers can use with FFI. And in Dart these APIs are C only, no other languages, so they work with dart:ffi.

The Flutter iOS and macOS embedding APIs are Obj-C. Android's embedding API is Java.

Right, so using JNIgen and FFIgen to generate bindings for these will create a dependency on package:jni an package:objective_c. And this is what you want to achieve with #110353.

I pointed out that this would be somewhat dangerous, because they would be shipping generated code for an API surface that is not fully stable, and that resulting failures would be runtime (vs. the traditional plugin model, where the failures are compile time).

Let me see if I understand this correctly. The failures show up at runtime because if you remove a method the dlsym or "lookup method" will fail.

Pinning the package:flutter_api would make that a compile-time error (because you'd get the new Dart API in a new SDK), but would also require pinning package:jni and package:objective_c. Both these packages are experimental and doing breaking changes, so we can only consider this once these packages become stable.

After discussing dart-lang/native#1865 with @HosseinYousefi, it seems that if we a solution for #110353, access to the Context should be in that place, and should be removed from package:jni. This would solve dart-lang/native#1865.

However, postponing a solution until package:jni and package:objective_c become stable would be unfortunate.

I wonder if we shouldn't consider providing some stability guarantees/versioning for the Java/ObjC APIs. Like Apple does with their version constraints on OS APIs and sqlite does. Plus a runtime version method. That seems to be the default way of dealing with version skew between bindings an API. As @stuartmorgan points out this leads to runtime failures. Be it really infrequent for sqlite or Apple APIs, so maybe it's unlikely as @knopp points out. (Edit: avoiding runtime failures is essentially what things like the minimum NDK version does. So having a Flutter Pluggin API version would be a good thing.)

An alternative solution only for dart-lang/native#1865 is to have Flutter provide a C API that gives an engine ID (not even a pointer that you can interact with). Then we could track the context per engine. (Having a C API avoids having to have a dependency on package:jni. dart:ffi is stable while package:jni is not yet.)

[knopp]

For Android, we could make FlutterEngine.engineForId package private for the time being, and instead expose getEngineId(), which would be the same Id as you get in PlatformDispatcher.instance.engineId. That way we could match the Id of initial engine provided to the plugin with the one called from dart code, without providing access to the engine itself.

[stuartmorgan-g]

This is the issue. dart-lang/native#1865

I see; that's very unfortunate.

The only way to fix it right now (I can think of) would be to make getApplicationContext() async, which would have a downstream effect, i.e. breaking cronet_http, which would need to make the build method async, which in turn would mean it can no longer be used in HttpClientFactory.

It seems like taking something that was possible before (writing a plugin shim, incorrectly assuming the plugin was a singleton, and exposing an API based on that), but packaging it into an easy-to-use, officially (quasi-)endorsed public API had problematic long-term effects that are difficult to unwind 😉

[stuartmorgan-g]

I wonder if we shouldn't consider providing some stability guarantees/versioning for the Java/ObjC APIs. Like Apple does with their version constraints on OS APIs

Apple doesn't solve the problem we're discussion here with versioning (which only works backwards, not forwards), they solve it by essentially never removing anything. They just deprecate things and leave them around until some major break point allows them to do some cleanup (e.g., Carbon was kept in zombie mode for many years, and only "removed" in that they didn't allow linking against it in 64-bit apps.)

We could do that, but it would be a policy change that would require a design document and sign off from leadership across the org. That policy would have prevented the recent Android v1 embedder cleanup, which the engine team felt very strongly was critical.

[HosseinYousefi]

It seems like taking something that was possible before (writing a plugin shim, incorrectly assuming the plugin was a singleton, and exposing an API based on that), but packaging it into an easy-to-use, officially (quasi-)endorsed public API had problematic long-term effects that are difficult to unwind 😉

Unfortunately somehow this was one of the first things written into package:jni three years ago and no issue was reported about it until a month ago.

For Android, we could make FlutterEngine.engineForId package private for the time being, and instead expose getEngineId(), which would be the same Id as you get in PlatformDispatcher.instance.engineId. That way we could match the Id of initial engine provided to the plugin with the one called from dart code, without providing access to the engine itself.

In order for package:jni not to have a dependency on Flutter (so it can be used in Dart-standalone as well), we either have to get an integer engineId argument for our context getter, or move it to another package:flutter_jni that depends on flutter and uses PlatformDispatcher.instance.engineId.

[knopp]

In order for package:jni not to have a dependency on Flutter (so it can be used in Dart-standalone as well), we either have to get an integer engineId argument for our context getter, or move it to another package:flutter_jni that depends on flutter and uses PlatformDispatcher.instance.engineId.

Context getter requires Flutter plugin, and would thus imply Flutter dependency, no? What exactly is the use case for removing dependency on Flutter?

[HosseinYousefi]

In order for package:jni not to have a dependency on Flutter (so it can be used in Dart-standalone as well), we either have to get an integer engineId argument for our context getter, or move it to another package:flutter_jni that depends on flutter and uses PlatformDispatcher.instance.engineId.

Context getter requires Flutter plugin, and would thus imply Flutter dependency, no? What exactly is the use case for removing dependency on Flutter?

Calling it in Dart-standalone could return null instead. The use case is using package:jni in Dart-standalone, for example on desktop. In general it's good to move the context getter and all the other Flutter-specific APIs to a separate package: dart-lang/native#1023

Right now the fact that jni doesn't actually depend on any APIs from the Flutter framework means that you can technically still use it in a Dart-standalone application as long as you don't call Flutter specific stuff like the context getter. This is not an ideal design though, hence the issue to separate the packages.

[knopp]

My point is why having getApplicationContext() in package:jni at all, why not just move it to flutter_jni.

[HosseinYousefi]

My point is why having getApplicationContext() in package:jni at all, why not just move it to flutter_jni.

Yeah that's what I tried to say. We should move it to flutter_jni.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.