Unity as a Library Support

Abierto
  • ¿Algo no está bien?
#2,416 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
android, csharp, ios, unity
Área
game-dev, mobile-dev

Línea de trabajo

Comienza leyendo las opciones AndroidNativeSupportEnabled y IosNativeSupportEnabled y los cambios de inicialización nativa referenciados en los pull requests 1924 y 1915. Revisa Il2CppBuildPreProcess.cs, AndroidManifestConfiguration.cs, BuildPostProcess.cs y SentryXcodeProject.cs para el manejo de símbolos. El trabajo estará terminado cuando Unity as a Library haya coordinado la configuración de los SDK nativos y de Unity, la sincronización de scopes y las subidas de símbolos en Android, iOS y UWP.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
295
Forks
63
Merge medio
3 d 17 h
PR fusionados (30 d)
26

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getsentry/sentry-unity

Todos los issues de getsentry/sentry-unity

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.