Unity as a Library Support #2416
Description
The Problem
Unity as a Library allows users to export the game as a library to be embedded in a different app. Right now, the SDK assumes the game gets exported as a standalone app on all platforms.
See the relevant Unity docs. The currently supported platforms are Android, iOS, and UWP.
Context - Android Investigation
I did some testing on Android and have a couple of findings:
- How to capture native crashes with the Android SDK see here - It details how to set up the Android SDK to "cover" the activity Unity uses to run the game
- How to capture C# errors see here - It details how to currently configure the Unity SDK to work in the UaaL usecase
Issues
- The guides above are not connected in any way. This leads to a lack of scope sync, breadcrumbs, and Unity context in native crashes.
- Symbol Upload is unresolved. If the library is exported, can those symbols be guaranteed to be present when building the actual app? Afaik we need to keep automatically emitting IL2CPP line mappings and uploaded, see
IL2CPP Pre Build- Windows:
UploadSymbols - Android:
UploadSymbols - iOS:
UploadSymbols
Proposal
With the changes to how the native SDKs get initialized in for Android (see #1924) and iOS (see #1915) the SDK no longer assumes them to already be active and initializes and sets up scope sync right before initializing.
Finer control through the Options
This means that the options AndroidNativeSupportEnabled and IosNativeSupportEnabled would need to change. They control at build time whether to add the native SDK to the generated project and at runtime whether to attempt to initialize it.
We'd need:
- One set of options to enable the Unity SDK providing and adding the native SDKs at build time.
- One set of options to check at runtime whether to attempt to initialize and sync with the native SDK if one is found.
Bridge Modification
Which is already almost the UaaL environment. We could make the bridges be more robust in attempting to check whether there is a surrounding native SDK and then call into it. Ideally, this would be tied to a version check somehow, like we intend to do for consoles too.