cc @dsnopek @m4gr3d

I'm taking this out of draft as it is working. This should not be merged until after we've updated the OpenXR version in the thirdparty folder to atleast 1.1.46

Opinion among the XR team is to also hold off merging until Godot 4.5 has been released as accompanying changes on the vendor plugin side will require some guidance.

Rebased so it should now automatically pick up the OpenXR loader for 1.1.47 :)

Just discussed with @m4gr3d , need to rebase this and we're planning on removing the custom loader option as there currently is no scenario where we need this.

This has now been rebased and I've removed the custom option. PR still works as expected.

Also as expected, with the current vendor plugin installed gradlew complains that we're including the loader twice. While we plan to remove the loader code from the vendor plugin, we want to be backwards compatible so we're looking into manifest changes that tell gradlew to ignore the loader from the vendor plugin.

Once that is resolved this can be merged.

XR Meeting: Fredia to detail his solution for prioritising loader between core and vendor plugin, then this should be ready to merge.

Have not particular tested this one, but if it works the same as khronos loader of the vendor plugin, it works for focus 3 for sure, as I tested it on there.

Have not particular tested this one, but if it works the same as khronos loader of the vendor plugin, it works for focus 3 for sure, as I tested it on there.

Thats the basic idea, it replaces the part of the vendor plugin where the khronos loader is included. This means that for any platform that doesn't require any additional manifest changes, you can create an APK that is deployable on all those platforms without requiring any additional plugins.

I'm not sure the pickFirst thing is working to get the libopenxr_loader.so from the Khronos package, rather than the godot_openxr_vendor plugin.

I tested exporting with this PR and godot_openxr_vendor v4.2.0 installed in my project, then I unzipped the APK file and took an MD5 hash of the jni/arm64-v8a/libopenxr_loader.so and compared that with the one from godot_openxr_vendors and the openxr_loader_for_android package. It had the one from godot_openxr_vendors!

When I remove the godot_openxr_vendors plugin, and export again - then I see the right libopenxr_loader.so inside the APK

I'm not sure the pickFirst thing is working to get the libopenxr_loader.so from the Khronos package, rather than the godot_openxr_vendor plugin.

I tested exporting with this PR and godot_openxr_vendor v4.2.0 installed in my project, then I unzipped the APK file and took an MD5 hash of the jni/arm64-v8a/libopenxr_loader.so and compared that with the one from godot_openxr_vendors and the openxr_loader_for_android package. It had the one from godot_openxr_vendors!

When I remove the godot_openxr_vendors plugin, and export again - then I see the right libopenxr_loader.so inside the APK

Well, its still better than completely breaking :)

Right now I don't think it matters much which one is included, as long as we're not doubling up. We're not really using the loader beyond connecting to the runtime, we obtain all function pointers ourselves so even if we're using an older loader, things still work.

It's probably going to matter once OpenXR 1.2 is available but by that time we'll have removed the loader from the vendors plugin.

Right now I don't think it matters much which one is included, as long as we're not doubling up.

I guess that's OK, so long as it's predictable which one gets used

But if we did want to have it favor the loader from the Khronos package, we might be able to make that happen by switching to pickLast or changing the order the dependencies are listed?

But if we did want to have it favor the loader from the Khronos package, we might be able to make that happen by switching to pickLast or changing the order the dependencies are listed?

Worth testing, but I'm out today so unless you have a moment to verify it'll have to wait. Also I'd like to know what determines the order :)

If we want to be specific, we can try the approach described in https://stackoverflow.com/questions/74258902/how-to-define-which-so-file-to-use-in-gradle-packaging-options/74279439#74279439

If we want to be specific, we can try the approach described in https://stackoverflow.com/questions/74258902/how-to-define-which-so-file-to-use-in-gradle-packaging-options/74279439#74279439

To be honest, that feels like waaaaay overkill for a temporary situation.

Honestly, I don't think it matters which version of the loader is added, and as long as we remove the loaders from the vendor plugins from v5.0.0 onwards, we're gonne be good.

The code looks good. I'll perform a few rounds of tests.

Finished testing, and things build as expected!

Thanks!