The presence of those abis cause them to be included in the set of `p_features` passed to the `gdextension_export_plugin#_export_file(...)` method, which caused them to be lumped in the `features_wo_arch` set.
When trying to find the gdextension library path, we use a predicate with the following logic:
```
[features_wo_arch, arch_tag](String p_feature) { return features_wo_arch.has(p_feature) || (p_feature == arch_tag); }
```
For a `gdextension` config file like the one below, this causes the first android entry (`android.armeabi-v7a = ...`) to always be returned regardless of archs since it always satisfies the predicate.
```
[configuration]
entry_symbol = "example_library_init"
compatibility_minimum = 4.1
[libraries]
linux.x86_64 = "res://libgdexample.so"
android.armeabi-v7a = "res://libgdexample.android.template_release.armeabi-v7a.so"
android.arm32 = "res://libgdexample.android.template_release.armeabi-v7a.so"
android.x86 = "res://x86/libgdexample.android.template_release.x86.so"
android.x86_32 = "res://x86/libgdexample.android.template_release.x86.so"
android.x86_64 = "res://libgdexample.android.template_release.x86_64.so"
android.arm64-v8a = "res://libgdexample.android.template_release.arm64-v8a.so"
android.arm64 = "res://libgdexample.android.template_release.arm64-v8a.so"
```
- When using the project name, allow underscore (`_`) characters
- Send a warning instead of an error when the project name is modified to fit the package name format
This makes it easy to retrieve the project version at runtime
for display purposes, while simplifying the export preset configuration.
You can now leave the version empty unless you need to override it on a per-preset
basis.
Since export presets save the values of default values to the `export_presets.cfg`
file, this change only affects export presets created after this commit was merged.
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
When trying to export a C# project, this displays an error message after
creating a export preset for an unsupported platform.
Support for these platforms is planned for a future release.
Follow-up to #75932.
Since these icons are only used by the export plugin, it makes sense to
move them and generate the headers there.
The whole `detect.is_active()` logic seems to be a leftover from before
times, as far back as 1.0-stable it already wasn't used for anything.
So I'm removing it and moving the export icon generation to
`platform_methods`, where it makes more sense.
This applies our existing style guide, and adds a new rule to that style
guide for modular components such as platform ports and modules:
Includes from the platform port or module should be included with relative
paths (relative to the root folder of the modular component, e.g.
`platform/linuxbsd/`), in their own section before Godot's "core" includes.
The `api` and `export` subfolders also need to be handled as self-contained
(and thus use relative paths for their "local" includes) as they are all
compiled for each editor platform, without necessarily having the api/export
matching platform folder in the include path.
E.g. the Linux editor build will compile `platform/android/{api,export}/*.cpp`
and those need to use relative includes for it to work.
Instead of reading files over the network, the new version uses a local file cache and only updates files when it changes.
The original remote filesystem was created 14 years ago, when ethernet was faster than hard drives or even flash. Also, mobile devices have a very small amount of storage.
Nowadays, this is no longer the case so the approach is changed to using a persistent cache in the target device.
Co-authored-by: m4gr3d
On Linux, thread IDs were not properly assigned with the current approach.
The line:
`std::thread new_thread(&Thread::callback, _thread_id_hash(thread.get_id()), p_settings, p_callback, p_user);`
does not work because the thread ID is not assigned until the thread starts.
This PR changes the behavior to use manually generated thread IDs. Additionally, if a thread is (or may have been created) outside Godot, the method `Thread::attach_external_thread` was added.
Users can still go down to 21 when using GL Compatibility.
This makes the default behavior match the default renderer, and thus avoids
a warning in the out of the box experience.
Also mark texture compression settings as basic, since out of the box users
who want to export to Android will need to enable ETC2/ASTC manually.
- Add runtime check and abort when the device doesn't meet the requirements for vulkan support
- Add filters to the AndroidManifest when exporting with a vulkan renderer
Remove the XR export logic from the legacy build system:
- On Android, Godot 4 export requires the use of Android plugins which are not supported by the legacy build system
- Provides added flexibility for configuring the Android manifest for XR specific capabilities.
* Only two texture import modes for low/high quality now:
* S3TC/BPTC
* ETC2/ASTC
* Makes sense given this is the general preferred and most compatible combination in most platforms.
* Removed lossy_quality from VRAM texture compression options. It was unused everywhere.
* Added a new "high_quality" option to texture import. When enabled, it uses BPTC/ASTC (BC7/ASTC4x4) instead of S3TC/ETC2 (DXT1-5/ETC2,ETCA).
* Changed MacOS export settings so required texture formats depend on the architecture selected.
This solves the following problems:
* Makes it simpler to import textures as high quality, without having to worry about the specific format used.
* As the editor can now run on platforms such as web, Mac OS with Apple Silicion and Android, it should no longer be assumed that S3TC/BPTC is available by default for it.
