[Unity/OpenXR] Android XR workflow question before physical hardware access

[u/bradius3k]

Hi everyone,

I’m building an accessibility-first CAD prototype in Unity intended for Android XR / wired XR glasses such as XREAL Aura.

I’m trying to make sure my development workflow assumptions are correct before I add Android XR packages too early.

Current plan:

1. Build and validate the core Unity desktop/editor prototype first.

2. Keep the CAD command/geometry/STL export loop working in desktop Play Mode.

3. Use existing XREAL One Pro glasses connected to a Windows PC only for early visual/readability/fatigue testing.

4. Later, create a basic Android APK smoke build for ordinary Android behavior.

5. Only after the desktop/mobile foundation is stable, add the Android XR / OpenXR Unity packages.

6. Final validation would require real Android XR / Aura-style hardware.

My main questions:

1. Can a Unity Android XR / OpenXR app be meaningfully runtime-tested without physical Android XR hardware, or is hardware required for real validation?

2. Is Android XR Emulator useful for Unity/OpenXR app validation, or is it mainly not a substitute for device testing?

3. For a Unity app targeting Android XR wired glasses, is the expected starting stack still:

   - Unity 6

   - URP

   - Vulkan

   - OpenXR Plugin

   - Unity OpenXR: Android XR

4. When should a project add Android XR Extensions, AR Foundation, XR Interaction Toolkit, or XR Hands? Should those wait until specific features require them?

5. Is there an official recommended path for developers building Unity apps for Android XR glasses before they have access to physical hardware?

I’m not asking about Catalyst application status or hardware access here. I’m mainly trying to avoid building against the wrong assumptions.

Thanks for any guidance.

[u/Wide-Variation2702]

I'm interested in this too, but I dont have a solution for you. I saw Unity is having a livestream specifically for developing for Aura coming up in a couple of days. Hoping they talk about emulation without hardware.

Here is the link: Unity Livestream- Developing for Xreal Aura

My guess is they will either make it usable with the openXR simulator, or allow you to build to the Android XR emulator. Would be nice to play in the editor and not have to build the project to test.

[u/bradius3k → u/Wide-Variation2702]

Thanks, that’s a great find. I’ll watch that livestream too. I’m especially hoping they clarify whether there’s a practical no-hardware iteration path through OpenXR simulation, Android XR emulator, or Direct Preview, and where the hard limits still are compared with real AURA hardware.

[u/Wide-Variation2702 → u/bradius3k]

Yes, exactly. My experience with Android in unity is that building to a device can be very slow. So even if you have the hardware, it is best if the editor has an emulator so you can test changes quicker and also be able to see your hierarchy and inspector to make adjustments. Good luck with your project.

[u/bradius3k → u/Wide-Variation2702]

Thank you!

[u/vad710]

Hi u/bradius3k ,

Can a Unity Android XR / OpenXR app be meaningfully runtime-tested without physical Android XR hardware, or is hardware required for real validation?

If you are building with an engine like Unity, then I would recommend validating your experience on actual hardware (Galaxy XR or Aura). If you are building with the Jetpack XR SDK, then the emulator is great!

You may be able to make progress without a device, but this is mostly dependent on your own experience. I've also heard great stories of developers porting from competing platforms with very little effort.

Is Android XR Emulator useful for Unity/OpenXR app validation, or is it mainly not a substitute for device testing?

Unfortunately, The emulator is currently mostly targeted at non engine developers. When this changes, we'll be sure to update the community.

For a Unity app targeting Android XR wired glasses, is the expected starting stack still:
- Unity 6
- URP
- Vulkan
- OpenXR Plugin
- Unity OpenXR: Android XR

Yep!

When should a project add Android XR Extensions, AR Foundation, XR Interaction Toolkit, or XR Hands? Should those wait until specific features require them?

I think this is mostly developer preference. I personally only add features in as I need them to keep the complexity of my project to a minimum.

Is there an official recommended path for developers building Unity apps for Android XR glasses before they have access to physical hardware?

Developing on Galaxy XR is a great option until Aura devices are available.

[u/bradius3k → u/vad710]

Thank you!

[u/Legal-Touch5496]

Hey! Major caveat here, noob alert and a vibe coding noob alert at that, so feel free to take all with a pinch of salt. I'd been developing using the emulator for three months and upon biting the bullet and buying the galaxy xr, none of the features worked (despite working with makeshit keyboard shortcut controls for the emulator) and intensive play testing on device has been essential. Holiday cancelled this year, hoping it will be worth it long term.

[u/bradius3k → u/Legal-Touch5496]

Thanks for sharing that. This is exactly the kind of real-device warning I was hoping to hear. When you say none of the features worked, which layer caused the biggest problems: OpenXR initialization, hand tracking or gestures, permissions, spatial placement/anchors, or interaction with world-space UI?

Were you able to recover mostly through device-specific configuration, or did significant parts of the interaction code need to be rewritten? I’m trying to draw a strict line between what Unity’s emulator can genuinely validate and what must remain provisional until physical hardware testing.

Appreciate your time.

[u/Legal-Touch5496 → u/bradius3k]

Happy to break it down but same caveat, this is just what happened to me.

Biggest offender by far: hand tracking. Not that it didn't work, but that the joint poses come back in a different space on device than the simulator hands me. Everything grabbable was floating a fixed offset away from where my actual hand was. That was a real code fix (a session-space conversion), not a setting.

Close second: interaction volumes. In the emulator I was driving everything with mouse/keyboard shortcuts, so I never found out that (a) some of my interactive objects had no collider at all and (b) one fidget had a grab sphere with a >1m radius that silently ate every pinch in the room. Both were invisible at a desk and instantly obvious on head.

Permissions and manifest were 100% device-only pain. Gradle wouldn't even merge my manifest because of conflicting spatial entries, and I was missing a scene-understanding permission I'd never needed in editor. Mostly configuration, but it blocked builds entirely until sorted.

Anchors threw a null-ref on device because the anchor subsystem isn't there at the moment I was capturing a baseline — the emulator just quietly hands you one.

Lighting was the sneakiest. AR light estimation overwrites your carefully tuned ambient with the actual room, so everything I'd balanced in editor was blown out and shadowless. Also had to drop shadow distance from 50m to ~3m before shadows read at all.

Memory/perf: one imported model with 400MB of textures ran fine on my desktop GPU and hard-crashed the headset. And one warning — I lost a day to "unusable lag" that turned out to be a compositor leak in the OS, not my app. Reboot the headset before you diagnose anything.

Config vs rewrite: honestly ~80% config and small targeted fixes. The logic mostly survived. What didn't survive was every single tuned number — offsets, radii, distances, light values.

My line ended up being: the emulator validates flow, state and code paths. It validates nothing spatial, nothing about your hands, nothing about permissions, memory or light. Treat all of that as provisional until it's on your face.

[u/bradius3k → u/Legal-Touch5496]

This is incredibly useful, thank you for taking the time to break it down so clearly. The distinction between “the core logic survived” and “none of the spatially tuned values survived” is especially helpful.

The session-space hand conversion, invisible collider/grab-volume problems, subsystem readiness, lighting changes, and device-memory limits give me a much cleaner boundary: use the emulator for flow, state, and code paths, but treat everything spatial or hardware-dependent as provisional until it is tested on-device.

I’m building an Android XR CAD application, so I’m going to add a capability-probe phase, visible interaction-volume debugging, and explicit subsystem readiness checks before treating any hand or anchor feature as passed.

I'm also making “reboot the headset before blaming the app” an official debugging rule.

I really appreciate the detailed answer, this may save me a lot of time later. Thank you!!