createExtensionContext throws Error #2113 for every extension ID, including ones that work

[JohnBoroda]

We are trying to add a very small ANE to an existing app and cannot get a context
for it. The failure turned out not to be specific to our extension, which is why
we are asking rather than filing a bug.

Environment

• AIR SDK 51.3.3.2
• Device: vivo V2514, Android 16 (API 36)
• App: targetSdk 35, minSdk 21, arm64, packaged with -target apk-debug
• The app already ships 37 ANEs (distriqt, AppsFlyer, AndroidX/Play dependency
  extensions, and so on)

What we built

A minimal extension with one Java class that calls
getWindow().setSoftInputMode(...), packaged with
adt -package -target ane for Android-ARM64, Android-ARM and default.

Symptom

ExtensionContext.createExtensionContext("ru.pragmatix.wormix.softinputmode", null)

Error #2113: Provided parameter LoaderContext.SecurityDomain is from a disallowed domain.

What makes this odd

From the same call site, the same call also fails for extensions that
demonstrably work in this very build:

• com.mesmotronic.ane.fullscreen → #2113
• com.distriqt.Application → #2113

The second one is the interesting case: distriqt's own ActionScript wrapper had
created a context for exactly that extension roughly 2 ms earlier in the same
call stack, successfully — its native side logs
DeviceController::startGeneratingDeviceOrientationEvents() right before our
attempt fails. So the extension is loaded and usable; our call for the same ID
is refused.

What we verified about our own extension

• it is packaged: assets/META-INF/AIR/extensions/<id>/META-INF/ANE/Android-ARM64/library.swf
• its five Java classes are present in classes*.dex
• the runtime unpacks it on the device next to the other 37 extensions, with the
  same layout (extension.xml + Android-ARM64/library.swf)

What we ruled out

• SWF version of library.swf: tried 51 and 44 (distriqt ships 44)
• debug information: rebuilt the SWC with -debug=false
• an XML comment before the root element of extension.xml
• FileAttributes sandbox flags — identical (0x19) in our library.swf, in
  the working extensions and in the main SWF
• contextType: both null and ""
• timing: the call is retried every 20 frames for minutes after startup, always
  with the same result

Our question

The one structural difference we are aware of is that our ActionScript wrapper is
compiled into the main SWF instead of coming from the extension's own SWC — we
create the context by ID and never link against the ANE's SWC, to avoid adding it
to our Maven repository.

Is that the problem? Must createExtensionContext be called from code that the
runtime loaded out of the extension's library.swf, and is #2113 how that
restriction surfaces? If so, is there a supported way to keep the wrapper in the
application, or is linking the extension's SWC as an external library the only
option?

For transparency: this was investigated with the help of an AI coding assistant.
All of the above was reproduced on the physical device listed.

[ajwfrost]

Hi

The one structural difference we are aware of is that our ActionScript wrapper is
compiled into the main SWF instead of coming from the extension's own SWC

Can I check that you mean that the "library.swf" that's within the extension is actually compiled into your main SWF already? So that when the extension is loaded, it will try to load the library.swf but will encounter a bunch of definitions that already exist?

And then presumably you are calling the createExtensionContext from within the main SWF file rather than this being run from within the library.swf context?

I think that this is likely to be the culprit; we can run a few tests to confirm this.. but I had always wondered why there is this requirement for an intermediate layer to be loaded in, and cannot really see why it should not be possible to have an ANE that doesn't have the ActionScript wrapper classes put into a library.swf. So we might at the same time have a look at updating this requirement..

For now -> I suspect if you're able to refactor your build so that it doesn't include those definitions directly but has the SWC as an external library, it should resolve the issue..

thanks