Facebook-sdk-for-unity: Android - falha na inicialização causada por incompatibilidades nas dependências

Ei @andnoonesthere , tive o mesmo problema e passei algum tempo ontem fazendo um fork que funciona com 2019.2.0f1 e Firebase. Eu testei a funcionalidade de ambos os SDKs no Android e no iOS e _parece_ que tudo está funcionando conforme o esperado. Como um aviso, as mudanças em meu fork devem tornar o processo de compilação incompatível com versões anteriores ao compilar o SDK por meio dos scripts fornecidos com versões do Unity anteriores a 2019.2.0f1.

Observe que se você quiser construir o SDK localmente, atualizei o repo para exigir a configuração de uma variável de ambiente para que as instâncias do Unity baseadas em Hub possam ser usadas (os arquivos .csproj e scripts de shell têm caminhos embutidos em código neste repo, tornando impossível construir em máquinas que não usam esse caminho exato para o Unity).

Caso você esteja interessado nas alterações que fiz, a diferença relevante está localizada aqui . O pacote está localizado aqui .

Entre em contato se tiver problemas para colocá-lo em funcionamento.

Observação adicional relacionada a esse problema específico, já que estou postando no repositório correto desta vez: removi o script do resolvedor que você referenciou em seu comentário e migrei as dependências para o arquivo Dependencies.xml e atualizei a versão do resolvedor e isso corrigiu a dependência problemas que eu estava tendo; que esperançosamente irá corrigi-los para você também.

Olá Michael,

Acabei de testar suas alterações (somente Android) e funcionou muito bem para mim também. Bom trabalho! :)
Também concordo que mover dependências para o arquivo Dependencies.xml também é uma coisa importante a se fazer.

Olhando para as suas alterações, acho que tanto a correção para as dependências quanto os caminhos da solução devem ser incluídos no SDK pelos desenvolvedores, para que seja mais fácil fazer nossas próprias modificações no futuro.

Obrigado novamente por seu trabalho. Eu acho que até que eles lançem um patch oficial estarei usando sua versão :)

Depois de alguns testes adicionais, vejo que, embora esteja tudo bem no dispositivo, recebo este aviso no editor:

FB.Init () já foi chamado. Você só precisa ligar para isso uma vez e apenas uma vez.

No entanto, tenho 100% de certeza de que ele é chamado apenas uma vez, realizo uma verificação adicional para FB.IsInitialized logo antes. Isso também pode não estar relacionado com a sua modificação, mas com algum bug no FB SDK recente. Deixe-me saber se você também tiver essa experiência.

Feliz por ajudar! Vou tentar manter meu fork atualizado conforme novas versões do SDK são lançadas até 2019.2.0f1 ser oficialmente adicionado.

Em relação ao seu último comentário: não estou vendo esse aviso no editor ou no dispositivo. Minha suspeita é que você está vendo isso porque FB.Init() não configura FB.IsInitialized imediatamente para true ; o SDK deve completar a inicialização - o que não é garantido ser imediato - antes de FB.IsInitialized ser definido.

O Editor espera especificamente que um delegado de carregamento de DLL seja chamado, o que pode ser visto aqui .

Eu recomendo acompanhar se a inicialização do Facebook está em andamento, além de se FB.IsInitialized é true ou não. Uma maneira rápida de rastrear isso é com um bool _isInitializing; que é definido como true no momento de FB.Init e definido como false no InitDelegate que você passa para o método FB.Init . Dessa forma, você pode abortar FB.Init chamadas adicionais se uma estiver em andamento, além de se já estiver concluída.

OK, então o erro foi devido à forma como carrego as cenas no modo de reprodução. Ao entrar no modo de reprodução, descarrego todas as cenas carregadas e, em seguida, carrego meu conjunto personalizado de cenas. Aí foi carregado duas vezes, já estava carregado naquela cena básica que foi descarregada no começo. Obrigado pelas dicas de qualquer maneira :)

Olá, @KylinChang. Por que isso foi fechado? Você já corrigiu problemas de dependências do seu lado e isso será incluído na próxima versão? Eu não vi nenhuma informação sobre isso.

Olá @andnoonesthere , Achei que você corrigiu os problemas. Eu reabri o problema e apresento uma tarefa para corrigi-lo.

@KylinChang - sim, meus problemas foram corrigidos por enquanto. Isso é graças ao fork feito por @ michael-looply. No entanto, suas alterações precisam ser adicionadas ao repositório principal, caso contrário, é apenas uma correção temporária. THX.

Olá @andnoonesthere e @ michael-looply. Qual versão do Firebase and Play Services Resolver você está usando, ou uma pergunta mais simples, como você usa sua solução alternativa?

Temos exatamente o mesmo problema e estamos tentando usar o Firebase 6.2.2 com seu resolvedor de serviços de reprodução e a solução alternativa fornecida por @ michael-looply com seu resolvedor de serviços de reprodução (tentamos os dois resolvedores e também um que não usar gradle), mas não foi possível compilar o aplicativo. Não tenho certeza se estamos fazendo algo errado ou se há algum outro plug-in que causa o mesmo problema que o Facebook (como AdMob, IronSource etc.)

Olá @Wolar - Estou usando o Firebase 6.2.2 e o Resolver 1.2.124.0. Eu mantenho apenas um diretório PlayServicesResolver em meu projeto. Que erros de compilação você está vendo? Não estou usando SDKs de mediação de anúncios fora do Unity Ads no momento, então não posso falar se eles estão causando mais problemas ou não.

É um erro de compilação do Gradle e é algo como:

"com.android.support.support-v4-27.0.2.aar 'usando Jetifier. Razão. O artefato fornecido contém um literal de string com uma referência de pacote' android.support.v4 'que não pode ser reescrito com segurança. Bibliotecas usando reflexão, como pois os processadores de anotação precisam ser atualizados manualmente para adicionar suporte para androidx .. () "

O SDK do Facebook está usando essa biblioteca e acho que alguma outra biblioteca também a usa. Eu tentei Jetifier habilitado e desabilitado em PlayServicesResolver, mas sem nenhum efeito. Também estamos usando um modelo gradle personalizado, de modo que PlayServicesResolver não copia as bibliotecas para a pasta Plugins, mas as adiciona a esse modelo gradle, mas acho que isso não deve ter nenhuma função.

@Wolar Você tem aquele AAR presente em seu diretório de ativos? É possível que outro SDK não esteja usando o Resolver e apenas importe diretamente os AARs para o projeto.

Como alternativa, seu bloco de dependências em mainTemplate.gradle contém duas referências à biblioteca de suporte? Você não pode ter duas versões explícitas da mesma biblioteca listada; se você tiver uma linha em seu bloco de dependências como implementation 'com.android.support:support-v4:25.3.1' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:7 do Resolver dentro do

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

seção e tem outra fora dessa seção como implementation 'com.android.support:support-v4:27.0.2' , então você não será capaz de construir. Por exemplo, o plugin ironSource Unity aconselha a modificação manual do arquivo mainTemplate.gradle com uma referência de biblioteca de suporte . Pode ser necessário criar um Dependencies.xml para ironSource que o Resolver possa processar em vez de modificar seu mainTemplate.gradle diretamente.

@ michael-looply Tenho certeza de que temos um dos AARs na pasta de plug-ins também, mas acho que tentei excluí-lo, pois esperava que pudesse causar o problema, mas acho que não ajudou. Vou verificar os outros sdks como IronSource, obrigado :)

Consegui resolver, eram mais problemas. O que realmente me ajudou foi exportar o projeto como projeto Android Studio e depurá-lo lá. Basicamente, essas bibliotecas também estavam em conflito com a AdMob e algumas bibliotecas restantes do Fabric que não usamos mais. Então, eu atualizei a AdMob, excluí aquele aar, alterei fortemente algumas versões de bibliotecas em arquivos de dependência e parece estar funcionando com o jetifier como libs androidx. Obrigado pela ajuda @ michael-looply

@Wolar Fico feliz em saber que está funcionando! Feliz por ajudar :)

Então, @KylinChang quando podemos esperar progresso neste?

@KylinChang ?

Ainda um problema em fevereiro de 2020.

• Unity 2019.3.1f1 (impossível fazer downgrade)
• mais novo facebook-unit-sdk-7.18.1
• uso obrigatório de androidx e jetifier devido ao AdMob mais recente (impossível fazer downgrade)
• O resolvedor Android ainda gera dependências obsoletas mencionadas em ProjectSettings / AndroidResolverDependencies.xml, bem como no modelo gradle. Nenhuma outra menção de bibliotecas obsoletas em todo o projeto
• as bibliotecas obsoletas desaparecem após a remoção do SDK do Facebook.

Existem planos para atualizar as dependências do FacebookSDK?

Ainda um problema em março de 2020

• Unity 2019.3.4f1
• SDK do Facebook 7.18.1
• IronSource SDK 6.15.0.1

Não consigo construir com qualquer outro SDK do planeta. Firebase e IronSource incluídos. Isso é ridículo porque se aplica diretamente a otimizações de anúncios, coisas relacionadas a dinheiro.

Ainda um problema em março de 2020

• Unity 2019.3.4f1
• SDK do Facebook 7.18.1
• IronSource SDK 6.15.0.1

Não consigo construir com qualquer outro SDK do planeta. Firebase e IronSource incluídos. Isso é ridículo porque se aplica diretamente a otimizações de anúncios, coisas relacionadas a dinheiro.

A solução do Looply não é mais suficiente para funcionar. Eu investiguei esse problema. O Facebook precisa atualizar seu SDK para usar o AndroidX. Mas, nesse meio tempo, o Google fornece a ferramenta Gerenciador de Dependência Externa, que deve Jetify o SDK do Facebook (e outras bibliotecas antigas) para que funcione com o AndroidX. Infelizmente, o EDM não funciona com o Facebook SDK por algum motivo. NO ENTANTO: O Jetifier que vem com o Android Studio funciona! Basta exportar seu projeto do Unity, abrir no Android Studio e adicionar estas linhas a gradle.properties:
android.useAndroidX = true
android.enableJetifier = true

Construa e execute e tudo deve funcionar. No entanto: o Facebook precisa consertar isso imediatamente. (Ou o Google precisa consertar seu Jetifier.) No entanto, todas as empresas que conheço, grandes e pequenas, lançaram versões AndroidX de suas bibliotecas. Estou chocado que o Facebook, uma grande empresa, ainda não tenha corrigido isso, pois isso causa muita dor aos desenvolvedores.

@lexscite

Para quem ainda está preso a isso:
1) Você pode corrigi-lo usando o Android Studio (como mencionei acima).
2) Há também uma solução da onesignal: https://documentation.onesignal.com/docs/trou troubleshooting-unity#section -android-x-compatibilidade que permite executar compilações diretamente do Unity (adicionando um arquivo settingsTemplate.gradle. )

Parece que o suporte Jetifier / AndroidX no Unity está um pouco quebrado.

Este bug:
https://github.com/googlesamples/unity-jar-resolver/issues/360 foi o que preenchi com a equipe Unity-jar-resolver, mas veremos se essa é a equipe certa para consertar.

Não há mais necessidade do Android Studio Exports para que o Jetifier funcione no Unity.

Usando a versão oficial mais recente de 2019.3 (a minha é 2019.3.12f1 atm), você pode simplesmente usar o modelo personalizado de propriedades do Gradle na parte superior do modelo principal do Gradle e adicionar:
android.useAndroidX=true
android.enableJetifier=true
para o arquivo gradleTemplate.properties recém-gerado.

Tenho exportado para o Android Studio para construir com todos os SDKs que meu editor deseja e trabalhado com as misérias dos erros de compilação do Android desde então, como um desenvolvedor júnior acho que encontrei todos os problemas, mas agora posso finalmente construir de dentro do Unity. O Jetifier não funcionava corretamente com o SDK do Facebook, exceto no Android Studio, então, se você usasse plug-ins migrados do AndroidX suficientes, seria difícil construir de dentro do Unity sem algumas mudanças de hacky.

Normalmente também preciso alterar Plugins / Android / AndroidManifest.xml para ter isso na tag do aplicativo:
tools:replace="android:appComponentFactory" android:appComponentFactory="leavemealone"
também xmlns:tools="http://schemas.android.com/tools" na tag de manifesto

Sim, é uma string aleatória, pois não tenho certeza de qual é o propósito disso, mas funciona e corrige meu erro de compilação de fusão de manifesto, tudo bem.

Agora posso construir com Ironsource (muitos adaptadores com ele), Facebook SDK, GameAnalytics, Adjust, Firebase, qualquer outro. Basicamente, pegue o Unity Jar Resolver mais recente, verifique as configurações, remova a resolução automática, remova a resolução na compilação, defina o patch de manutenção e use o jetifier para true, force a resolução, adicione quaisquer dependências / repositórios extras que desejar, faça o truque do gradleproperties, compile dentro do Unity, pronto .

Encontrei esse problema no Facebook Unity SDK v8.1.1. Devo fazer todas as coisas que @ mohamad-al-amaary fazia sempre que desejo integrar o SDK do Unity do Facebook?

@ nguyentrong101094
Nas versões 2019.4 LTS Unity não tive problemas, tudo que você precisa fazer é esta parte da minha resposta inicial:
android.useAndroidX = true
android.enableJetifier = true

Além disso, acho que o novo EDM tem uma opção "Patch gradleTemplate.properties" que deve fazer isso para você mesmo. Acabei de ativar o manifesto principal personalizado, o modelo principal personalizado do Gradle, o modelo personalizado de propriedades do Gradle em cada projeto, pelo menos, e definir as duas propriedades e ter certeza de resolver com EDM (https://github.com/googlesamples/unity-jar- resolver / blob / master / external-dependency-manager-latest.unitypackage) antes da construção.

@Subtle-Tea eu tentei isso. Ainda recebo este erro ao construir

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

Estou usando o Unity 17/04/2019