Why Mobile VR Apps Need Headset-Specific Work

Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below.

A Cardboard VR app and an Android VR app are not the same thing as a “VR app” in the abstract. They live on a specific headset SDK, a specific Android build, and a specific set of video playback assumptions. Every time one of those shifts, the app has to be adjusted. This explainer looks at headset-specific work in a mobile VR app through the history of Fulldive VR (package in.fulldive.shell, repo fulldiveVR/fulldive-unity), with the important caveat that everything below is historical repository evidence, not a statement about what the current app supports on any given store today.

Why headset-specific work is unavoidable

A mobile VR app renders into whatever projection pipeline the headset SDK gives it. On Cardboard, that is a simple phone-held-in-a-lens housing with tap events and no controllers. On WaveVR (HTC’s runtime for the Vive Focus family), it is a full 6DoF pose with controller inputs. On Daydream, it was a smartphone plus a three-DoF controller. Each runtime imposes different assumptions about:

How the eye textures are composed.
What input the user can produce (tap, gaze, controller buttons, trigger).
Which Android permissions the app must request at runtime and when.
How the system draws overlays, system dialogs, and brightness controls on top of the rendered scene.

Change the runtime or change the Android OS, and pieces of the app break in small, inconsistent ways. The fulldive-unity repository in 2021 shows the shape of that maintenance work clearly: WaveVR browser changes, Vive SDK updates, permission handling adjustments, localization fixes, and video scaling fixes all landed in the same period. That maintenance bleeds into adjacent areas of the codebase too — for example, later 2023 main-panel text formatting work (commit 6eef91a3) and 2024 engine modernization (commit dfc07c05) both touch the same rendering surfaces the headset SDKs drive into. These are historical commits from a period when the product targeted WaveVR-family headsets alongside phone-in-housing Cardboard-style use; they are not a claim that the current build ships WaveVR or Cardboard support today.

WaveVR, Vive, and the Android browser surface

The fulldive-unity 2021 commit pattern includes WaveVR-specific browser adjustments. That is not “WaveVR support” as a bullet point. It is the concrete plumbing of: how a URL text field accepts input when the only keyboard is the controller, how pages scroll on a curved in-VR surface, how video inside a page surfaces to the in-app player.

The browser work is part of a broader pipeline we described in the 360 and 3D video post. The in-app browser uses a dedicated brightness shader (commit 92e73443) because the user cannot reach the phone’s brightness slider from inside a headset, and playback controls inside the browser surface are their own code path (commit f04087ba). Change the headset SDK, and both of those paths need revalidation.

Permissions, localization, and video scaling

The 2021 permission-handling work in Fulldive VR reflects real Android platform pressure. Runtime permission flows have changed repeatedly across Android 10, 11, 12, and 13. A mobile VR app that predated one of those releases did not automatically keep working; the in-VR UI had to be wired to handle the system’s new permission prompts, and in some cases the Unity side had to pause the scene while the Android side surfaced a dialog.

Localization fixes from the same period reflect the mundane but real work of shipping a VR app globally: string catalogs, right-to-left layout in the browser chrome, and text rendering on curved surfaces. Video scaling fixes reflect the fact that the correct eye-texture resolution depends on the headset, the GPU, and the source video. Picking wrong on any of these produces letterboxing, cropping, or blurred 360 content.

None of this is visible from a store description. All of it is required to keep a mobile VR app installable and usable.

What this tells a new Android VR developer

The lesson from the repository is not specific to Fulldive. Any Android VR app that targets more than one headset SDK takes on per-headset engineering cost. The Android Developers XR references (Android XR overview) and Unity’s own XR platform documentation (Unity XR Plug-in Framework) make this architectural choice explicit: each provider plugs in behind a common interface, but platform-specific quirks leak through the abstraction. That is where the work is.

What this does not do

Fulldive VR’s repository shows WaveVR, Vive SDK, and Cardboard-style commits in 2021. We are not saying the current store build runs on Cardboard, Daydream, or WaveVR. Google retired the Daydream platform in 2019; Cardboard is maintained as open source but is no longer a first-party Google runtime; WaveVR continues through HTC for its own devices. Before using any Fulldive VR version with a specific headset, check what the current Android build actually declares — and treat this post as a history of headset-specific engineering, not a compatibility chart.

How Fulldive VR plays 360 and 3D video on Android covers the player pipeline that sits on top of these SDK layers.
Rebuilding Fulldive VR: Unity migration and legacy repairs explains the 2024 engine modernization.
What a mobile VR app can and cannot do in 2026 frames the honest current state.
The Fulldive company story places Fulldive VR inside the wider Android app ecosystem.
Fulldive apps lists every current product.

Sources

Repository evidence: fulldiveVR/fulldive-unity, 2021 commit pattern around WaveVR, Vive SDK, permission handling, localization, and video scaling; supporting commits f04087ba, 92e73443, 6eef91a3, and dfc07c05; history inspected 2026-04-13.
External reference: Android XR developer overview.
External reference: Unity XR Plug-in Framework.

Last updated: 2026-04-16. Commit hashes and version numbers are drawn from Fulldive repositories inspected on 2026-04-13.