Unity as a Library Support

Aperta
#2,416 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
android, csharp, ios, unity

Direzione di ricerca

Inizia leggendo le opzioni AndroidNativeSupportEnabled e IosNativeSupportEnabled e le modifiche all'inizializzazione nativa referenziate nelle pull request 1924 e 1915. Esamina Il2CppBuildPreProcess.cs, AndroidManifestConfiguration.cs, BuildPostProcess.cs e SentryXcodeProject.cs per la gestione dei simboli. Il lavoro è completo quando Unity as a Library coordina la configurazione degli SDK nativi e Unity, la sincronizzazione degli scope e il caricamento dei simboli su Android, iOS e UWP.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

2. High Errors Feature Unity

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

Proposal

With the changes to how the native SDKs get initialized in for Android (see https://github.com/getsentry/sentry-unity/pull/1924) and iOS (see https://github.com/getsentry/sentry-unity/pull/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.

Lingua principale
C#
Stelle
295
Fork
63
Merge medio
3g 17h
PR unite (30g)
26

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di getsentry/sentry-unity

Tutte le issue di getsentry/sentry-unity

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.