Forum Discussion
Enrolled devices in MHMS breaks Shared Spatial Anchors
We are experiencing an unexpected and undocumented bug with the SharedSpatialAnchors when having the devices enrolled into Meta Horizon Management System. We've have reached out to MHMS through work.meta.com, though they redirected us to post our problem on this forum instead.
The problem:
When restarting a device that is enrolled in MHMS the SharedSpatialAnchors of our application no longer works.
Our application works as expected on devices not rolled into MHMS, and it also works the first time opening the app after enrolling the device into MHMS. However, when restarting the enrolled device the SharedSpatialAnchors no longer works. This happens for all devices we have attempted to enroll into MHMS, where enrolled devices fail after a restart whereas non-enrolled ones works as expected.
Our application works as expected on devices not rolled into MHMS, and it also works the first time opening the app after enrolling the device into MHMS. However, when restarting the enrolled device the SharedSpatialAnchors no longer works. This happens for all devices we have attempted to enroll into MHMS, where enrolled devices fail after a restart whereas non-enrolled ones works as expected.
The failure we are experiencing is this weird failure when saving the anchors (OVRSpatialAnchor.SaveAsync). The returning OVRAnchor.SaveResult gives FailurePermissionInsufficient, a failure message documented as "User has not granted all the required permissions for the app to use this API" but otherwise not stated in the guides.
Note that this is not the settings for Enhanced Spatial Services, which would have given the SpaceCloudstorageDisabled error. As this the name suggests it has something to do with the permissions and settings of the application we have scoured these several times in both MHMS and on the Quest 3 itself, and cant see any reason why this only happens after a restart.
Our setup:
We are using Quest 3 devices with the latest OS version v77.1027, using Unity v2022.3.60f, and the Meta SDK v77.0. The device is enrolled into a simple MHMS Device Preset with Social Features turned on, while the developer settings are enabled. On the Quest 3, the Enhanced Spatial Services is toggled.
The attached screenshot is of the code creating and saving the saved spatial anchors, though we are fairly certain it ha nothing to do with the code:
Line 138 creates the OVRSpatialAnchorcomponent on a new gameobject and the method in line 144 ensures that it has been created.
In line 146 we call OVRSpatialAnchor.SaveAnchorAsync, which gives the SaveResult FailurePermissionInsufficient in line 151.
The guides we have used to create our application is the official Spatial Anchors Overview guide on Shared Spatial Anchors:
Spatial Anchor guide from Core SDK 77:
https://developers.meta.com/horizon/reference/unity/v77/struct_o_v_r_anchor
https://developers.meta.com/horizon/reference/unity/v77/struct_o_v_r_anchor
The troubleshooting guide linked was of no help as it did not mentioned the experienced error:
3 Replies
UPDATE
After some testing we discovered the following:
Resetting the device and enrolling it into a Preset group with Socials enabled allows the ShareSpatialAnchors to run while the device is active. However, if restarting the device it no longer works.
Changing presets or device configurations does not help at all for the issue, once it has occured once we have found no solution how to resolve it.
Ive updated the inital post to reflect the reset issues.We have the same issue, only when using a device enrolled in MHMS, and only when that app is still in development (unreleased). Publishing it to the store allows the app to use spatial anchors, which we verified by changing the app id of one of our public apps, which broke spatial anchor support. Note that our app does not use shared spatial anchors (cloud saving), just local anchors.
Hi, we have exactly the same issue: our apps are using the local anchors and the devices enroled with MHMS cannot use spatial anchors anymore (whereas other devices not enroled can still use them).
It seems linked to a permission but not one we can control. It could be due to the current OS version (we are in v79 at the moment) so our solution for the moment is to wait for v80 and hope it will be resolved...
