GuidesReferenceIssuesSupportGet 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.

ARCore (in developer preview)

Android Cardboard Distribution:

Google Daydream Distribution:

Oculus Gear VR Distribution:

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:


Required Android Min Sdk Version

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. Also note that once you use the overrides above, you no longer need to include it's corresponding "uses-permission" in the manifest (it's one or the other).

<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:

ABI Splitting

ViroCore includes architectures for two generations of ARM devices: armeabi-v7a and arm64-v8a. This means both of these will be packaged in your APK -- even though your customers only need one or the other. To ensure that your customers only receive the ABI they need, we recommend using Android's ABI splitting feature. This will dramatically reduce the binary size of your app.

To use ABI splitting, add a splits block to your module-level build.gradle file. In the example below, we produce on APK for armeabi-v7a architectures, and one for arm64-v8a architectures. This is the recommended configuration for apps using Viro.

android {
  splits {
    abi {
      enable true

      // Specifies a list of ABIs that Gradle should create APKs for
      include "armeabi-v7a", "arm64-v8a"

      // Specifies that we do not want to also generate a universal APK that includes all ABIs
      universalApk false

Once you've added this to your gradle, select the module in the Project Pane and build with Build > Build APK. The APKs for each ABI will be placed in the project's build/outputs/apk/ directory.