Skip to content

Conversation

matthargett
Copy link

These are the first few steps toward support for Android XR devices. This should not narrow support for prior Android operating systems and devices. This adds some v8 toolchain root hints to help make sure that the Android OS-supplied v8 library is used, and not a compile of JSC.

For context, there are multiple targets we care about for shipping our existing WebXR BabylonJS app in a native container (in priority order of important to our goals/customers):

  • Samsung Galaxy XR
  • XREAL One Pro+ (Android XR variant)
  • Pico 4 Ultra (Android 14)
  • HTC Vive XR Elite (Android ~12)
  • Meta Quest 3 (Android ~14)

The next step will be to create a WebXR API-compatible N-API native module that can integrate with BabylonNative ether by itself, or coordinated through NativeScript. This should allow for existing BabylonJS WebXR codepaths to remain unchanged and for the JS layer to stay ignorant of the kind of JS+3D runtime container it happens to be executing in.

@matthargett
Copy link
Author

The Win32_x64_D3D12 job appears to fail intermittently beyond my PR due to timeouts. Let me know if there's anything else I need to do. I'm upstreaming the NDK bump and the C++20 clang compatibility fix into JsRuntimeHost , PR in progress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant