Facebook-sdk-for-unity: Android - Absturz beim Start durch Inkompatibilitäten in Abhängigkeiten

Hey @andnoonesthere , ich hatte das gleiche Problem und habe gestern einige Zeit damit verbracht, einen Fork zu erstellen, der mit 2019.2.0f1 und Firebase funktioniert. Ich habe die Funktionalität beider SDKs auf Android und iOS getestet und es sieht so aus, als ob alles wie erwartet läuft. Als Warnung sollten die Änderungen in meinem Fork den Build-Prozess abwärtskompatibel machen, wenn das SDK über die bereitgestellten Skripte mit Unity-Versionen vor 2019.2.0f1 erstellt wird.

Beachten Sie, dass ich, wenn Sie das SDK lokal erstellen möchten, das Repository so aktualisiert habe, dass die Konfiguration einer Umgebungsvariablen erforderlich ist, damit Hub-basierte Unity-Instanzen verwendet werden können (die .csproj- Dateien und Shell-Skripte haben in diesem

Falls Sie an den von mir vorgenommenen Änderungen interessiert sind, finden Sie das entsprechende Diff hier . Paket befindet sich hier .

Lassen Sie mich wissen, wenn Sie Probleme beim Starten und Ausführen haben.

Zusätzlicher Hinweis zu diesem speziellen Problem, da ich dies diesmal im richtigen Repository poste: Ich habe das Resolver-Skript entfernt, auf das Sie in Ihrem Kommentar verwiesen haben, und die Abhängigkeiten in die Datei Dependencies.xml migriert und die Resolver-Version aktualisiert, wodurch die Abhängigkeit behoben wurde Probleme, die ich hatte; das wird sie hoffentlich auch für dich beheben.

Hallo Michael,

Ich habe Ihre Änderungen gerade getestet (nur Android) und es hat auch bei mir super funktioniert. Gut gemacht! :)
Ich stimme auch zu, dass das Verschieben von Abhängigkeiten in die Datei Dependencies.xml ebenfalls eine wichtige Sache ist.

Wenn ich mir Ihre Änderungen ansehe, denke ich, dass sowohl der Fix für die Abhängigkeiten als auch die Lösungspfade von den Entwicklern in das SDK aufgenommen werden sollten, damit wir in Zukunft unsere eigenen Änderungen einfacher vornehmen können.

Nochmals vielen Dank für Ihre Arbeit. Ich denke, bis sie einen offiziellen Patch veröffentlichen, werde ich deine Version verwenden :)

Nach einigen zusätzlichen Tests sehe ich, dass auf dem Gerät alles in Ordnung ist, und ich erhalte diese Warnung im Editor:

FB.Init() wurde bereits aufgerufen. Sie müssen dies nur einmal und nur einmal aufrufen.

Ich bin mir jedoch zu 100% sicher, dass es nur einmal aufgerufen wird. Ich führe kurz zuvor eine zusätzliche Prüfung auf FB.IsInitialized durch. Das hängt möglicherweise auch nicht mit Ihrer Modifikation zusammen, sondern mit einem Fehler im aktuellen FB-SDK. Lass es mich wissen, wenn du das auch erlebst.

Freue mich zu helfen! Ich werde versuchen, meinen Fork auf dem neuesten Stand zu halten, da neue SDK-Versionen veröffentlicht werden, bis 2019.2.0f1 offiziell hinzugefügt wird.

Zu Ihrem letzten Kommentar: Ich sehe diese Warnung weder im Editor noch auf dem Gerät. Mein Verdacht ist, dass Sie das sehen, weil FB.Init() FB.IsInitialized nicht sofort auf true ; das SDK muss die Initialisierung abschließen – was nicht garantiert sofort ist – bevor FB.IsInitialized festgelegt wird.

Der Editor wartet speziell auf den Aufruf eines DLL-Ladedelegaten, der hier zu sehen

Ich empfehle, zu verfolgen, ob die Facebook-Initialisierung im Gange ist und ob FB.IsInitialized true oder nicht. Eine schnelle Art und Weise , dies zu verfolgen , ist mit einem bool _isInitializing; , die gesetzt wird true zum Zeitpunkt des FB.Init und auf false im InitDelegate , die Sie an die Methode FB.Init . Auf diese Weise können Sie weitere FB.Init Anrufe abbrechen, wenn ein Anruf in Bearbeitung ist oder bereits abgeschlossen ist.

OK, der Fehler lag also daran, wie ich Szenen im Wiedergabemodus lade. Beim Aufrufen des Wiedergabemodus entlade ich alle geladenen Szenen und lade dann meine benutzerdefinierten Szenen. Dort wurde es zweimal geladen, es war bereits in der Grundszene geladen, die am Anfang entladen wurde. Danke trotzdem für die Tipps :)

Hallo @KylinChang. Warum wurde das geschlossen? Sie haben bereits Abhängigkeitsprobleme auf Ihrer Seite behoben und es wird in der nächsten Version enthalten sein? Ich habe keine Informationen dazu gesehen.

Hallo @andnoonesthere , ich dachte, du hättest die Probleme behoben. Ich öffne das Problem erneut und reiche eine Aufgabe ein, um das Problem zu beheben.

@KylinChang - ja, meine Probleme sind

Hallo @andnoonesthere und @michael-looply. Welche Version von Firebase und Play Services Resolver verwenden Sie oder eine einfachere Frage, wie verwenden Sie Ihre Problemumgehung?

Wir haben genau das gleiche Problem und versuchen, Firebase 6.2.2 mit seinem Play Services Resolver und der von @michael-looply bereitgestellten Problemumgehung mit seinem Play Services Resolver zu verwenden (wir haben beide Resolver ausprobiert und auch einen, der dies nicht tut Gradle verwenden), aber wir konnten die Anwendung nicht kompilieren. Ich bin mir nicht sicher, ob wir etwas falsch machen oder ob es ein anderes Plugin gibt, das das gleiche Problem wie Facebook verursacht (wie AdMob, IronSource usw.)

Hallo @Wolar - Ich verwende Firebase 6.2.2 und Resolver 1.2.124.0. Ich behalte nur ein PlayServicesResolver- Verzeichnis in meinem Projekt. Welche Kompilierungsfehler sehen Sie? Ich verwende derzeit keine Anzeigenvermittlungs-SDKs außerhalb von Unity Ads, daher kann ich nicht sagen, ob diese weitere Probleme verursachen oder nicht.

Es ist ein Gradle-Build-Fehler und ungefähr wie folgt:

"com.android.support.support-v4-27.0.2.aar" mit Jetifier. Grund. Das angegebene Artefakt enthält ein Zeichenfolgenliteral mit einer Paketreferenz "android.support.v4", das nicht sicher umgeschrieben werden kann. Bibliotheken, die Reflektion verwenden, wie z da Anmerkungsprozessoren manuell aktualisiert werden müssen, um Unterstützung für androidx..() hinzuzufügen."

Facebook SDK verwendet diese Bibliothek und ich denke, einige andere Bibliotheken verwenden sie auch. Ich habe sowohl Jetifier aktiviert als auch deaktiviert in PlayServicesResolver ausprobiert, jedoch ohne Wirkung. Wir verwenden auch eine benutzerdefinierte Gradle-Vorlage, sodass der PlayServicesResolver die Bibliotheken nicht in den Plugins-Ordner kopiert, sondern sie dieser Gradle-Vorlage hinzufügt, aber das sollte meiner Meinung nach keine Rolle spielen.

@Wolar Haben Sie diesen AAR in Ihrem Assets-Verzeichnis? Es ist möglich, dass ein anderes SDK den Resolver nicht verwendet und die AARs einfach direkt in das Projekt importiert.

Enthält Ihr Abhängigkeitsblock in Ihrer implementation 'com.android.support:support-v4:25.3.1' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:7 vom Resolver innerhalb des

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

Abschnitt und haben einen anderen außerhalb dieses Abschnitts wie implementation 'com.android.support:support-v4:27.0.2' , dann können Sie nicht bauen. Zum Beispiel empfiehlt das ironSource Unity-Plugin, die Datei mainTemplate.gradle manuell mit einer Referenz zur Unterstützungsbibliothek zu . Möglicherweise müssen Sie eine Dependencies.xml für ironSource erstellen, die der Resolver verarbeiten kann, anstatt Ihre mainTemplate.gradle direkt zu

@michael-looply Ich bin mir ziemlich sicher, dass wir auch einen der AARs im Plugin-Ordner haben, aber ich glaube, ich habe versucht, ihn zu löschen, da ich erwartet hatte, dass er das Problem verursachen könnte, aber ich denke, es hat nicht geholfen. Ich werde die anderen SDKs wie IronSource überprüfen, danke :)

Ich konnte es lösen, es waren mehr Probleme. Was mir wirklich geholfen hat, war, das Projekt als Android Studio-Projekt zu exportieren und dort zu debuggen. Im Grunde standen diese Bibliotheken auch in Konflikt mit AdMob und einigen übrig gebliebenen Bibliotheken von Fabric, die wir nicht mehr verwenden. Also habe ich AdMob aktualisiert, dieses aar gelöscht, einige Versionen von Bibliotheken in Abhängigkeitsdateien hart geändert und es scheint mit Jetifier als Androidx-Bibliotheken zu funktionieren. Danke für die Hilfe @michael-looply

@Wolar Freut mich zu hören, dass es funktioniert! Freue mich zu helfen :)

Also @KylinChang, wann können wir

@ KylinChang ?

Noch ein Thema im Februar 2020.

• Unity 2019.3.1f1 (Downgrade unmöglich)
• neueste facebook-unity-sdk-7.18.1
• Erzwungene Nutzung von Androidx und Jetifier durch neuestes AdMob (Downgrade nicht möglich)
• Der Android-Resolver generiert immer noch die erwähnten veralteten Abhängigkeiten in ProjectSettings/AndroidResolverDependencies.xml sowie in der Gradle-Vorlage. Keine weitere Erwähnung veralteter Bibliotheken projektweit
• veraltete Bibliotheken verschwinden nach dem Entfernen des Facebook SDK.

Gibt es Pläne, die Abhängigkeiten von FacebookSDK zu aktualisieren?

Noch ein Thema im März 2020

• Einheit 2019.3.4f1
• Facebook-SDK 7.18.1
• IronSource-SDK 6.15.0.1

Kann mit keinem anderen SDK auf dem Planeten bauen. Firebase und IronSource enthalten. Dies ist lächerlich, da es direkt auf Anzeigenoptimierungen und Geldbezogene Dinge zutrifft.

Noch ein Thema im März 2020

• Einheit 2019.3.4f1
• Facebook-SDK 7.18.1
• IronSource-SDK 6.15.0.1

Kann mit keinem anderen SDK auf dem Planeten bauen. Firebase und IronSource enthalten. Dies ist lächerlich, da es direkt auf Anzeigenoptimierungen und Geldbezogene Dinge zutrifft.

Die Lösung von Looply reicht nicht mehr aus, um zu funktionieren. Ich habe dieses Problem untersucht. Facebook muss sein SDK aktualisieren, um AndroidX verwenden zu können. Aber in der Zwischenzeit stellt Google das External Dependency Manager-Tool bereit, das das Facebook SDK (und andere alte Bibliotheken) Jetify soll, damit es mit AndroidX funktioniert. Leider funktioniert EDM aus irgendeinem Grund nicht mit dem Facebook SDK. ABER: Der mit Android Studio gelieferte Jetifier funktioniert! Exportieren Sie einfach Ihr Projekt aus Unity, öffnen Sie es in Android Studio und fügen Sie diese Zeilen zu gradle.properties hinzu:
android.useAndroidX=true
android.enableJetifier=true

Bauen und ausführen und alles sollte gehen. Allerdings: Facebook muss dies pronto beheben. (Oder Google muss seinen Jetifier reparieren.) Jedes Unternehmen, das ich kenne, groß und klein, hat jedoch AndroidX-Versionen ihrer Bibliotheken veröffentlicht. Ich bin schockiert, dass Facebook, ein riesiges Unternehmen, dies noch nicht behoben hat, da es Entwicklern viel Ärger bereitet.

@lexscite

Für alle, die noch daran hängen:
1) Sie können es mit Android Studio beheben (wie oben erwähnt).
2) Es gibt auch eine Lösung von onesignal: https://documentation.onesignal.com/docs/troubleshooting-unity#section -android-x-compatibility, mit der Sie Builds direkt aus Unity ausführen können (durch Hinzufügen einer settingsTemplate.gradle-Datei. )

Es scheint, dass die Jetifier/AndroidX-Unterstützung in Unity etwas kaputt ist.

Dieser Fehler:
https://github.com/googlesamples/unity-jar-resolver/issues/360 habe ich beim unity-jar-resolver-Team eingereicht, aber wir werden sehen, ob dies überhaupt das richtige Team ist, um das Problem zu beheben.

Es sind keine Android Studio-Exporte mehr erforderlich, damit Jetifier in Unity funktioniert.

Mit der neuesten offiziellen Version 2019.3 (meine ist 2019.3.12f1 atm) können Sie einfach die benutzerdefinierte Gradle-Eigenschaftsvorlage über der Haupt-Gradle-Vorlage verwenden und Folgendes hinzufügen:
android.useAndroidX=true
android.enableJetifier=true
in die neu generierte Datei gradleTemplate.properties.

Ich habe in Android Studio exportiert, um mit allen SDKs zu bauen, die mein Publisher will, und seitdem die Misere von Android-Build-Fehlern durchgearbeitet, als Junior-Entwickler denke ich, dass ich auf jedes Problem gestoßen bin, aber jetzt kann ich endlich aus Unity heraus bauen. Jetifier funktionierte nicht richtig mit Facebook SDK, außer in Android Studio. Wenn Sie also genügend von AndroidX migrierte Plugins verwendet haben, wäre es ohne einige hackige Änderungen schwierig, innerhalb von Unity zu erstellen.

Normalerweise muss ich auch Plugins/Android/AndroidManifest.xml ändern, um dies im Anwendungs-Tag zu haben:
tools:replace="android:appComponentFactory" android:appComponentFactory="leavemealone"
auch xmlns:tools="http://schemas.android.com/tools" im Manifest-Tag

Ja, es ist eine zufällige Zeichenfolge, da ich nicht sicher bin, was der Zweck davon ist, aber es funktioniert und behebt meinen manifesten Merger-Build-Fehler, na ja.

Ich kann jetzt mit Ironsource (viele Adapter damit), Facebook SDK, GameAnalytics, Adjust, Firebase und was auch immer bauen. Im Grunde holen Sie sich einfach den neuesten Unity Jar Resolver, überprüfen Sie die Einstellungen, entfernen Sie die automatische Auflösung, entfernen Sie die Auflösung beim Build, setzen Sie das Patch-Maintemplate und verwenden Sie den Jetifier auf true, erzwingen Sie die Auflösung, fügen Sie alle gewünschten zusätzlichen Abhängigkeiten / Repos hinzu, führen Sie den Gradleproperties-Trick aus, bauen Sie in Unity auf, fertig .

Ich bin auf dieses Problem beim Facebook Unity SDK v8.1.1 gestoßen. Muss ich all die Dinge tun, die @mohamad-al-amaary jedes Mal getan hat, wenn ich das Facebook Unity SDK integrieren möchte?

@nguyentrong101094
In den 2019.4 LTS Unity-Versionen hatte ich keine Probleme, alles, was Sie tun müssen, ist dieser Teil meiner ersten Antwort:
android.useAndroidX=true
android.enableJetifier=true

Ich denke auch, dass neues EDM eine Option "Patch gradleTemplate.properties" hat, die das sogar für Sie tun sollte. Ich aktiviere jetzt zumindest für jedes Projekt das benutzerdefinierte Hauptmanifest, die benutzerdefinierte Haupt-Gradle-Vorlage, die benutzerdefinierte Gradle-Eigenschaftenvorlage und stelle die beiden Eigenschaften ein und stelle sicher, dass sie mit EDM aufgelöst werden (https://github.com/googlesamples/unity-jar- Resolver/blob/master/external-dependency-manager-latest.unitypackage) vor dem Build.

@Subtle-Tea Das habe ich versucht. Ich bekomme immer noch diesen Fehler beim Build

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

Ich verwende Unity 2019.4.17