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.
Turns out, `HTTPRequest`'s call is only needed for internet requests.
Files on the local machine will be loaded directly into `bytes`, leaving
`buffer` empty. Calling `buildBuffer()` will then delete the data.
Pros: It's a standard Haxe feature that other Haxelibs may rely on. Plus
it offers built-in thread safety, unlike `onUpdate`.
Cons: It incurs two `mutex.acquire()` calls per frame.
As noted in pngpriv.h, the alternative (assembly code) doesn't currently
work on arm64.
There's no mention of iOS or tvOS, so maybe we could remove those?
Overriding headers has always been risky, and finally we see why.
Apparently on iOS, files may be compiled in such a way that the original
SDL_config.h file is included, not Lime's custom one. It's hard to do
anything more than we've already done to manage include order, so we
need to find another option.
One such option is to make the two files as similar as possible, such
that it usually doesn't matter which one ends up being included. Then we
only set `USING_GENERATED_CONFIG_H` when it really matters.
SDL_cocoavideo.m now enforces this, as of this commit:
ec8fa57750
That commit also removed the destructors from SDL_render_metal.m, which
implies it's required on iOS too.
And before anyone asks, SDL seems to have no plans to back down on this.
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.
