Facebook-sdk-for-unity: Android - Crash au démarrage causé par des incompatibilités dans les dépendances

Salut @andnoonesthere , j'ai eu le même problème et j'ai passé du temps hier à créer un fork qui fonctionne avec 2019.2.0f1 et Firebase. J'ai testé les fonctionnalités des deux SDK sur Android et iOS et il semble que tout fonctionne comme prévu. À titre d'avertissement, les modifications apportées à mon fork devraient rendre le processus de génération rétrocompatible lors de la génération du SDK via les scripts fournis avec les versions Unity antérieures à 2019.2.0f1.

Notez que si vous souhaitez créer le SDK localement, j'ai mis à jour le référentiel pour exiger la configuration d'une variable d'environnement afin que les instances Unity basées sur Hub puissent être utilisées (les fichiers .csproj et les scripts shell ont des chemins codés en dur dans ce référentiel, ce qui rend impossible de construire sur des machines qui n'utilisent pas ce chemin exact vers Unity).

Au cas où vous seriez intéressé par les modifications que j'ai apportées, le diff correspondant se trouve ici . Le paquet est situé ici .

Faites-moi savoir si vous rencontrez des problèmes lors de la mise en route.

Remarque supplémentaire liée à ce problème particulier puisque je publie ceci dans le bon référentiel cette fois : j'ai supprimé le script de résolution que vous avez référencé dans votre commentaire et j'ai migré les dépendances dans le fichier Dependencies.xml et mis à jour la version du résolveur et cela a corrigé la dépendance problèmes que j'avais; qui, espérons-le, les corrigera pour vous aussi.

Bonjour Michael,

Je viens de tester vos modifications (Android uniquement) et cela a également très bien fonctionné pour moi. Bon travail! :)
Je conviens également que le déplacement des dépendances vers le fichier Dependencies.xml est également une chose importante à faire.

En regardant vos modifications, je pense que le correctif pour les dépendances et les chemins de solution devraient être inclus dans le SDK par les développeurs, afin que nos propres modifications soient plus faciles à l'avenir.

Merci encore pour votre travail. Je suppose que jusqu'à ce qu'ils publient un correctif officiel, j'utiliserai votre version :)

Après quelques tests supplémentaires, je constate que tout va bien sur l'appareil, j'obtiens cet avertissement dans l'éditeur :

FB.Init() a déjà été appelé. Vous n'avez besoin de l'appeler qu'une seule fois.

Cependant, je suis sûr à 100% qu'il n'est appelé qu'une seule fois, j'effectue une vérification supplémentaire pour FB.IsInitialized juste avant. Cela pourrait aussi bien ne pas être lié à votre modification mais à un bug du récent SDK FB. Faites-moi savoir si vous rencontrez cela aussi.

Heureux d'aider! J'essaierai de garder mon fork à jour au fur et à mesure que de nouvelles versions du SDK seront publiées jusqu'à ce que 2019.2.0f1 soit officiellement ajouté.

Concernant votre dernier commentaire : je ne vois pas cet avertissement dans l'éditeur ou sur l'appareil. Je soupçonne que vous voyez cela parce que FB.Init() ne définit pas immédiatement FB.IsInitialized à true ; le SDK doit terminer l'initialisation - qui n'est pas garantie d'être immédiate - avant que FB.IsInitialized soit défini.

L'éditeur attend spécifiquement qu'un délégué de chargement DLL soit appelé, ce qui peut être vu ici .

Je recommande de savoir si l'initialisation de Facebook est en cours en plus de savoir si FB.IsInitialized est true ou non. Un moyen rapide de suivre cela consiste à bool _isInitializing; un true au moment de FB.Init et défini sur false dans le InitDelegate que vous passez dans la méthode FB.Init . De cette façon, vous pouvez annuler des appels FB.Init supplémentaires si l'un est en cours en plus de s'il est déjà terminé.

OK, donc l'erreur était due à la façon dont je charge les scènes en mode lecture. Lorsque j'entre en mode lecture, je décharge toutes les scènes chargées, puis charge mon ensemble personnalisé de scènes. C'est là qu'il a été chargé deux fois, il était déjà chargé dans cette scène de base qui a été déchargée au début. Merci pour les conseils en tout cas :)

Salut @KylinChang. Pourquoi cela a-t-il été fermé ? Vous avez déjà corrigé les problèmes de dépendances de votre côté et cela sera inclus dans la prochaine version ? Je n'ai vu aucune information à ce sujet.

Salut @andnoonesthere , je pensais que vous aviez résolu les problèmes. Je rouvre le problème et dépose une tâche pour résoudre le problème.

@KylinChang - oui, mes problèmes sont résolus pour le moment. C'est grâce au fork fait par @michael-looply Cependant, ses modifications doivent être ajoutées au référentiel principal, sinon ce n'est qu'un correctif temporaire. Merci.

Bonjour @andnoonesthere et @michael-looply. Quelle version de Firebase et de Play Services Resolver utilisez-vous, ou question plus simple, comment utilisez-vous votre solution de contournement ?

Nous avons exactement le même problème et nous essayons d'utiliser Firebase 6.2.2 avec son résolveur de services de jeu et la solution de contournement fournie par @michael-looply avec son résolveur de services de jeu (nous avons essayé les deux résolveurs et aussi un qui ne fonctionne pas use gradle) mais nous n'avons pas pu compiler l'application. Je ne sais pas si nous faisons quelque chose de mal ou s'il existe un autre plugin qui provoque le même problème que Facebook (comme AdMob, IronSource, etc.)

Salut @Wolar - J'utilise Firebase 6.2.2 et Resolver 1.2.124.0. Je ne garde qu'un seul répertoire

C'est une erreur de build gradle et c'est quelque chose comme :

"com.android.support.support-v4-27.0.2.aar" à l'aide de Jetifier. Raison. L'artefact donné contient une chaîne littérale avec une référence de package "android.support.v4" qui ne peut pas être réécrite en toute sécurité. Bibliothèques utilisant la réflexion telles car les processeurs d'annotation doivent être mis à jour manuellement pour ajouter la prise en charge d'androidx..()"

Le SDK Facebook utilise cette bibliothèque et je pense que d'autres bibliothèques l'utilisent également. J'ai essayé à la fois Jetifier activé et désactivé dans PlayServicesResolver mais sans aucun effet. Nous utilisons également un modèle de gradle personnalisé afin que PlayServicesResolver ne copie pas les bibliothèques dans le dossier Plugins, mais les ajoute plutôt à ce modèle de gradle, mais cela ne devrait jouer aucun rôle, je suppose.

@Wolar Avez-vous cet AAR présent dans votre répertoire Assets ? Il est possible qu'un autre SDK n'utilise pas le résolveur et importe directement les AAR dans le projet.

Sinon, votre bloc de dépendances dans votre mainTemplate.gradle contient-il deux références à la bibliothèque de support ? Vous ne pouvez pas avoir deux versions explicites de la même bibliothèque répertoriées ; si vous avez une ligne dans votre bloc de dépendances comme implementation 'com.android.support:support-v4:25.3.1' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:7 du résolveur à l'intérieur du

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

section et avoir un autre en dehors de cette section comme implementation 'com.android.support:support-v4:27.0.2' , alors vous ne pourrez pas construire. Par exemple, le plugin ironSource Unity conseille de modifier manuellement le fichier mainTemplate.gradle avec une référence de bibliothèque de support . Vous devrez peut-être créer un Dependencies.xml pour ironSource que le résolveur peut traiter au lieu de modifier directement votre mainTemplate.gradle .

@michael-looply Je suis presque sûr que nous avons également l'un des AAR dans le dossier des plugins, mais je pense que j'ai essayé de le supprimer car je m'attendais à ce que cela puisse causer le problème, mais je pense que cela n'a pas aidé. Je vais vérifier les autres sdks comme IronSource, merci :)

J'ai pu le résoudre, c'était plus de problèmes. Ce qui m'a vraiment aidé, c'est d'exporter le projet en tant que projet Android Studio et de le déboguer là-bas. Fondamentalement, ces bibliothèques étaient également en conflit avec AdMob et certaines bibliothèques restantes de Fabric que nous n'utilisons plus. J'ai donc mis à niveau AdMob, supprimé cet aar, modifié durement quelques versions de bibliothèques dans les fichiers de dépendance et il semble fonctionner avec jetifier en tant que bibliothèques androidx. Merci pour l'aide @michael-looply

@Wolar Content d'apprendre que ça marche ! Heureux d'aider :)

Alors @KylinChang, quand pouvons-nous nous attendre à des progrès sur celui-ci ?

@KylinChang ?

Toujours un problème en février 2020.

• Unity 2019.3.1f1 (rétrogradation impossible)
• le plus récent facebook-unity-sdk-7.18.1
• utilisation forcée d'androidx et de jetifier en raison de la dernière version d'AdMob (rétrogradation impossible)
• Le résolveur Android génère toujours les dépendances obsolètes mentionnées dans ProjectSettings/AndroidResolverDependencies.xml ainsi que le modèle gradle. Aucune autre mention de bibliothèques obsolètes à l'échelle du projet
• les bibliothèques obsolètes disparaissent après la suppression du SDK Facebook.

Existe-t-il des plans pour mettre à niveau les dépendances FacebookSDK ?

Toujours un problème en mars 2020

• Unité 2019.3.4f1
• SDK Facebook 7.18.1
• Kit de développement logiciel IronSource 6.15.0.1

Je ne peux pas construire avec, je pense, n'importe quel autre SDK sur la planète. Firebase et IronSource inclus. C'est ridicule car cela s'applique directement aux optimisations des publicités, des choses liées à l'argent.

Toujours un problème en mars 2020

• Unité 2019.3.4f1
• SDK Facebook 7.18.1
• Kit de développement logiciel IronSource 6.15.0.1

Je ne peux pas construire avec, je pense, n'importe quel autre SDK sur la planète. Firebase et IronSource inclus. C'est ridicule car cela s'applique directement aux optimisations des publicités, des choses liées à l'argent.

La solution de Looply ne suffit plus pour fonctionner. J'ai enquêté sur ce problème. Facebook doit mettre à jour son SDK pour utiliser AndroidX. Mais en attendant, Google fournit l'outil External Dependency Manager, qui est censé activer le SDK Facebook (et d'autres anciennes bibliothèques) pour qu'il fonctionne avec AndroidX. Malheureusement, EDM ne fonctionne pas avec le SDK Facebook pour une raison quelconque. CEPENDANT : Le Jetifier fourni avec Android Studio fonctionne ! Exportez simplement votre formulaire de projet Unity, ouvrez-le dans Android Studio, ajoutez ces lignes à gradle.properties :
android.useAndroidX=true
android.enableJetifier=true

Construisez et exécutez et tout devrait aller. Cependant : Facebook doit corriger cela pronto. (Ou Google doit réparer leur Jetifier.) Cependant, toutes les entreprises que je connais, grandes et petites, ont publié des versions AndroidX de leurs bibliothèques. Je suis choqué que Facebook, une énorme entreprise, n'ait pas encore résolu ce problème car cela cause beaucoup de douleur aux développeurs.

@lexscite

Pour ceux qui sont encore bloqués là-dessus :
1) Vous pouvez le réparer en utilisant Android Studio (comme je l'ai mentionné ci-dessus.)
2) Il existe également une solution de onesignal : https://documentation.onesignal.com/docs/troubleshooting-unity#section -android-x-compatibility qui permet d'exécuter des builds directement depuis Unity (en ajoutant un fichier settingsTemplate.gradle. )

Il semble que la prise en charge de Jetifier/AndroidX dans Unity soit quelque peu interrompue.

Ce bogue :
https://github.com/googlesamples/unity-jar-resolver/issues/360 est ce que j'ai déposé auprès de l'équipe unity-jar-resolver, mais nous verrons si c'est même la bonne équipe pour le réparer.

Plus besoin d'Android Studio Exports pour que Jetifier fonctionne dans Unity.

En utilisant la dernière version officielle 2019.3 (la mienne est 2019.3.12f1 atm), vous pouvez simplement utiliser le modèle de propriétés Gradle personnalisé en plus du modèle principal Gradle, et ajouter :
android.useAndroidX=true
android.enableJetifier=true
dans le fichier gradleTemplate.properties nouvellement généré.

Depuis, j'exporte vers Android studio pour construire avec tous les SDK que mon éditeur veut et travaille sur les misères des erreurs de construction Android, en tant que développeur junior, je pense avoir rencontré tous les problèmes, mais maintenant je peux enfin construire à partir de Unity. Jetifier ne fonctionnait pas correctement avec le SDK Facebook, sauf dans le studio Android. Par conséquent, si vous utilisiez suffisamment de plug-ins migrés AndroidX, il serait difficile de créer à partir de Unity sans quelques modifications compliquées.

Je dois aussi généralement changer Plugins/Android/AndroidManifest.xml pour avoir ceci dans la balise d'application :
tools:replace="android:appComponentFactory" android:appComponentFactory="leavemealone"
aussi xmlns:tools="http://schemas.android.com/tools" dans la balise manifeste

Oui, c'est une chaîne aléatoire car je ne sais pas quel est le but de cela, mais cela fonctionne et corrige mon erreur de construction de fusion manifeste, eh bien.

Je peux maintenant construire avec Ironsource (de nombreux adaptateurs avec), Facebook SDK, GameAnalytics, Adjust, Firebase, etc. Fondamentalement, obtenez simplement le dernier Unity Jar Resolver, vérifiez les paramètres, supprimez la résolution automatique, supprimez la résolution lors de la construction, définissez le patch maintemplate et utilisez jetifier sur true, forcez la résolution, ajoutez toutes les dépendances/repos supplémentaires que vous souhaitez, faites l'astuce gradleproperties, construisez dans Unity, terminé .

J'ai rencontré ce problème sur Facebook Unity SDK v8.1.1. Dois-je faire tout ce que @mohamad-al-amaary a fait chaque fois que je souhaite intégrer le SDK Unity de Facebook ?

@nguyentrong101094
Dans les versions 2019.4 LTS Unity, je n'ai eu aucun problème, tout ce que vous avez à faire est cette partie de ma réponse initiale :
android.useAndroidX=true
android.enableJetifier=true

De plus, je pense que le nouvel EDM a une option "Patch gradleTemplate.properties" qui devrait le faire pour vous même. J'active simplement le manifeste principal personnalisé, le modèle Gradle principal personnalisé, le modèle de propriétés Gradle personnalisé pour chaque projet au moins maintenant, et je définis les deux propriétés, et je m'assure de résoudre avec EDM (https://github.com/googlesamples/unity-jar- resolver/blob/master/external-dependency-manager-latest.unitypackage) avant la compilation.

@Subtle-Tea J'ai essayé ça. J'ai toujours cette erreur lors de la construction

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

J'utilise Unity 2019.4.17