XR editor: execution modes and limitations
Device variants, separate immersive execution, permissions and troubleshooting.
The XR editor is an Android editor variant for working inside an XR device system. The editor panel, ordinary game and immersive XR game are different modes. Seeing the editor in a headset panel proves neither tracking nor immersive project execution.
Choose the matching build
Current Reckfell 1.0.0 source defines Android, HorizonOS and PICO OS variants. This lists configurations, not released APKs or testing of every device. Use a package matching your system/ABI. Unverified store listings are not linked.
| Variant | Source declarations |
|---|---|
| Android | Optional OpenXR feature and a separate immersive activity; base minSdk=24. This does not make every Android phone an XR device |
| HorizonOS | arm64-v8a; manifest declares min/target HorizonOS 69, required headtracking and quest2/quest3/questpro/quest3s models |
| PICO OS | arm64-v8a; minSdk=29 and required headtracking |
Manifest numbers are build input requirements, not acceptance of a current OS release. Verify runtime extensions, controllers, hand tracking, passthrough and spatial data separately. This Android port is not a desktop PCVR editor.
C# editor tools are unsupported in these variants: the module build gate allows desktop editors only. Use the desktop editor and separate device deployment for C# games. An Android target for C# games does not change that restriction.
Minimal workflow
- Verify installation/startup of the matching XR editor. Open a local small project without C#, confirming resource saving and reopening as described in Android editor.
- First run/stop a simple non-XR level. This checks ordinary Play independently of immersive startup.
- Configure OpenXR, active XROrigin3D/XRCamera3D and required action bindings. Do not add C# examples to an editor without C# tools; verify those examples through the desktop workflow.
- Run the immersive project. Check head tracking, controller/hand bindings and stopping. Return to the editor through the device system menu; exact OS entries can differ.
- Save an edit in the editor and repeat the run. Verify the intended renderer and each vendor capability before using a large scene.
These are device acceptance steps, not a completed demonstration. Do not make old names for experimental OS menu entries mandatory instructions.
Input and window placement
The XR editor feature depends on Android recognizing a native XR device; it is not an arbitrary project flag. Current implementation disables game embedding on such devices: run/window_placement/game_embed_mode offers only Disabled=-1. Expect separate Play/immersive execution rather than promised desktop-style embedding.
Check interface/touchscreen/enable_long_press_as_right_click for context actions; changing it requires an editor restart. Adjust handle size with interface/touchscreen/scale_gizmo_handles, also requiring restart. Automatic touch defaults differ from ordinary phones; do not assume these options are enabled already. Use a device-supported keyboard for text and separately verify system-reserved shortcuts.
Permissions and project access
Folder access follows the Android editor. Keep the complete project in an accessible local directory rather than opening one cloud document. A synchronization app's permissions do not automatically grant the editor the same access. Shared-file access does not expose other apps' private directories: Android restrictions still apply.
XR runtime permissions are requested separately with xr/openxr/enabled. The HorizonOS implementation adds USE_SCENE; camera access is requested separately when CameraFeed is activated. A permission/manifest entry establishes neither API support nor available room data. Handle missing functionality or show its specific cause when permission is denied.
An important HorizonOS difference: its overlay manifest removes REQUEST_INSTALL_PACKAGES from the common manifest. The generic instruction to allow APK installation from the editor therefore does not apply to every XR build. This guide does not establish standalone-game installation from the XR editor.
Projects and native plugins
Transfer project.reckfell, levels, prefabs, source assets and sidecar metadata. Save/close the active copy first and wait for import after transfer. A native plugin needs an Android arm64-v8a library matching the engine and vendor dependencies. A desktop library or different ABI will not work. Installing a plugin cannot add unsupported headset runtime extensions.
Troubleshooting
| Symptom | Check |
|---|---|
| Editor opens but immersive game does not | Matching activity/app variant, OpenXR runtime, project XR enablement and Output |
| No C# build | Mobile editor-tools limitation; develop through the desktop editor |
| No embedded Play | Expected XR-editor restriction; use separate execution |
| Missing planes/anchors/camera | Specific capability, permissions and room data; an editor panel proves none of these |
| Cannot open folder | Complete local project copy and editor access |
| System controller works but game input does not | Action map, active XR session, tracking and correct origin; the system pointer proves no game bindings |
| Frame-rate drops | Start with a simple scene; measure device GPU/CPU and renderer rather than enabling every effect |
Verification limits
Variants, manifest requirements, permissions, disabled game embedding, touch settings and the C# editor gate were source-reviewed. The Python gate ran on the host; APK builds, headset execution, OS menus, immersive switching, tracking/hand input, passthrough, project saving and performance remain untested. No images are presented as current XR-editor captures. Engine source, installed Runtime and SDK unchanged.