As a Meta Quest developer, you have the option to build .apk binaries that target specific models of Meta Quest headsets. When a user downloads your app, they download the .apk binary specific to their headset model. We call this device targeting.

Device targeting allows you to do the following:

You can apply device targeting after uploading a build through the developer dashboard, or before uploading a build by setting the necessary parameters in your android manifest, upload CLI arguments, or MQDH settings.

To help illustrate the feature, we will walk through scenarios that are likely to be among the most common use cases for the feature. Those scenarios include the following:

If your app already has a build history with no targeting, then your app builds are available to all devices. This means the Current Builds page on your Production release channel would have a single build with “All Devices” as its device target.

Wishing to end support for your app on the Meta Quest (and while adhering to our policy), you decide that the current build will be the last available build for the Meta Quest (aka freezing a build). For the next app update, you’ll create a new build and upload it to the platform. Next, you’ll go to the build detail page and remove Quest from the list of supported devices.

After saving your selection and publishing the build, you will have successfully created 2 separate tracks of builds – one for Meta Quest and the other for every other device. The table on the Current Builds page would now show two builds, with the device targets for each.

Later on, you decide that you wish to add mixed reality and other features to your app for your Meta Quest 3 users. Perhaps you also do not want to bundle the assets that enable these features into the same build for other devices since it would bloat the APK size unnecessarily. To achieve this, you would create a new build just for Meta Quest 3, upload it, select Quest 3 as the only supported device and publish it. Now the Current Build page has 3 builds including the new Quest 3 track.

So now you have bifurcated your builds into 3 separate device tracks. But let’s say you discover that there are security related issues affecting your Meta Quest users that you really need to fix. You’ll create a hotfix build and upload it to one of your private release channels (e.g. ALPHA) and set Quest as its only supported device. Once you are done testing the build, you’ll need to publish it to the Production channel to replace the current Meta Quest build. To do this:

Now the Meta Quest build has been updated, and that is reflected in the fact that it now sits on top of the current builds list.

Note: If you remove a device from the supported devices of a build that is currently live, support for that device will fall back to the next available build in the Production release channel history. That build would subsequently become the most current build for the removed device (reflected on the Current Builds page), and will trigger a rollback update on the device. You will be asked for confirmation whenever you make changes like this, with the devices being rolled back and the build they are being rolled back to displayed.

With the devices properly targeted, and your Meta Quest app being deprecated, you could decide that you no longer wish to sell your app to Meta Quest users. In other words, your app should be completely hidden from the store on Meta Quest devices which would allow you to completely drop Meta Quest support. We provide the ability to do this through a metadata update on App Submissions:

Once the changes are approved by our review team, your app will no longer be visible or searchable in the store from the selected devices. Please note that on the Mobile and Web stores, users with unsupported devices would still be able to purchase the app if they click Continue on the Purchase warning modal.

While modifying device targets on the developer dashboard allows for maximum control, developers may also do this with their build or CI system by setting a default value in the AndroidManifest.xml or CLI arguments.

In a previous blog post, we described a mechanism for discontinuing Quest 1 support by removing “quest” from the value of the com.oculus.supportedDevices meta-data tag in an application’s AndroidManifest.xml.

Device targeting complements this comprehensively with a new meta-data attribute, com.meta.store.defaultDeviceTargets. This initializes the Device Targeting settings for the binary in the developer dashboard. Multiple targets may be “joined” using the “|” operator.

For example, binaries with this meta-data tag will support only Quest 1 and 2 by default:

<meta-data android:name="com.meta.store.defaultDeviceTargets" android:value="quest1only|quest2only" />

The following specifiers may be used for this purpose:

In addition to the manifest, developers and CI systems may provide a default set of targets by providing extra context to ovr-platform-util.

To do this, include the device specifier(s) as a suffix to the --channel parameter. Like the AndroidManifest, specifiers may be combined with the “|” operator.

The following example command uploads a build to the alpha channel that targets Quest 1 and 2 only. The suffix has been highlighted in bold for clarity.

Note: values provided by the CLI or MQDH override the value of com.meta.store.defaultDeviceTargets from the AndroidManifest.xml.

Learn about uploading device targeted builds on MQDH here.

There are a number of requirements and restrictions we have put in place while using the device targeting feature. Some of these include: