The Khronos Group has TAGGED OpenXR SDK 1.1.65, and while the headline reads like ROUTINE plumbing, the registry UNDERNEATH it tells a BIGGER story: SEVEN new multi-vendor XR_EXT extensions, ONE new ByteDance vendor extension, and THREE Android-specific extensions now FORMALLY marked as DEPRECATED in favor of cross-vendor replacements. The release went up on GitHub on October 16 at about 1:03 p.m. ET. Read against the REGISTRY file itself, the notes also get TWO details WRONG: they OMIT one of the Android deprecations, and they call an extension “ratified” that Khronos’s own registry page says is NOT.
What Landed in the Registry
Comparing the xr.xml registry at the 1.1.63 tag (September 1) with the 1.1.65 tag, the COUNT of supported extensions MOVES from 253 to 261. Ratified entries go from 52 to 58, multi-vendor XR_EXT entries from 40 to 47, and entries carrying a deprecatedby pointer from 20 to 23. The EIGHT additions are:
XR_EXT_spatial_object_tracking(ratified): tracks furniture-class OBJECTS with nine semantic labels (sofa, bed, chair, table, lamp, plant, display screen, wall art, cabinet), plus SEPARATE components for a KEYBOARD and a MOUSE.XR_EXT_spatial_mesh_tracking(ratified): room MESHES with per-vertex and per-triangle labels for floor, wall, ceiling, table, chair, sofa, and bed, normals, and a “watertight mesh” feature.XR_EXT_spatial_entity_archetypes(ratified): lets an app ENUMERATE which component types a runtime groups together for a given kind of spatial entity.XR_EXT_spatial_plane_semantic_label2(ratified): a second plane-label set that adds DOOR and WINDOW to floor, wall, ceiling, and table.XR_EXT_enumerate_swapchain_formats2andXR_EXT_app_consumed_swapchain(both ratified): the second defines swapchains whose images the APP consumes, with acquire, release, and properties calls.XR_EXT_aosp_hand_tracking_permission: an Android permission extension. More on its STATUS below.XR_BD_motion_tracker: a ByteDance vendor extension that, in the registry, defines ONE thing, an interaction profile at/interaction_profiles/bytedance/motion_tracker_bd.
Every one of the four spatial extensions DEPENDS on XR_EXT_spatial_entity, the cross-vendor scene-understanding FRAMEWORK Khronos has been BUILDING out release by release. The September tag added spatial CONTAINERS and image tracking; this one fills in OBJECTS, MESHES, and RICHER PLANES. The SDK’s hello_xr sample also GAINS an alternate mode, selectable with --program or an adb property, that demonstrates the spatial container functionality.
The Android Deprecations, Including One the Notes Skip
The release notes say TWO Android extensions are now deprecated: XR_ANDROID_trackables_image in favor of XR_EXT_spatial_image_tracking, and XR_ANDROID_unbounded_reference_space in favor of XR_EXT_stationary_reference_space. The registry file shows a THIRD: XR_ANDROID_scene_meshing now CARRIES deprecatedby="XR_EXT_spatial_mesh_tracking", an attribute that was ABSENT at the 1.1.63 tag. The notes do NOT mention it.
There is a second WRINKLE. Two of the three replacements are ratified, but XR_EXT_stationary_reference_space carries NO ratification attribute in the registry. Deprecation in OpenXR does not REMOVE an extension, so EXISTING Android XR apps keep WORKING; it SIGNALS where Khronos wants NEW code to go. For developers targeting Android XR alongside Quest, Pico, and other runtimes, that DIRECTION matters: scene meshing and image tracking written against the EXT versions are, on paper, PORTABLE.
“Ratified” Is Not What the Registry Says
The 1.1.65 notes list XR_EXT_aosp_hand_tracking_permission under “New ratified multi-vendor extension.” The Khronos registry page for that extension, generated from version 1.1.65, gives its ratification status as “Not ratified,” and the xr.xml entry has no ratified attribute, UNLIKE the six other new EXT entries. The registry entry itself defines ONLY a version number and a name string. Whether the notes or the registry is WRONG is for Khronos to CLARIFY; as published, they DISAGREE.
Why This Matters Beyond the Spec
SHARED extensions are what let studios SHIP the same feature across HEADSETS without a SEPARATE code path per vendor. Andrew Eiche, CEO of Owlchemy Labs, put the BUSINESS case PLAINLY earlier this month:
Nothing at all for platforms that support OpenXR (Apple and Sony dont). At Owlchemy we use OpenXR in all our games. It's how we can port so fast.
— Andrew Eiche (@buddingmonkey) October 9, 2026
We can call platform features from OpenXR extensions or specific libraries we use per-platform. We try to be as generic as possible.
Object, mesh, and plane understanding are EXACTLY the platform features that have HISTORICALLY lived in VENDOR extensions. Moving them into ratified EXT form is the PRECONDITION for mixed reality apps that RUN unchanged across runtimes. It is NOT a GUARANTEE: a ratified extension still has to be IMPLEMENTED by each runtime, and this release does NOT say WHICH runtimes support any of the new spatial extensions today. The keyboard and mouse labels in object tracking are a NOTABLE inclusion as headset makers PUSH PRODUCTIVITY use, where finding a PHYSICAL keyboard in passthrough is a BASIC task.
The Rest of 1.1.65
Outside the registry, the SDK changes are MAINTENANCE: a Windows loader fix for API layer enumeration when it hits an invalid registry key, a loader fix that stops assuming uint32_t is unsigned int in manifest version parsing, an API dump layer fix that treats jobject as an external handle, a validation layer fix for platform-specific handles, a more CONSISTENT OpenGL ES 3.1 requirement, and REMOVAL of pre-C++17 filesystem code. The Android loader and the API layers are published to Maven Central at version 1.1.65, and the release attaches PREBUILT hello_xr APKs for OpenGL ES and Vulkan.
The Bottom Line
OpenXR 1.1.65 is the most CONSEQUENTIAL scene-understanding drop since spatial entities arrived: SIX ratified multi-vendor extensions and THREE Android extensions now formally POINTED at portable SUCCESSORS. The paperwork is not CLEAN, with one deprecation missing from the notes and one “ratified” claim contradicted by the registry. Developers should READ xr.xml and the registry pages, not JUST the changelog, before PLANNING a migration.
Sources: OpenXR SDK 1.1.65 release notes (October 16), OpenXR SDK 1.1.63 release notes (September 1), the specification/registry/xr.xml file at both tags in KhronosGroup/OpenXR-SDK-Source, Khronos registry pages for XR_EXT_spatial_object_tracking, XR_EXT_spatial_mesh_tracking, XR_EXT_app_consumed_swapchain, and XR_BD_motion_tracker, and @buddingmonkey on X.