search

Unity-Technologies / arfoundation-samples

Example content for Unity projects based on AR Foundation
Other
3.03k stars 1.13k forks source link

[Bug] ARSessionState.Unsupported state does not seem to be correctly checked and set #578

Closed AdrienMgm closed 4 years ago

AdrienMgm commented 4 years ago

Unity bug report case number 1270519

Describe the bug ARSessionState.Unsupported state does not seem to be correctly checked and set.

To Reproduce Steps to reproduce the behavior:

  1. Create an AR project with ARCore
  2. Use ARSession.CheckAvailability()
  3. Check ARSession.state
  4. Log the state for an unsupported device

Expected behavior After the ARSession.CheckAvailability() coroutine is finished, the ARSession.state should be ARSessionState.Unsupported for all unsupported devices.

Actual behavior We use ARSession.CheckAvailability() to check the ARSessionState before launching the tracking. In order to inform the user that the device is unsupported or it needs to install/update ARCore library. Unfortunately, the unsupported state does not seems to work properly in our project neither in your arfoundation-samples. We never fall into this state, instead we are in the ARSessionState.NeedsInstall. Once we try to install ARCore the Play store indicates that our device is not supported.

Smartphone (please complete the following information):

Edit: I have changed the title, because I swapped them by mistake

tdmowrer commented 4 years ago

This is the expected behavior for unsupported devices. See explanation here: https://github.com/Unity-Technologies/arfoundation-samples/issues/569#issuecomment-670066458

AdrienMgm commented 4 years ago

So, what is the purpose of the enum ARSessionState.Unsupported? Maybe it should be mentioned in the doc if this is the expected behaviour.

Is it, and will it always be impossible to handle the case where users install the app without going through the Playstore? Any unsupported device will fail to correctly run an AR required app, isn't that a bad UX practice?

By the way, this weird behaviour happens on a Nokia 6.1 whereas it should be compatible according to the google documentation.

Sadly, I can't run the command mentioned in your previous explanation #569 because this is an external QA that reported the issue.

tdmowrer commented 4 years ago

Is it, and will it always be impossible to handle the case where users install the app without going through the Playstore? Any unsupported device will fail to correctly run an AR required app, isn't that a bad UX practice?

Yes. This is how ARCore works, and it is not something ARFoundation can reason about.

By the way, this weird behaviour happens on a Nokia 6.1 whereas it should be compatible according

There are specific device variants that aren't always supported. Without more details, I can't give you more information. Can your external QA run that command?

tdmowrer commented 4 years ago

This is the ARCore documentation for the function that checks for device compatibility:

For ARCore-required apps (as indicated by the manifest meta-data) this method will assume device compatibility and will always immediately return one of AR_AVAILABILITY_SUPPORTED_INSTALLED, AR_AVAILABILITY_SUPPORTED_APK_TOO_OLD, or AR_AVAILABILITY_SUPPORTED_NOT_INSTALLED

So ARFoundation asks ARCore "what is the support status?" and ARCore, if it is "required", assumes it must be running on a compatible device. Since it can't find the ARCore APK already on the device, it gives us the AR_AVAILABILITY_SUPPORTED_NOT_INSTALLED case, which is why ARFoundation then tries to install ARCore from the Play Store.