Two reasons:
1. This is how it always worked in practice. The old special case actually did nothing due to an oversight.
2. Per the principle of least astonishment, Lime should avoid messing with the user's assets. If they wanted it to be a template, they would have specified `type="template"`.
The implementation was copy-pasted, so it makes more sense to have only a single copy. `HTML5Platform` added a comment about possible future changes, so I kept that. Future changes will still be possible by overriding the function.
The old code appeared to be trying to do this, but it didn't work. When it found appinfo.json, it would call `copyAsset()` with an extra `context` argument, which is what you do for templates. However, `copyAsset()` only processes templates when `type == TEMPLATE`, otherwise it ignores the extra argument and processes it as a normal asset.
Having eight separate implementations made it harder to maintain. While an asset embedding bug got fixed on desktop targets, it got overlooked on others. This lead to assets being included twice on those other targets: once embedded, and once normally. (#1898) Now, that behavior is controlled from one place, and the bug is fixed for eight targets at once.
This also standardizes the case of `asset.embed == true && asset.type == TEMPLATE`. Previously, some targets would prioritze `embed` over `type`, embedding the template into the app without even processing it as a template. Now, it will always prioritize `type`, processing templates as templates and never trying to embed them.
Three targets are left out since they have more complex asset embedding behavior. I haven't checked if the bug is present on any of those.
Haxe 5 defaults to 1.15, but we're currently still bundling an older version. So we need to specify hl-ver or it won't work properly because Haxe 5 will produce code that older HashLink isn't compatible with.
If hl-ver is already specified, or if a custom HL_PATH is defined, does not set hl-ver because that may be undesirable.
This change moves away from purely hard coding the minimum sdk version for android and also correctly sets the PLATFORM_NUMBER define. The gcc toolchain is no longer compatible in lime 8.3.x+ so, we shouldn't have to worry about the PLATFORM define at all.
It might be wise to enforce a baseline minimum version and complain if users try to use something lower than the default.
Options are default, always, never, and shortEdges. Defaults to default.
What default means depends on which Android SDK version is used.
According to the Android docs, starting with Android SDK 35, most options will be forced to act the same as always. However, for SDK 34 (which is the current minimum on Google Play) this should remain configurable.
https://developer.android.com/develop/ui/views/layout/display-cutout
34 is the minimum required version by Google Play, so it should be default.
Bumping to 34 and 35 requires updating both gradle-version and gradle-plugin-version.
The new versions now require an ndkVersion flag in build.gradle. This can be obtained by reading source.properties in the root of the NDK.
JDK 17 will be required for these updates. Previously required JDK 11.
Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable.
I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths.
As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
* Add Drop file event support for android.
* Updated MIME type configuration and intent filter generation.
* "supportedMimeTypes" => "mimeType"
* `mimeType` -> `accept-file-intent`
The former was unclear about how the dependency would relate to web workers. Would it only be available to workers? Would it automatically spin up a worker?
`allow-web-workers` isn't 100% perfect, but it implies the correct answers to the questions above (no and no) and isn't too long.
