Quest Binary Device Targeting
Updated: Dec 19, 2024
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:
- have separate builds that match the separate performance abilities of Meta Quest 3 and older devices
- have a separate build leveraging the unique capabilities of the Meta Quest Pro
- end support for apps on an older device such as the original Meta Quest (see our policy on ending support)
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.
Device Targeting on the Developer Dashboard
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:
- Discontinuing support for an app on the Meta Quest
- Having a special build just for Meta Quest 3
- Pushing hotfixes to the discontinued app on the Meta Quest
- Having a main build for every other device
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:
Click the “Change Current Build” button on the top right on the Production release channel Current Build page to launch the modal
Select the device track you wish to update (in this case Quest). This will filter the builds in the dropdown to only the ones that support those devices across all channels.
Select the Quest-only build uploaded earlier
Change the build status to “Approved” and click submit
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:
- Create a new app submission. This should clone your most recent approved submission
Ensure the Release Holdout checkbox is unchecked
Go to the Specs section under the App Metadata tab and select “Quest” on the Purchase-Blocked Devices field
- Save changes and submit for review
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.
Device Targeting Outside the Developer Dashboard
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.
Setting default device targets using the AndroidManifest.xml 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:
- quest1only, quest2only, questproonly, quest3only
- quest2+, questpro+, quest3+
- questpro-
Setting default device targets using the CLI 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.
ovr-platform-util upload-quest-build -a APPID -s SECRET --apk build.apk --channel "alpha:
quest1only|quest2only
"
Note: values provided by the CLI or MQDH override the value of com.meta.store.defaultDeviceTargets
from the AndroidManifest.xml.
Setting device targets through MQDH Learn about uploading device targeted builds on MQDH
here.
Requirements and Restrictions
There are a number of requirements and restrictions we have put in place while using the device targeting feature. Some of these include:
- A build must support at least one device
- An app must always have at least one forward-compatible build among the current builds in its LIVE release channel
- A forward-compatible build is one that has “Future devices” included in its supported devices
- A build included in an app submission is required to be forward-compatible
- For builds attached to an app submission, their supported devices cannot be changed while the app submission is pending review
- Once an app is released with support for set of devices, there must always be at least one build that supports each device
- This means you cannot remove support for a device by removing that device from all published builds in the build history of your LIVE release channel
- If you wish to end support for a device, you’ll have to go through App Submission (explained above) to hide your app from the store.