Skip to content

android(test app): declare CAMERA + WAKE_LOCK permissions for Lume Pad#350

Open
leaiss wants to merge 1 commit into
mainfrom
feat/android-permission-audit
Open

android(test app): declare CAMERA + WAKE_LOCK permissions for Lume Pad#350
leaiss wants to merge 1 commit into
mainfrom
feat/android-permission-audit

Conversation

@leaiss
Copy link
Copy Markdown
Collaborator

@leaiss leaiss commented May 27, 2026

Summary

Pre-Lume-Pad audit of the test app's AndroidManifest.xml. Adds two missing permissions that would otherwise silently degrade the day-1 experience, plus a Step 0 in android-bringup-checklist.md documenting how to grant them.

What this fixes (silent failures avoided)

Missing Day-1 symptom Fix
android.permission.CAMERA CNSDK's libleiaSDK-faceTrackingInApp.so opens the front camera at leia_core_enable_face_tracking. Without CAMERA: silent open() failure, no face reported, xrLocateViews always returns default centered eye position. No crash, no log error — just no head tracking. Hours of "why isn't head tracking working" debugging. Declared in manifest + pm grant documented
uses-feature camera.front Play Store filters the app off no-camera devices, AND Android may not surface camera in runtime dialog Declared required="false" so emulator (no camera) still installs
android.permission.WAKE_LOCK Long XR sessions don't generate input → screen dims/sleeps → session pauses Declared (install-time grant)

Notes on CAMERA runtime grant

CAMERA is "dangerous" on Android 6+; declaring it in the manifest isn't enough — the user must grant at runtime. The test app is a pure NativeActivity with no Java/Kotlin wrapper to surface the system dialog. Two workarounds documented in the bring-up checklist:

  1. Pre-grant via adb (works on emulator + developer-mode device):
    adb shell pm grant com.displayxr.cube_handle_vk_android android.permission.CAMERA
  2. Wait for CNSDK's own dialog at first leia_core_enable_face_tracking — depends on CNSDK behavior on Lume Pad, untested pre-hardware.

Production-quality permission handling (wrap NativeActivity in a Kotlin Activity that calls requestPermissions() at onCreate) deferred — that's a separate ~50 LOC change with its own review concerns.

Verification

Built + installed on the Android-36 emulator:

$ adb shell dumpsys package com.displayxr.cube_handle_vk_android | grep -E 'CAMERA|WAKE_LOCK|INTERNET'
      android.permission.INTERNET
      android.permission.CAMERA
      android.permission.WAKE_LOCK
      android.permission.INTERNET: granted=true
      android.permission.WAKE_LOCK: granted=true
        android.permission.CAMERA: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]

Install/launch unchanged. xrCreateInstance -> XR_SUCCESS still reaches the runtime as before.

Test plan

  • On Lume Pad, run the bring-up checklist Step 0 → confirm dumpsys package | grep CAMERA shows granted=true before launching the app.
  • Head tracking works during session (visible face-driven parallax / cube perspective).
  • If CNSDK throws its own permission dialog before Step 0's pm grant is run, document the timing in the bring-up doc for future installs.

🤖 Generated with Claude Code

CNSDK's face tracker (libleiaSDK-faceTrackingInApp.so, loaded by the
broker into the test app's process) needs the front-facing camera at
runtime. Without `android.permission.CAMERA` in the manifest:

  - The system camera service silently refuses the open() call.
  - CNSDK never reports a detected face.
  - xrLocateViews falls back to the default centered eye position.
  - **No crash, no log error** — just silently no head tracking on
    Lume Pad. Hours of "why isn't head tracking working" debugging
    saved by declaring this up front.

Adds:
  - uses-permission CAMERA + WAKE_LOCK
  - uses-feature camera + camera.front (required=false so the same APK
    still installs on the emulator which has no camera HW)

CAMERA is "dangerous" on Android 6+ — declared in the manifest, but
the user must also grant it at runtime. Test app is a pure
NativeActivity with no Java wrapper to surface the system dialog. Two
day-1 workarounds documented in android-bringup-checklist.md Step 0:

  1. `adb shell pm grant com.displayxr.cube_handle_vk_android \
       android.permission.CAMERA` (pre-grant via developer mode)
  2. Wait for CNSDK to throw the system dialog at first
     leia_core_enable_face_tracking (untested — depends on CNSDK
     behavior on Lume Pad).

Production-quality permission handling (wrap NativeActivity in a
Kotlin Activity that requests permission at onCreate) deferred to
follow-up.

WAKE_LOCK is install-time and lets the runtime keep the screen on
during long XR sessions without user input.

Verified on emulator: install/launch unchanged, xrCreateInstance
still reaches XR_SUCCESS, declared permissions visible via
`adb shell dumpsys package`.
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