GuidesIssuesSupportGet API Key


To distribute your application follow the instructions for each respective platform. If you are distributing with Viro, please follow our Attribution guidelines. Links provided below.

Android Cardboard Distribution:

Google Daydream Distribution:

Oculus Gear VR Distribution:

Building for Production

First make sure you prepare your apk to be signed. More information on this can be found from the React native documentation:

Once you have prepared your gradle files for a signed apk, you can build a production Android app that bundles your assets and code into an apk. To do this run the following from your project root android directory (ProjName/android) in terminal:

To build for GVR or ARCore release:
./gradlew assembleGvrRelease

To build for Oculus Gear VR run:

./gradlew assembleOvrRelease

Updating Android project to Target API level 28

The following steps are needed to update your Android project to Target API Level 28. This is required as of November 2018: Google Play Store no longer accepts APKs built using any Target older than 26.

The instructions below are for Target 28. If due to other dependency issues you prefer Target 26 or 27 to Target 28, simply replace the Gradle version numbers below to what works best for your project setup.

  1. Now open android/build.gradle file.
  • If not already present, add google() under buildscript -> repositories and allprojects -> repositories sections.
  • Under buildscript -> dependencies, change gradle classpath to classpath ''
  1. Open android/gradle/wrapper/ and update distributionUrl to distributionUrl=https\://
  2. Open android/app/build.gradle and make the following changes
  • Update compileSdkVersion to compileSdkVersion 28
  • Update buildToolsVersion to buildToolsVersion '28.0.3'
  • Add flavorDimensions "platform" under buildToolsVersion, if not already present.
  • In the defaultConfig section, update targetSdkVersion to targetSdkVersion 28.
  • In the dependencies section, update compile '' to implementation ''
  • (Needed only if you are updating to target 28. Not needed for targets 26 or 27) Update our AWS dependencies (needed for key validation) to the following
    implementation 'com.amazonaws:aws-android-sdk-core:2.7.7'
    implementation 'com.amazonaws:aws-android-sdk-ddb:2.7.7'
    implementation 'com.amazonaws:aws-android-sdk-ddb-mapper:2.7.7'
    implementation 'com.amazonaws:aws-android-sdk-cognito:2.7.7'
    implementation 'com.amazonaws:aws-android-sdk-cognitoidentityprovider:2.7.7'
  • Finally, change all compile tags in dependencies section to implementation.

That's it! Sync your Android Project once these changes are done and start building.

Targeting Older Android Builds

Depending on you users and application, you might need to target and build with older versions of the Android SDK in Android Studio. To do so, simply lower the minSdkVersion version number as specified in the build.gradle file to the desired version. You will also need to inform Android about the version override in your Android manifest file with the *overrideLibrary tag:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android=""
    <!-- Required to read the paired viewer's distortion parameters -->
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
    ... other permissions ...
    <!-- Perform our override here -->
    <uses-sdk tools:overrideLibrary="com.viro.renderer"/>

Depending on the features that you want to use in your application, there is also a minimum sdk version number to which you can lower the minSdkVersion towards for them to function properly. These features and their corresponding numbers are as shown below:

ViroSceneView features
(3D rendering without AR / VR)

API level 18, as restricted by OpenGL ES 3.0.

ViroViewARCore features
(3D rendering with AR Core)

API level 24 for an AR Required App.

ViroViewGVR features
(3D Rendering with VR)

API level 19 for cardboard compatibility.
API level 25 for daydream compatibility.

You can also target a wider range of Android SDK versions by building a hybrid application made out of mutually exclusive 3D ViroCore and 2D Android layout experiences. These applications delay the creation and use of AR / VR components and only inflates them on an AR / VR capable device. Else, on non-compatible devices, developers can then display their original 2D Android content as per normal. This drastically helps increase the application's audience size and reach.

Additional Android Device Type Support

An application's audience size, or the number of supported devices are ultimately defined by the Google Play Store. It filters out in-compatible devices, based on defined features in your manifest file. For example, devices without gyroscope sensors will be deemed incompatible if your app defines a gyroscope uses-feature in your manifest. For VR / AR, features like openGL, accelerometer and gyroscopes are required.

However, for hybrid apps with exclusive 2D + optional AR experiences, there are situations where you may not want to use the gyroscope sensor at all - say, for your non-AR experiences on older devices. Currently, your app is ultimately 'blocked' from being downloaded by a larger audience with incompatible device types. For example, the gyroscope uses-feature tag required for AR then effectively blocks a large portion of your customers from downloading your app (those who don't have a gyroscope sensor), even though your app is "AR Optional" and has an exclusive 2D layout experience!

Thus, to get around this problem, we've provided you a list of uses-feature overrides that you can define in your manifest as shown below. These overrides effectively makes required features (like gyroscope / openGL / camera) optional instead. As a result, the Google Play store will then be able to identify a larger selection of compatible devices, where you can then dynamically determine AR/VR/Rendering capability and inflate your Android 2D or Viro Core 3D views as needed.


When using Overriding Tags:

Note: Because Google Play no longer has the feature tags that are overwritten to filters apps by device compatibility, developers are responsible for dynamically checking required uses-features that are needed for AR / VR rendering. As such for every uses-feature that you override with, ensure that you dynamically check for this feature in Java before loading the desired AR / VR experience!

Note that you can also pick any set of overrides above that you desire:

<uses-feature android:glEsVersion="0x00030000" android:required="false" tools:node="remove" tools:replace="required" />
<uses-feature android:name="android.hardware.sensor.accelerometer" android:required="false" tools:replace="required" />
<uses-feature android:name="android.hardware.sensor.gyroscope" android:required="false" tools:replace="required" />
<uses-feature android:name="" android:required="false" tools:replace="required" />
<uses-feature android:name="android.hardware.microphone" android:required="false" tools:replace="required" />

Here's an example of the total number of supported devices that you can target on the Google Play store with the above overrides on a Viro Core Hello World AR project: