It isn't always safe to assume `./` is the app directory, and removing
that assumption opens up options.
Requires at least Haxe 3.4, but I don't think Lime supports 3.3 anyway.
I can't think of any practical reasons for an Android extension to compile an ndll. All of Android's system functions require Java, not C++, and you can get the speed of C++ just by writing Haxe code.
I surveyed several Android extensions on lib.haxe.org, and not one of them used ndlls when targeting Android.
Otherwise it throws the following error on build:
"Apps targeting Android 12 and higher are required to specify an explicit value for `android:exported` when the corresponding component has an intent filter defined. See https://developer.android.com/guide/topics/manifest/activity-element#exported for details."
To publish apps on Google Play everyone needs to target SDK 31+, which is Android 12+, so this is like a must now.
If "true", the activity is accessible to any app, and is launchable by its exact class name.
If "false", the activity can be launched only by components of the same application, applications with the same user ID, or privileged system components. This is the default value when there are no intent filters.
-lib hxnodejs is no longer included in the compilation of ApplicationMain (but it is still included for compilation of ElectronSetup, of course). hxnodejs was removed from ApplicationMain because it forces some require() calls to be included in the generated .js, which would require disabling certain Electron security features to work properly in newer versions of Electron than we targeted previously. Electron's documentation recommends not to do that.
To use Node.js APIs, you need to run them in more secure contexts, while communicating over IPC with a "preload script" from the "renderer" process. In Lime/OpenFL, this would require a custom ElectronSetup template override, but that shouldn't be all that surprising. See: https://www.electronjs.org/docs/latest/tutorial/process-model for more details on the Electron side.
If the code is loaded via AMD/requirejs:
- we call define() instead of exporting 'lime' globally
- we disable AMD while the embedded libraries are loading, so that they
register themselves in the global scope.
