The existing 'idea.platform.prefix' system-property approach
only worked because of a Android Studio bug that leaks the
system properties from Android Studio into Gradle build:
- https://issuetracker.google.com/201075423
This bug was fixed in Android Studio 2023.3.1 (Jellyfish).
The correct way of identifying builds from Android Studio is to
use the following project property (not system property):
- android.injected.invoked.from.ide
Replace the use of WindowInsetsAnimation with WindowInsetsAnimationCompat; the former was only introdcued in api 30 and caused a crash on older versions of Android.
Fixes https://github.com/godotengine/godot/issues/91773
* Replaces `find(...) != -1` with `contains` for `String`
* Replaces `find(...) == -1` with `!contains` for `String`
* Replaces `find(...) != -1` with `has` for containers
* Replaces `find(...) == -1` with `!has` for containers
Random-access access to `List` when iterating is `O(n^2)` (`O(n)` when
accessing a single element)
* Removed subscript operator, in favor of a more explicit `get`
* Added conversion from `Iterator` to `ConstIterator`
* Remade existing operations into other solutions when applicable
Gradle automatically handles up-to-date checks for output files and directories. This behavior sometimes causes the `copyAndRename*` task to fail on Windows machines when gradle tries to check on existing files in the output directories it doesn't have access to.
To fix the issue, we disable this gradle behavior following the instructions in https://docs.gradle.org/8.2/userguide/incremental_build.html#sec:disable-state-tracking
The previous logic passed the path to the Android keystore as-is to an external tool. This causes the tool to fail if the path is Godot-specific (e.g: 'res://<path_to_keystore>'
Once sensor listeners are registered, onSensorChanged() (and subsequently
getRotatedValues()) gets called multiple times per socond. Obtaining
WindowManager on each of those calls is superfluous and can be avoided
by extracting it to a lazy class val. getRotatedValue() can also be
called before checking sensor type, and used for each one of them,
resulting in less code repetition.
This PR prevents potential NPEs, and follows Kotlin conventions more closely
by replacing the unsafe !! operator with safe ?. (or ?.let) (usually
!! would only be used very rarely, and with a good reason - there is one
place left in this PR where !! makes sense), and by replacing Java style
'if (x != null)' with Kotlin's '?.'
