OpenXR Hand Tracking Works in Editor but Fails on Quest Build - Feature Group and Manifest Capability Fix

Problem: Hand tracking works in Unity Editor simulation or Link testing, but after building to Quest the hands disappear, pinch input never fires, or runtime falls back to controllers only.

Quick fix path: This mismatch is usually caused by one of three gaps: OpenXR feature groups differ between Editor assumptions and Android build target, manifest capabilities do not match enabled hand-tracking features, or runtime permissions are not granted on device.

Use the checklist below to make Editor and Quest build behavior align.

Why this happens

When Editor tests pass, teams often assume device build will match. Quest builds add extra constraints:

1. OpenXR feature groups are resolved per Android target, not your Editor platform.
2. Hand tracking features can require matching manifest capabilities and store/runtime settings.
3. Device permission state and tracking mode can silently disable hand input.

So your scene setup can be correct while build metadata is still wrong.

Step 1 - Verify OpenXR settings for Android target only

1. Open Edit -> Project Settings -> XR Plug-in Management.
2. Select the Android tab.
3. Enable OpenXR for Android.
4. In OpenXR features, enable only the hand-tracking and interaction profiles your app actually uses.
5. Disable unused or conflicting features that can change capability declarations.

Verification: Android OpenXR feature list is explicit and minimal, not copied from unrelated platform settings.

Step 2 - Align hand tracking feature groups with manifest capabilities

1. Open Project Settings -> Player -> Android -> Publishing Settings (or manifest override path in your stack).
2. Confirm capability or permission declarations required for your selected Quest/OpenXR hand-tracking path are present.
3. If you use a custom AndroidManifest.xml, diff it against a known-good Unity-generated manifest to catch missing XR capability entries.
4. Rebuild after capability changes, then inspect merged manifest output.

Verification: Merged manifest contains expected XR/hand-tracking capability declarations and no stale conflicting entries.

Step 3 - Confirm Quest runtime hand-tracking mode and permission state

On the headset:

1. Enable a hand-tracking compatible mode (for example, hands and controllers).
2. Ensure app-level permission prompts are accepted.
3. Reboot headset once after changing hand tracking mode to clear stale runtime state.

Verification: Quest system UI itself detects hands before launching your app.

Step 4 - Validate input action maps in device build

1. Check that hand action maps are enabled at runtime in build, not just in Editor play path.
2. Ensure hand bindings exist for the same action asset referenced in build scenes.
3. Log action-map enable calls and first hand input events during app startup.

Verification: Device logs show action maps enabled and hand action callbacks firing.

Step 5 - Run a clean build-and-test sequence

1. Clear previous build output.
2. Build Android player with your current OpenXR and manifest settings.
3. Install fresh package to Quest (avoid relying on stale install state).
4. Run a minimal hand-tracking smoke scene first, then full scene.

Verification: Hands render, pinch/select input triggers, and no fallback-only controller behavior appears.

Alternative fixes for stubborn cases

• Reimport XR packages after Unity minor upgrades.
• Remove duplicate XR rigs or bootstrap prefabs that override runtime setup.
• Test with a clean sample scene to isolate project-specific scripts.
• Pin XR/OpenXR package versions if behavior changed after dependency bumps.

Prevention tips

• Capture a release checklist row for OpenXR feature group and merged manifest validation.
• Treat Editor-pass and device-pass as separate gates in CI or release QA.
• Keep one canonical Quest XR bootstrap prefab across all scenes.
• Re-run hand-tracking smoke tests after any XR package upgrade.

Related problems and links

• Unity Quest Hand Tracking Not Working on Meta Quest 3 - XR Input Fix
• Unity OpenXR Validation Failed on Quest 3 - XR Plugin and Feature Group Fix
• Unity XR VR Setup Not Working - Virtual Reality Development Fix
• Official docs: Unity OpenXR, Meta Quest Unity documentation

FAQ

Why does this work over Link but fail in standalone Quest build

Link and standalone run different runtime paths and capability contexts. Android manifest and device permission gaps usually only surface in standalone builds.

Do I need to edit manifest manually for every project

Not always. Start with Unity-managed manifest, then only customize when needed and verify merged output after each change.

Is enabling every OpenXR feature safer

No. Extra features can introduce capability drift and validation issues. Enable only what your app requires.

Bookmark this fix for your Quest release checklist. Share it with teammates who touch XR settings before device builds.