How should I do feature detection for AR support?

[milesgreen]

What’s the best way to do feature detection to check for AR support on a device?

Would like to display alternative content / messaging. Not sure best way to tell if SceneViewer is supported and available?

[cdata]

@milesgreen I would take a look at what we do for activating Scene Viewer: https://github.com/GoogleWebComponents/model-viewer/blob/2d4aaf35735397a1d89f7f5df28f8a0a080d569c/src/features/ar.ts#L38-L82

The important thing to understand is that there is no way to detect the availability of Scene Viewer up front. You have to trigger an intent, and you can only trigger an intent when the user interacts with the page.

When the intent fails, it will navigate to a configured browser fallback URL if provided. In <model-viewer>, we look for a hashchange event to detect if the fallback URL was hit, and if it was, we know that Scene Viewer is not available. But, it's impossible to detect this until the user interacts with something.

<model-viewer> has a fallback mode where it goes fullscreen. You can check for <model-viewer> going fullscreen and then display your alternative content at that time. We don't have any good built-in option for folks who want to take specific, custom action in response to the Scene Viewer intent failing. You can request such a feature if you think there is a good way for us to help out there.

[milesgreen]

OK. Thanks.

So we can't predetermine if it'll work on a user's device, but we can detect if the intent fails. Got it.

With regards to listening for fullscreen; but doesn't <model-viewer> always go fullscreen as the first step (tap on cube icon)? From there the user taps View in your space. I guess I'm not clear exactly where <model-viewer> ends and Scene Viewer begins, and at which point the intent is actually being triggered. 😖

Surfacing Scene Viewer intent failing as an event of <model-viewer> might be a helpful feature though?

[mkeblx]

@milesgreen When you see the View in your space non-AR screen that is within Scene Viewer: the intent has been successful and SV has been launched. It is a fullscreen Android view but different than model-viewer's Fullscreen API fallback view. The intent is triggered right when you click the cube icon.

Yes I would also find it useful to have an event triggered for intent failing.

[milesgreen]

Thanks for clarifying @mkeblx

[nicolocarpignoli]

@cdata Hi there,
what I'm trying to achieve is:

• when user clicks on the button to enter on the AR
• I can navigate to a fallback URL.

Questions:

• Is that possible?
• How can I listen for the intent failure, and then trigger a navigation?
• Also, this will work for both iOS and Android?

Thank you so much

[cdata]

Yes, that's possible with Android devices. Unfortunately, <model-viewer> has a built-in fallback right now and it requires that we use the fallback URL mechanism. However, you can see documentation on adding a fallback URL to an Android intent here: https://developer.chrome.com/multidevice/android/intents#example

If you combine the documentation above with the documentation for launching Scene Viewer, you can achieve what you are trying to do: https://developers.google.com/ar/develop/java/scene-viewer

Separately, it would be feasible for us to dispatch an even when we fail to launch Scene Viewer. However, we do not do that today, so it would need to be a separate feature request.

[nicolocarpignoli]

@cdata is there any update on this with latest releases? the feature detection and event triggering about Scene Viewer launch fail is the same of the previous comments? Thanks

[elalish]

@nicolocarpignoli Things have improved a bit in this regard. We now expose an ar-status attribute & event which will change to "failed" when the user attempts to enter AR and can't. We no longer have the fullscreen fallback, so that flow is also simpler. We can't detect a failure on iOS, but so far that doesn't seem to be much of a problem (it's always available).

[nicolocarpignoli]

@nicolocarpignoli Things have improved a bit in this regard. We now expose an ar-status attribute & event which will change to "failed" when the user attempts to enter AR and can't. We no longer have the fullscreen fallback, so that flow is also simpler. We can't detect a failure on iOS, but so far that doesn't seem to be much of a problem (it's always available).

That's good to know, thanks!

About iOS: last time I tried it was available for iOS 13 - and now 14 (it was NOT working for iOS 12 even if they claim it does). I don't know if now they fixed it on iOS 12 but the more we go on the less is relevant. Probably now iOS 13 + iOS 14 covers pretty much the 80-85% of Apple's devices

[avalyset]

Reviving this old thread with a distinct failure mode that isn't quite what's discussed above. The thread covers detecting when the Scene Viewer intent fails to launch. cdata noted back in 2020 that "it would be feasible for us to dispatch an event when we fail to launch Scene Viewer. However, we do not do that today, so it would need to be a separate feature request" — and ar-status="failed" now covers that launch-attempt case.

What I hit is different: the Scene Viewer intent launched fine, but the AR session then failed inside Scene Viewer's process — ARCore returned "Failed to create CameraConfigManager: Unable to build any valid camera configs", so session-started never fired. The device was a Pixel 9a (codename tegu), which appears to be missing from ARCore's device-profile database ("Found nothing for tegu/tegu"); it fell back to a generic profile. It only resolved after clearing ARCore's local data (pm clear com.google.ar.core), which forced a re-sync of the device-profile / Phenotype cache. Notably, a full system + Play Store update did NOT fix it — the ARCore package was untouched by the update and AR still failed; only clearing ARCore's data worked.

From model-viewer's side this post-handoff failure is completely invisible: ar-status fires session-started on launch intent, with no signal at all when the session fails inside Scene Viewer afterward — the user just returns to the browser with no indication anything went wrong. So this is a separate gap on top of the launch-failure one: even with a launch-failure event, a failure after a successful handoff still wouldn't be caught. Likely unfixable given the fire-and-forget intent architecture, but worth noting for anyone debugging a "works on some Android devices, silently fails on others" report.