The short answer

Run a focused 10–15 minute checklist on the Android XR device during the vendor demo or on a loaner: open two or three apps, force side-by-side and freeform windows, test virtual and external keyboards, pointer/gesture input, media continuity and copy/paste, and save screenshots and a short video for any failure.

Time needed about 15 minutes, during a demo

Key takeaways
  • Hands-on multi-window tests on the actual XR headset find failures app-store statements miss.
  • A repeatable 10–15 minute demo highlights the most common failures: resize, input, audio focus and persistence.
  • Test both virtual and external keyboards plus pointer/gesture input; each method reveals different bugs.
  • Record a short video and exact reproduction steps; vendors need those to diagnose manifest or lifecycle issues.
  • If an app refuses to resize or mutes audio when backgrounded, ask about android:resizeableActivity and the target SDK.
Before you start
  • Android XR headset or glasses paired and signed into the account you will use for work
  • All apps installed and signed in (email/messaging, document viewer/editor, browser, and a video-call app)
  • External Bluetooth keyboard and pointer available if you will test them
  • Developer options enabled on the headset or companion for optional ADB access and a laptop with adb if you will gather logs
  • Permissions granted for camera, microphone and storage for apps used in tests

The steps

  1. Prepare the device and accountsPower on the Android XR device, sign into the account, confirm the companion phone is paired, and install or update the apps you will test.You should see: Device home appears, companion shows the device as connected, and each app opens to a signed‑in screen.
  2. Open the first two apps side‑by‑sideLaunch an email or messaging app and a document app or browser, then use the XR windowing UI to place them side‑by‑side or in two freeform windows.You should see: Both app UIs are visible at once, each occupying a distinct region of the view.
  3. Resize and move windowsDrag window borders or use resize controls to make one window narrow and the other wide; move a window to a new position.You should see: Both apps reflow their UI to the new sizes without crashing and controls remain reachable.
  4. Test text input and copy/pasteFocus a text field in one app, type with the virtual keyboard, then connect an external keyboard and repeat. Select text, copy it, switch focus to the other app and paste.You should see: Text input works with both keyboards, selection highlights correctly, and paste inserts the copied text in the target app.
  5. Run a video call and present slidesOpen the video-call app, join a test call, then open slides or notes in the second window and present or switch between them.You should see: Camera and microphone stay active, video and audio continue, and slides remain visible while you navigate windows.
  6. Test browser links and background behaviourOpen a chat app and a browser. From chat, open a link to the browser, switch back and forth, and confirm tabs remain logged-in and pages do not reload unnecessarily.You should see: Links open in the browser, background tabs remain active, and session state persists when switching windows.
  7. Close and re-open an app to check persistenceClose one of the apps completely and re-open it. Observe whether its prior window size and position are restored.You should see: The app restores to the same or similar window size and position, or documents remain where you left them.
  8. Capture evidence and save resultsTake two screenshots (expected and failing states) and record a 15–30 second video reproducing any failure. Save app package names and versions, and note device model and firmware.You should see: You have at least one video and two screenshots per failing item plus a short text file with exact reproduction steps.

How to test Android apps for windowing on Android XR

Run a short, step‑by‑step checklist on the exact Android XR headset you will buy or on a loaner during the vendor demo. Open the apps you rely on, create two or three windows, exercise input and media, and record screenshots and video so you can show the failure and its reproduction steps to the vendor.

Start while the vendor watches if you can. Use the headset's native windowing controls or the companion phone UI. Check the device page at /devices/android-xr to confirm which models support side‑by‑side or freeform modes and any firmware notes.

Prerequisites and quick setup before you start

Have the headset paired, signed in and updated, with the apps installed and accounts logged in. Prepare one input method (virtual keyboard) and, if you will test it, an external Bluetooth keyboard and a pointer. Enable developer options for repeatable checks if someone on your team can interpret logs.

ADB is optional. Use adb devices to confirm visibility and adb shell dumpsys window windows to list windows only when you intend to capture logs for the vendor; include those logs only if someone on your team understands them. Check the maker support pages for firmware and XR mode differences before testing.

  • Signed-in accounts for each app you will test.
  • External Bluetooth keyboard and pointer if you will test them.
  • Developer options enabled on the headset or companion for optional ADB access.
  • Permissions granted for camera, microphone and storage where required.
  • A place to save screenshots and short videos (phone, cloud folder or laptop).

The 10–15 minute checklist you can run during a demo

Run the steps below in order. Each takes one to three minutes. If any step fails, stop, record a short video and two screenshots, and note exact reproduction steps. The sequence catches cascading problems: resizing first, then input, then media continuity and persistence.

If you handle procurement, have the vendor watch you run the checklist and ask them to reproduce the failure immediately or provide manifest and build details.

  • Open app A (email or messaging) and app B (document or browser) and arrange them side‑by‑side or in freeform windows.
  • Resize and drag both windows; verify UI reflow and reachable controls.
  • Switch focus while typing: test virtual keyboard, then external keyboard; test copy/paste between windows.
  • Start a video call in app C and present slides or notes in app B; confirm audio and video remain active while you navigate windows.
  • Open links from chat into the browser and check background tabs and login persistence.
  • Close and re-open an app and verify window size and position persist.
  • Record a 15–30 second video and two screenshots for any failure and save the exact steps.

Core test scenarios for business workflows

Focus on the three workflows your team will use: email or chat with a document, video call with slides or notes, and browser plus messaging. These exercises show different failure modes: layout and reflow, input handling, and audio/media focus.

Example apps to exercise include an email client or messaging app, a document viewer/editor, a browser and a video‑call app such as /apps/google-meet. For browser workflows also test multi‑tab behaviour and link opening in /apps/google-chrome.

  • Email + document: type, select, drag to resize, and paste between apps.
  • Video call + slides: join a call, present slides or switch to notes, then return to camera and check audio.
  • Browser + chat: open links from chat, switch tabs, and confirm session persistence.

Input, interaction and accessibility checks you cannot skip

Test both the built‑in virtual keyboard and an external keyboard. Check cursor movement, keyboard shortcuts and long‑press context menus. If users rely on a pointer or hand gestures, verify the app accepts pointer events and drag/resize gestures reliably.

Enable accessibility features your users need, such as captions or a screen reader, and confirm they follow the active audio and UI focus. Not all apps forward audio to the system caption engine in multi‑window mode; treat that as a functional gap.

  • Text entry: type, move cursor with arrow keys, select and copy/paste between windows.
  • Pointer/hand: drag to resize, hover menus and right‑click equivalents.
  • Voice/assistant: start voice input and confirm it inserts text to the active field.
  • Accessibility: enable captions or screen reader and confirm they follow the active audio source.

Performance, persistence and what to watch for

Watch UI scaling and frame rate during resize and while video plays. Look for hangs, visual artefacts, or apps that restart their activity on size change. Whether a window restores its previous size and position after relaunch shows how well the app handles multi‑window lifecycle events.

Treat sudden thermal warnings, frequent app restarts or severe throttling as symptoms that the app or device UI is not handling concurrent workloads. Note these as reasons to withhold approval until the behaviour is fixed or documented.

  • Does media keep playing while unfocused? (Pass = continuous audio/video)
  • Does the app preserve window size and position after restart? (Pass = persistent)
  • Does the UI stay responsive while typing and during media playback? (Fail if hangs, stutters or crashes)

How this fails in practice and why

A common failure chain is refusal to resize, lost input focus, then dropped audio when another window gains focus. You will see an app snap back to full screen or the text cursor disappear; these symptoms usually trace to manifest settings or unhandled activity lifecycle events.

Vendors often validate only on phones. When you escalate, ask for the manifest flags (for example whether activities are resizeable) and the target SDK they compile against; those facts indicate whether a fix is a configuration change or requires code changes.

  • Fail symptom: app snaps to full screen on resize. Cause: activity not resizeable. Fix: vendor enables resizing or provides an XR-aware build.
  • Fail symptom: external keyboard ignored. Cause: custom input handler. Fix: vendor maps standard IME events.
  • Fail symptom: audio mutes when switching. Cause: improper audio‑focus handling. Fix: vendor updates audio focus callbacks.

Record results and escalate with useful evidence

Capture two screenshots and a 15–30 second video for every failing step, plus a short text file with the exact steps you took. Save the app package name, app version, device make and model, firmware and whether you used external input so the vendor can reproduce the issue on the same configuration.

When you raise an issue ask specific questions: does the app set android:resizeableActivity, what is the target SDK, and has the app been tested on Android XR or the exact device family? Include a privacy notice for anyone in recorded calls and follow local recording rules.

  • Evidence: one short video showing the failure, two screenshots (expected and actual), app package name and app version.
  • Vendor questions: manifest resizeable setting, target SDK, testing on XR hardware, and any XR feature flags used.
  • Privacy note: inform demo participants you are recording screen and audio and obtain consent where required.

Next step: run this checklist during your next demo

Run the checklist now during the vendor demo or on a loaner unit. Use the evidence format above; if you see failures keep the recordings and ask the vendor for a manifest or a patched build to judge whether the fix is configuration or code work.

After the demo compare results with GlassesApps' app directory at /apps and the productivity category at /categories/productivity, and consult /articles/10-minute-smart-glasses-test for a condensed checklist you can reuse.

Sources and further reading

Where this usually goes wrong

  • App refuses to resize and snaps to full screenThe activity is not declared resizeable or the app uses custom window management that ignores multi‑window APIs.Capture video, ask the vendor whether android:resizeableActivity is set, and request a resizeable build or an XR‑aware release.
  • Keyboard input disappears when switching windowsThe app loses input focus or uses a custom input handler that does not follow Android focus rules in multi‑window.Record the sequence, note which keyboard was used, and ask the vendor to reproduce with standard IME events.
  • Video call mutes or disconnects when another window gets focusThe app mishandles Android audio focus or lifecycle callbacks when backgrounded in multi‑window.Provide video evidence and ask the vendor to test audio focus callbacks and background media handling on XR hardware.
  • Window position resets after app restartThe app does not persist window size/position or does not restore state on activity recreation.Ask the vendor whether they store and restore window state; persistence fixes usually require a code change.
  • Pointer or hand gestures are ignored in one appThe app uses touch‑only handlers or does not map pointer events for XR pointer/gesture input.Record a short video showing missing pointer events and request the vendor to add pointer event handling or XR input mapping.

The checklist

  • Prepare the device and accounts
  • Open the first two apps side‑by‑side
  • Resize and move windows
  • Test text input and copy/paste
  • Run a video call and present slides
  • Test browser links and background behaviour
  • Close and re-open an app to check persistence
  • Capture evidence and save results

Frequently asked questions

Do I need an ADB connection to run these tests?

No. You can run the entire checklist from the headset UI and companion app in 10–15 minutes. Use ADB only to capture dumpsys window output or logs when you want deeper evidence; include ADB logs with vendor reports only if someone on your team can interpret them.

Will apps that work on phones behave the same on Android XR?

Not always. Many apps assume a phone layout and a single active window; those assumptions break on XR. Only a hands‑on multi‑window test on the target XR hardware reveals resizing, input and audio focus problems.

What do I ask the vendor when a test fails?

Ask for the app manifest flags (for example whether activities are resizeable), the target SDK and whether they have tested on Android XR or the specific device model. Request a reproduction of your recorded video and a build that demonstrates a fix or the steps they used to reproduce.

Should I prioritise external keyboard tests or pointer/gesture tests?

Prioritise the input methods your users will use. For knowledge workers, external keyboards and cursor support matter most. For frontline users, pointer and gesture behaviour is decisive. Run both if you can; each finds different classes of bugs.

Find apps that work on your glasses

Every app in the directory lists the glasses it runs on, how it works on each, and the official source that proves it.

Browse the app directory