Creating an XR provider

An XR provider is part of a Unity project and minimally consists of a manifest file and one or more native plug-insA set of code created outside of Unity that creates functionality in Unity. There are two kinds of plug-ins you can use in Unity: Managed plug-ins (managed .NET assemblies created with tools like Visual Studio) and Native plug-ins (platform-specific native code libraries). More info
See in Glossary. It can also include other assets such as scriptsA piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info
See in Glossary and images. As long as these are in your project when you launch the Editor, Unity discovers them.

Note: You must relaunch Unity whenever you change a provider’s manifest or Editor native plug-inA platform-specific native code library that is created outside of Unity for use in Unity. Allows you can access features like OS calls and third-party code libraries that would otherwise not be available to Unity. More info
See in Glossary.

File layout

Native plug-ins must be in a subfolder relative to UnitySubsystemsManifest.json. If your provider is not part of a package, Unity only finds UnitySubsystemsManifest.json files that are up to one level deep in the Assets folder.

UnitySubsystemsManifest.json

This manifest contains information about your provider, such as the subsystems it provides and the plug-in name.

For more information, see the UnitySubsystemsManifest.json page.

Building a provider plug-in

To learn how to build a native plug-in for your targeted platform, see documentation on the Unity native plugin interface. After you get your dynamic library into Unity, ensure that all of the options (such as the target platform in the Plug-in Settings) are correct.

You need to register a lifecycle handler for the subsystems that you intend to implement. For example:

extern "C" void UNITY_INTERFACE_EXPORT UNITY_INTERFACE_API
UnityPluginLoad(IUnityInterfaces* unityInterfaces)
{
  s_XrDisplay = unityInterfaces->Get<IUnityXRDisplayInterface>();
  UnityLifecycleProvider displayLifecycleHandler =
  {
    NULL, // This can be any object you want to pass as userData to the following functions
    &Lifecycle_Initialize,
    &Lifecycle_Start,
    &Lifecycle_Stop,
    &Lifecycle_Shutdown
  };
  s_XrDisplay->RegisterLifecycleProvider("Provider Plugin Name", "Display0", &displayLifecycleHandler);

  // Register with other subsystems
}

Note: The parameters passed to RegisterLifecycleProvider must match the name and id fields in your manifest file.

When you call your Initialize method at a later point, you get an instance handle you can use to call methods that take a UnitySubsystemHandle. Example:

/// Callback executed when a subsystem should initialize in preparation for becoming active.
static UnitySubsystemErrorCode UNITY_INTERFACE_API Lifecycle_Initialize(UnitySubsystemHandle handle, void* data)
{
  // Register for callbacks on the graphics thread.
  UnityXRDisplayGraphicsThreadProvider gfxThreadProvider = { NULL, NULL, &GfxThread_WaitForNextFrameDesc, NULL };
  s_XrDisplay->RegisterProviderForGraphicsThread(handle, &gfxThreadProvider);

  return kUnitySubsystemErrorCodeSuccess;
}

The SDK package includes an example project that builds sample plug-ins.

Loading in Unity

For more information about loading your provider in Unity, see the Runtime discovery and activation of subsystems page.