Facebook-sdk-for-unity: Android: bloqueo en el inicio causado por incompatibilidades en las dependencias

Hola @andnoonesthere , tuve el mismo problema y pasé un tiempo ayer haciendo una bifurcación que funciona con 2019.2.0f1 y Firebase. He probado la funcionalidad de ambos SDK en Android e iOS y parece que todo funciona como se esperaba. Como advertencia, los cambios en mi bifurcación deberían hacer que el proceso de compilación sea incompatible con versiones anteriores al compilar el SDK a través de los scripts proporcionados con las versiones de Unity anteriores a 2019.2.0f1.

Tenga en cuenta que si desea construir el SDK localmente, actualicé el repositorio para requerir la configuración de una variable de entorno para que se puedan usar instancias de Unity basadas en Hub (los archivos .csproj y los scripts de shell tienen rutas codificadas en este repositorio, lo que hace es imposible construir en máquinas que no usan esa ruta exacta a Unity).

En caso de que esté interesado en los cambios que hice, la diferencia relevante se encuentra aquí . El paquete se encuentra aquí .

Avísame si tienes algún problema para ponerlo en marcha.

Nota adicional relacionada con este problema en particular, ya que estoy publicando esto en el repositorio correcto esta vez: eliminé el script de resolución al que hizo referencia en su comentario y migré las dependencias al archivo Dependencies.xml y actualicé la versión de resolución y eso solucionó la dependencia problemas que estaba teniendo; que con suerte los solucionará también para usted.

Hola Michael,

Acabo de probar tus cambios (solo Android) y también funcionó muy bien para mí. ¡Buen trabajo! :)
También estoy de acuerdo en que mover las dependencias al archivo Dependencies.xml también es algo importante.

Al observar sus cambios, creo que los desarrolladores deberían incluir tanto la corrección de las dependencias como las rutas de solución en el SDK, por lo que hacer nuestras propias modificaciones sería más fácil en el futuro.

Gracias de nuevo por tu trabajo. Supongo que hasta que publiquen un parche oficial, usaré tu versión :)

Después de algunas pruebas adicionales, veo que mientras en el dispositivo todo está bien, recibo esta advertencia en el editor:

FB.Init () ya ha sido llamado. Solo necesita llamar a esto una vez y solo una vez.

Sin embargo, estoy 100% seguro de que se llama solo una vez, realizo una verificación adicional para FB.IsInitialized justo antes. Eso también podría no estar relacionado con su modificación, sino con algún error en el reciente FB SDK. Avísame si también experimentas esto.

¡Feliz de ayudar! Intentaré mantener mi bifurcación actualizada a medida que se lancen nuevas versiones de SDK hasta que se agregue oficialmente 2019.2.0f1.

Con respecto a su último comentario: no veo esa advertencia en el editor o en el dispositivo. Mi sospecha es que estás viendo eso porque FB.Init() no establece inmediatamente FB.IsInitialized en true ; el SDK tiene que completar la inicialización, que no se garantiza que sea inmediata, antes de que se configure FB.IsInitialized .

El editor espera específicamente a que se invoque un delegado de carga de DLL, que se puede ver aquí .

Recomiendo hacer un seguimiento de si la inicialización de Facebook está en curso, además de si FB.IsInitialized es true o no. Una forma rápida de rastrear esto es con un bool _isInitializing; que se establece en true en el momento de FB.Init y se establece en false en el InitDelegate que pasa al método FB.Init . De esa manera, puede cancelar llamadas FB.Init adicionales si hay una en curso, además de si ya se completó.

Bien, entonces el error se debió a la forma en que cargo las escenas en el modo de reproducción. Al entrar en el modo de reproducción, descargo todas las escenas cargadas y luego cargo mi conjunto personalizado de escenas. Ahí es donde se cargó dos veces, ya estaba cargado en esa escena básica que se descargó al principio. Gracias por los consejos de todos modos :)

Hola @KylinChang. ¿Por qué esto estaba cerrado? ¿Ya solucionó los problemas de dependencias de su lado y se incluirá en la próxima versión? No he visto ninguna información al respecto.

Hola @andnoonesthere , pensé que habías solucionado los problemas. Vuelvo a abrir el problema y presento una tarea para solucionarlo.

@KylinChang : sí, mis problemas están solucionados por ahora. Esto es gracias a la bifurcación hecha por @ michael-looply. Sin embargo, sus cambios deben agregarse al repositorio principal, de lo contrario, es solo una solución temporal. Gracias.

Hola @andnoonesthere y @ michael-looply. ¿Qué versión de Firebase and Play Services Resolver estás usando, o una pregunta más simple, cómo usas tu solución?

Tenemos exactamente el mismo problema y estamos tratando de usar Firebase 6.2.2 con su resolución de servicios de reproducción y la solución proporcionada por @ michael-looply con su resolución de servicios de reproducción (hemos probado ambos resolutores y también uno que no use gradle) pero no pudimos compilar la aplicación. No estoy seguro de si estamos haciendo algo mal o si hay algún otro complemento que causa el mismo problema que Facebook (como AdMob, IronSource, etc.)

Hola @Wolar : estoy usando Firebase 6.2.2 y Resolver 1.2.124.0. Solo guardo un directorio PlayServicesResolver en mi proyecto. ¿Qué error (s) de compilación está viendo? No estoy usando ningún SDK de mediación de anuncios fuera de Unity Ads en este momento, por lo que no puedo hablar sobre si están causando más problemas o no.

Es un error de compilación de Gradle y es algo como:

"com.android.support.support-v4-27.0.2.aar" usando Jetifier. Razón. El artefacto dado contiene un literal de cadena con una referencia de paquete "android.support.v4" que no se puede reescribir de manera segura. Bibliotecas que usan la reflexión como ya que los procesadores de anotaciones deben actualizarse manualmente para agregar compatibilidad con androidx .. () "

Facebook SDK está usando esta biblioteca y creo que alguna otra biblioteca también la usa. Probé Jetifier habilitado y deshabilitado en PlayServicesResolver pero sin ningún efecto. También estamos usando una plantilla de Gradle personalizada para que PlayServicesResolver no copie las bibliotecas en la carpeta de complementos, sino que las agregue a esa plantilla de Gradle, pero eso no debería desempeñar ningún papel, supongo.

@Wolar ¿Tiene ese AAR presente en su directorio de Activos? Es posible que otro SDK no esté usando el Resolver y simplemente importe directamente los AAR al proyecto.

Alternativamente, ¿su bloque de dependencias en su mainTemplate.gradle contiene dos referencias a la biblioteca de soporte? No puede tener dos versiones explícitas de la misma biblioteca en la lista; si tiene una línea en su bloque de dependencias como implementation 'com.android.support:support-v4:25.3.1' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:7 del Resolver dentro del

// Android Resolver Dependencies Start
... dependencies
// Android Resolver Dependencies End

y tiene otro fuera de esa sección como implementation 'com.android.support:support-v4:27.0.2' , entonces no podrá compilar. Por ejemplo, el complemento ironSource Unity aconseja modificar manualmente el archivo mainTemplate.gradle con una referencia de biblioteca de soporte . Es posible que deba crear un Dependencies.xml para ironSource que el Resolver pueda procesar en lugar de modificar su mainTemplate.gradle directamente.

@ michael-looply Estoy bastante seguro de que también tenemos uno de los AAR en la carpeta de complementos, pero creo que intenté eliminarlo como esperaba, podría causar el problema, pero creo que no ayudó. Verificaré los otros sdks como IronSource, gracias :)

Pude resolverlo, fueron más problemas. Lo que realmente me ayudó fue exportar el proyecto como proyecto de Android Studio y depurarlo allí. Básicamente, estas bibliotecas también entraban en conflicto con AdMob y algunas bibliotecas sobrantes de Fabric que ya no usamos. Así que actualicé AdMob, eliminé ese aar, modifiqué algunas versiones de bibliotecas en archivos de dependencia y parece que funciona con jetifier como bibliotecas androidx. Gracias por la ayuda @ michael-looply

@Wolar ¡ Me alegra saber que está funcionando! Feliz de ayudar :)

Entonces @KylinChang, ¿cuándo podemos esperar avances en este?

@KylinChang ?

Sigue siendo un problema en febrero de 2020.

• Unity 2019.3.1f1 (degradación imposible)
• más nuevo facebook-unity-sdk-7.18.1
• uso obligatorio de androidx y jetifier debido a la versión más reciente de AdMob (degradación imposible)
• El solucionador de Android aún genera las dependencias obsoletas mencionadas en ProjectSettings / AndroidResolverDependencies.xml, así como en la plantilla gradle. Ninguna otra mención de bibliotecas obsoletas en todo el proyecto
• las bibliotecas obsoletas desaparecen después de eliminar el SDK de Facebook.

¿Hay planes para actualizar las dependencias de FacebookSDK?

Sigue siendo un problema en marzo de 2020

• Unidad 2019.3.4f1
• SDK de Facebook 7.18.1
• IronSource SDK 6.15.0.1

Creo que no se puede construir con ningún otro SDK del planeta. Firebase y IronSource incluidos. Esto es ridículo porque se aplica directamente a las optimizaciones de anuncios, cosas relacionadas con el dinero.

Sigue siendo un problema en marzo de 2020

• Unidad 2019.3.4f1
• SDK de Facebook 7.18.1
• IronSource SDK 6.15.0.1

Creo que no se puede construir con ningún otro SDK del planeta. Firebase y IronSource incluidos. Esto es ridículo porque se aplica directamente a las optimizaciones de anuncios, cosas relacionadas con el dinero.

La solución de Looply ya no es suficiente para funcionar. Investigué este problema. Facebook necesita actualizar su SDK para usar AndroidX. Pero mientras tanto, Google proporciona la herramienta External Dependency Manager, que se supone que Jetify el SDK de Facebook (y otras bibliotecas antiguas) para que funcione con AndroidX. Desafortunadamente, EDM no funciona con Facebook SDK por alguna razón. SIN EMBARGO: ¡El Jetifier que viene con Android Studio sí funciona! Simplemente exporte su proyecto desde Unity, abra en Android Studio, agregue estas líneas a gradle.properties:
android.useAndroidX = true
android.enableJetifier = verdadero

Construya y ejecute y todo debería funcionar. Sin embargo: Facebook necesita arreglar esto pronto. (O Google necesita arreglar su Jetifier). Sin embargo, todas las empresas que conozco, grandes y pequeñas, han lanzado versiones de AndroidX de sus bibliotecas. Me sorprende que Facebook, una gran empresa, no haya solucionado esto todavía, ya que causa mucho dolor a los desarrolladores.

@lexscite

Para cualquiera que todavía esté atascado en esto:
1) Puede solucionarlo usando Android Studio (como mencioné anteriormente).
2) También hay una solución de onesignal: https://documentation.onesignal.com/docs/troubleshooting-unity#section -android-x -compatibilidad que le permite ejecutar compilaciones directamente desde Unity (agregando un archivo settingsTemplate.gradle. )

Parece que el soporte Jetifier / AndroidX en Unity está algo roto.

Este error:
https://github.com/googlesamples/unity-jar-resolver/issues/360 es lo que presenté con el equipo de unity-jar-resolver, pero veremos si ese es el equipo adecuado para solucionarlo.

Ya no es necesario exportar a Android Studio para que Jetifier funcione dentro de Unity.

Con la versión oficial más reciente de 2019.3 (la mía es 2019.3.12f1 atm), puede usar la plantilla de propiedades personalizadas de Gradle en la parte superior de la plantilla principal de Gradle y agregar:
android.useAndroidX=true
android.enableJetifier=true
al archivo gradleTemplate.properties recién generado.

He estado exportando a Android Studio para compilar con todos los SDK que mi editor desea y trabajando con las miserias de los errores de compilación de Android desde entonces, como desarrollador junior creo que encontré todos los problemas, pero ahora finalmente puedo compilar desde Unity. Jetifier no funcionaba correctamente con el SDK de Facebook, excepto en el estudio de Android, por lo que si usaba suficientes complementos migrados a AndroidX, sería difícil de construir desde Unity sin algunos cambios hacky.

También suelo cambiar Plugins / Android / AndroidManifest.xml para tener esto en la etiqueta de la aplicación:
tools:replace="android:appComponentFactory" android:appComponentFactory="leavemealone"
también xmlns:tools="http://schemas.android.com/tools" en la etiqueta de manifiesto

Sí, es una cadena aleatoria ya que no estoy seguro de cuál es el propósito de esto, pero funciona y corrige mi error de compilación de fusión de manifiesto, bueno.

Ahora puedo construir con Ironsource (muchos adaptadores con él), Facebook SDK, GameAnalytics, Adjust, Firebase, lo que sea. Básicamente, solo obtenga el último Unity Jar Resolver, verifique la configuración, elimine la resolución automática, elimine la resolución en la compilación, configure la plantilla principal del parche y use jetifier en verdadero, fuerce la resolución, agregue las dependencias / repositorios adicionales que desee, haga el truco de gradleproperties, compile dentro de Unity, listo .

Me encontré con este problema en Facebook Unity SDK v8.1.1. ¿Tengo que hacer todas las cosas que hizo @ mohamad-al-amaary cada vez que quiero integrar Facebook Unity SDK?

@ nguyentrong101094
En las versiones 2019.4 LTS Unity no he tenido problemas, todo lo que necesita hacer es esta parte de mi respuesta inicial:
android.useAndroidX = true
android.enableJetifier = verdadero

También creo que el nuevo EDM tiene una opción "Patch gradleTemplate.properties" que debería hacer eso incluso por ti. Solo habilito el manifiesto principal personalizado, la plantilla principal personalizada de Gradle, la plantilla personalizada de propiedades de Gradle ahora al menos en cada proyecto, y configuro las dos propiedades, y me aseguro de resolver con EDM (https://github.com/googlesamples/unity-jar- resolver / blob / master / external-dependency-manager-latest.unitypackage) antes de la compilación.

@ Subtle-Tea Probé eso. Sigo recibiendo este error al compilar

AndroidManifest.xml:38: AAPT: error: unexpected element <queries> found in <manifest>.

Estoy usando Unity 2019.4.17