Cardboard scans QR codes and may follow redirects while looking for viewer parameters

Three features, two languages, one viewer parameter

The SDK's stated scope is small and specific. It provides what you need to create your own virtual reality experiences for Google Cardboard, and it names the essential features: motion tracking, stereoscopic rendering, and user interaction via the viewer button.

With those three you can build new VR experiences or add VR to an existing app. That is the entire promise, and it is narrower than a general VR engine because the target is a phone in a viewer rather than a headset with a positional tracking system of its own.

The binding is C++ for both platforms. The getting started pointers are separate for Android NDK and for iOS, and the API reference is a single document covering the Android NDK and iOS surface together, which suggests the two platforms share a common core rather than being two independent implementations.

The repository layout matches that. There is a `sdk/` directory holding the shared and platform specific code, a `java_api/` directory for the Android side, and `proto/` for the generated interface. Sample applications sit at `hellocardboard-android/` and `hellocardboard-ios/`, and there is also a `paperscope/` directory whose purpose the README does not describe.

Build files for both toolchains are at the root: `build.gradle`, `settings.gradle`, `gradle.properties`, the `gradlew` wrapper and its Windows batch file, plus a `Podfile` and a `Cardboard.xcworkspace/` for the iOS side.

There is also a `third_party/` directory, which tells you the SDK vendors some dependencies rather than fetching them all, and a project that has done so for VR will care what and why.

QR scanning can leave the device, and that is documented rather than assumed

This is the section that deserves the most attention from anyone doing a security or privacy review, and it is unusual that a SDK documents it this plainly.

The README states that the libraries `cardboard` and `cardboard-xr-plugin` do not collect any data. Then it qualifies that: when a QR code is recognized during scanning as requested by the developer, these libraries may make multiple web requests to retrieve the Cardboard viewer device parameters.

The behaviour is specified exactly. If the decoded URL matches `https://google.com/cardboard` or `https://google.com/cardboard/cfg?p=...`, it is parsed locally to retrieve the viewer device parameters. Otherwise, the decoded URL is requested through a normal web request, and any HTTP redirects are followed until a matching URL is found.

That second branch is the significant one. A QR code that encodes anything else, including a shortener, an attacker controlled page, or a redirect chain, results in the SDK making an outbound request to it and following whatever it redirects to, and doing so potentially multiple times, before it finds a Cardboard URL or gives up.

So the trust boundary is the camera and the code the user points it at. On a device without egress this becomes a visible failure rather than a silent one, which is a reason to test scanning in your target network rather than on a laptop.

The two files that implement it are named: `QrCodeContentProcessor.java` under `sdk/qrcode/android/java/com/google/cardboard/sdk/qrcode/`, and `device_params_helper.mm` under `sdk/qrcode/ios/`. Those are the files to read when you need to know exactly what your application does with a scanned code.

Apache 2.0 for the assets, and the name is not licensed

The licensing has two halves and the second one is easy to miss.

The SDK assets are licensed under the Apache License 2.0. The repository metadata reports the project licence as a custom one GitHub cannot classify, which is consistent with the LICENSE file at the root carrying the Apache text plus the trademark terms below it.

The trademark position is stated clearly. The Google Cardboard name is a trademark owned by Google and is not included within the assets licensed under the Apache License 2.0.

The brand guidelines then draw a line with specific examples on each side, which is more useful than a general prohibition.

What you can do: use the mark to describe or refer to apps developed with the Cardboard SDK in ways that would be considered fair use, and to make truthful factual statements about compatibility or interoperability. The examples given are that an app is compatible with Google Cardboard or that an app works with Google Cardboard.

What you cannot do: use it in a manner implying that Google has endorsed or authorized your app or that makes it appear an official Google product, with the specific example of not calling your product an official Google Cardboard app; incorporate it into your own product names, service names, trademarks, logos or company names; display it misleadingly, unfairly, defamatorily, infringingly, libelously, disparagingly, obscenely or objectionably; and alter or distort it, including through hyphenation, combination or abbreviation, with the examples of not writing G Cardboard or Google-Cardboard.

The project also points at Google's own trademark usage guidelines at google.com/permissions/logos-trademarks, so the README's list is the floor and not the whole.

For a viewer manufacturer there is a separate note: the Cardboard viewer specification is open source and ready to use for building a viewer.

Release cadence, and where the actual API lives

The release history shows a project on a steady quarterly cadence. The recent tags are v1.35.0 on 2026-08-31, v1.34.0 on 2026-05-28 and v1.33.0 on 2026-03-11, and the last push was on 2026-08-31, the same day as v1.35.0. The repository is not archived.

Because the numbers move every few months, a native dependency on a specific SDK version needs a policy.

The documentation is hosted on Google's developer site rather than in this repository, and the README gives four entry points and no inline tutorial. There is a quickstart for Android NDK and one for iOS, an API reference for both platforms, release notes on the releases page of the repository, and a roadmap on the Projects page.

So this repository is the source plus a pointer. If you want to understand what changed in a version, the release notes on the releases page are where the detail lives, not the README.

Contribution instructions are a single line: read and follow the steps in `CONTRIBUTING.md` at the root. There is a `.github/` directory and an `.idea/` directory, so the project carries both continuous integration configuration and JetBrains project files.

Where a general VR engine, or your own tracking, fits instead

If your target hardware is a standalone headset rather than a phone in a viewer, this SDK is answering a question you are no longer asking. Its three features are the ones that make sense when the phone's own sensors and screen are the device.

If you are writing for several VR platforms at once, a cross platform engine with its own abstraction layer will save more than this SDK gives you, because Cardboard is one target among several and this SDK does nothing about the others.

Against writing the pieces yourself: motion tracking on a phone is a sensor fusion problem, stereoscopic rendering is two viewports with an IPD calculation, and the viewer button is a Bluetooth input device with its own pairing story. The QR scan exists because the viewer parameters cannot be reliably guessed, which is a real constraint and one you would have to solve yourself.

The honest limitation is the one the README does not quantify. It does not state which viewer models are supported, what happens when a scan returns an unrecognised device, or how device parameters are cached after a scan. For a shipping application those are the questions to answer from the source and the release notes rather than assume.

What the SDK does give you is the parameters themselves, which is the part that would otherwise tie your application to the device it happens to be running on.

Editorial conclusion

Adopt the Cardboard SDK if your target hardware is a phone based viewer that fits in a cardboard holder and you want Google's own parameters for those devices rather than a generic mobile VR framework. Do not adopt it for new work without checking device support, because the repository's most recent release is v1.35.0 from 2026-08-31 and nothing in the README states which viewers are still supported or what happens on an unrecognised one. Verify first that your build can scan a viewer QR code without unexpected egress, since the SDK documents that a decoded URL which is not the Cardboard configuration URL is requested over the network with redirects followed, and on an air gapped network that call becomes a hang.

Frequently asked questions

Official sources

1. googlevr/cardboard on GitHub
2. Issues
3. README
4. Releases