Exclusively OpenXR for Android/PCVR

[mikeskydev]

This PR implements the early stages of https://github.com/mikeskydev/unity-openxr-extensions, moving away from vendor specific XR SDKs towards using OpenXR for as many features as possible.

TODO:

• Fix up AndroidManifest; some things are implemented in the package, others should be.
• Test Pico a bit more thoroughly.
• Re-orient pico controllers

Out of scope:

• Switch MX Ink to OpenXR Re-Add MX Ink support in OpenXR #942.

Test Matrix Nov '25:

• Quest 3
• Quest 1
• Pico 4/Ultra
• Windows

This removes dependency on the Oculus Core SDK and the Pico SDK, allowing us to use the same codepath. Annoyingly our package name is still different on Oculus, so we have to do a separate build. @mikeage could we consider using apktool to hack our own package as a post-build step, rather than building twice?

Oculus Passthrough is delivered via the new upm package, and as a plus we get passthrough on Pico and Quest PCVR!

Oculus Platform is required for age check (and some MR features that are currently commented out), but we check which platform we're running on before initializing, otherwise it can crash non-oculus android devices. I will reimplement the MR features in my OpenXR package at a later date.

Wave is removed (never actually used, and we can do it properly with OpenXR), as is the Pimax build, getting our current builds down to 6.

Closes #447

[mikeage]

apktool may be a drop problematic; we have to make sure it's signed properly. But it's probably possible. Maybe a followup PR?

[mikeskydev]

Yeah it can be a followup, I'm hoping we can make the change then re-sign as we have our original keys

[mikeage]

I pushed three commits with three smallish fixes that I think are important. Other than that, this looks good, but I think we need to test an upload to a different channel before merging

[mikeskydev]

Good catch on the symbols, but do we really need the quest specific version? It's just a package ID change... I'd rather use our proper ID on places we have control over

[mikeage]

Are you asking about Github or ArborXR? Or both?

I'd rather not break an upgrade for someone who previously installed that one.

Maybe on a major release we can talk about it, but not just slipped in like that.

[mikeskydev]

Oof, yeah I forgot about that... what a pain. I hate past me.

[mikeskydev]

Maybe on a major release we can talk about it, but not just slipped in like that.

According to this https://github.com/icosa-foundation/open-brush/milestone/4 we are only one issue away from 3.0, so... :)

[mikeskydev]

Bytedance have said we don't need to explicitly support Neo 3, so removed it from the target platforms. If it works, it's a happy coincidence.

[mikeage]

I looked at the manifests between the current Q2+ version and this Android Quest build. There are a few subtle differences:
This one adds <uses-permission android:name="android.permission.BLUETOOTH"/>
This one removes <uses-permission android:name="com.oculus.permission.USE_SCENE"/>, <uses-permission android:name="com.oculus.permission.USE_ANCHOR_API"/> and <uses-permission android:name="com.oculus.permission.IMPORT_EXPORT_IOT_MAP_DATA"/>
This one adds <uses-permission android:name="com.oculus.permission.BOUNDARY_VISIBILITY"/>. I think this was problematic before.

It also changes:

        <meta-data android:name="com.oculus.supportedDevices" android:value="quest2|questpro|eureka"/>

to

        <meta-data android:name="com.oculus.supportedDevices" android:value="quest|quest2"/>

There are a few other minor changes that I don't believe are significant. But these might be relevant (maybe not the permissions)

[mikeskydev]

Bluetooth; I'm not sure what could be enabling that, one to check.

USE SCENE and USE ANCHOR API are from the experimental colocation work which was never officially turned on and will need a huge refactor now. I think the map data one is also related.

Boundary visibility should be good now as it's officially supported, and the upload test I did didn't block it.

Supported devices is set to quest1|quest2 as that gives the largest compatibility, Quest 1 crashes (!) if it sees anything newer than quest2, and from quest2 upwards it's actually backwards compatible, but will fail upload validation if anything like quest pro or quest 3 is included alongside quest1. Threading the needle! (These values don't impact the ability to run the app, annoyingly. In an ideal world we don't even have this line.)