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'.
If you have a `<section if="cpp">` tag in your project.xml, you don't want it to be active just because a system environment variable happens to be named "cpp". You only want it active if actually targeting C++.
Previously, null was propagated, which could lead to confusing errors from arithmetic operations. Now, it is ignored, and a warning is displayed that says where the invalid value can be found.
This is its only use case, so there's no need for an intermediate step of getting the library root. `haxelib path` does return the NDLL folder; the problem with the old implementation of `__findHaxelib()` was it got Lime's source folder instead.
We could fall back to `haxelib path` for very old versions of Haxelib, but most likely even people stuck on Haxe 3 have updated Haxelib.
Also, `haxelib path` gave incorrect results in the first place, so falling back wouldn't do any good.
The `Asset` constructor sets `asset.id` to the asset's path, a sensible default. Of course, if the asset has a name instead of a path, we have to use that instead. Or if the user specified an ID, that's even better.
We just don't want to default to `""`, since then a bunch of assets could have the same ID.
Resolves#1758.
If you check `paths.exists()` first, then there's no benefit to calling `getPath(id)`: it always just returns `paths.get(id)`. It's more effective to let `getPath()` perform all of its checks.
See pull request for details. Summary:
* Reduce dependencies between CI jobs, allowing more of them to run in parallel.
* Use Linux for as many jobs as possible.
* Merge matching "-ndll" and "-samples" jobs. This way, the latter doesn't have to waste time recreating the former's environment, and the workflow summary is simplified. Downside: this delays package-haxelib.
* Update to a newer macOS version, as the old version massively slowed down Homebrew.
* Skip the HelloWorld test for Mac and iOS, as those two can build slowly under some circumstances, delaying package-haxelib. These could be restored later, if performance seems good enough.
* Add `HAXE_VERSION` environment variable, so future updates will only have to make one change. Unfortunately, doing the same for the Windows/Mac/Linux versions would severely hurt performance, so those remain hard-coded.
* Split up some steps within jobs for better organization.
Fixes the following exception when we don't have permissions:
> Failed to execute 'getGamepads' on 'Navigator': Access to the feature "gamepad" is disallowed by permissions policy.
By catching the exception, it should now behave the same as older browsers, where navigator.getGamepads() doesn't exist at all.
In the future, it might make sense to set a flag if navigator.getGamepads() throws, and skip calling it more than once. However, we may want to listen for some kind of browser event that indicates that permission was granted later, and clear the flag when appropriate. Perhaps the gamepadconnected event?
---------
Co-authored-by: Josh Tynjala <joshtynjala@bowlerhat.dev>
Multiplying `dataLength * 8` produces a high number, which in the case of very long audio files can exceed the integer limit. Multiplying by 8.0 coerces to float, allowing much higher values.
An alternate solution is to divide first and multiply by 8 second, thus keeping the number from getting too large at any point. However, the purpose of the 8 is to convert `dataLength` from bytes to bits, so it's clearer if those two are close together.
Backends now return error and response data, but public API has not changed.
This allows OpenFL to expose URLLoader.data on IOErrorEvent.IO_ERROR to match the behavior of Flash
