The HashLink executable expects hlboot.dat and libraries to be in the current working directory (it's not enough for them to be in the same directory as the executable). Make the .app file launch a shell script that 1) changes the current working directory 2) launches the HashLink executable
This is recommended as a best practice, though AFAIK this only matters
for projects that are going to be imported by other projects.
For instance, you used to be able to include `:deps:extension-api` by
including any extension that depended on it. Now, every project that
wants to use `extension-api` has to include it directly. (Which is fine
because in practice, they all already do so.)
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.
https://developer.android.com/studio/projects/configure-agp-ndk#agp_version_41
The documentation tells you to be careful about this, since you're
putting local-only information into a file that gets uploaded to version
control, but Lime doesn't really need to worry about that.
Granted, Lime DID use local.properties, but that's no longer practical.
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.
This is required by SDL_mfijoystick.m as long as `ENABLE_MFI_RUMBLE` is
defined. And guess what? That's the file that defines it. There's no way
to disable it except decreasing the max iOS version.
Seems like iOS 13 is the new minimum.
Problem one: it requires its own binary, which we haven't built. There
are instructions in sdl/src/hidapi/README.txt, if we ever want to try.
Problem two: the Android app segfaults when `hid_init()` calls
`g_JVM->AttachCurrentThread()`. This might be a bug in NDK 21's jni.h,
but that seems unlikely. Perhaps a version mismatch?
In any case, we aren't using the code at the moment, so the easy answer
is to leave it out.
On Android, `SDL_RWops` no longer stores a plain file descriptor,
so the `AAsset` API must be used instead:
https://developer.android.com/ndk/reference/group/asset
`HAVE_INOTIFY` is required on Linux at the moment, but the bug will be
fixed in the next SDL release.
When building a Lime application in debug mode on Windows, the console
subsystem is used and Windows looks for a 'main' function. However, the
Main.cpp file used when linking statically always defines a 'WinMain'
function regardless of whether the application is being built in debug
mode.
This commit adds an additional check in the Main.cpp that defines a
'main' function instead of 'WinMain' when building in debug mode.
-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.
It took a lot of work to get web workers to work, but web workers finally work!
`transferList` doesn't seem to work, though. It makes the object
inaccessible as expected, but it doesn't seem to affect performance.
This file isn't entirely consistent with the rest of Lime, but it is self-consistent and I think we should keep it that way.
(I fixed a few unrelated lines while I was at it. I know it makes the pull request less tidy, but I wanted to confine simple formatting changes to a single commit.)
