Environment:
- Niantic Spatial SDK (NSDK / nsdk-library-upm): 4.1.0-26051913 (git commit ee58c671595129854bf6c26aa0bfd952e6ff6e57). Also reproduced on 4.2.0 (commit 0b40e8b).
- Unity: 6000.3.11f1
- AR Foundation: 6.4.2 / ARKit XR Plugin: 6.4.2 / XR Plugin Management: 4.5.4 / Input System: 1.19.0
- Device: iPad (2025)
- Loader: NsdkARKitLoader
- VPS config: Universal Localization enabled (2 req/s), VPS Map Localization enabled (initial 2 req/s, continuous 0.5 req/s), Geolocation Smoothing disabled.Bug reproduction steps:
Description:
When the app is interrupted while a VPS localization session is active — the most reliable trigger is locking the device (or otherwise backgrounding the app) while scanning for or tracking a wayspot/ARLocation — the native VPS pipeline becomes permanently wedged.
After the interruption ends:
- ARKit itself recovers fully and normally: ARSession returns to SessionTracking, camera frames flow at 60 fps, device pose updates, GPS and compass are live. There is no ARKit error or interruption-reason.
- But VPS can no longer localize. The native VPS request loop stops issuing requests (the localization-request-record count freezes), and the map anchor (ARLocation) is never (re)acquired — it stays in tracking state None / count 0, and no VpsMapLocalize requests are produced (only UniversalLocalize continues, or in the worst case all requests stop).
Critically, this state cannot be cleared from within the running process. We have confirmed it survives:
- Disabling/re-enabling ARLocationManager (provider Stop()/Start()),
- A full XR loader Deinitialize() + Initialize() (i.e. LoaderUtility-style teardown that re-runs NsdkUnityContext.Initialize and recreates the native context, PlatformAdapterManager and the VPS2 subsystem),
- Fully exiting the AR experience and re-entering it from scratch.
The ONLY thing that restores VPS is terminating and relaunching the app process.
This strongly suggests the wedged state lives in process-global native state (e.g. a shared task runner / network/request state in nsdk) that is not reset by tearing down and recreating the Unity context.
Locking the device while NOT in an active localization session (i.e. idle, with the VPS provider stopped) does NOT cause the problem — a fresh localization afterward works. The problem only occurs when the interruption happens while a localization session is running.
Reproduction:
- Start an AR/VPS experience and begin localizing against a wayspot/ARLocation (VpsMapLocalize active; can be either still scanning or already localized).
- Lock the device (press the side/top button) — or send the app to background — while that localization session is active. (On lock, iOS revokes the camera, which interrupts ARKit.)
- Unlock / foreground the app and point the camera back at the mapped scene.
Expected: VPS resumes localizing the location, as it does on the initial uninterrupted session.
Actual: ARKit tracks normally, but VPS never localizes the map anchor again. The localization-request loop is frozen; the anchor is never acquired. This persists across provider restart, full XR-loader re-init, and exit/re-enter. Only a full app relaunch recovers VPS.
Reproducible 100% of the time on the device above.
Two requests:
- Is there a supported API to fully reset the native VPS pipeline at runtime without relaunching the process (something deeper than ARLocationManager Stop/Start or a loader re-init)?
- Could NSDK handle the app-suspend/resume (ARKit camera interruption) lifecycle so an interruption during an active localization session does not permanently wedge VPS?