The previous packaging format for Godot Android plugins consisted of the plugin's `gdap` config file accompanied by binaries defined in the `gdap` file.
This format is now deprecated (starting with Godot 4.2), and instead Godot Android plugins are now packaged as `EditorExportPlugin` plugins.
The `EditorExportPlugin` class has been updated with the following methods to provide the necessary set of functionality:
- `_supports_platform`: returns true if the plugin supports the given platform
- `_get_android_dependencies`: retrieve the set of android dependencies (e.g: `org.godot.example:my-plugin:0.0.0`) provided by the plugin
- `_get_android_dependencies_maven_repos`: retrieve the urls of the maven repos for the provided android dependencies
- `_get_android_libraries`: retrieve the local paths of the android libraries (AAR files) provided by the plugin
- `_get_android_manifest_activity_element_contents`: update the contents of the `<activity>` element in the generated Android manifest
- `_get_android_manifest_application_element_contents`: update the contents of the `<application>` element in the generated Android manifest
- `_get_android_manifest_element_contents`: update the contents of the `<manifest>` element in the generated Android manifest
Decouples the Godot java entry point from the Android Fragment component. This enables the Godot component to be more easily reused across different types of Android components including Activities and Services.
We can't rely on the error code from `gio` or `kioclient5`, in my
rudimentary testing they return `1` for both missing files and other
situations like not having a Trash can on the mounted volume.
Fixes#79108.
During GDC and general testing on Steam Deck units, we found that single
gamepads would often register inputs twice under certain circumstances.
This was caused by SteamInput creating a new virtual device, which Godot
registers as a second gamepad. This resulted in two gamepad devices
reporting the same button presses, often leading to buggy input response
on games with no multi-device logic and other-wise could cause intended
Steam rebindings to not work as intended (for example, swapping o and x
on a playstation pad if that feature isn't supported by the game.)
SDL gets around this by taking in a list of devices that are to be
ignored. When valve sees a controller that wants to be rebound via
SteamInput, they push a new VID/PID entry onto the environment
variable `SDL_GAMECONTROLLER_IGNORE_DEVICES` for the original gamepad
so that all game inputs can be read from the virtual gamepad instead.
This leverages the same logic as we are already using SDL gamepad
related HID mappings.
We don't use that info for anything, and it generates unnecessary diffs
every time we bump the minor version (and CI failures if we forget to
sync some files from opt-in modules (mono, text_server_fb).
