Just coming in early to comment on the name. Can we s/SplitAot/DeferredFeature or DeferredModule here and elsewhere in docs and instructions etc? Since "split AOT" is a strict subset of what we're really shipping.

do you need to change this too?

if you create circular connections, best to break them yourself. Especially when there are singletons like JNI involved.

though you can check the completion of that call by just waiting for that future itself no? Explain why they need this

This is for displaying things like loading bars, status messages, etc. The status here is purely informational and is not necessary for function. I'll add that to the docs.

I thought you added somewhere the redundancy with loadLibrary. Best be explicit about the web that exists everywhere. i.e. if you installDynamicFeature, you don't really have to check this or listen or the channel, if you listen on the channel, you don't really have to wait for the loadLibrary future, if you loadLibrary, it's the same as installDynamicFeature with loading unit etc, and fully create the web and cross reference everything to everything.

i.e. we don't want users guessing there's 3-4 APIs that can more or less do the same thing. What am I missing out if I just use 1 and don't use all of them.

to make sure I understand, this is purely optional right? i.e. if a user calls loadLibrary in Dart (which ultimately leads here), they can just await that call instead of listening to this right?

Yes, the methodChannel lives in parallel with the loadLibrary() code path. Since assets only modules do not have any library to load off of, this manual methodChannel way mirrors the functionality but allows specifying the moduleName directly. The channel accepts a loadingUnitId and a moduleName, but in the dart-side wrapper API I plan on exposing will restrict this to just taking a moduleName for now. The full loadingUnitId+moduleName API can be exposed in the future if/when dart allows initiating a loading unit load directly by loading unit id without a matching dart library loadLibrary() call.

maybe just do if feature manager is not null, set channel to null in the if below? So we don't have to create a new channel destroy pattern.

We're also telling implementers to now take this and do stuff with it right? Describe what's expected to be sent when on this channel if you subclass.

I thought you added somewhere the redundancy with loadLibrary. Best be explicit about the web that exists everywhere. i.e. if you installDynamicFeature, you don't really have to check this or listen or the channel, if you listen on the channel, you don't really have to wait for the loadLibrary future, if you loadLibrary, it's the same as installDynamicFeature with loading unit etc, and fully create the web and cross reference everything to everything.

i.e. we don't want users guessing there's 3-4 APIs that can more or less do the same thing. What am I missing out if I just use 1 and don't use all of them.

This is probably a more prominent error right? If they look up something that don't exist, don't silently fail.