Flutter: Compatível com pacotes de aplicativos com binários de 32 e 64 bits dentro deles

não

Eu tive o mesmo aviso. Alguém da equipe do Flutter poderia comentar ou explicar o mesmo, e o que podemos fazer para garantir que o appbundle gerado com flutter build appbundle --release também tenha o código de 64 bits. @zoechi Você pode nos contar algo sobre isso?

Eu também estou vendo isso. Aqui está uma captura de tela:

E a documentação "saiba mais" está aqui: https://developer.android.com/distribute/best-practices/develop/64-bit

Estou ansioso por uma resposta da equipe Flutter.

Também recebi esta mensagem de aviso hoje.

O mesmo problema aqui.

eu também

eu também

Já existe uma solução para isso?

Olhe para isto: https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

Funcionou para mim

o botão [start rollout to internal test] está desabilitado na página de lançamentos de aplicativos do Google Play Console (a tela onde a mensagem de aviso de 64 bits acima aparece)

o requisito de pacote de 64 bits agora é um obstáculo para projetos de flutter.

/ cc @mklim @cbracken

Parece que a Play Store começou a emitir um aviso que é acionado se usar as instruções de lançamento padrão do Flutter.
https://flutter.dev/docs/deployment/android

É possível enviar APKs para ARM de 32 e 64 bits com Flutter; no momento, isso requer apenas algumas etapas extras. Várias abordagens para resolver isso são discutidas em:
https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

Também estamos procurando agora para ver a melhor forma de atualizar o modelo / ferramentas / etapas de versão padrão para evitar esse aviso.

Obrigado pela sua paciência.

@eseidelGoogle Corrija-me se eu estiver errado, no entanto, pensei que o objetivo de um pacote de aplicativos era compactar tudo em um único arquivo e permitir que a Play Store enviasse apenas o

Como indiquei na minha pergunta original, estou usando flutter build appbundle . Nesse caso, a solução que você propôs não se aplicaria, certo?

Tentamos flutter build appbundle ontem e estávamos recebendo mensagens de erro da Play Store informando que era uma compilação de depuração ...

é claro que também precisa funcionar em cenários add2app onde as instruções de flutter.dev não são usadas, mas em vez disso, o android studio build-> Generate Signed APK é usado

Obrigado por classificá-lo como crítico

Acabamos de discutir isso pessoalmente. @tvolkert vai encontrar alguém para ajudar a encerrar isso.

Também estou recebendo este aviso, há uma maneira de padronizar para 64 bits?

Uma pequena modificação em build.gradle pode forçar a inclusão de libs nativos de 64 bits no apk e aab de lançamento - dê uma olhada aqui para uma solução alternativa

Para o bem do Google, dê-nos visibilidade de quantos telefones ainda usam 32 bits.
Se você adicionar libs de 64 bits e 32 bits, você aumenta o tamanho final do apk.

Eu tenho um projeto sem oscilação, onde divido o APK por ABI, então tenho apks separados para 32 bits e 64 bits para reduzir o tamanho. Agora, esta etapa parece me forçar a aumentar o tamanho do apk no futuro.
Mas por que ?

Não tenho estatísticas de quantos telefones de 32 bits existem na Índia / África ... Tenho certeza de que não há quase nada na Europa, nos Estados Unidos e em partes da Ásia.
E quanto ao x86 / x86_64 vs armeabi / arm64-v8a? Precisamos adicionar libflutter.so para todos os 4 ABIs no apk de produção final?
.. também mips ... há algum telefone por aí que ainda usa mips? Somente o google sabe.

@VarolOkan Use AAB e deixe o Google gerar

o botão [start rollout to internal test] está desabilitado na página de lançamentos de aplicativos do Google Play Console (a tela onde a mensagem de aviso de 64 bits acima aparece)

o requisito de pacote de 64 bits agora é um obstáculo para projetos de flutter.

@eseidelGoogle ou qualquer pessoa - alguém pode confirmar se este é
a) um empecilho
ou b) um aviso até agosto
consulte: https://forums.expo.io/t/warning-with-the-google-play-64-bit-requirement/22305
Ele indica que há algumas caixas à esquerda para verificar e fazer funcionar, e se o aviso diz agosto, parece um grande problema se realmente é início de maio.

Além disso - muito útil saber se de fato não existem aproximadamente máquinas de 32 bits e usar um abiFilter de linha única para braço de 64 bits é uma opção viável para suportar 99,5% dos usuários ou algo assim; Eu vi alguém limpando um ano atrás "todos os telefones do mercado" eram de 64 bits ... talvez isso signifique que há muitos telefones antigos?

Meu entendimento é que isso não é um obstáculo, mas sim um aviso comum. Pedimos a @blasten para dar uma olhada no que podemos fazer aqui para fazer com que a configuração padrão do Flutter evite esse aviso. Espero que tenhamos algumas atualizações nos próximos dias.

Como @eseidelGoogle disse, cuidarei desse problema. Enquanto isso, você tentou seguir estas etapas https://github.com/flutter/flutter/issues/18494#issuecomment -489807239?

Isso não é mais um problema? https://github.com/flutter/flutter/issues/18494#issuecomment -482795450

Não é um empecilho. Recebi o aviso, mas consegui liberar meu aplicativo para
a playstore.

Kr Morten

Na terça - feira, 7 de maio de 2019 às 17h46, Audrius Karosevicius
escreveu:

Isso não é mais um problema? # 18494 (comentário)
https://github.com/flutter/flutter/issues/18494#issuecomment-482795450

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/31922#issuecomment-490135779 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AA4B4J5BY3BJVIELNEPC4N3PUGP7BANCNFSM4HJU7TZA
.

>

;-)
/ Morten

Web: http://buildsucceeded.dk
Mobil: 51 21 90 79

Para resumir:

1) No início deste ano, o Play comunicou aos desenvolvedores que exigirá que os aplicativos carregados na loja forneçam versões de 64 bits a partir de agosto (https://android-developers.googleblog.com/2019/01/get-your-apps-ready -for-64-bit.html). Esta semana, a Play Store começou a exibir uma mensagem informativa para aplicativos carregados para fornecer um aviso sobre o próximo requisito. No entanto, os requisitos da Play Store não mudaram neste momento.

2) O requisito do APK de 64 bits cujas referências de aviso são possíveis de cumprir agora com um pequeno esforço manual para modificar os arquivos gradle em um projeto Flutter: https://github.com/flutter/flutter/issues/18494#issuecomment - 489807239 para um exemplo de como.

3) Estamos trabalhando para tornar o comportamento padrão do Flutter compatível com as próximas atualizações das diretrizes do Play em relação ao suporte de 64 bits, sem nenhum esforço adicional dos usuários. Espero que as obras sejam concluídas nos próximos dias / semanas, muito antes dos prazos de agosto.

Se eu esqueci alguma coisa acima, por favor, não hesite em comentar ou entrar em contato. Pedimos desculpas por não termos atualizado antes de o Play ativar o aviso. Obrigado a todos por sua ajuda e feedback!

@eseidelGoogle

1. Não consigo publicar o aplicativo criado por flutter build apk . A Play Store não aceita compilações somente de 32 bits em meu perfil.
2. A solução do nº 18494 (comentário) falha em dispositivos de 32 bits como o OnePlus One.

Na minha opinião, é um empecilho.

@eseidelGoogle

1. Resolvido. O Google Play não aceita nenhuma construção se Classificação e Países não estiverem configurados. Apenas a mensagem é enganosa.

O requisito do APK de 64 bits para o qual as referências de aviso são possíveis de cumprir agora com um pequeno esforço manual para modificar os arquivos gradle em seu projeto Flutter: # 18494 (comentário) para um exemplo de como.

depois de algumas horas de tentativa e erro, __não__ consegui produzir um apk assinado nem um appbundle contendo um libflutter.so de 64 bits

o único libflutter.so incluído no pacote é o
armeabi-v7a (32 bits)
, ao usar
Android Studio 3.4
Versão # AI-183.5429.30.34.5452501, construída em 10 de abril de 2019

menu: Build> Generate Signed Bundle / APK

flutter build apk --release --target-platform=android-arm64 -v
flutter build appbundle --release --target-platform=android-arm64 -v

ambos falham @> Tarefa: app: validateSigningRelease FALHA

@ciez Isso produziu apk de 64 bits apenas para mim:

$ flutter build apk --release --target-platform=android-arm64
Initializing gradle...                                              1.1s
Resolving dependencies...                                           1.8s
Running Gradle task 'assembleRelease'...                                
Running Gradle task 'assembleRelease'... Done                       9.0s
Built build/app/outputs/apk/release/app-release.apk (7.5MB).

@adriank
sim, funciona.
descobri qual era o problema: "~" no caminho para o keystore.jks precisava ser substituído por / home / user

desculpe pelo falso alarme.

parece que cada pacote construído assim pode ter como alvo apenas 1 arco, no máximo?

Aguardando a atualização do Flutter, pois a solução alternativa apenas interrompeu minhas compilações.

@mulderpf qual solução alternativa você aplicou e como sua construção

Veja este comentário para a última atualização da equipe Flutter.

Recebi uma atualização: tenho isso funcionando no meu ramo!
A sugestão é usar flutter build appbundle --release --target-platform=android-arm-all (recomendado para obter o APK dividido fora da caixa) ou flutter build apk --release --target-platform=android-arm-all em uma versão futura.

Alguém no fuso horário PST está disposto a experimentar? Em caso afirmativo, entre em contato no Gitter ou no Slack :)

@blasten Infelizmente, não consegui produzir appbundle com o seu branch. O Gradle falha em app:properties alguma forma, mas olhando para o código, parece promissor.
Você conseguiu verificar se flutter/engine carregará instantâneos AOT do diretório ./lib/ ? Olhando para o código do mecanismo, ele usa ativos em todos os lugares ... Se funcionar, resolverá o problema geral dos App Bundles, pois, por enquanto, eles não têm o suporte de direcionamento do diretório de ativos pela ABI.

@SPodjasek correto, ele também precisaria de uma construção local do mecanismo, para que as classes no APK procurassem os novos instantâneos.

@blasten Consegui consertar minha árvore de construção e agora posso construir com sucesso o App Bundle que contém instantâneos AOT em base/lib/${abi}/

  4649616  2019-05-13 20:52   base/lib/arm64-v8a/isolate_snapshot_data.so
  6296768  2019-05-13 20:52   base/lib/arm64-v8a/isolate_snapshot_instr.so
  8472736  2019-05-13 20:52   base/lib/arm64-v8a/libflutter.so
    32352  2019-05-13 20:52   base/lib/arm64-v8a/vm_snapshot_data.so
    19200  2019-05-13 20:52   base/lib/arm64-v8a/vm_snapshot_instr.so
  3700504  2019-05-13 20:52   base/lib/armeabi-v7a/isolate_snapshot_data.so
  6019680  2019-05-13 20:52   base/lib/armeabi-v7a/isolate_snapshot_instr.so
  6036116  2019-05-13 20:52   base/lib/armeabi-v7a/libflutter.so
    23520  2019-05-13 20:52   base/lib/armeabi-v7a/vm_snapshot_data.so
    12640  2019-05-13 20:52   base/lib/armeabi-v7a/vm_snapshot_instr.so

E eu me pergunto se seria o suficiente para modificar isso ...

https://github.com/flutter/engine/blob/1b649a57d18a8c41ae017d79cf9bdb999a2276ac/shell/platform/android/io/flutter/view/FlutterMain.java#L334 -L336

para algo como:

getContext().getApplicationInfo().nativeLibraryDir;

Claro, não seria tão simples, mas para ter uma ideia geral ...

Veja como tentar flutter build appbundle com suporte de 32 e 64 bits:

1. Baixe flutter.jar de https://drive.google.com/open?id=1yAkfhPKfhdd8MwW39qfkZDePc66SMA_z e coloque-o em {flutterInstallationPath}/bin/cache/artifacts/engine/android-arm-release . Para verificar o caminho de instalação do Flutter, use which flutter

Se você quiser ver as alterações em FlutterMain.java, consulte: https://github.com/blasten/engine/commit/b3ab9def28a414ffa53bf10ad6a3249f31ed00e3

1. Confira o patch deste branch:

$ cd {flutterInstallationPath}
$ git remote add arm-all https://github.com/blasten/flutter
$ git fetch arm-all apk_defaults
$ git checkout apk_defaults

$ git build appbundle --release --target-platform=android-arm-all

Deixe-me saber o que você encontrar.

+1

@danysz Em vez de escrever +1, se você tivesse votado a favor deste assunto, faria mais sentido (sem ressentimentos para você). Para os outros, se eles lerem esta mensagem, por favor, não escreva "eu também", "o mesmo aqui", "+1", em vez disso vote positivamente neste problema.

Obrigado!

Os aplicativos

05-14 10:50:35.979  3445 28828 I ActivityManager: Start proc 30019:xxx/u0a262 for activity xxx/com.example.flutterapp.MainActivity
05-14 10:50:36.067 30019 30019 I FirebaseInitProvider: FirebaseApp initialization successful
05-14 10:50:36.108 30019 30019 E flutter : [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings.
05-14 10:50:36.108 30019 30019 E flutter : [ERROR:flutter/runtime/dart_vm.cc(241)] Could not setup VM data to bootstrap the VM from.
05-14 10:50:36.108 30019 30019 E flutter : [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance.
05-14 10:50:36.108 30019 30019 F flutter : [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.
05-14 10:50:36.108 30019 30019 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 30019 (xxx), pid 30019 (xxx)

Isso vai para o meu dispositivo físico e para o dispositivo 9/10 do Test Lab - temos um resultado inconsistente para o Pixel-Q-beta.

@danysz Em vez de escrever +1, se você tivesse votado a favor deste assunto, faria mais sentido (sem ressentimentos para você). Para os outros, se eles lerem esta mensagem, por favor, não escreva "eu também", "o mesmo aqui", "+1", em vez disso vote positivamente neste problema.

Obrigado!

feito

@blasten Analisando suas alterações, descobri que, para os aplicativos existentes, é necessário modificar AndroidManifest.xml

diff --git a/packages/flutter_tools/templates/app/android.tmpl/app/src/main/AndroidManifest.xml.tmpl b/packages/flutter_tools/templates/
app/android.tmpl/app/src/main/AndroidManifest.xml.tmpl
index 4778a2080..f3492835e 100644
--- a/packages/flutter_tools/templates/app/android.tmpl/app/src/main/AndroidManifest.xml.tmpl
+++ b/packages/flutter_tools/templates/app/android.tmpl/app/src/main/AndroidManifest.xml.tmpl
@@ -24,6 +24,11 @@
             <meta-data
                 android:name="io.flutter.app.android.SplashScreenUntilFirstFrame"
                 android:value="true" />
+            <!-- If true, the snapshots are read from lib instead of the assets 
+                 directory in the APK. -->
+            <meta-data
+                android:name="io.flutter.view.FlutterMain.snapshot-in-lib"
+                android:value="${snapshotInLib}" />
             <intent-filter>
                 <action android:name="android.intent.action.MAIN"/>
                 <category android:name="android.intent.category.LAUNCHER"/>

No entanto, ainda falha ...

@blasten

git build

$ git build appbundle --release --target-platform=android-arm-all

"git build" or "flutter build" ? :-)

Infelizmente, não consegui produzir appbundle com suas instruções. O Gradle falha nas propriedades do app: de alguma forma (após uma "Ferramenta de vibração de construção ..." e alguns downloads do android-arm - * ....).

Parece que o processo de download substituiu flutter.jar

@MoacirSchmidt Tive problemas semelhantes, mas a limpeza de diretórios de compilação ( flutter clean ) e caches de gradle ( ~/.gradle/caches & ${projectRoot}/android/.gradle ) ajudou

Para pessoas com problemas para criar apk de 64 bits.
Essa configuração funcionou para mim.

build.gradle

executar flutter build apk --release --target-platform=android-arm

increment versionCode

execute flutter build apk --release --target-platform=android-arm64

mais discussão em https://github.com/flutter/flutter/issues/18494

flutter build appbundle agora está no mestre, alguma pessoa voluntária quer tentar?

Para pessoas como eu, que tem medo de mudar os arquivos do Gradle - se você quiser apenas a versão de 64 bits, flutter build apk --release --target-platform=android-arm64 funciona mesmo sem modificar o build.gradle.

@blasten Tentei flutter build appbundle no canal beta . Quando tento fazer o upload para a Play Store, ainda recebo o erro 32/64.

Eu sei que você disse master mas ainda tenho alguns erros que estou resolvendo nesse branch. Só queria te dar essa informação!

Também estou recebendo este aviso!

Existe alguma maneira de construir um pacote de aplicativos para todas as arquiteturas?

Alguma atualização sobre como consertar isso?

Estou fechando este bug, pois se refere a pacotes de aplicativos. Se você mudar para o branch master, poderá usar flutter build appbundle para gerar pacotes de aplicativos que suportam arquiteturas de CPU de 32 e 64 bits. Se você preferir ou não puder usar pacotes de apps, siga este tópico para obter suporte adicional por meio de APKs gordos.

@blasten - você poderia fornecer algum tipo de instrução sobre como usá-lo no Android Studio?
Aqui está minha configuração de vibração atual:

Resumo médico (para ver todos os detalhes, execute flutter doctor -v):
[√] Flutter (Canal estável, v1.2.1, no Microsoft Windows [Versão 10.0.17763.503], local en-US)
[√] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
[√] Android Studio (versão 3.4)

Quando essa alteração irá para a filial stable ?

@blasten funciona com Add2App?

@blasten como assinar o pacote de aplicativos criado por flutter build appbundle?

@blasten é uma boa maneira de usar o branch master para aplicativos de produção?

@dblokhin você pode usar flutter channel master para mudar para o canal mestre. Observe que agora também está disponível no canal dev.

@tvolkert - qualquer período de tempo em que isso será mesclado com o branch stable ?

@ angel1st eu gostaria de convidar cerca de 3 meses a partir de agora.

@truongsinh - considerando que 1º de agosto é cerca de dois meses a partir de agora, eu esperaria uma adoção muito mais rápida, na verdade ...

@ angel1st já está estável! Vou descobrir mais ...

@ angel1st já está estável!

Você tem certeza sobre isso? O estável atual é 1.5.4-hotfix 2 e não está gerando bundles com 32 e 64. Ou estou faltando alguma coisa?

@shinayser ainda não é, desculpe. Vou descobrir mais e atualizar o tópico. Como Todd mencionou, o canal master é a única opção neste momento.

Eu tentei o appbundle. Eu tinha a versão 1.6.1 anterior do Flutter no master
canal.

A saída do pacote foi de cerca de 12 MB, o que não gerou o aviso
e os tamanhos de APK individuais estavam em torno de 7. Até agora, tudo está bem.

Mas quando abri o aplicativo após atualizar pela Play Store, meu aplicativo recebeu
preso na tela inicial.

Não tive escolha para reverter para o apk de compilação vibratório que funcionou bem, idk como
e porque.

Então, eu não acho que esse problema foi resolvido ainda, porque mesmo que o aviso
desapareceu com o appbundle, assim como o próprio aplicativo. O appbundle é
tornando o aplicativo inútil, pois fica preso na tela inicial.

Nesse caso, sinta-se à vontade para entrar em contato comigo diretamente no Gitter: https://gitter.im/flutter/flutter. Se possível, será útil enviar o arquivo .aab que a ferramenta gerou.

Acredito que precisamos documentar o uso de uma forma ou de outra. Também acredito que ter isso mesclado com stable antes do final de junho é vital se a equipe do Flutter quiser manter os desenvolvedores por perto.

@ angel1st estamos trabalhando muito para que este trabalho seja promovido a stable até o final de junho.

Algumas atualizações:

Conseguimos reproduzir os aplicativos que ficam presos na tela inicial após implantar um APK de um pacote de aplicativos (gerado usando flutter build appbundle do canal mestre).

Isso parece ser causado por nossa colocação dos instantâneos AOT ( vm-snapshot-data , vm-snapshot-instr , isolate-snapshot-data , isolate-snapshot-instr ) como bibliotecas dentro de /lib/{abi}/lib_{snapshot}.so para obter a divisão ABI para pacotes de aplicativos.

EDIT : A causa raiz acabou sendo que o código no incorporador Android espera um diretório denominado flutter_assets nesta linha , mas minha recente mudança para oferecer suporte a pacotes de aplicativos desativou a criação desse diretório, o que fez com que o aplicativo nunca iniciasse. Este compromisso de @ jason-simmons https://github.com/flutter/engine/compare/7f4f52f95294...e8db5dfd52ee corrige o problema.

Conclusão

O plano atual é permitir que a ferramenta flutter gere bibliotecas compartilhadas ELF em vez de instantâneos AOT. Este recurso acaba de ser adicionado ao Dart SDK em https://github.com/dart-lang/sdk/commit/af93ebcf4cb55ae5f0f39a183ad2d42ca13ae51f.

O que isso significa é que obteremos a divisão ABI para pacotes de aplicativos e APKs gordos usando bibliotecas reais.

Vou atualizar esse bug e https://github.com/flutter/flutter/issues/18494 assim que o problema for corrigido. Enquanto isso, passar --target-platform para build appbundle permitirá que você crie pacotes de aplicativos sem mover os instantâneos AOT para lib/ .

Algumas atualizações:

Conseguimos reproduzir os aplicativos que ficam presos na tela inicial após implantar um APK de um pacote de aplicativos (gerado usando flutter build appbundle do canal mestre).

Isso parece ser causado por nossa colocação dos instantâneos AOT ( vm-snapshot-data , vm-snapshot-instr , isolate-snapshot-data , isolate-snapshot-instr ) como bibliotecas dentro de /lib/{abi}/lib_{snapshot}.so para obter a divisão ABI para pacotes de aplicativos. Afinal, os instantâneos não são bibliotecas reais e nosso hack para obter esse comportamento não funcionou.

O plano atual é permitir que a ferramenta flutter gere bibliotecas compartilhadas ELF em vez de instantâneos AOT. Esse recurso acaba de ser adicionado ao Dart SDK em dart-lang / sdk @ af93ebc .

O que isso significa é que obteremos a divisão ABI para pacotes de aplicativos e APKs gordos usando bibliotecas reais.

Vou atualizar este bug e o # 18494 assim que o problema for corrigido. Enquanto isso, passar --target-platform para build appbundle permitirá que você crie pacotes de aplicativos sem mover os instantâneos AOT para lib/ .

@blasten funcionará corretamente quando você tiver outras bibliotecas que também usam código nativo? Por exemplo: VLC. Ele produz cerca de .so quando estamos construindo o APK.

Sim - você pode usar outras bibliotecas de código nativas em seu APK.

No novo formato de pacote, um aplicativo Flutter incluirá a biblioteca de mecanismo libflutter.so junto com outro .so contendo os dados do instantâneo AOT compilados do código Dart do seu aplicativo. O aplicativo pode adicionar outras .so bibliotecas não relacionadas ao Flutter, se necessário.

Para sua informação, a correção para o problema de travar na tela inicial deve estar no lançamento do canal dev 1.7.0 (em breve) (https://github.com/flutter/flutter/wiki/Bad-Builds#v161--- v167)

Olá a todos. A correção para o problema de travar na tela inicial foi parar no canal de desenvolvimento - você deverá ver se flutter upgrade para v1.7.0. Experimente e informe-nos se encontrar problemas com flutter build appbundle .

@tvolkert Não funcionou para mim antes e não funciona para mim agora. Nem no canal dev (1.7.0) nem no canal mestre (1.7.1). A construção do aplicativo com flutter build appbundle trava após ser publicado na Play Store e executado em um dispositivo real.
Editar: agora funciona no canal dev (1.7.0) após excluir o aplicativo do dispositivo e reinstalá-lo da Play Store.
Edit2: NÃO funciona. A Play Store foi um pouco mais lenta do que o normal enquanto distribuía a versão correta. O que posso fazer para ajudar na reprodução?

@masewo você pode coletar a marca de exclusão do dispositivo, junto com qual versão do Flutter estava em execução no momento?

@ jason-simmons @blasten mais alguma coisa que você gostaria de ajudar a rastrear isso?

@tvolkert

lápide:

2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: Build fingerprint: 'samsung/crownltexx/crownlte:9/PPR1.180610.011/N960FXXS2CSDJ:user/release-keys'
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: Revision: '28'
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: ABI: 'arm64'
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: pid: 8261, tid: 8261, name: asewo.myfirstapp  >>> net.masewo.myfirstapp <<<
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG: Abort message: '[FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.
    '
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x0  0000000000000000  x1  0000000000002045  x2  0000000000000006  x3  0000000000000008
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x4  0000000000000000  x5  0000000000000000  x6  0000000000000000  x7  0080000000000000
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x8  0000000000000083  x9  000000767c1f9890  x10 fffffff87ffffbdf  x11 0000000000000001
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x12 00000075ded1c000  x13 0000000000000008  x14 ffffffffffffffff  x15 0000402003ff3b02
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x16 000000767c2302b0  x17 000000767c16f958  x18 0000007fdd2251da  x19 0000000000002045
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x20 0000000000002045  x21 0000000000000083  x22 00000075edde02e0  x23 00000075dec79fc0
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x24 00000075de3a6150  x25 0000000000000000  x26 00000075f7614ca0  x27 0000000000000003
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x28 0000000000000000  x29 0000007fdd225b00
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     sp  0000007fdd225ac0  lr  000000767c162da0  pc  000000767c162dcc
2019-06-04 08:32:44.377 8326-8326/? A/DEBUG: backtrace:
2019-06-04 08:32:44.377 8326-8326/? A/DEBUG:     #00 pc 0000000000021dcc  /system/lib64/libc.so (abort+124)
2019-06-04 08:32:44.377 8326-8326/? A/DEBUG:     #01 pc 0000000000e4a6a0  /data/app/net.masewo.myfirstapp-J4PFXKn_O2diLnKpCeu2eg==/split_config.arm64_v8a.apk (offset 0xe2d000)

vibração:

D:\Programme\Android\flutter\bin\flutter.bat doctor --verbose
[√] Flutter (Channel dev, v1.7.0, on Microsoft Windows [Version 10.0.18362.145], locale de-DE)
    • Flutter version 1.7.0 at D:\Programme\Android\flutter
    • Framework revision f36a35d20a (3 days ago), 2019-05-31 15:27:56 -0400
    • Engine revision a32df2c928
    • Dart version 2.3.2 (build 2.3.2-dev.0.0 445a23a9bc)

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at D:\Programme\Android\sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: D:\Programme\Android\Android Studio Dev\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)
    • All Android licenses accepted.

[√] Android Studio (version 3.5)
    • Android Studio at D:\Programme\Android\Android Studio Beta
    • Flutter plugin version 36.0.7
    • Dart plugin version 191.7221
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b02)

[√] Connected device (1 available)
    • SM N960F • xxxxxxxxxxxxxxxx • android-arm64 • Android 9 (API 28)

@ jason-simmons @blasten é esta afirmação que está causando a falha no caso de @masewo

@masewo , não conseguimos reproduzir a falha do nosso lado sem nossos aplicativos - você gostaria de criar um arquivo .aab não assinado da versão 1.7.1 que demonstra esse comportamento e enviá-lo para mim por e-mail (tvolkert @ google .com)? Em caso afirmativo, isso seria extremamente útil!

Para sua informação, o seguinte anúncio foi enviado para [email protected] sobre nosso suporte de 64 bits.

https://groups.google.com/forum/#!topic/flutter -announce / oIzwT9EDczc

@tvolkert A equipe também está trabalhando para tornar https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps compatível com todos os pontos que você listou ?

1. Fornece uma maneira (por padrão) de criar um pacote de aplicativos compatível com 32 e 64 bits. (já disponível para teste no canal dev)

2. Fornece uma maneira (por padrão) de criar um APK compatível com 32 e 64 bits. (em progresso)

@truongsinh Sim, veja este comentário no PR pendente: https://github.com/flutter/flutter/pull/33696#issuecomment -498934359

@masewo e todos os outros: fomos capazes de replicar o travamento descrito em https://github.com/flutter/flutter/issues/31922#issuecomment -498541765 e o estamos rastreando.

tldr: aguarde um pouco - estamos resolvendo 🙂

Olá a todos,

TLDR:

Identificamos o problema com as falhas quando baixadas da Play Store e estamos trabalhando em uma correção, a ser entregue dentro do mesmo prazo descrito acima em https://github.com/flutter/flutter/issues/31922#issuecomment -498880614

Explicação de alto nível

Para os interessados, a explicação um tanto longa é que, com dispositivos executando Android Marshmallow ou posterior, a Play Store detectará aplicativos empacotados como App Bundles contendo vários ABIs - e instalará esses aplicativos no dispositivo na forma de "divisão APKs ". Ao fazer isso, os arquivos .so contidos neles não são extraídos do arquivo zip do APK, o que é diferente do comportamento dos APKs não divididos. Como o mecanismo atual do mecanismo Flutter

A solução é apenas dlopen as bibliotecas, e o Android abstrai onde as bibliotecas estão localizadas (ou seja, dentro de um arquivo ou não). No entanto, os arquivos .so necessários nunca foram bibliotecas verdadeiras para começar - eles eram apenas blobs binários de dados que carregamos no Dart VM. Então, como parte disso, estamos tornando-as bibliotecas ELF (por exemplo, https://github.com/dart-lang/sdk/commit/6d608fb52bc1926a73d986d73ab228b77cfb7ca2 e https://github.com/flutter/flutter/pull/33696).

Olá a todos,

Acreditamos que todas as correções chegaram na ponta da árvore no canal master . Se você quiser experimentá-los, faça o seguinte:

• flutter build appbundle

  Por padrão, o App Bundle contém seu código Dart e o tempo de execução Flutter compilado para armeabi-v7a (32 bits) e arm64-v8a (64 bits)

• flutter build apk --split-per-abi

  Este comando resultará em dois APKs:

  build/app/outputs/apk/release/app-armeabi-v7a-release.apk
build/app/outputs/apk/release/app-arm64-v8a-release.apk

• flutter build apk

  Isso resultará em um APK gordo que contém seu código compilado para todos os ABIs de destino. Esses APKs serão maiores em tamanho do que suas contrapartes divididas, fazendo com que o usuário baixe binários nativos que não são aplicáveis ​​à arquitetura de seu dispositivo.

flutter build appbundle agora está trabalhando para mim. Obrigado @tvolkert !

Pode confirmar que está funcionando (depois de alternar para o mestre) em vários dispositivos Android. Que salva-vidas, obrigado.

Excelente! Os agradecimentos vão para @blasten , @ jason-simmons e @ rmacnak-google - sou apenas o mensageiro 🙂

Obrigado a todos da equipe e colaboradores do Flutter por uma resposta tão rápida. Esperançosamente, este chegará ao canal beta em 1,5 meses :)

@tomaszpolanski o plano é colocá-lo em beta no final de junho e estável no início de julho 🙂

@tvolkert existe um sinalizador de comando flutter build appbundle que podemos passar para incluir também o x86?

@athornz não está no modo de liberação atm. Consulte: https://github.com/flutter/flutter/issues/9253. No entanto, será possível adicionar instantâneos AOT para x86_64 em um futuro próximo.

Mudar para o branch master me dá o seguinte erro. Construções estáveis, mas não incluem 64 bits no pacote de lançamento.

Running flutter doctor...
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, v1.7.4-pre.108, on Mac OS X 10.14.5 18F132, locale nl-NL)
[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
[✓] iOS tools - develop for iOS devices
[✓] Android Studio (version 3.4)
[✓] IntelliJ IDEA Community Edition (version 2018.2.7)
[✓] Connected device (1 available)

• No issues found!
MacBook-Pro-van-Wendel:zaira wendel$ flutter build appbundle --build-name=1.0.6 --build-number=6 -t lib/main_prod.dart --flavor=prod
Initializing gradle...                                              0,9s
Resolving dependencies...                                           2,2s
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
Running Gradle task 'bundleProdRelease'...                              
Running Gradle task 'bundleProdRelease'... Done                    78,6s
Gradle task bundleProdRelease failed with exit code 1

@xinoxapps , você pode enviar a saída completa de flutter build appbundle -v (como um link gist.github.com, para facilitar a leitura deste tópico 🙂)?

@xinoxapps , não consegui reproduzir este problema localmente. Agora, observando os avisos que você está recebendo, parece que há alguma lógica de configuração build.gradle , que pode ou não estar causando o problema. Seria possível chegar a um caso mínimo de reprodução? Por exemplo, tente remover algumas das configurações personalizadas do Gradle até que funcione e, em seguida, compartilhe o que exatamente causou o problema. É assim que eu defini o sabor:

android {
  flavorDimensions "version"
    productFlavors {
        prod { }
    }
}

Olá a todos,

Essas correções agora estão ativas no canal dev , no lançamento v1.7.4 ou posterior.

Mudei para pacotes de aplicativos e empurrei para a Play Store, e a maioria dos usuários parece feliz. No entanto, tenho dois relatórios do aplicativo que não inicia em um dispositivo x86 que suporta emulação ARM, o Asus ZenFone 2 ZE551ML: https://www.gsmarena.com/asus_zenfone_2_ze551ml-6917.php. Infelizmente, os usuários não foram capazes de fornecer a saída adb logcat. O novo formato ELF foi projetado para funcionar nesses dispositivos?

Mudar para os canais master e dev me dá este erro com flutter build appbundle :

* What went wrong:
Execution failed for task ':app:transformNativeLibsWithMergeJniLibsForProductionRelease'.
> More than one file was found with OS independent path 'lib/armeabi-v7a/libapp.so'

@darioielardi você pode incluir links gist.google.com com a saída de flutter build appbundle -v , bem como o conteúdo de seus arquivos android/build.gradle e android/app/build.gradle ?

@tvolkert certo, https://gist.github.com/darioielardi/f7497398a39b2c12d4ea1767ca6b6e69

Mudei para pacotes de aplicativos e empurrei para a Play Store, e a maioria dos usuários parece feliz. No entanto, tenho dois relatórios do aplicativo que não inicia em um dispositivo x86 que suporta emulação ARM, o Asus ZenFone 2 ZE551ML: https://www.gsmarena.com/asus_zenfone_2_ze551ml-6917.php. Infelizmente, os usuários não foram capazes de fornecer a saída adb logcat. O novo formato ELF foi projetado para funcionar nesses dispositivos?

sim, eu tenho o mesmo problema. ele funciona com appbundle flutter build e a maioria dos dispositivos executa bem meus aplicativos. mas não para este asus

re: x86: https://github.com/flutter/flutter/issues/31922#issuecomment -501851721

@blasten Sim, entendo que x86 nativo não é compatível, mas acho que o problema aqui é que os pacotes de aplicativos ARM / ARM64 estão sendo instalados pelo Google Play em dispositivos x86 que anunciam suporte para ARM por meio de tradução, mas os novos appbundles de alguma forma não funcionar corretamente em tais dispositivos (talvez porque os novos formatos ELF confundem o tradutor ARM). Os APKs ARM (não ARM64) originais parecem funcionar neles, no entanto, conforme confirmado, revertendo para um branch master de duas semanas (e1a784ae para ser específico) e observando que os dois usuários que estavam vendo problemas agora têm meu aplicativo executando novamente em seus dispositivos ZenFone 2. Isso vai me impedir de atualizar para a v1.7.4.

@xinoxapps , você pode enviar a saída completa de flutter build appbundle -v (como um link gist.github.com, para facilitar a leitura deste tópico 🙂)?

Funciona para mim agora no canal dev. Você ainda precisa de alguma informação?

@xinoxapps não - fico feliz em saber que está funcionando para você.

@darioielardi o problema foi corrigido no master agora. Execute flutter upgrade no canal mestre.

@darioielardi o problema foi corrigido no master agora. Execute flutter upgrade no canal mestre.

@blasten Eu mudei para o mestre e flutter build appbundle
Execution failed for task ':app:transformClassesAndResourcesWithProguardForRelease'.

este é meu gradle e saída completa https://gist.github.com/julindra/80cd2e588cf11bdd0df3f34239b07409

Olá a todos,

Nosso objetivo é conseguir mais algumas correções de bug para add-to-app e sabores - e cortar uma versão v1.7.5 dev. Como tal, estamos adiando a promoção para a versão beta para obter essas correções. Ainda esperamos estabilidade no início de julho.

flutter build appbundle funcionou para mim. Muito obrigado @tvolkert .

@julindra adicionar -ignorewarnings a 'proguard-rules.pro corrige esse problema. Atualmente, não incluímos o pacote android.arch. *. Outra opção é editar seu android/app/build.gradle e adicionar o seguinte:

.gradle dependencies { implementation "android.arch.lifecycle:common-java8:1.1.1" implementation 'android.arch.lifecycle:extensions:1.1.1' }

cc @ matthew-carroll

Eu carreguei o pacote app.aab para a Play Store. O aviso de 64 bits ausentes havia desaparecido, mas o aplicativo travou ao ser iniciado após a instalação da Play Store. Alguma sugestão?

Também é seguro usar flutter build appbundle para lançar em produção?

@sulaysumaria você pode postar o resultado da execução de flutter doctor ?

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.5.4-hotfix.2, on Mac OS X 10.14.5 18F132, locale en-IN)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✗] iOS toolchain - develop for iOS devices
    ✗ Xcode installation is incomplete; a full installation is necessary for iOS development.
      Download at: https://developer.apple.com/xcode/download/
      Or install Xcode via the App Store.
      Once installed, run:
        sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
    ✗ libimobiledevice and ideviceinstaller are not installed. To install with Brew, run:
        brew update
        brew install --HEAD usbmuxd
        brew link usbmuxd
        brew install --HEAD libimobiledevice
        brew install ideviceinstaller
    ✗ ios-deploy not installed. To install:
        brew install ios-deploy
    ✗ CocoaPods not installed.
        CocoaPods is used to retrieve the iOS platform side's plugin code that responds to your plugin usage on the Dart side.
        Without resolving iOS dependencies with CocoaPods, plugins will not work on iOS.
        For more info, see https://flutter.dev/platform-plugins
      To install:
        brew install cocoapods
        pod setup
[!] Android Studio (version 3.4)
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
[✓] VS Code (version 1.35.1)
[✓] Connected device (1 available)

! Doctor found issues in 2 categories.

@truongsinh

Também tentei gerar apk a partir do pacote de aplicativos e instalá-lo. Ele também trava no lançamento.

$ bundletool build-apks --bundle=build/app/outputs/bundle/app.aab --output=app.apks
$ bundletool install-apks --apks app.apks

Tente mudar para o canal dev e verifique.

Tentei construir no canal dev , mas quebrou uma das minhas dependências. Vou tentar comentar e construir para ver se o aplicativo funciona.

Também é seguro usar o canal dev para o lançamento de produção?

OPA, desculpe. Eu teria mais cuidado se fosse para produção.

Vou construir APKs por enquanto. Embora o Google sugira fazer upload de pacotes em vez de apks, será bom se isso for corrigido na próxima versão no branch estável.

Eu encontrei isso usando adb logcat:

[FATAL:flutter/runtime/dart_vm.cc(389)] Error while initializing the Dart VM: Snapshot not compatible with the current VM configuration: the snapshot requires 'product use_bare_instructions no-"asserts" causal_async_stacks no-bytecode arm-eabi softfp' but the VM has 'product use_bare_instructions no-"asserts" causal_async_stacks no-bytecode arm64-sysv'

Estou no canal stable .

A solução de https://github.com/flutter/flutter/issues/19865 funcionou.

Também tive que remover a seção splits de build.gradle.

O aplicativo funciona bem agora quando instalado via bundletool. Vou tentar fazer o upload para a playstore e verificar se tudo está indo bem.

@sulaysumaria a correção só está disponível no branch master ainda. Se você estiver estável - conforme indicado em sua saída flutter doctor

[✓] Flutter (Channel stable, v1.5.4-hotfix.2, on Mac OS X 10.14.5 18F132, locale en-IN)

a correção não é aplicada. Você precisa esperar até que a correção esteja estável se quiser construir com estável. Parece que está algo em torno de 1.7.x até então você precisa fazer o upload do apk separadamente.

Ohh ... Obrigado @pythoneer . Você sabe quando estará disponível no canal estável?

@sulaysumaria sem problemas. É mencionado várias vezes neste tópico

Ainda esperamos estabilidade no início de julho.

Funcionou no canal dev . Usei flutter build appbundle --target-platform android-arm,android-arm64 e carreguei o pacote para a Play Store e funcionou perfeitamente.

@sulaysumaria - você deve usar as instruções já preparadas com o canal mestre ou dev .

@julindra adicionar -ignorewarnings a 'proguard-rules.pro corrige esse problema. Atualmente, não incluímos o pacote android.arch. *. Outra opção é editar seu android/app/build.gradle e adicionar o seguinte:

dependencies {
  implementation "android.arch.lifecycle:common-java8:1.1.1"
  implementation 'android.arch.lifecycle:extensions:1.1.1'
}

cc @ matthew-carroll

Obrigado. Acabei de usar o canal dev e adicionar -ignorewarnings , funciona perfeitamente.

trabalhou para mim com flutter build appbundle
https://github.com/flutter/flutter/issues/18494#issuecomment -489807239

@blasten pode ser

@cbracken , acho que pode ser fechado agora ou após a próxima versão estável.

Você ainda está planejando resolver o problema de incompatibilidade com o dispositivo ZenFone 2 e dispositivos x86 semelhantes que permitem a instalação de aplicativos ARM da Play Store e usam libhoudini para executá-los?

Tentei construir no canal dev , mas quebrou uma das minhas dependências. Vou tentar comentar e construir para ver se o aplicativo funciona.

Também é seguro usar o canal dev para o lançamento de produção?

Nunca usei nenhum branch em vez de dev e meus aplicativos estão funcionando perfeitamente. Portanto, confie no ramo, ele nunca desaponta. @sulaysumaria

@matthewlloyd , ouvimos da equipe da Play Store que é melhor adicionar um binário x86 explícito do que tentar fazer nossos binários existentes funcionarem bem com o tradutor arm-> x86. - No entanto, a equipe recentemente melhorou o código que o compilador Dart gera, e eu me pergunto se isso talvez tenha feito a tradução funcionar. Experimente e me diga. Caso contrário, dependendo da situação, pode ser necessário construir a versão JIT para x86, que normalmente é usada para depuração / criação de perfil em emuladores.

@blasten Obrigado pela informação. Isso me deixa um pouco confuso porque eu não tenho um desses dispositivos - apenas duas análises anônimas da Play Store de usuários descontentes do ZenFone 2 - então não tenho como testar. O risco de quebrar as coisas é muito grande para enviar outra compilação de appbundle até que alguém confirme que o código aprimorado realmente funciona nesses dispositivos. A menos que haja uma maneira de dizer à Play Store para excluir esses dispositivos, continuarei lançando compilações criadas com uma versão antiga do Flutter (e APKs de 32 bits), até que seja testado e confirmado como corrigido pelo Google, ou confirmado que não é mais um edição. Acho que não será até que mais aplicativos sejam enviados para a loja usando o novo formato appbundle / .so. Eu vou esperar...

para quem ainda está procurando, aqui estava a solução que funcionou para mim:

flutter build apk --split-per-abi
não funcionou ,, mesmo depois de editar o gradle de compilação
de https://flutter.dev/docs/deployment/android#build -an-apk

em vez disso, use:

1. flutter build appbundle
2. e, em seguida, carregue app.aab

problema corrigido para 32 e 64 bits, e a liberação do alerta não é compatível com o requisito do Play 64 bits. "desapareceu.

Obrigado @ juliengit2 , flutter build appbundle funciona.

Vale a pena citar a versão flutter também, pois eu tinha a v1.5.0 até agora e não funcionou.
Tive que atualizar (atualmente para v1.7.9) para fazê-lo funcionar.

@PerechicK , por último você quis dizer canal estável ou canal dev?

Canal DEV, como aparece hoje aqui: https://flutter.dev/docs/development/tools/sdk/releases?tab=windows

Ainda não sei desde qual versão esse problema foi corrigido.

Ao usar qualquer coisa que não seja o branch estável, estou correndo em um dos meus plug-ins lançando o erro "Métodos marcados com @UiThread devem ser executados no encadeamento principal", que foi introduzido com este flutter sdk commit https: // github. com / flutter / engine / commit / 2c9e37c34e79475bbde7c8163eb5e56cdb9662a1.

Existe uma maneira de construir o appbundle de 64 bits ao usar o branch estável 1.5.4-hotfix.2?

@uj este problema https://github.com/flutter/flutter/issues/33562 pode estar relacionado ao seu erro se estiver usando firebase_database .

e nenhum 64 bits introduzido em 1.7.4+ de acordo com o Flutter Docs

Não, não é firebase_database, é realmente OneSignal, mas sua única solução é "usar o branch estável do Flutter"

Existe uma maneira de construir o appbundle de 64 bits ao usar o branch estável 1.5.4-hotfix.2?

@uj mesmo que você não possa construir um appbundle de 64 bits com 1.5.4-hotfix.2 , você pode construir 2 apks, um com 32 bits, outro com 64 bits, carregue os dois apks para a Google Store para resolver o aviso.

Flutter 1.5.4-hotfix.2 appbundle atualmente tem como alvo a android-arm, que cria apenas código nativo de 32 bits ( flutter build appbundle -h ). Para alterar isso, execute flutter build appbundle --target-platform=android-arm64 para alterar o destino padrão.

Isso agora está ao vivo no canal beta, no lançamento v1.7.8+hotfix.2

@tvolkert - excelentes notícias, obrigado. Você poderia ser mais específico quando podemos esperar a correção ao vivo no estável , por exemplo, uma data em que isso acontecerá?

@ angel1st https://en.wikipedia.org/wiki/Forward-looking_statement 🙂

(estamos trabalhando para que isso aconteça o mais rápido possível)

@tvolkert - considerando o fato de que estamos a cerca de três semanas do prazo final do Google em relação aos pedidos de 64 bits, espero um prazo de sua parte também. Além disso, nós, como desenvolvedores, precisaremos de algum buffer de tempo entre o seu lançamento e o prazo acima mencionado para que possamos construir, testar e lançar nossos aplicativos sem perturbar nossos clientes.
Fora isso, eu realmente aprecio os esforços e resultados nos últimos dois meses, mas espero que você seja capaz de se colocar no nosso lugar e ver como as coisas parecem dessa perspectiva. Obrigado pela compreensão e todos os esforços até agora!

@ angel1st absolutamente. De acordo com o anúncio anterior , pretendemos estabilizar isso no início de julho (muito em breve) - não consigo prever a data exata.

Eu tenho esse problema na unidade 2017.4.20 ou 2019.1.2, como posso resolver isso? isto
está no link blow: https://stackoverflow.com/questions/56687339/what-is-this-error-in-build-adroid-and-build-app-bundle-in-unity-2017-4-17 por favor ajude eu Porque estou neste problema há 2 meses obrigado

Espero ver este resolvido o mais rápido possível. O prazo é apertado

@DoubleHub você pode mudar para o canal beta para resolvê-lo.
Ou espere para lançar a versão estável em 8 de julho.

@ abc873693 Eu li sobre isso, acho que vou esperar pela versão estável. Estou feliz que este problema finalmente foi resolvido oficialmente!

@ abc873693 Tive problemas ao tentar publicar aplicativos Android na Play Store usando o canal _beta_. Os relatórios de pré-lançamento mostraram avisos de acessibilidade. Parece que o aplicativo não passou da tela inicial. Todas as capturas de tela de todos os dispositivos permaneceram na tela inicial.

A solução para mim foi simplesmente mudar para o canal STABLE e construir o app-bundle usando o sinalizador --target-platform.

Olá a todos,

v1.7.8+hotfix.2 foi liberado para o canal estável, então esta correção agora está disponível em todos os canais. Obrigado a todos pela paciência e ajuda ao longo do caminho!

@tvolkert Obrigado! Acabei de confirmar que a observação que mencionei aqui não existe mais com o canal estável!

@tvolkert como aplicar este v1.7.8+hotfix.2 em um projeto existente? Eu preciso recriar tudo de novo?

@jaasaria, esse problema está relacionado à construção de seu aplicativo para lançamento. se você estiver no estável, precisará atualizar a instalação do flutter. o problema relatado aqui é em torno da construção de um pacote de aplicativos de acordo com este link

@jaasaria basta executar: $ flutter channel stable && flutter upgrade

@MaikuB Criei meu arquivo src há um mês e toda vez que construo meu projeto, preciso executar o comando flutter build appbundle --target-platform=android-arm64 vez de flutter build appbundle para evitar o erro playstore x64.

@dblokhin Acabei de ser atualizado e felizmente meu projeto não quebrou. :) Te agradece

Obrigado @ juliengit2 , flutter build appbundle funciona.

Vale a pena citar a versão flutter também, pois eu tinha a v1.5.0 até agora e não funcionou.
Tive que atualizar (atualmente para v1.7.9) para fazê-lo funcionar.

Obrigado pelo aviso!

Tenho flutter versão 1.7.8 + hotfix.3 "flutter build appbundle" resultará em app.aab com 32 e 64 bits?

estranho tentei com 1.7.8 + hotfix.3 com canal estável e recebo novamente o aviso de playstore:

"Esta versão não é compatível com o requisito de 64 bits do Google Play ..."

ao enviar um pacote após: _flutter build appbundle_

Tentei também atualizar a vibração, mas o mesmo resultado.
e com uma nova instalação do Flutter: o mesmo resultado

Aqui está minha conf:

Qualquer ideia??

@ juliengit2 Abra o .aab como um zip normal, vá para a pasta base/lib e verifique se há pastas armeabi-v7a e arm64-v8a

Tentei fazer isso com a pasta lib do meu app "flutter build appbundle" contém v8a e v7a. Posso empurrar a atualização agora, não quero outro aviso chegando ao e-mail do meu chefe.

Outro caso semelhante de um APK distante recebendo aviso https://github.com/flutter/flutter/issues/18494#issuecomment -509937209

para aqueles com o mesmo problema, removi no build.gradle:

ndk {
    abiFilters "armeabi-v7a", "x86", "armeabi", "mips"
}

e o aviso desapareceu.

(se você mantiver os abifilters, ainda obterá "release is not compliant", mesmo com _flutter build appbundle_

Olá, criei meu appbundle com sucesso, mas quando tento carregá-lo na Play Store, recebi este erro ...
Para fazer upload de um Android App Bundle, você deve estar inscrito no App Signing do Google Play.
Exporte sua chave do Android Studio. No menu Build, selecione Generate Signed Bundle / APK. Selecione a opção Bundle e pressione Avançar. Selecione Exportar a chave criptografada e pressione Avançar.

Tento exportar a chave criptografada assim, diretamente do módulo android, mas não consegui terminar o processo porque recebo este erro

Processo 'command' / Users / oaacelasu / Documents / flutter / bin / flutter '' finalizado com valor de saída diferente de zero 1

bref, suponho que não seja a maneira correta ... Existe outra solução alternativa para obter a chave criptografada para registrar o aplicativo diretamente do comando flutter build appbundle?

Tentei usar o appbundle na playstore,
mas no android 6.0 arm 64, ele travou na inicialização por causa do libflutter.so não pôde ser encontrado, e depois que eu verifiquei o libflutter.so foi incluído no aab arm 64

@matthewlloyd , reproduzi isso com um Chromebook local (embora esse Chromebook possa sair em uma viagem de três semanas na segunda-feira. Tenho que verificar). Acho que ele _deve_ reproduzir na maioria dos Chromebooks x86 - acho que provavelmente há mais desses do que telefones x86.

a equipe aprimorou recentemente o código que o compilador Dart gera, e eu me pergunto se isso talvez tenha feito a tradução funcionar. Experimente e me diga. Caso contrário, dependendo da situação, pode ser necessário construir a versão JIT para x86, que normalmente é usada para depuração / criação de perfil em emuladores.

@blasten , você estava pensando em alguma versão específica do Dart? Reproduzi com 2.3.1 (com flutter 1.7.8 + hotfix.2) Devo testar com 2.4.0?

Além disso, reproduzi quando lançamos uma versão alfa. Ainda preciso descobrir como testar um appbundle sem passar pela Play Store.

@wreppun Obrigado pelo

@matthewlloyd Isto é o que apareceu no registro de travamento da Play Store:

java.lang.UnsatisfiedLinkError: 
  at java.lang.Runtime.loadLibrary0 (Runtime.java:984)
  at java.lang.System.loadLibrary (System.java:1530)
  at io.flutter.view.FlutterMain.startInitialization (FlutterMain.java:122)
  at io.flutter.view.FlutterMain.startInitialization (FlutterMain.java:99)
  at io.flutter.app.FlutterApplication.onCreate (FlutterApplication.java:22)
  at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1024)
  at android.app.ActivityThread.handleBindApplication (ActivityThread.java:5549)
  at android.app.ActivityThread.-wrap2 (ActivityThread.java)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1595)
  at android.os.Handler.dispatchMessage (Handler.java:102)
  at android.os.Looper.loop (Looper.java:154)
  at android.app.ActivityThread.main (ActivityThread.java:6320)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:891)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:781)

Isso pode aparecer em alguns de seus (antigos) registros de travamento se algum de seus usuários optou por compartilhar estatísticas.

O dispositivo era um HP Chromebook x360.

Lamento que isso não esteja funcionando em 100% das configurações. Estamos trabalhando para obter uma melhor cobertura de teste em uma variedade de SDKs e dispositivos. Enquanto isso, irei configurar alguns testes no laboratório de teste do Firebase.

A esta altura, acho que a maneira mais eficaz de consertar todos esses problemas é, provavelmente, registrar novos problemas e criar um link de volta para este. @tvolkert e eu garantiremos que cada um seja examinado, mas nos ajudaria se pudéssemos classificá-los em depósitos separados e rastrear suas correções individualmente.

É bem possível que precisemos fazer pequenos ajustes no compilador Dart, que fizemos no passado para CPUs ou emuladores que tinham peculiaridades de processador específicas. Sem testar em um Chromebook x86 (o que ainda não fiz), não posso dizer com certeza.

Aqueles que estão tendo problemas podem nos ajudar a resolver os problemas restantes registrando novos problemas para cada um? Isso seria de grande ajuda para garantir que abordaremos cada um. Obrigado!

@wreppun Obrigado - Eu verifiquei os relatórios de falha do meu aplicativo e nenhum dos usuários afetados do Asus ZenFone 2 enviou nada.

@blasten Não se preocupe, isso é ótimo. Se alguém puder mostrar que os novos appbundles funcionam em um dispositivo Asus ZenFone 2, isso seria o suficiente para me fazer seguir em frente. Infelizmente não tenho acesso a um, mas espero que os laboratórios de testes móveis do Google tenham.

@matthewlloyd no "Asus ZenFone" no laboratório de teste do Firebase. Qual versão do SDK? Na maioria das vezes, o problema pode ser reproduzido apenas executando uma versão específica do Android SDK.

Qual versão do SDK? Na maioria das vezes, o problema pode ser reproduzido apenas executando uma versão específica do Android SDK.

😂

Olá equipe do Flutter,
Eu gostaria de enfatizar o status deste tópico. Do meu ponto de vista, existem dois problemas graves:

• A versão de flutter estável atual 1.7.8+hotfix.3 não cria apks estáveis ​​- pelo menos split-per-abi não funciona como deveria - o arm32 tem um problema de regressão e não pode ser executado em alguns dispositivos arm32 . Ainda não está claro quando isso será consertado;
• Prazo de 1º de agosto - em cerca de uma semana, nós, como desenvolvedores, não seremos capazes de atualizar nem lançar novos aplicativos flutuantes na Google Play Store - tão simples quanto isso. Considerando o problema da versão atual do flutter (como mencionado acima) e o tempo restante, não acho que seja viável esperar ter a correção no canal estável antes do final do mês (a menos que alguém de vocês tenha uma varinha mágica: - ))

Considerando as duas questões acima, gostaria de sugerir o seguinte plano de contingência, qual IMO nos serviria melhor como desenvolvedores:

• Canal estável de reversão para sua versão anterior a hotfix.2
• Adie o prazo de 1º de agosto por alguns meses - eu entendo que isso exigirá algum escalonamento sobre o problema, mas espero que vocês entendam como o impacto sério pode ter se os desenvolvedores não puderem lançar um aplicativo de flutter

Posso falar apenas em meu nome, mas tenho clientes com contratos e decidi passar do React Native para o Flutter, pois acreditava que o Google forneceria um suporte melhor para os seus próprios produtos. Tenho projetos em andamento e aplicativos para apoiar.
Agora me encontro em um caso absurdo, quando o Google me força a lançar a versão apk de 64 bits e ao mesmo tempo não me fornece a ferramenta para fazer isso (e sim, eu sei que a equipe do Flutter não é o mesmo que o Google Play equipe, mas de onde eu pareço - você é a mesma entidade empresarial).
Se o Google não cumprir o prazo, isso levará a uma forte reação do Flutter, já que cada dia após 1º de agosto reduzirá a credibilidade do framework.
Peço desculpas se minhas palavras soam um pouco mais fortes, só espero que você possa se colocar no meu lugar por enquanto.

Qualquer pessoa - por favor, vote e esperamos que nossa voz seja ouvida!

Eu também concordo com isso ... Mas como um plano de contingência, sugiro não reverter para a versão anterior, mas sim mudar para o canal dev ....

Pela minha experiência pessoal, também não me senti confortável em usar o dev canal i inicialmente. Pensei em manter o canal stable , porque você sabe, é estável! ... Mas agora estou usando o canal dev e lançando aplicativos usando pacotes de aplicativos na Play Store sem nenhum problema. ..

A situação é algo que não deveria ocorrer, pois ambos são produtos do Google ...

O que apresentei é apenas uma solução alternativa mais simples, porque você pode começar a enviar atualizações usando aab s e não apk s, que é sugerido pelo Google ...

@ angel1st mesmo problema, mesmos problemas, mesmos sapatos
@sulaysumaria se mudarmos para o canal dev, o problema libapp.so será resolvido?
Porque nem o canal mestre parece funcionar

O que apresentei é apenas uma solução alternativa mais simples, porque você pode começar a enviar atualizações usando aabs e não apks, o que é sugerido pelo Google ...

@sulaysumaria - não é tão simples quanto parece, acredite em mim ... Também mudar para o canal dev parece levar a algumas complicações com pacotes e plug-ins de terceiros que levarão a diferentes conjuntos de problemas.

@campioncino Acho que sim porque nunca enfrentei esse problema .... Eu simplesmente crio o appbundle de lançamento e faço o upload para a Play Store ... Ele nunca mostra nenhum aviso .... e o aplicativo funciona bem quando instalado da Play Store ( pelo menos o que meu cliente está usando até agora ...)

@ angel1st , posso entender ... nesse caso reverter é a única opção ... Mas essas dependências precisam ser atualizadas ou você nunca poderá atualizar para uma versão mais recente ... Também enfrentei esse tipo de problema com um plugin Eu estava usando, felizmente eles lançaram uma versão mais recente em beta para suportar a versão mais recente do flutter ... Talvez se o plugin não for mantido, não deveríamos usá-lo.

@sulaysumaria Eu nunca enfrentei esse problema também ... até a última compilação.
Vou tentar mas não é tão simples de testar, porque só acontece em alguns aparelhos.

Por exemplo, no Samsung Galaxy Tab 2 7.0 P3110, Android 4.2.2 e em algum outro tablet antigo com Android 4.1.2

Ohhh ... Meu aplicativo não é para tablets com certeza ... Seria melhor se você testasse uma vez ...

Olá a todos,

Este é o status atual:

1. As indicações são de que https://github.com/flutter/flutter/issues/35838 afeta o Android 4.2 e anteriores, o que significa que afeta cerca de 3% dos telefones Android . Estamos trabalhando com as pessoas afetadas nesse bug para identificar o escopo da correção e rastrear possíveis problemas auxiliares que provavelmente afetam apenas alguns aplicativos (como um possível bug não relacionado na VM do

2. Se alguém preferir construir a partir de uma versão anterior do Flutter e construir manualmente APKs de 32 e 64 bits, pode fazer isso baixando uma versão anterior do Flutter aqui . Reverter nossa versão estável não é uma opção - fazer isso causaria muito mais problemas do que resolveria.

3. Se alguém estiver tendo problemas para construir para Android _outro_ além de https://github.com/flutter/flutter/issues/35838 , registre um problema separado e me envie uma cópia, pois queremos muito rastrear esses problemas.

4. Separadamente, estamos trabalhando ativamente para aumentar nossa matriz de teste para detectar melhor os problemas em uma ampla variedade de dispositivos / versões do Android no início do processo (para que os relatórios de bug não sejam nossa primeira linha de defesa).

@tvolkert - obrigado pelo feedback. Só para ter certeza de que estamos na mesma página - reverter para a versão anterior do Flutter não faz sentido até o prazo final de 1º de agosto ser adiado , já que o Google Play não permite que eu carregue a versão de 32 aplicativos somente após 1º de agosto.

@ angel1st essa opção seria adequada para o seu caso?

1. Reverter o flutter SDK para v1.5.4-hotfix.2 ( flutter version v1.5.4-hotfix.2 )
2. Crie 2 APKs separados (um em flutter build apk --target-platform android-arm 32 bits e um em flutter build apk --target-platform android-arm64 64 bits)
3. Faça upload de ambos os APKs na Google Play Store

Eu sei que é uma solução alternativa, mas pelo menos resolve o problema de estabilidade e o de "aviso".

@truongsinh - obrigado pela sugestão - vale a pena considerar. Você teria a gentileza de confirmar a etapa 2 de sua sugestão acima que não exigirá alterações como na sugestão anterior, por exemplo, app gradle emendas?

@ angel1st contanto que você tenha o aplicativo inteiro em movimento (ou seja, não https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps) e não tenha modificado nada no Gradle arquivos (ou seja, arquivos vanilla de flutter create ), acredito que não temos que fazer nada.

Você pode fazer a verificação rápida sozinho (assumindo a versão "3.4.5", seguindo https://github.com/flutter/flutter/issues/31922#issuecomment-512292798, minha escolha pessoal de formato para "número de compilação" é bbxxyyzz , em que bb é apenas o para identificar 32 ou 64 bits, xx é maior, yy é menor, zz é patch, mas também há outro formato recomendado, consulte https://developer.android.com/google/play/publishing/multiple-apks#using-a-version-code-scheme):

• flutter create hello_world
• flutter build apk --target-platform android-arm --build-number 32030405 --build-name=3.4.5
• mv build/app/outputs/apk/release/app-release.apk build/app/outputs/apk/release/app-release-32.apk
• flutter build apk --target-platform android-arm64 --build-number 64030405 --build-name=3.4.5
• mv build/app/outputs/apk/release/app-release.apk build/app/outputs/apk/release/app-release-64.apk

Incluo os 2 APKs aqui. Eles funcionam com meu Pixel 2. Também olhando para a análise do APK, podemos ver claramente que cada APK tem libflutter.so e 4 arquivos de instantâneo / aot diferentes

app-release-32.apk.zip
app-release-64.apk.zip

Apenas uma observação para quando enviar dois apks ... O Google não permite o upload de vários arquivos com o mesmo número de compilação, então você pode querer alterar o número da compilação antes de criar apk para 64 bits.

Apenas uma observação para quando enviar dois apks ... O Google não permite o upload de vários arquivos com o mesmo número de compilação, então você pode querer alterar o número da compilação antes de criar apk para 64 bits.

Ah, é verdade (ref https://developer.android.com/google/play/publishing/multiple-apks#Rules). Apenas certifique-se de que, para cada versão, o número de compilação de 64 bits é maior do que 32 bits (atualizei meu exemplo anterior https://github.com/flutter/flutter/issues/31922#issuecomment-512223030).

Ei, recebo uma mensagem de erro quando tento construir com appbundle . flutter build apk funciona bem, mas quero publicar uma nova versão na Play Store. Alguém pode me ajudar qual poderia ser o motivo?

A saída da execução de flutter build appbundle --target-platform android-arm,android-arm64 --flavor my_flavor --release -t "bin/main.dart é a seguinte:

Initializing gradle...                                              0,6s
Resolving dependencies...                                           2,0s
Running Gradle task 'bundleMy_AppRelease'...                   
Running Gradle task 'bundleMy_AppRelease'... Done          1,9s
Gradle build failed to produce an Android bundle package.

Infelizmente, a mensagem de erro não ajuda muito. Também a saída do médico de vibração:

[✓] Flutter (Channel stable, v1.7.8+hotfix.3, on Mac OS X 10.14.5 18F132, locale de-DE)
    • Flutter version 1.7.8+hotfix.3 at /Users/tom/development/flutter
    • Framework revision b712a172f9 (2 weeks ago), 2019-07-09 13:14:38 -0700
    • Engine revision 54ad777fd2
    • Dart version 2.4.0

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Users/tom/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.3, Build version 10G8
    • CocoaPods version 1.6.1

[✓] iOS tools - develop for iOS devices
    • ios-deploy 1.9.4

[✓] Android Studio (version 3.4)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 36.1.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[✓] Connected device (1 available)
    • iPhone Xʀ • 095B1A07-E138-4A80-9783-8CA36DC8049A • ios • com.apple.CoreSimulator.SimRuntime.iOS-12-4 (simulator)

• No issues found!

Editar
Se eu tentar usar --split-per abi a construção também falha com flutter build apk .

@wreppun Obrigado - Eu verifiquei os relatórios de falha do meu aplicativo e nenhum dos usuários afetados do Asus ZenFone 2 enviou nada.

@blasten Não se preocupe, isso é ótimo. Se alguém puder mostrar que os novos appbundles funcionam em um dispositivo Asus ZenFone 2, isso seria o suficiente para me fazer seguir em frente. Infelizmente não tenho acesso a um, mas espero que os laboratórios de testes móveis do Google tenham.

Até eu estou enfrentando problemas com o Asus Zenfone. Quando estou executando usando flutter build apk o aplicativo é executado no telefone. Mas quando eu faço o upload para a App Store usando appbundle, ele não se move à frente da tela inicial.

Qualquer solução ??

Tentei compilar e lançar uma nova versão de um dos meus aplicativos (app) na "Play Store", mas tive alguns problemas.

1-) Quando faço upload de 32 e 64 bits, o site recusa, por causa da versão de 32 bits.

2-) Quando eu carrego apenas 32 bits, o site recusa, pois preciso dos 64 bits.

3-) Quando faço upload de apenas 64 bits, o site funciona, mas meus clientes talvez não tenham o Android de 64 bits. No meu celular, por exemplo, eu uso esse mesmo app, mas no meu celular só funciona quando eu uso o apk 32 bits. Quando eu instalo o apk de 64 bits no meu celular, ele para na tela inicial.

Como devo fazer agora para liberar ??

Tigerclaw1980 usa a opção flutter appbundle

Tigerclaw1980 usa opção flutter appbundle @MoacirSchmidt

Usei Delphi Beta para fazer arquivos apk para 32 e 64 bits. Não sei se esta opção está disponível

Tentei compilar e lançar uma nova versão de um dos meus aplicativos (app) na "Play Store", mas tive alguns problemas.

1-) Quando faço upload de 32 e 64 bits, o site recusa, por causa da versão de 32 bits.

2-) Quando eu carrego apenas 32 bits, o site recusa, pois preciso dos 64 bits.

3-) Quando faço upload de apenas 64 bits, o site funciona, mas meus clientes talvez não tenham o Android de 64 bits. No meu celular, por exemplo, eu uso esse mesmo app, mas no meu celular só funciona quando eu uso o apk 32 bits. Quando eu instalo o apk de 64 bits no meu celular, ele para na tela inicial.

Como devo fazer agora para liberar ??

@ Tigerclaw1980 você corrigiu este erro?