The RayNeo X3 Pro is an initial Konjure client target. The retained Android
application is Konjure (dev.alkem.konjure), with a Rust/wgpu stereo renderer
and an Android lifecycle/camera boundary. It can render scenes, show an upright
Camera2 preview, and run the established perception/offload paths.
What has been observed
The retained application has been exercised on a connected X3 Pro: native Vulkan stereo, scene submission, an upright camera path, HUD rendering, and short camera/perception profile samples. Camera observations are normalized upright once at capture, before preview, inference, recording, or offload. On the tested configuration, camera metadata reported a 90° sensor orientation with display rotation 0°; the rotation must still be derived from the current device metadata.
Those results establish the named app behavior under the recorded conditions. They do not establish optical registration, depth correctness, durable mapping, or room anchoring. The retained renderer currently treats its scene as untracked; orientation-only or head-locked presentation does not meet Konjure’s room-anchoring requirement.
SDK and language boundary
The new Konjure DSL runs in Rust and WASM. The Android application now embeds
konjure-lang::LiveRuntime and renders its committed geometry, including
language-owned meshes. Pair a live session to receive
source revisions, fixed simulation ticks and typed callbacks from the website.
The existing Android scene-document paths remain available.
Android debug signing uses a stable key outside the checkout at
~/.local/share/konjure/signing/debug.keystore (or $XDG_DATA_HOME). Set
KONJURE_ANDROID_KEYSTORE to use an existing development key. An APK signed by
a different key cannot update the installed app; preserve the matching key
instead of uninstalling the app and losing its state.
A RayNeo adapter must provide its own lifecycle, permissions, graphics surfaces, sensor and clock conversion, and tracked reference-space evidence. A valid room anchor needs a source and target frame, timestamp, tracking/calibration evidence, and an anchor lifecycle; an SDK scene flag alone cannot supply those facts.
Before a device claim
Select the intended USB glasses or verify the paired wireless target before building. Keep raw recordings, calibration data, and device identifiers outside the repository. A device build or install is separate from a physical acceptance: test tracking, relocalization, room placement, interruption, reconnect, and wearer-visible output for the exact configuration being claimed.
Read Browser & WebXR for the browser’s separate session-local placement behavior, and support status for the current SDK boundary.