It looks like we'll want to take `BackgroundWorker` in a different direction, so for the moment it's safest not to change anything about it. That way, there's only one historical version to maintain backwards compatibility with.
`__activeThreads` and `__idleThreads` only need to be allocated for multi-threaded pools. Plus, there's no benefit to using a `List` here; we only add to and remove from the end.
And finally, checking `event.job == null` instead of `isOfType()` is faster and avoids an issue in HTML5. Sadly it is less safe, so we might need to revisit it eventually.
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.
It turns out that adb isn't included GitHub Actions unless you install it specifically. However, you can technically build Android apps with Lime without adb, so we shouldn't report the error in initialize(). Most important is install(), where both adb and emulator are commonly used.
Followup to eed47e7132
The 'SDK Tools' package located in /tools/ is officially considered 'obsolete', so we should not use it by default.
We now prefer /platform-tools/adb over /tools/adb
We now prefer /emulator/emulator over /tools/emulator
If the newer replacement executables are missing, we still try to fall back to /tools/. This should allow older Android SDKs to continue to work properly.
Additionally, if neither version can be found, we report an error. For adb, we always need it, so we always report an error if it is missing. For emulator, we report an error only if we're actually going to use an emulator.
/tools/android doesn't have a newer alternative. We were running 'android list avds' to get a list of all available AVDs. However, both '/emulator/emulator -list-avds' and '/tools/emulator -list-avds' provide a simple list of AVDs separated by line breaks. So it seems that we never actually needed /tools/android. Plus, it outputs a better format that doesn't require searching every line of the output string for 'Name:', and we can just split and trim. So I completely removed /tools/android and we now use either '/emulator/emulator -list-avds' or '/tools/emulator -list-avds'.
