When Meta upgraded devices from Android 10 to Android 12 under the hood with Quest firmware version 51, ManageXR became restricted in the ways it could write files to specific directories. While ManageXR can still write to almost any directory, /Android/data is unique. We implemented a temporary workaround to prevent disruption to your workflows, but Android has been trying to restrict apps from giving complete access to /Android/data since the release of Android 11. And, as we cautioned in prior announcements, deploying to this directory would stop being possible at some point in the future.
Our testing of the latest firmware on the Meta Public Test Channel has shown this workaround for deploying files to /Android/data is no longer viable on Meta devices on version 63 or above.
What this means for your deployment
You will no longer be able to grant permission to remotely push files to /Android/data via ManageXR on Meta Devices running v63+
You may still preload files via the Device Setup Tool - but ManageXR will not be able to report on the status of those files. Devices with preloaded files to Android/data will report being Out of Date
Devices with files already deployed prior to firmware v63 to /Android/data may continue to work as intended–but it is unclear if this will behave reliably
Your applications will need to be updated to read from other directories
It is officially time to migrate from deploying files to /Android/data via ManageXR. Although this may require updating your applications, we recommend customers do this as soon as possible to avoid interruptions to updates and your end-user experience.
Migration strategies
Your steps to migrate successfully will depend on your specific deployment and your ability to confirm your devices are up to date in ManageXR.
Strategy 1 [recommended]
Pick a new destination for your applications data
Potentially /Android/obb/{com.your.packagename} - or a public directory that is accessible without specific permissions, depending on your needs
Deploy files to the new location in addition to the old location. You can do this!
Update your applications to be able to read from both the new location or the old location (with a preference for the new location)
Once your new application is deployed, remove the previous files
Update your applications to no longer read from the old location
Strategy 2
For a simpler migration plan that requires more active management, you could deploy both the new application version that will read files from an accessible location and the files in their new location at the same time. Depending on the size of your downloads, this might cause interruptions to your end-user experience!
Pick a new destination for your application data
Potentially /Android/obb/{com.your.packagename} - or a public directory that is accessible without specific permissions, depending on your needs
Update your applications to be able to read from the new location instead of the old
Deploy files to the new location along with your updated application
How to copy files to new directories
We recommend using our nested files feature to do this! You should be able to recreate your folder structure from within this library and then redeploy them in a new directory.
Here's a quick example:
Need help getting your file structure configured or want to talk about your migration plan? We're here to help! Drop us a note at support@managexr.com, or use the chat bubble in the bottom right of your screen.
Frequently Asked Questions
My app can write to its /Android/data, so why can’t ManageXR?
My app can write to its /Android/data, so why can’t ManageXR?
Individual Android applications have permission to write to their own folder within /Android/data. For example, if your application is com.application.packagename, you would have read and write access to /Android/data/com.application.packagename. Some developers deploy files here via ManageXR so their applications can read them without additional permissions.
This is meant to be a private directory specific to your app. Android has been slowly removing other applications’ ability to read and write to this directory over several Android versions. In some ways, this is an attempt to improve privacy and security - but in others, it limits what third-party applications can do.
Will devices with files already deployed to /Android/data continue to work as intended?
Will devices with files already deployed to /Android/data continue to work as intended?
Our testing has revealed that devices with existing permissions for /Android/data appear to continue to work - but we have no idea how long this will last or how well this will behave, and we cannot commit to supporting this for the long term.