Current OpenXR Version
1.0.30
What's New
OpenXR version changed from 1.0.29 to 1.0.30
Release XR_FB_FACE_TRACKING2. Its usage has been updated in the XrFaceTrackingFB and XrBodyFaceEyeSocial sample
Release XR_META_BODY_TRACKING_FIDELITY, XR_META_BODY_TRACKING_FULL_BODY, and XR_META_BODY_TRACKING_CALIBRATION. Their usage has been updated in XrBodyTrackingFB sample
What's Fixed
Increased the logger buffer length from 256 to 512
Speed up cubes in XrSpaceWarp sample to better showcasing the consequence when motion vector resolution is low
On each app shutdown, clean all member variable so that sample apps won’t crash on second time launch
Fixed a crash when closing XrPassthrough and XrPassthroughOcclusion sample
Runtime Behavior Changes

We sometimes find that the runtime shipped with a bug or non-conformant behavior and in such cases we may change the runtime so that future applications get conformance and bug fixes.

In cases where such bug fixes or behavior changes may be incompatible with existing applications, the OpenXR version number that an application is compiled against is used to gate the behavior change. This allows older applications that may have been working around the issue continue to work as expected, while newly-built applications can receive the conformant or correct behavior.

For example, if your app builds with version 1.0.25 and a behavior change is gated on 1.0.26, then your application will continue to function as expected even with a newer Oculus OS runtime built to support OpenXR version 1.0.26 or greater. However, if you rebuild your application with 1.0.26 or greater, the new behavior will be enabled for your application.

The following list is intended to give developers forewarning of such behavior changes in order that they might be addressed when applications are updated and built on against newer OpenXR headers.


Behavior Changes On Upcoming OpenXR Version:
Clients linking against OpenXR version >= 1.0.31 need to request the scene permission com.oculus.permission.USE_SCENE in the app to display the permission dialog and get user consent before they can query scene data use XrQuerySpacesFB.


Behavior Changes On Previous OpenXR Version:
Apps linked against OpenXR headers older than 1.0.22 have their XrSwapchainCreateInfo.next pointer ignored to prevent Unity applications from crashing due to an uninitialized next pointer.
Apps linked against OpenXR 1.0.23 or newer treat the XrCompositionLayerImageLayoutFB.flipY flag correctly. Prior to 1.0.23 there was a bug in the OpenXR implementation where this flag was ignored.
Prior to OpenXR version 1.0.23 the thumbs joints of our hands were rotated in a way that did not match OpenXR specification. Apps linked against 1.0.23 and greater should get thumb joint rotations that match the specification.
Apps building against OpenXR version 1.0.24 or higher can enable STAGE space when a stationary Guardian is configured.
Apps linked to OpenXR versions prior to 1.0.24 would not receive data to the khr/simple_controller action profile and grip and aim poses were broken. Apps linking to 1.0.24 or greater should receive the correct data.
Clients linking to OpenXR version 1.0.28 or higher will not have output structs types correctly validated. Applications that are passing invalid structure types to xrEnumerateConfigurationViews or xrLocateViews may now be returned an XR_ERROR_VALIDATION_FAILURE error where they previously were not.
Clients linking to OpenXR version 1.0.29 or higher cannot rely on the return value of xrGetFaceExpressionWeightsFB to know if the returned expression weights values are valid. Instead they should check the valid flag on the XrFaceExpressionWeightsFB struct. Note that the valid flag is set on older OpenXR versions as well.
Clients linking against OpenXR version >= 1.0.29 will have the XR_HAND_JOINT_PALM_EXT pose calculated as (XR_HAND_JOINT_MIDDLE_METACARPAL_EXT pose + XR_HAND_JOINT_MIDDLE_PROXIMAL_EXT pose) / 2.
Known Issues
Sample apps won't build with Android Studio Chipmunk 2021.2.1 or newer. Please use an older version for now.
The DynRes requirement for GPU Level 5 is not correctly enforced. If requesting GPU Level 5, it is up to you to ensure you are also enabling DynRes. If you don't, your app risks a performance regression in a future release when the DynRes enforcement gets fixed.
Sample apps won't build with NDK newer than version 26.0.10792818. Please use an older version for now.