Troubleshooting

Context Awareness

Inaccurate/noisy depth and semantic segmentation outputs

Check the Troubleshooting section in the Depth Overview page for details on why you may not be seeing optimal depth and semantic segmentation outputs. The section is focused on depth, but many of the model considerations should be applied to semantic predictions in a similar way as they are applied to depth estimations.

Crash on Android Devices with Awareness Features

If you’re targeting Android and getting a crash when accessing awareness features similar to:

signal 7 (SIGBUS), code 1 (BUS_ADRALN)

Make sure in your Android build settings, Scripting Backend is set to IL2CPP and Target Architectures is set to both ARMv7 and ARM64.

Localization

Takes too long for devices to find maps and stabilize

Check the best practices described in Establishing Localization for tips on how to localize more effectively. However, it is expected that older and/or slower devices will take longer to localize than the latest high-end devices.

Performance and battery impact when using AR awareness features with shared AR

Using both AR awareness features, such as semantic segmentation or meshing, and multiplayer shared AR features, such as environment co-localization scanning, can result in performance issues. In some cases this might even result in battery drain issues. If you have to use both awareness features and shared AR multiplayer and encounter performance issues, you can try the following:

Reduce the resolution (suggested 1080p) rather than using the Unity default
Reduce the FPS and fixed update time to 30fps

Hardware

Can My Device Run ARDK?

There is a helper component called CapabilityChecker that runs a hardware and software check on your device and sets a static flag ARReady to true if your device is AR capable (it will fail if run in the Unity Editor). Add that helper to your scene and query the field in your AR manager to check if your device is AR capable (or use similar code in your own manager class).

Memory Management

Memory Leaks: Anonymous Method Subscriptions and Static Wrappers

One issue with subscribing to events with an anonymous method is that there is no easy way to unsubscribe. For the top level ARDK objects (i.e., instances of IARSession, IMultipeerNetworking, IARNetworking), this is not a large issue as we can simply destroy and recreate them as needed. However, static classes (i.e., the classes ARSessionFactory, MultipeerNetworkingFactory, ARNetworkingFactory) are persistent across scenes, and will cause previously subscribed methods to be called in a new scene.

Therefore when subscribing to static events, make sure not to subscribe with anonymous methods, and to unsubscribe properly upon destruction.

Networking

Connection Fails

Check the Networking Error Codes page for how to diagnose your issue using connection error codes.

If the connection failure is due to unstable ARDK servers, check the #help channel on Slack to see if there is a reported recent outage. If not, please don’t hesitate to report the issue you are encountering on the help channel —our support team is here to assist you.

Non-deterministic Claims of Authority

GreedyAuthorityReplicator is currently not network safe. If two peers simultaneously attempt to claim the role of Authority, a race condition will be encountered. It is recommended to have peers deterministically claim authority (for example, only the host will claim authority, or each owner of a NetworkSpawned object is the authority).

Host Migration

Currently, the server does not transfer the role of host if the original host leaves a MultipeerNetworking / ARNetworking session. However, if the host leaves an ARNetworking session after generating a map, peers that join will still be able to sync against that map and perform networked actions. As there will never be a new host, any logic that is dependent on the host peer will not function properly.

Reusing Networking Sessions

See the “Reconnecting And Host Leaving” section of the Networking Limits and Best Practices page for details regarding leaving sessions and session timeout behaviour.

Platform

Platform Specific Options and Methods

A few run options are platform-specific. These are marked as such in the documentation and will result in undefined behavior. For example, the method ARCamera.ProjectPoint(...) is an iOS only method.

Permissions

Certain features may not work or cause your app to crash if they require permissions that have not yet been granted. See the Permissions page to see which features require which permissions.

While iOS permissions are automatically requested by the platform the first time a feature requiring that permission is started, Android permissions must be requested somewhere in your application code. ARDK’s PermissionRequester API wraps around Unity’s Android Permissions API to provide both async/await and callback options for methods to request permissions.

To enable greater control over when/how to request permissions on both Android and iOS, a platform-agnostic permission requesting API is in development.

Problems Using Firebase and Unity Editor with ARDK

If your Unity ARDK project also uses Google Firebase, you may experience problems while using the Unity editor on the desktop. You may see errors such as: QObject: Cannot create children for a parent that is in a different thread. The ARDK team is looking into this issue, but you can make a temporary work-around by editing your local project’s Assets/ARDK/Internals/StartupSystems.cs and in the ManualStartup() method, commenting out the _ROR_CREATE_STARTUP_SYSTEMS(); line. Your code should look something like this:

    public static void ManualStartup()
    {
#if (AR_NATIVE_SUPPORT || UNITY_EDITOR_OSX)
      try
      {
        // The following line is commented out to avoid a Firebase issue
        // _ROR_CREATE_STARTUP_SYSTEMS();
        if (ServerConfiguration.AuthRequired)
          SetAuthenticationParameters();
      }
      catch (DllNotFoundException e)
      {
        ARLog._DebugFormat("Failed to create ARDK startup systems: {0}", false, e);
      }
#endif
    }

When you build and test your project for mobile devices, you should undo this change (uncomment _ROR_CREATE_STARTUP_SYSTEMS();). This is a temporary work-around that should only be needed for using Unity on the desktop. Your project should build and run on mobile devices without needing this work-around. Note that this work-around will disable some ARDK features, such as Virtual Studio remote mode and networking.

Issues When Using the Unity Input System

If you’re seeing build errors or warnings such as “StandaloneInputModule will not work”, you might be trying to build scenes from the ARDK-Examples package in a Unity project that’s configured to use the Unity Input System. The ARDK-Examples package hasn’t been updated to use the Unity Input System, so you’ll need to remove this package from your project.