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

Criado em 15 jun. 2018  ·  286Comentários  ·  Fonte: flutter/flutter

usando flutter build apk --release --flavor pro make arquivo apk, mas arm64-v8a não inclui libflutter.so file.so inicialização do aplicativo falha.
quando eu adiciono --target-platform=android-arm64 : flutter build apk --release --flavor pro --target-platform=android-arm64 , o arquivo apk inclui so flie. Mas a inicialização do aplicativo falha na CPU de 32 bits.
o que posso fazer, o arquivo apk pode ser executado em 64 e 32 cpu @ mravn-google

/System.err(15263): java.lang.UnsatisfiedLinkError: Couldn't load flutter from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.jianzhibao.ka.enterprise-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.jianzhibao.ka.enterprise-1, /vendor/lib, /system/lib]]]: findLibrary returned null

Eu crio um novo projeto, depuro ou libero, trabalho bem. A diferença do novo projeto do meu projeto é que eu adiciono um arquivo so

image

Onde está o problema ?

crowd platform-android new feature gradle tool waiting for PR to land (fixed)

Comentários muito úteis

Eu tenho o mesmo problema, construir para 32 bits excluirá dispositivos de 64 bits, embora seja executado neles. Construir para 64 especificando --target-platform android-arm64 funciona em dispositivos de 64 bits, mas trava em dispositivos de 32 bits. Além disso, o Google restringirá o upload de apks para 64 bits em 2019.

Equipe Flutter, resolva este problema básico!

Todos 286 comentários

AFAIK, atualmente, Flutter só adicionará libflutter.so a uma pasta de plataforma selecionada no APK de lançamento. A solução que funcionou para mim foi forçar o build.gradle a fazer apenas 32 bits (excluindo todas as bibliotecas de 64 bits + Intel)

release {

    ...
            ndk{
                abiFilters "armeabi-v7a"
            }
}

cc @Hixie

@swavkulinski como você lançaria o para apks na playstore?

Tenho o mesmo problema - mas flutter.so não está incluído na pasta "armeabi-v7a.
Possui apenas bibliotecas de terceiros para x86 e armeabi-v7a - mas não arm64.
Gostaria de construir flutter apenas para "armeabi-v7a com
ndk {
abiFilters "armeabi-v7a" // também não funciona "armeabi", "x86",
}
e definir como plataforma de destino como @ mravn-google sugere para android-arm.

APK sem especificar o arco e não inclui bibliotecas
screen shot 2018-07-26 at 21 06 53

APK com bibliotecas e nenhuma especificação de braço
screen shot 2018-07-26 at 21 10 30

APK com arco específico e bibliotecas incluídas
screen shot 2018-07-26 at 21 12 58

Alguma sugestão de como depurar etapas adicionais?

@xxseabxx eu tenho o mesmo problema

Eu tenho o mesmo problema, construir para 32 bits excluirá dispositivos de 64 bits, embora seja executado neles. Construir para 64 especificando --target-platform android-arm64 funciona em dispositivos de 64 bits, mas trava em dispositivos de 32 bits. Além disso, o Google restringirá o upload de apks para 64 bits em 2019.

Equipe Flutter, resolva este problema básico!

Equipe Flutter, resolva este problema básico!

Então, estou errado em dizer que o flutter só suporta apk de lançamento para 32 ou 64 bits, mas não para ambos?

alguma sorte aqui?

Acho que o comentário de xxseabxx pode funcionar, mas não tentei ...

Também estou tendo o mesmo problema.

Em todas as minhas dependências, isolei pelo menos um pacote que causa o problema, preenchi um relatório de bug de acordo: https://github.com/azihsoyn/flutter_mlkit/issues/36

Para isolar o problema, para cada uma das minhas dependências / plug-ins:

1) Crie um projeto de vibração vazio

2) Substitua main.dart por

o código de exemplo do pacote (ex: https://pub.dartlang.org/packages/flutter_html_view#-example-tab-)

3) Atualize o pubspec.yaml de acordo

4) correr

$ flutter build apk

Descobriu-se que quem estava criando era flutter_mlkit.

Eu quero ser capaz de atingir as arquiteturas 32 e 64.

Tem o mesmo problema. --target-platform = android-arm64 funciona para mim, mas eu gostaria de oferecer suporte a 32 bits até que o Google desligue os 32 bits

Equipe Flutter, resolva este problema básico!

muitos terceiro SDK não estão funcionando, acho que é urgente

Posso reproduzir isso ao adicionar Mapbox ao aplicativo Android.

Eu também tenho o mesmo problema. Eu uso o baiduMap no meu projeto, o modelo bebug está ok, libere o travamento.
user flutter build apk --release --target-platform = android-arm64 no meu telefone está ok, mas o telefone de 32 bits irá travar. Equipe do Flutter, resolva este problema o mais rápido possível.

Semelhante a https://github.com/azihsoyn/flutter_mlkit/issues/36 , funciona para mim, o apk pode ser executado em telefones de 32 bits e 64 bits. @ peace2knowledge

este deve ser um problema muito importante para o lançamento do apk

existe uma solução alternativa para esse problema?

  1. extrair lib/armeabi-v7a/libflutter.so de $<FLUTTER>/bin/cache/artifacts/engine/android-arm-release/flutter.jar
  2. copie o arquivo armeabi-v7a/libflutter.so em $<project>/android/jniLibs/armeabi-v7a/
  3. modifique $<project>/android/app/build.gradle conforme abaixo:
android {
...
    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
            ndk {
                abiFilters "arm"
            }
        }
        debug {
            ndk {
                abiFilters "arm"
            }
        }
}
    }

Para NDK, o conjunto de ferramentas de 64 bits requer minSdkVersion> = 21.

Isso me desbloqueou (com o conjunto minSdkVersion adequado):

minSdkVersion = 16

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

minSdkVersion = 21

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

Exclua todos os abiFilters, funciona para mim.

@zoechi @Hixie colisão suave. Também estou encontrando isso ao tentar integrar com o aplicativo existente, que é nosso caso de uso mais importante no momento.

minddk = 21, mas ainda não atualizou a plataforma de destino

@neiljaywarner um polegar para cima no comentário inicial seria mais eficaz para aumentar a prioridade

  1. extrair lib/armeabi-v7a/libflutter.so de $<FLUTTER>/bin/cache/artifacts/engine/android-arm-release/flutter.jar
  2. copie o arquivo armeabi-v7a/libflutter.so em $<project>/android/jniLibs/armeabi-v7a/
  3. modifique $<project>/android/app/build.gradle conforme abaixo:
android {
...
    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
            ndk {
                abiFilters "arm"
            }
        }
        debug {
            ndk {
                abiFilters "arm"
            }
        }
}
    }

Isso não funcionou para mim - gerou um APK sem a pasta lib (e, portanto, tinha metade do tamanho do meu apk anterior).

Também descobrimos que se implementarmos a solução apenas de 32 bits que alguns postaram (por exemplo, https://medium.com/flutterpub/flutter-app-couldnt-find-libflutter-so-c95ad81cbccd), isso resultará em um não aplicativo de alto desempenho. Em particular, em um teste em um Samsung S6 e S9, estamos vendo uma rolagem muito lenta em uma grande lista.

Não acho que o problema seja apenas o arm64 libflutter.so ausente.

Tentei adicionar a biblioteca ausente ao APK criando para arm64, copiando libflutter.so e, em seguida, reconstruindo e adicionando manualmente a biblioteca arm64 ao APK, realinhando e assinando novamente:

flutter build apk --target-platform=android-arm64
mkdir -p tmp/lib/arm64-v8a
cp build/app/intermediates/transforms/mergeJniLibs/release/0/lib/arm64-v8a/libflutter.so tmp/lib/arm64-v8a/
flutter build apk
cp build/app/outputs/apk/release/app-release.apk tmp/
cd tmp
aapt add app-release.apk lib/arm64-v8a/libflutter.so
zipalign 4 app-release.apk app-release-aligned.apk
apksigner sign --ks keystore.jks app-release-aligned.apk

O APK resultante tem libflutter.so para armeabi-v7a e arm64-v8a, mas falha na inicialização com o seguinte erro:

12-22 09:53:29.274 7457 7457 F flutter : [FATAL:flutter/runtime/dart_vm.cc(403)] Error while initializing the Dart VM: Snapshot not compatible with the current VM configuration: the snapshot requires 'product no-type_checks no-asserts no-error_on_bad_type sync_async reify_generic_functions arm-eabi softfp' but the VM has 'product no-type_checks no-asserts no-error_on_bad_type sync_async reify_generic_functions arm64-sysv'

Suponho que ativos de instantâneos separados também precisem ser enviados para cada arco. Por enquanto, construir dois APKs separados é a única solução que funciona para mim.

este é um problema bastante desagradável para se deparar depois de passar um tempo escrevendo um front-end em flutter apenas para descobrir que a versão não cria o apk corretamente.

terei o mesmo problema quando começar a usar o iOS?

A que horas posso resolver este problema?

Será que nossos arquivos gradle não sabem como agrupar todos os bits certos para ambos? @ jason-simmons @cbracken pode saber?

Ou @FaisalAbid poderia?

Será que nossos arquivos gradle não sabem como agrupar todos os bits certos para ambos? @ jason-simmons @cbracken pode saber?

Ou @FaisalAbid poderia?

Por bits certos, suponho que você queira dizer mais do que libflutter.so, de acordo com este comentário: https://github.com/flutter/flutter/issues/18494#issuecomment -449557182

No momento, acho que a única solução é construir APKs de 32 bits até que haja uma correção. Observe, entretanto, que vimos problemas de desempenho com 32 bits (embora não seja o código ideal com listas grandes).

Está funcionando bem para mim construir APKs separados de 64 bits e 32 bits e fazer o upload de ambos para o Google (eles fornecem o APK correto para os dispositivos corretos automaticamente).

Você faz uma construção com abiFilters definido como armeabi-v7a e --target-platform=android-arm , faz upload desse APK e, em seguida, faz outra construção com abiFilters definido como arm64-v8a e --target-platform=android-arm64 e carregue esse também.

Observe que você também precisa usar um código de versão diferente para cada APK, então inclua algo no código da versão para indicar que é de 64 ou 32 bits, o mesmo que faria para DPI ou nível de API.

Atualmente, a melhor opção é definir abiFilters condicionalmente da plataforma de destino

        ndk {
            if (project.hasProperty('target-platform') &&
               project.property('target-platform') == 'android-arm64') {
                abiFilters 'arm64-v8a'
            } else {
                abiFilters 'armeabi-v7a'
            }
        }

O problema que tenho é que agora preciso fazer upload de dois apks com códigos de versão diferentes
A verdadeira correção para isso é ser capaz de construir pacotes Android com várias plataformas de destino. Os pacotes de aplicativos estão em flutter master no momento, mas não consegui fazê-los funcionar neste

A Play Store exigirá 64 bits a partir de 1º de agosto.

Supondo que ainda haverá dispositivos de 32 bits que desejam executar nossos aplicativos após 1 de agosto, como garantir que 32 bits E 64 bits sejam incluídos nas compilações de lançamento?

https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

_Todos os novos aplicativos e atualizações de aplicativos que incluem código nativo são obrigados a fornecer versões de 64 bits, além das versões de 32 bits, ao publicar no Google Play._

Este requisito é facilmente atendido agora com aplicativos Flutter, simplesmente criando dois APKs - um para dispositivos de 32 bits e outro para dispositivos de 64 bits - e enviando ambos como parte do mesmo lançamento. O Google Play fornecerá automaticamente o APK apropriado para o dispositivo apropriado. Estou fazendo isso e funciona bem. Eu concordo com outros comentaristas que não é _ideal_, mas IMO realmente não é um grande problema para fazer isso parte do seu fluxo de trabalho.

Seria ótimo se isso pudesse ser corrigido em um futuro próximo. A abordagem de vários APKs é apenas uma solução temporária até que o Flutter crie APKs com várias versões de arquitetura .so, assim como outros projetos Android fazem.

Requer muito manuseio manual (códigos de versão, sistema de compilação, automação), além de Android App Bundles que deveriam liberar os desenvolvedores das etapas manuais de compilação.

Atualmente, este problema menciona apenas versões de 32 e 64 bits, mas também há x86, x64 e alguns desenvolvedores na China ainda falam sobre o suporte a mips.

O flutter não deveria suportar o máximo das 7 arquiteturas de Android com o menor tamanho apk possível fora da caixa?

https://proandroiddev.com/reducing-apk-size-by-using-abi-filters-and-apk-split-74a68a885f4e

@MarcelEdward Deveria - no entanto, IMHO, o tamanho do APK não é o aspecto mais importante, visto que o Android agora oferece suporte total para App Bundles (aab) e os usuários finais farão o download de uma versão otimizada para seus telefones de qualquer maneira.

Para o tamanho de um APK específico da plataforma, que deve ser o mais otimizado / pequeno possível.

Durante o desenvolvimento, pode ser doloroso reinstalar um APK de tamanho completo sempre que você altera o código nativo. Um truque é usar abifilters para limitar a compilação de depuração para a arquitetura de seus telefones de teste. Não tenho certeza se isso é tão relevante agora, já que o Flutter suporta o hot reload.

https://github.com/flutter/flutter/issues/17829 É sobre os pacotes de aplicativos aap, mas só consigo encontrar 32 bits quando compilar com apk de compilação de flutter

Então, quando eu entendo o richt, temos que construir duas versões serperate com pelo menos 32 e 64 carregá-los e, em seguida, o aplicativo irá milagrosamente construir um aap para que o consumidor obtenha a versão otimizada para sua arquitetura específica

@MarcelEdward A loja de jogos não cria um pacote de aplicativos. Ele apenas serve o APK apropriado para o dispositivo com base na arquitetura do dispositivo. Isso é suportado muito antes do surgimento dos pacotes de aplicativos, não apenas para arquitetura, mas também para tamanho / resolução de tela, nível de API e outros diferenciadores. Você pode ler mais sobre isso aqui .

Você pode ver um bom exemplo disso dando uma olhada nas 13 variantes do Google Maps aqui (observe que APKMirror não tem nada a ver com essa funcionalidade, exceto ser uma maneira fácil de obter uma lista das variantes de um determinado aplicativo). A Play Store oferece o APK apropriado a partir dessas variantes para o seu dispositivo com base em suas características.

Se você usasse um pacote de aplicativos, você só teria que fazer o upload do pacote uma vez em vez de fazer upload de vários APKs, mas meu entendimento é que a Play Store, então, gera as várias variantes do APK para você, então o resultado final é semelhante, mas há menos trabalho para você se automatizar. (Pacotes de aplicativos também suportam os novos módulos carregados dinamicamente, mas isso é outra história.)

Portanto, parece que o recurso desejado aqui é ser capaz de executar flutter build com dois --target-platform argumentos e fazer flutter colocar automaticamente ambas as arquiteturas no APK, certo?

@Hixie não é libflutter.so gerado apenas uma vez por versão de flutter e tipo de liberação? Nesse caso, você teria 8 variantes (32,64, x86, x86_64). Acho que esses devem ser simplesmente selecionados quando um aplicativo flutter é construído e filtrado, dependendo de qual é o telefone ou caso de uso de destino. O Gradle pode fazer a filtragem muito bem.

O que a arquitetura de um telefone tem é algo de nível muito baixo, eu não tenho idéia de qual arquitetura as pessoas que usam nossos aplicativos têm. O Flutter compila 32 bits quando nenhuma arquitetura é especificada, então eu presumiria que 32 bits serve para todos. Mas agora o jogo a loja exigirá 64 bits em agosto, então quando 32 bits servirem para todos e 64 bits for necessário, esses dois devem entrar em uma versão de lançamento?

Eu não tenho um telefone Android, então presumo que ele funcionará quando funcionar em um simulador. Até que os usuários do nosso aplicativo indiquem o contrário.

@ MarcelEdward2 Não é apenas 32 bits x 64 bits. Existem quatro arquiteturas compatíveis com o Android NDK moderno:

  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86_64

No momento, o padrão do Flutter é construir um APK contendo código nativo compilado apenas para armeabi-v7a. Isso funcionará bem no arm64-v8a, embora com uma penalidade de desempenho em comparação com algo compilado para arm64-v8a nativamente. No entanto, ele será executado em um emulador ARM em x86 ou x86_64, assumindo que o dispositivo tenha um. Se o dispositivo x86 / x86_64 não tiver um emulador ARM, ele não será executado.

Mais uma vez, o requisito de agosto não exige que você produza um APK ou AAB universal contendo as duas arquiteturas. Ele simplesmente exige que cada versão que você faça contenha (pelo menos) um APK adequado para dispositivos de 64 bits. Modificações no Flutter para possibilitar a construção de um APK / AAB universal com suporte para várias arquiteturas seriam boas em termos de fluxo de trabalho do desenvolvedor, mas você pode atender a esse requisito com ou sem essas melhorias.

Editado para adicionar: pessoalmente, acho que o suporte de primeira classe para pacotes de aplicativos é a melhor maneira de melhorar a situação de vários arquivos.

appbundle parece ser a solução daqui para frente ... Acho que a próxima etapa é esta: # 29303

Pelo que entendi esse bug, ele está muito relacionado com a mudança para .aab como o formato de saída padrão para flutter build e fazer com que .aab inclua compilações de 32 e 64 bits:
https://developer.android.com/studio/projects/dynamic-delivery

Meu entendimento foi que parte desse trabalho já pode estar em andamento. @dnfield pode saber.

/ cc @mklim

Parece que .aab ajudaria, mas pode não ser realmente necessário. O problema é tão simples quanto adicionar os binários de braço de 32 e 64 bits ao APK?

Ahh, entendi. É porque precisaríamos incluir potencialmente o instantâneo AOT para o arco de destino também. E agora apenas colocamos isso em ativos, não colocamos uma versão por arquitetura em libs . Se pudéssemos colocar o instantâneo AOT na pasta libs específica da arquitetura, isso poderia funcionar, caso contrário, gostaríamos de usar o formato .aab por esse motivo.

Queremos fazer isso de qualquer maneira para oferecer suporte à construção de .AARs para casos de uso add2app. Eu vou cutucar.

ndk {
            if (project.hasProperty('target-platform') &&
               project.property('target-platform') == 'android-arm64') {
                abiFilters 'arm64-v8a'
            } else {
                abiFilters 'armeabi-v7a'
            }
        }

Isso funcionou para mim após dias de solução de problemas

A solução postada por @AppleEducate não funciona quando tento executar o aplicativo no emulador.

Coloque na seção de lançamento

Esta foi a minha solução:

  1. em app gradle
splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }
  1. execute flutter build apk --release --target-platform=android-arm

  2. carregue app-armeabi-v7a-release.apk para a Play Store

  3. incremento versionCode

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

  5. carregue app-arm64-v8a-release.apk para a Play Store

A Google Play Store servirá o aplicativo de acordo com a arquitetura do dispositivo. Dispositivos de 32 bits estão felizes, dispositivos de 64 bits estão felizes e estou feliz em saber que o tamanho do meu APK permanece relativamente pequeno, embora ainda atenda às duas arquiteturas.

Se incluirmos suporte para ambas as arquiteturas no mesmo APK, espera-se que o tamanho do seu aplicativo seja de mais de 10 MB

@ edTheGuy00 Duvido que seja interessante o tamanho do upload para a Play Store. Os telefones Android irão pedir um espaço livre temporário 125+ de qualquer maneira e se recusarão a usar armazenamento externo para desempacotar. Isso é tudo que os usuários sabem sobre o tamanho do aplicativo. Realmente não importa quanto um aplicativo usa após a instalação. Ele pedirá 125 MB + de espaço livre para instalação.

Torne possível incluir todas as arquiteturas possíveis. Não me importo se o upload para a Play Store será de 250 MB.

Seria bom se o flutter usasse o espaço de gigabites no armazenamento externo para instalação em um telefone Android. Isso se a vibração pode influenciar a instalação em um telefone Android

Acho que o script flutter.gradle deve incluir todos os ABIs no APK final (APK universal) e, em seguida, ativar os APKs divididos por padrão. As ferramentas do Android irão selecionar o APK correto para fazer o upload para o dispositivo conectado e está tudo bem. O APK universal final pode então ser carregado para a play-store ou os APKs divididos para cada ABI.

Enquanto isso, como uma solução, você pode adicionar isso ao final de seu build.gradle em seu diretório android\app .

// Include both 32bit and 64bit arm libflutter.so files into your APK
project.afterEvaluate {
    assembleRelease.doLast {
        String src
        if(project.hasProperty('target-platform') &&
            project.property('target-platform') == 'android-arm64') {
            // If we are building the 64bit then we also want to add the 32bit libflutter.so
            src = "$flutterRoot/bin/cache/artifacts/engine/android-arm-release/flutter.jar"
        }else{
            // If we are building the opposite (32bit), we include the 64bit libflutter.so
            src = "$flutterRoot/bin/cache/artifacts/engine/android-arm64-release/flutter.jar"
        }
        copy {
            from zipTree(src)
            include 'lib/*/libflutter.so'
            into "$buildDir/intermediates/jniLibs/release/0/"
        }
    }
}

Também recomendo adicionar isso à sua seção buildTypes > release . Isso garantirá que seu APK de lançamento contenha ambos os ABIs.

ndk {
    abiFilters 'armeabi-v7a', 'arm64-v8a'
}

Depois de uma colaboração com @slightfoot ,

project.afterEvaluate {
    assembleRelease.doFirst {

        String src
        if(project.hasProperty('target-platform') &&
                project.property('target-platform') == 'android-arm64') {
            // If we are building the 64bit then we also want to add the 32bit libflutter.so
            src = "$flutterRoot/bin/cache/artifacts/engine/android-arm-release/flutter.jar"
        }else{
            // If we are building the opposite (32bit), we include the 64bit libflutter.so
            src = "$flutterRoot/bin/cache/artifacts/engine/android-arm64-release/flutter.jar"
        }
        copy {
            from zipTree(src)
            include 'lib/*/libflutter.so'
            into "src/main/jniLibs/"
            eachFile {
                it.path = it.path.replaceFirst("lib/", "")
            }
        }
    }
}

Atualização: Depois de tentar executar este APK no dispositivo, ele falha e, portanto, não é uma solução viável. O erro é "Erro ao inicializar o Dart VM: instantâneo não compatível com a configuração atual da VM:
o instantâneo requer 'product use_bare_instructions no- "afirma" causal_async_stacks arm-eabi softfp'
mas a VM tem 'product use_bare_instructions no- "afirma" causal_async_stacks arm64-sysv' "

Ahh, entendi. É porque precisaríamos incluir potencialmente o instantâneo AOT para o arco de destino também. E agora apenas colocamos isso em ativos, não colocamos uma versão por arquitetura em libs . Se pudéssemos colocar o instantâneo AOT na pasta libs específica da arquitetura, isso poderia funcionar, caso contrário, gostaríamos de usar o formato .aab por esse motivo.

Queremos fazer isso de qualquer maneira para oferecer suporte à construção de .AARs para casos de uso add2app. Eu vou cutucar.

@dnfield , você já teve algum sucesso nisso?

Trabalhando com a peça do plug-in no momento. Estamos tentando priorizar partes dele para corrigir os problemas do Android X, mas devemos ver mais alguns resultados disso.

@gerryhigh e eu estávamos investigando isso. Por favor, ignore minhas últimas respostas. O problema é apenas o fato de que libflutter.so não está incluído para 64 bits, mas para AOT você tem que executar o processo de construção duas vezes, uma para 32 bits e novamente para 64 bits. Em seguida, você obtém dois conjuntos de código Dart compilado em seus ativos de aplicativo, bem como duas versões de libflutter.so. Acho que o objetivo final seria configurar tarefas de compilação para Flutter para que ele execute as duas etapas de compilação separadas e tenha APKs separados configurados automaticamente.

Mas, por enquanto, a única solução é executar a compilação duas vezes e fazer o upload de vários APKs para a Play Store.

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

Isso pode ser melhor alcançado com a ativação de APKs divididos. Mais detalhes podem ser encontrados aqui: https://developer.android.com/studio/build/configure-apk-splits

@slightfoot sim, esta é a melhor solução que encontrei até agora, conforme mencionei no meu comentário lá https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

@slightfoot se bem entendi, não seria possível construir um APK universal já que alguns códigos estão localizados na pasta de ativos que não permite a divisão de arquivos de acordo com a arquitetura de destino como a pasta lib?

O instantâneo construído para cada arquitetura é diferente. Simplesmente copie o motor libflutter.so fará com que o instantâneo não possa ser carregado se a arquitetura do instantâneo não corresponder à arquitetura do motor de flutter.
Portanto, atualmente não há como construir um apk universal que contenha todas as arquiteturas, a menos que separemos os arquivos de instantâneo e inclua o arquivo de instantâneo para cada arquitetura.

Estou um pouco confuso quanto ao motivo disso ser um problema.

As compilações de depuração criam libflutter.so em x86_64, x86, armeabi-v7a e arm64-v8a.

As compilações de lançamento devem fazer exatamente o mesmo.

AGP (Android Gradle Plugin) já inclui a funcionalidade para filtrar arquiteturas, então se um usuário desejar fazer isso para uma versão de lançamento, ele pode modificar seu build.gradle.

@eseidel @dnfield Eu realmente não acho que isso seja resolvido pelo Android App Bundles - eles ainda não são a saída padrão do Android e, quando executados a partir do IDE, os apks serão usados ​​por um bom tempo, mas tenho certeza.

Os AABs são outro motivo pelo qual o Flutter deve incluir todas as arquiteturas de libflutter.para que a Play Store possa filtrar a arquitetura que ela entrega aos dispositivos.

@athornz, o problema não é com libflutter.so mas com o código do DART compilando até AOT snapshot compilações de depuração incluem a VM do DART, portanto, todo o seu código do DART executa JIT na VM , mas as versões de lançamento compilam seu código de dardos em um instantâneo e colocam esse instantâneo em uma pasta de ativos. O ideal é que o instantâneo seja compilado para cada arquitetura e colocado ao lado de libflutter.so mas esse não é o caso no momento. Portanto, embora você possa incluir libflutter.so para todas as arquiteturas, o instantâneo só funcionará para a arquitetura para a qual foi compilado.

Algum plano para corrigir esse problema?

A Google Play Store pede ao desenvolvedor para fornecer suporte de 64 bits após 1 de agosto de 2019.

https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

O requisito de 64 bits: o que isso significa para os desenvolvedores
A partir de 1º de agosto de 2019:
_Todos os novos aplicativos e atualizações de aplicativos que incluem código nativo são obrigados a fornecer versões de 64 bits, além das versões de 32 bits, ao publicar no Google Play._
Extensão: o Google Play continuará a aceitar apenas atualizações de 32 bits para jogos existentes que usam Unity 5.6.6 ou mais antigo até agosto de 2021.
A partir de 1º de agosto de 2021:
O Google Play interromperá a exibição de aplicativos sem versões de 64 bits em dispositivos compatíveis com 64 bits, o que significa que eles não estarão mais disponíveis na Play Store nesses dispositivos.
Isso incluirá jogos construídos com Unity 5.6.6 ou mais antigo.

@trevorwang já podemos construir 64 bits e enviá-los junto com 32 bits para a Play Store. Então isso não é um problema.

@slightfoot Quer dizer que preciso construir outro APK de 64 bits e fazer upload para o Google Play?

Como você sabe, o Google Play não está disponível na China continental. Preferimos um APK universal para oferecer suporte a todas as plataformas.

praticamente @trevorwang . É assim que eu faço https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

A divisão não funciona no arquivo gradfle. Você tem que fazer algo com um dos arquivos build.gradle para que o flutter saiba como compilar diferentes arquiteturas. Ou o Google Play rejeitará a segunda compilação.

Obrigado @ edTheGuy00

Mas realmente precisamos de um APK universal incluindo todos os abis para o mercado da China.

@trevorwang você pode construir para cada

A limitação de 64 bits é apenas uma limitação da Google Play Store. Você ainda pode implantar o APK armeabi-v7a apenas e todos poderão executar seu aplicativo.

Construir APKs separados por arquitetura é uma solução alternativa e definitivamente não é uma solução para todos.

Assim que a limitação de 64 bits do Google Play entrar em vigor, esse problema afetará a maioria dos desenvolvedores do Flutter, então realmente precisamos de uma solução que permita várias arquiteturas dentro de um apk / pacote.

Só um lembrete rápido

A equipe do Flutter usa o número de "polegares para cima" em um problema do GitHub como um guia para sua prioridade.

Acho que essa questão deve ter alta prioridade.

Obrigado pelo trabalho de @gerryhigh e @slightfoot

Eu adicionei flutter a um aplicativo existente e corrigi esse problema com a seguinte solução alternativa.
_Por favor, adicione isso ao seu módulo de aplicativo do projeto host._

Este é o script para o modo de depuração, altere de acordo com o lançamento.

project.afterEvaluate {
    assembleDebug.doLast {
        def flutterRoot = System.getenv("FLUTTER_HOME")
        def archTypes = ["arm", "arm64"]
        archTypes.forEach { item ->
            copy {
                from zipTree("$flutterRoot/bin/cache/artifacts/engine/android-$item/flutter.jar")
                include 'lib/*/libflutter.so'
                into "$buildDir/intermediates/jniLibs/debug/"
                eachFile {
                    it.path = it.path.replaceFirst("lib/", "")
                }
            }
        }
    }
}

Algum desenvolvimento recente?

O que acabei fazendo, já que queria

  • apks separados para cada arquitetura
  • não ter que modificar o versionCode manualmente
  • execute um único comando para produzir os apks
  1. Adicionado ao gradle. Ele adiciona 1 ou 2 no final do versionCode, então a versão 1004 torna-se 10041 para arm e 10042 para arm64.
ext.platformCodes = ['android-arm': 1, 'android-arm64' : 2]
android.applicationVariants.all { variant ->
    variant.outputs.each { output ->
        int code = 0
        if (project.hasProperty('target-platform')) {
            code = project.ext.platformCodes.get(project.property('target-platform'))
        }
        output.versionCodeOverride = variant.versionCode * 10 + code
    }
}
  1. Para produzir os apks, eu uso um comando de terminal mais longo (que você pode colocar em um script). Ele executa a compilação duas vezes e cria cópias dos apks no final:
flutter clean; flutter build apk --release --target-platform=android-arm; mv build/app/outputs/apk/release/app-release.apk build/app/outputs/apk/release/app-release-arm32.apk; flutter build apk --release --target-platform=android-arm64; mv build/app/outputs/apk/release/app-release.apk build/app/outputs/apk/release/app-release-arm64.apk;

Espero que isto ajude.

Portanto, este é um problema que também estou tendo ... Estou criando um pacote de aplicativos em vez de um apk e quando estou enviando para o Google, ele me dá o aviso e não me deixa testá-lo alfa.

Tenho usado codemagic para fazer isso, há uma maneira de assiná-lo e colocá-lo em um pacote? ou usar codemagic para pontuá-lo?

Estou enfrentando o mesmo problema que pensei que não deveria existir.

Como isso está nos "Objetivos" do Milestone.

P2: Essas são tarefas que achamos que vale a pena consertar nos próximos anos. Inclui problemas que identificamos que podem bloquear o envio completo de aplicativos voltados para o consumidor, problemas de correção e bugs relacionados a polimento e qualidade. A data neste marco é totalmente arbitrária e destina-se apenas a classificar o marco de forma adequada.

Já é um problema crítico e se tornará um obstáculo completo ainda este ano, quando o Google aplicar a limitação de 64 bits.

Eu superei o marco nisso. Nenhuma data sólida ainda.

Para ser claro: é possível, mas difícil, cumprir as novas diretrizes hoje. Queremos tornar isso mais fácil.

Portanto, o método @andreidiaconu funcionou para mim, desde que eu construísse o aplicativo manualmente.

Mas tenho usado codemagic para construir e implantar.

Então, isso é um desperdício, o Flutter precisa fazer isso construí-lo.

No momento, eu pessoalmente não me importo se é complicado. Se for complicado, será automatizado por um script. A questão é se isso é possível e como, porque o Google Play Console me avisa:

Esta versão não é compatível com o requisito de 64 bits do Google Play
Os seguintes APKs ou App Bundles estão disponíveis para dispositivos de 64 bits, mas têm apenas código nativo de 32 bits: 6.
A partir de 1º de agosto de 2019, todos os lançamentos devem estar em conformidade com o requisito de 64 bits do Google Play.
Inclua código nativo de 64 e 32 bits em seu aplicativo. Use o formato de publicação do Android App Bundle para garantir automaticamente que cada arquitetura de dispositivo receba apenas o código nativo de que precisa. Isso evita aumentar o tamanho geral do seu aplicativo.

Não quero uma solução que precise de códigos de versão diferentes e quero uma solução que funcione com Android App Bundles (AAB).

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

Os seguintes APKs ou App Bundles estão disponíveis para dispositivos de 64 bits, mas têm apenas código nativo de 32 bits: 3.

Qualquer solução?

Eu superei o marco nisso. Nenhuma data sólida ainda.

Para ser claro: é possível, mas difícil, cumprir as novas diretrizes hoje. Queremos tornar isso mais fácil.

Os documentos devem ser atualizados com instruções sobre como fazer isso para os pacotes apk e app? Tudo o que vi até agora são vários códigos e configurações que não tenho certeza de onde colocar. Provavelmente poderia descobrir isso com alguma tentativa e erro, mas não é o ideal.

o mesmo problema

Obrigado pelo trabalho de @gerryhigh e @slightfoot

Eu adicionei flutter a um aplicativo existente e corrigi esse problema com a seguinte solução alternativa.
_Por favor, adicione isso ao seu módulo de aplicativo do projeto host._

Este é o script para o modo de depuração, altere de acordo com o lançamento.

project.afterEvaluate {
    assembleDebug.doLast {
        def flutterRoot = System.getenv("FLUTTER_HOME")
        def archTypes = ["arm", "arm64"]
        archTypes.forEach { item ->
            copy {
                from zipTree("$flutterRoot/bin/cache/artifacts/engine/android-$item/flutter.jar")
                include 'lib/*/libflutter.so'
                into "$buildDir/intermediates/jniLibs/debug/"
                eachFile {
                    it.path = it.path.replaceFirst("lib/", "")
                }
            }
        }
    }
}

Esta solução / alternativa parece muito promissora, obrigado @trevorwang ! Eu tenho problemas para implementar isso em um projeto de flutter existente, no entanto. Você tem um arquivo build.gradle de exemplo ou algo equivalente que demonstre isso?

NOTE QUE ISTO PROVAVELMENTE NÃO RESOLVERÁ SEU PROBLEMA - VEJA ABAIXO

Graças à resposta do @trevorwang e à sugestão do ./android/app/build.gradle mostrada abaixo.
Você também pode ver o arquivo inteiro aqui .

afterEvaluate {
    mergeReleaseJniLibFolders.doLast {
        def archTypes = ["arm-release", "arm64-release"]
        archTypes.forEach { item ->
            copy {
                from zipTree("$flutterRoot/bin/cache/artifacts/engine/android-$item/flutter.jar")
                include 'lib/*/libflutter.so'
                into "$buildDir/intermediates/jniLibs/release/"
                eachFile {
                    it.path = it.path.replaceFirst("lib/", "")
                }
            }
        }
    }
}

@SPodjasek obrigado! Cheguei a algo semelhante. No meu caso, preciso alterar assembleRelease em seu snippet para mergeReleaseJniLibFolders , caso contrário, o arquivo * .so extra acabará em "intermediários / ...", mas não no apk final.

@noinskit Parece que minha solução anterior estava sujeita a erros. Depois de executar flutter clean ele gerou aab's com apenas bibliotecas de 32 bits. Substituir assembleRelease por mergeReleaseJniLibFolders parece funcionar também após a limpeza da compilação.

@SPodjasek , você precisa ajustar alguma outra opção?

Aqui está meu app.gradle

def flutterRoot = localProperties.getProperty('flutter.sdk')
if (flutterRoot == null) {
    throw new GradleException("Flutter SDK not found. Define location with flutter.sdk in the local.properties file.")
}

afterEvaluate {
    mergeReleaseJniLibFolders.doLast {
        def archTypes = ["arm-release", "arm64-release"]
        archTypes.forEach { item ->
            copy {
                from zipTree("$flutterRoot/bin/cache/artifacts/engine/android-$item/flutter.jar")
                include 'lib/*/libflutter.so'
                into "$buildDir/intermediates/jniLibs/release/"
                eachFile {
                    it.path = it.path.replaceFirst("lib/", "")
                }
            }
        }
    }
}

Ambos os meus diretórios intermediários / jniLibs / release / arm64-v8a e armeabi-v7a têm libflutter.so conforme esperado, mas o APK de lançamento final ainda está faltando libflutter.so em arm64-v8a.

Aqui está a imagem

flutter

@ function1983 Você pode ver meu build.gradle completo aqui .
Na minha versão vibrante:

[✓] Flutter (Channel beta, v1.5.4, on Linux, locale pl_PL.UTF-8)
    • Flutter version 1.5.4 at .../development/flutter
    • Framework revision b593f5167b (2 weeks ago), 2019-04-22 07:51:33 -0700
    • Engine revision ca31a7c57b
    • Dart version 2.3.0 (build 2.3.0-dev.0.1 cf4444b803)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at .../Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: .../development/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b16-5323222)
    • All Android licenses accepted.

[✓] Android Studio (version 3.4)
    • Android Studio at .../development/android-studio
    • Flutter plugin version 35.2.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b16-5323222)

Eu tenho tentado usar a solução @SPodjasek 's para construir uma appbundle que inclui ambas as versões 64 e 32 bits. Ele é compilado com sucesso, posso carregá-lo no Google Play Console e posso instalá-lo em telefones de 32 e 64 bits. Mas o aplicativo trava ao ser iniciado em um dispositivo android-arm64 por algum motivo (parece funcionar em um velho telefone Android de 32 bits que eu estava testando).

Aqui está o erro que recebo no dispositivo de 64 bits:

Abortar mensagem: '[ FATAL: flutter / runtime / dart_vm.cc (416)] Erro ao inicializar o Dart VM: Snapshot não compatível com a configuração VM atual: o snapshot requer' product use_bare_instructions no- "asserts" causal_async_stacks arm-eabi softfp 'mas a VM tem' produto use_bare_instructions no- "afirma" causal_async_stacks arm64-sysv '

Não tenho certeza do que posso fazer ... Talvez tenha que me limitar a suportar dispositivos de 64 bits por enquanto.

@Torrunt, esse erro ocorre porque o mecanismo está tentando ignorar o instantâneo AOT para 32 bits e encontrar um para 64.

Estamos trabalhando para produzir um AAB que tenha ambos, para que a loja possa dividi-los corretamente.

@SPodjasek Usar isso aumentou o tamanho do arquivo meu app-release.apk de 11,1 MB para 15,7 MB

@SPodjasek Usar isso aumentou o tamanho do arquivo meu app-release.apk de 11,1 MB para 15,7 MB

Sim, visto que inclui libflutter.so para 32 e 64 bits. Se você não precisa disso, mantenha o padrão atual para incluir apenas 32 bits e espere a equipe de flutter lidar com isso corretamente.

parece que existem algumas possibilidades:

  • espere até que a equipe de flutter resolva o problema da arquitetura 32 x 64, fazendo com que a google play store aceite as compilações de flutter novamente
  • temos que limitar os dispositivos Android usados ​​a apenas 32 bits, para que os aplicativos de flutter funcionem apenas em dispositivos de 32 bits
  • temos que convencer o Google a não aplicar 64 bits na Play Store. (Eu me pergunto qual é a diferença entre 32 e 64 bits, algo como números maiores?)
  • instale os 32 aplicativos de alguma forma em dispositivos de 64 bits, mas não na Play Store ...

Nota para pessoas que usam --target-platform para construir para android-arm e android-arm64 separadamente e fazer upload de dois APK.
Preste atenção que alguns plug-ins usam bibliotecas nativas que podem ter como alvo ambos, e flutter não filtra as pastas de bibliotecas, então seu APK de "32 bits" ainda terá como alvo arm64 e irá travar porque libflutter.so não está presente e instantâneos AOT estão construído para armv7.

Portanto, você precisará filtrar explicitamente o abi de destino em seu arquivo build.gradle.

Acho que flutter build apk --target-platform ... deveria logicamente fazer essa filtragem.

Usando a solução de @SPodjasek , recebi um erro sobre igualar arm-eabi versus arm64-sysv . Acho que a melhor solução, que funcionou para mim, é apenas construir para 32 bits por enquanto até que tudo esteja resolvido (solução de @swavkulinski aqui ):

Em seu app nível build.gradle :

android {
    // ...
    buildTypes {
        release {
            // ...
            ndk {
                abiFilters "armeabi-v7a"
            }
        }
    }
}

Resumindo o problema do assunto - não será possível construir tal APK para armeabi-v7a e arm64-v8a. O Flutter usa instantâneos AOT que são dependentes de ABI, portanto, com o APK, a única solução possível seria usar várias compilações de APK.
A solução seria usar App Bundles, que, por enquanto, também apresenta alguns problemas (# 31922).
Depois que o # 32787 foi mesclado, agora é possível usar App Bundles.

Como defino o sabor e meu arquivo de destino (-t lib / another_main.dart, por exemplo) ao gerar um Android app Bundle por meio do Android Studio? oo

Isso terá suporte por meio de flutter build appbundle após a fusão de https://github.com/flutter/flutter/pull/32787 !

@swavkulinski como você lançaria o para apks na playstore?

Ainda era possível naquela época. Agora você tem que limitar a 64 bits. Fomos bloqueados pela biblioteca NDK de terceiros, que era apenas de 32 bits.

@blasten
Isso também adicionará suporte para flutter build apk --release ? Ou está planejado a eliminação do suporte para APKs em favor de pacotes de aplicativos em longo prazo? Eu gosto bastante da relativa simplicidade do APK gordo.

@zimmi Correto. Os pacotes de aplicativos devem ser o caminho a seguir. Você ainda pode usar flutter build apk --release quando necessário. O que é mais simples em um APK gordo em comparação com AAB?

O que é mais simples em um APK gordo em comparação com AAB?

AAB não é um arquivo de instalação. O próprio Android não pode usá-lo. É o formato de arquivo apenas para Google Play Store. Portanto, precisa de apk quando:

  • Instalando diretamente no dispositivo.
  • Distribuindo app diretamente.
  • Distribuir por meio de qualquer outro mercado de aplicativos, exceto Google Play Store. (Amazônia e toda a China).

Eu vejo. Obrigado pelo fundo.

Além disso, você pode extrair os APKs do AAB usando bundletool .

@blasten
Obrigado por confirmar!
Em relação ao comentário de simplicidade: O que @audkar disse. Também com AABs, o desenvolvedor deve pensar sobre os cenários de falha em potencial causados ​​por ativos ausentes. Testar todas as configurações de dispositivo possíveis é difícil, portanto, se essas falhas ocorrerem, é provável que estejam em produção.

O tamanho do aplicativo pode ser um preço que alguns estão dispostos a pagar por essa tranquilidade.

Tenho certeza de que há lugares melhores para discutir os méritos de cada abordagem do que essa questão, porém, não quero atrapalhar isso.

/ cc @jonahwilliams , talvez precisemos oferecer suporte a APKs gordos em build apk .
Devemos também alterar o padrão para build apk ?

O suporte para apk gordo é definitivamente necessário. Existem várias ferramentas (distribuição beta, etc.) que ainda não funcionam com pacotes de aplicativos.

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

Discutimos para oferecer suporte a uma lista de plataformas em build apk , então você poderia fazer algo assim: flutter build apk --target-platform android-arm,android-arm64

@blasten Eu mudei para o canal master, atualizei e construí o appbundle, funcionou bem. Em seguida, carregue-o no console de jogo e todos os avisos desaparecerão. (macOS 10.14.4)

Impressionante! Compilarei minha construção esta noite depois de fazer minhas alterações.

O pacote parece não funcionar embora, o aplicativo trava ao ser baixado.

Issue: java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{com.mattetti.sounds/com.mattetti.sounds.MainActivity}: java.lang.ClassNotFoundException: Didn't find class "com.mattetti.sounds.MainActivity" on path: DexPathList[[zip file "/data/app/com.mattetti.sounds-ewwlQg0QphABpwu8t14HWA==/base.apk", zip file "/data/app/com.mattetti.sounds-ewwlQg0QphABpwu8t14HWA==/split_config.arm64_v8a.apk", zip file "/data/app/com.mattetti.sounds-ewwlQg0QphABpwu8t14HWA==/split_config.xxhdpi.apk"],nativeLibraryDirectories=[/data/app/com.mattetti.sounds-ewwlQg0QphABpwu8t14HWA==/lib/arm64, /data/app/com.mattetti.sounds-ewwlQg0QphABpwu8t14HWA==/base.apk!/lib/arm64-v8a, /data/app/com.mattetti.sounds-ewwlQg0QphABpwu8t14HWA==/split_config.arm64_v8a.apk!/lib/arm64-v8a, /data/app/com.mattetti.sounds-ewwlQg0QphABpwu8t14HWA==/split_config.xxhdpi.apk!/lib/arm64-v8a, /system/lib64]]

Parece que com.mattetti.sounds.MainActivity não está no pacote?

Não tenho certeza por que, como posso verificar por que ele foi removido?

@mattetti Você está usando um módulo Flutter ? Está MainActivity estendendo FlutterActivity ?

@blasten
Aqui estão minhas dependências

environment:
  sdk: ">=2.2.2 <3.0.0"

dependencies:
  flutter:
    sdk: flutter
  rxdart: ^0.22.0
  shared_preferences: ^0.5.2
  http: ^0.12.0
  cached_network_image: ^0.8.0
  url_launcher: ^5.0.2

  # The following adds the Cupertino Icons font to your application.
  # Use with the CupertinoIcons class for iOS style icons.
  cupertino_icons: ^0.1.2

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_launcher_icons: "^0.7.0"

dependency_overrides:
  # requried for flutter_icons at this point
  image: 2.0.7

Mas também acabei de notar que renomeei o pacote do meu aplicativo, mas não alterei o caminho para o meu arquivo MainActivity.java que ainda é android/app/src/main/java/com/example/old_name/ esse pode ser o problema. Amanhã, tentarei mudar o caminho e empurrar outro pacote.

olá @blasten , tentei compilar o appbundle e recebi este erro

[  +48 ms] FAILURE: Build failed with an exception.
[   +3 ms] * What went wrong:
[        ] Failed to capture snapshot of input files for task ':app::flutter:package:packLibsDevRelease' property
'rootSpec$2$1' during up-to-date check.
[        ] > java.io.IOException: The filename, directory name, or volume label syntax is incorrect
[        ] * Try:
[        ] Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log
output. Run with --scan to get full insights.
[        ] * Get more help at https://help.gradle.org
[        ] Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
[        ] See https://docs.gradle.org/4.6/userguide/command_line_interface.html#sec:command_line_warnings
[        ] BUILD FAILED in 1m 28s

Meu projeto usa sabor e este é o comando que executo

flutter build appbundle --flavor stage -t lib/main-stage.dart -v

O pacote de aplicativos também incluirá o mapping.txt? Ao fazer upload de pacotes de aplicativos para o Google Play Console via Codemagic, não há mapping.txt incluído, portanto, nenhum teste automatizado ou relatórios de pré-lançamento - que você tem ao fazer upload de um apk :(

então a questão é:

A equipe do Flutter fará uma atualização para o lançamento de 64 bits ou não antes de agosto para que possamos fazer o upload e atualizar nossos aplicativos que são feitos com flutter ou não?

@YazeedAlKhalaf Sim. Você pode usar flutter build appbundle hoje e obterá um pacote de aplicativos que contém 32 e 64 bits.

@mattetti o problema foi corrigido?

@nohli mapping.txt soa como uma solicitação de recurso. Sinta-se à vontade para registrar um novo bug.

@skybur você pode executar flutter doctor ? O seu projeto Flutter é um aplicativo ou módulo?

@blasten Meu projeto é um aplicativo.

Aqui está o resultado de flutter doctor

[√] Flutter (Channel master, v1.6.1-pre.68, on Microsoft Windows [Version 10.0.17763.503], locale en-US)
    • Flutter version 1.6.1-pre.68 at D:\Devs\Flutter\testappbundle\flutter
    • Framework revision d5aae54a28 (22 hours ago), 2019-05-20 23:19:18 -0400
    • Engine revision 301f560bd8
    • Dart version 2.3.1 (build 2.3.1-dev.0.0 b48c8b1d1c)

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at D:\AndroidSDK
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = D:\AndroidSDK
    • ANDROID_SDK_ROOT = D:\AndroidSDK
    • Java binary at: D:\AndroidStudio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[√] Android Studio (version 3.2)
    • Android Studio at D:\AndroidStudio
    • Flutter plugin version 31.3.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[√] VS Code, 64-bit edition (version 1.33.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.0.2

[!] Connected device
    ! No devices available

! Doctor found issues in 1 category.

@blasten : obtendo o mesmo erro que skybur

Tentando usar flutter build appbundle , fazer upload para a loja e abrir em um telefone Android:
Falha instantânea na abertura.

log adb:
05-22 09:40:52.404 27305 27305 E flutter : [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings. 05-22 09:40:52.404 27305 27305 E flutter : [ERROR:flutter/runtime/dart_vm.cc(241)] Could not setup VM data to bootstrap the VM from. 05-22 09:40:52.404 27305 27305 E flutter : [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance. 05-22 09:40:52.404 27305 27305 F flutter : [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM. 05-22 09:40:52.404 27305 27305 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 27305 (tform.atomicdex) 05-22 09:40:52.432 27339 27339 I crash_dump64: obtaining output fd from tombstoned 05-22 09:40:52.433 1417 1417 I /system/bin/tombstoned: received crash request for pid 27305 05-22 09:40:52.434 27339 27339 I crash_dump64: performing dump of process 27305 (target tid = 27305) 05-22 09:40:52.434 27339 27339 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 05-22 09:40:52.434 27339 27339 F DEBUG : Build fingerprint: 'lge/judyln_lao_com/judyln:8.0.0/OPR1.170623.032/190501244a6e5.FGN:user/release-keys' 05-22 09:40:52.434 27339 27339 F DEBUG : Revision: '12' 05-22 09:40:52.434 27339 27339 F DEBUG : ABI: 'arm64' 05-22 09:40:52.434 27339 27339 F DEBUG : pid: 27305, tid: 27305, name: PACKAGE_NAME >>> PACKAGE_NAME <<< 05-22 09:40:52.434 27339 27339 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 05-22 09:40:52.435 27339 27339 F DEBUG : Abort message: '[FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM. 05-22 09:40:52.435 27339 27339 F DEBUG : ' 05-22 09:40:52.435 27339 27339 F DEBUG : x0 0000000000000000 x1 0000000000006aa9 x2 0000000000000006 x3 0000000000000008 05-22 09:40:52.435 27339 27339 F DEBUG : x4 0000000007d0bf68 x5 0000000007d0bf68 x6 0000000007d0bf68 x7 0000000007d0bfd8 05-22 09:40:52.435 27339 27339 F DEBUG : x8 0000000000000083 x9 8644075c81e36b5a x10 00000077ccff6a48 x11 8644075c81e36b5a 05-22 09:40:52.435 27339 27339 F DEBUG : x12 8644075c81e36b5a x13 0000000000000020 x14 ffffffffffffffdf x15 00000077ca27ec68 05-22 09:40:52.435 27339 27339 F DEBUG : x16 00000077ca2732b8 x17 00000077ca205a44 x18 0000000000000048 x19 0000000000006aa9 05-22 09:40:52.435 27339 27339 F DEBUG : x20 0000000000006aa9 x21 0000007fe4fb81b8 x22 00000077b3dffba0 x23 00000077bd29d7a0 05-22 09:40:52.435 27339 27339 F DEBUG : x24 00000077aa79a150 x25 0000000000000000 x26 0000000000000000 x27 0000000000000002 05-22 09:40:52.435 27339 27339 F DEBUG : x28 0000000000000000 x29 0000007fe4fb81a0 x30 00000077ca1aa8e4 05-22 09:40:52.435 27339 27339 F DEBUG : sp 0000007fe4fb8160 pc 00000077ca205a4c pstate 0000000060000000 05-22 09:40:52.436 27339 27339 F DEBUG : 05-22 09:40:52.436 27339 27339 F DEBUG : backtrace: 05-22 09:40:52.436 27339 27339 F DEBUG : #00 pc 0000000000079a4c /system/lib64/libc.so (tgkill+8) 05-22 09:40:52.436 27339 27339 F DEBUG : #01 pc 000000000001e8e0 /system/lib64/libc.so (abort+88) 05-22 09:40:52.436 27339 27339 F DEBUG : #02 pc 000000000001d61c /data/app/PACKAGE_NAME-F-z4qH6HT271dk7M7oI8Uw==/split_config.arm64_v8a.apk (offset 0xea7000)

@Kiruel, não está muito claro para mim por que as pessoas continuam dizendo que o pacote de aplicativos está resolvendo esse problema.

O pacote de aplicativos nada mais é do que um APK dividido automatizado e não há divisão na pasta de ativos. Portanto, os instantâneos ainda visam apenas uma única arquitetura.

Provavelmente estou faltando alguma coisa, mas na minha opinião, a única solução agora é construir o APK para cada arquitetura com a filtragem ndk correspondente no arquivo gradle. Em seguida, faça upload de cada um desses APK.

se não conseguirmos resolver esse problema com o APK, também não há chance de que o pacote de apps funcione.

@ndusart Não acho que seja verdade. A documentação do pacote de aplicativos diz:

res /, lib / e assets /: esses diretórios são idênticos aos de um APK típico. Quando você faz upload do pacote de aplicativos, o Google Play inspeciona esses diretórios e empacota apenas os arquivos que atendem à configuração do dispositivo de destino, preservando os caminhos dos arquivos.

Portanto, ele pode, de alguma forma, dividir os ativos.

@jereksel isso apenas informa que esses diretórios estão funcionando exatamente da mesma maneira no pacote de aplicativos do que no apk e a pasta assets/ não está dividida. É usado para ter ativos armazenados em uma estrutura de arquivo muito específica no aplicativo, não se destina a ser analisado pelo sistema operacional ou qualquer coisa.

Se eu estiver errado, diga-me como podemos dividir esta pasta com base na ABI de destino.

E esta citação apenas confirma o que digo, se isso não for possível agora com o APK, isso não será possível usando o pacote de aplicativos, pois essas pastas funcionam exatamente da mesma em ambas as maneiras.

Eu não vi os ativos se dividirem, mas descobri o seguinte:

https://medium.com/google-developer-experts/exploring-the-android-app-bundle-ca16846fa3d7

assets.pb - é o equivalente a uma tabela de recursos para ativos de aplicativo e só estará presente se você estiver usando ativos em seu aplicativo.

Então, meu palpite é que o Android Studio não divide ativos, mas os pacotes de aplicativos em si têm suporte para isso.

Você tem alguma documentação oficial? Tudo isso parece pouco confiável.
O seguinte artigo, https://medium.com/mindorks/android-app-bundle-aab-98de6dad8ba8 , afirma que podemos anexar um sufixo ao nome das pastas em assets/ para dividi-lo, mas atualmente isso só pode ser feito no idioma.

Ainda assim, isso ainda não parece estável e não deve ser baseado no agora. Os instantâneos da VM devem ser deportados para a pasta lib/ se isso for possível ou o comando flutter deve vir com um recurso completo para construir um APK para um alvo específico (ainda há trabalho a fazer nisso por ser acessível a muitas pessoas) e atrasar a produção de um pacote de aplicativos quando ele estiver pronto.

@blasten

Mudei para o canal master, atualizei e construí o appbundle. Infelizmente, o aplicativo falha após o download da loja Google Play com o seguinte logcat

2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings.
2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm.cc(241)] Could not setup VM data to bootstrap the VM from.
2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance.
2019-05-22 09:42:14.824 6995-6995/? A/flutter: [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.

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

Discutimos para oferecer suporte a uma lista de plataformas em build apk , então você poderia fazer algo assim: flutter build apk --target-platform android-arm,android-arm64

@blasten

Mudei para o canal master, atualizei e construí o appbundle. Infelizmente, o aplicativo falha após o download da loja Google Play com o seguinte logcat

2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings.
2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm.cc(241)] Could not setup VM data to bootstrap the VM from.
2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance.
2019-05-22 09:42:14.824 6995-6995/? A/flutter: [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.

flutter build appbundle agora está no mestre, alguma pessoa voluntária deseja tentar?
Discutimos para oferecer suporte a uma lista de plataformas em build apk , então você poderia fazer algo assim: flutter build apk --target-platform android-arm,android-arm64

Tenho o mesmo problema, embora ainda não tenha nenhum registro.

@skybur, o problema que você estava tendo pode estar relacionado a https://github.com/flutter/flutter/issues/33119. Se for esse o caso, este patch deve corrigi-lo.

@ndusart
Sim você está certo. Eu verifiquei o código-fonte do bundletool e a divisão de ativos é apenas por idioma:
https://github.com/google/bundletool/blob/master/src/main/java/com/android/tools/build/bundletool/splitters/ModuleSplitter.java#L286

Esta foi a minha solução:

  1. em app gradle
splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }
  1. execute flutter build apk --release --target-platform=android-arm
  2. carregue app-armeabi-v7a-release.apk para a Play Store
  3. incremento versionCode
  4. execute flutter build apk --release --target-platform=android-arm64
  5. carregue app-arm64-v8a-release.apk para a Play Store

A Google Play Store servirá o aplicativo de acordo com a arquitetura do dispositivo. Dispositivos de 32 bits estão felizes, dispositivos de 64 bits estão felizes e estou feliz em saber que o tamanho do meu APK permanece relativamente pequeno, embora ainda atenda às duas arquiteturas.

Se incluirmos suporte para ambas as arquiteturas no mesmo APK, espera-se que o tamanho do seu aplicativo seja de mais de 10 MB

Há uma coisa importante para dizer a vocês. Se você usar o método que cito. Você pode precisar comentar a configuração, quando quiser continuar a depurar seu aplicativo. Encaro o erro que a gradlew clean ... etc, e finalmente descobri que isso deveria ser comentado!

Espero que isso tenha ajudado alguém a pular.

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

Discutimos para oferecer suporte a uma lista de plataformas em build apk , então você poderia fazer algo assim: flutter build apk --target-platform android-arm,android-arm64

flutter build appbundle está funcionando! Não preciso adicionar essa configuração, apenas fazer o código. No entanto, leva um pouco de tempo para compilar, mas é a única maneira de passar no Google Play agora.

@Tokenyet você conseguiu baixar o aplicativo da Play Store e executá-lo depois de enviar .aab ? Se for esse o caso, você se importaria de colar a saída de flutter doctor ?

@blasten

Mudei para o canal master, atualizei e construí o appbundle. Infelizmente, o aplicativo falha após o download da loja Google Play com o seguinte logcat

2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings.
2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm.cc(241)] Could not setup VM data to bootstrap the VM from.
2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance.
2019-05-22 09:42:14.824 6995-6995/? A/flutter: [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.

flutter build appbundle agora está no mestre, alguma pessoa voluntária deseja tentar?
Discutimos para oferecer suporte a uma lista de plataformas em build apk , então você poderia fazer algo assim: flutter build apk --target-platform android-arm,android-arm64

Exatamente a mesma coisa aqui, ao tentar executar meu aplicativo da Play Store (criado como appbundle). Quais logs vocês precisam para resolver isso?

Isso será útil:

  1. Baixe bundletool em https://developer.android.com/studio/command-line/bundletool
  2. Execute flutter build appbundle (indique se você aprovou algum sinalizador ou se fez alterações _custom_ em qualquer script do Gradle)
  3. Execute bundletool build-apks --bundle=build/app/outputs/bundle/release/app.aab --output=out.apks para extrair o conjunto de APK.
  4. Execute unzip -l out.apks e por último flutter doctor e cole a saída de ambos os comandos em seu comentário.

Se possível:

Teste localmente no dispositivo usando bundletool e o conjunto de APK. Estas são as etapas , cole o logcat em seu comentário.

Não consigo reproduzir o problema, embora só tenha testado localmente usando bundletool .

@blasten Portanto, o erro anterior foi corrigido, mas encontrei outro erro. Presumo que isso seja causado por algo em meu projeto. Existe alguma maneira de depurar isso?

[+6084 ms] Failed to execute aapt
[  +17 ms] com.android.ide.common.process.ProcessException: Failed to execute aapt
[   +1 ms]      at com.android.builder.core.AndroidBuilder.processResources(AndroidBuilder.java:809)
[   +1 ms]      at com.android.build.gradle.internal.res.LinkAndroidResForBundleTask.taskAction(LinkAndroidResForBundleTask.kt:128)
[   +1 ms]      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[   +1 ms]      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[   +1 ms]      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[        ]      at java.lang.reflect.Method.invoke(Method.java:498)
[        ]      at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
[   +4 ms]      at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
[   +1 ms]      at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
[        ]      at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
[   +3 ms]      at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:788)
[  +29 ms]      at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:755)
[   +1 ms]      at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:124)
[   +1 ms]      at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
[   +2 ms]      at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
[   +1 ms]      at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
[   +9 ms]      at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
[        ]      at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:113)
[        ]      at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:95)
[   +1 ms]      at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:73)
[        ]      at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
[   +1 ms]      at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
[        ]      at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
[        ]      at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
[   +5 ms]      at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
[        ]      at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
[   +1 ms]      at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
[   +1 ms]      at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
[  +12 ms]      at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
[   +4 ms]      at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
[        ]      at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
[        ]      at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
[        ]      at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:256)
[        ]      at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
[        ]      at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
[        ]      at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
[        ]      at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
[   +1 ms]      at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:249)
[   +6 ms]      at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:238)
[        ]      at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123)
[        ]      at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79)
[        ]      at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
[   +1 ms]      at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
[   +1 ms]      at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:663)
[   +1 ms]      at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:597)
[        ]      at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
[  +14 ms]      at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
[   +1 ms]      at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
[   +4 ms]      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[   +1 ms]      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[   +2 ms]      at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
[   +1 ms]      at java.lang.Thread.run(Thread.java:745)
[  +26 ms] Caused by: java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.v2.Aapt2Exception: AAPT2 error: check logs for details
[   +4 ms]      at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:503)
[   +1 ms]      at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:482)
[        ]      at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:79)
[        ]      at com.android.builder.internal.aapt.AbstractAapt.link(AbstractAapt.java:34)
[        ]      at com.android.builder.core.AndroidBuilder.processResources(AndroidBuilder.java:807)
[        ]      ... 51 more
[        ] Caused by: java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.v2.Aapt2Exception: AAPT2 error: check logs for details
[   +1 ms]      at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:503)
[        ]      at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:462)
[        ]      at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:79)
[        ]      at com.android.builder.internal.aapt.v2.QueueableAapt2.lambda$makeValidatedPackage$1(QueueableAapt2.java:166)
[   +4 ms]      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[   +1 ms]      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[   +1 ms]      ... 1 more
[   +1 ms] Caused by: com.android.builder.internal.aapt.v2.Aapt2Exception: AAPT2 error: check logs for details
[   +1 ms]      at com.android.builder.png.AaptProcess$NotifierProcessOutput.handleOutput(AaptProcess.java:443)
[   +1 ms]      at com.android.builder.png.AaptProcess$NotifierProcessOutput.err(AaptProcess.java:395)
[        ]      at com.android.builder.png.AaptProcess$ProcessOutputFacade.err(AaptProcess.java:312)
[        ]      at com.android.utils.GrabProcessOutput$1.run(GrabProcessOutput.java:104)
[        ] FAILURE: Build failed with an exception.
[        ] * What went wrong:
[        ] Execution failed for task ':app:bundleProdReleaseResources'.
[        ] > Failed to execute aapt
[        ] * Try:
[        ] Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
[   +5 ms] * Get more help at https://help.gradle.org
[        ] BUILD FAILED in 30s
[ +324 ms] Running Gradle task 'bundleProdRelease'... (completed in 31.5s)

@blasten sigo todos os seus passos meus logs:

➜  PROJECT_NAME git:(master) ✗ unzip -l out.apks
Archive:  out.apks
  Length      Date    Time    Name
---------  ---------- -----   ----
 43369811  01-01-1970 01:00   standalones/standalone-armeabi_tvdpi.apk
 43327197  01-01-1970 01:00   standalones/standalone-armeabi_hdpi.apk
 43319503  01-01-1970 01:00   standalones/standalone-armeabi_mdpi.apk
 43320027  01-01-1970 01:00   standalones/standalone-armeabi_ldpi.apk
 43346424  01-01-1970 01:00   standalones/standalone-armeabi_xxhdpi.apk
 43350403  01-01-1970 01:00   standalones/standalone-armeabi_xxxhdpi.apk
 43332970  01-01-1970 01:00   standalones/standalone-armeabi_xhdpi.apk
 50349155  01-01-1970 01:00   standalones/standalone-armeabi_v7a_ldpi.apk
 50348629  01-01-1970 01:00   standalones/standalone-armeabi_v7a_mdpi.apk
 50398968  01-01-1970 01:00   standalones/standalone-armeabi_v7a_tvdpi.apk
 50356358  01-01-1970 01:00   standalones/standalone-armeabi_v7a_hdpi.apk
 50362126  01-01-1970 01:00   standalones/standalone-armeabi_v7a_xhdpi.apk
 50375565  01-01-1970 01:00   standalones/standalone-armeabi_v7a_xxhdpi.apk
 50379553  01-01-1970 01:00   standalones/standalone-armeabi_v7a_xxxhdpi.apk
 50660246  01-01-1970 01:00   standalones/standalone-arm64_v8a_ldpi.apk
 50659718  01-01-1970 01:00   standalones/standalone-arm64_v8a_mdpi.apk
 50710027  01-01-1970 01:00   standalones/standalone-arm64_v8a_tvdpi.apk
 50667415  01-01-1970 01:00   standalones/standalone-arm64_v8a_hdpi.apk
 50673185  01-01-1970 01:00   standalones/standalone-arm64_v8a_xhdpi.apk
 50686641  01-01-1970 01:00   standalones/standalone-arm64_v8a_xxhdpi.apk
 43345757  01-01-1970 01:00   standalones/standalone-x86_mdpi.apk
 43346287  01-01-1970 01:00   standalones/standalone-x86_ldpi.apk
 43396086  01-01-1970 01:00   standalones/standalone-x86_tvdpi.apk
 50690619  01-01-1970 01:00   standalones/standalone-arm64_v8a_xxxhdpi.apk
 43359247  01-01-1970 01:00   standalones/standalone-x86_xhdpi.apk
 43353470  01-01-1970 01:00   standalones/standalone-x86_hdpi.apk
 43372688  01-01-1970 01:00   standalones/standalone-x86_xxhdpi.apk
 43376653  01-01-1970 01:00   standalones/standalone-x86_xxxhdpi.apk
 43340224  01-01-1970 01:00   standalones/standalone-x86_64_ldpi.apk
 43339701  01-01-1970 01:00   standalones/standalone-x86_64_mdpi.apk
 43390033  01-01-1970 01:00   standalones/standalone-x86_64_tvdpi.apk
 43347418  01-01-1970 01:00   standalones/standalone-x86_64_hdpi.apk
    57027  01-01-1970 01:00   splits/base-ldpi.apk
    56501  01-01-1970 01:00   splits/base-mdpi.apk
    61951  01-01-1970 01:00   splits/base-hdpi.apk
    67741  01-01-1970 01:00   splits/base-xhdpi.apk
    81187  01-01-1970 01:00   splits/base-xxhdpi.apk
    85188  01-01-1970 01:00   splits/base-xxxhdpi.apk
   105385  01-01-1970 01:00   splits/base-tvdpi.apk
 43353194  01-01-1970 01:00   standalones/standalone-x86_64_xhdpi.apk
    11313  01-01-1970 01:00   splits/base-ca.apk
    11211  01-01-1970 01:00   splits/base-da.apk
    12040  01-01-1970 01:00   splits/base-fa.apk
    11659  01-01-1970 01:00   splits/base-ja.apk
    12486  01-01-1970 01:00   splits/base-ka.apk
    12511  01-01-1970 01:00   splits/base-pa.apk
    12856  01-01-1970 01:00   splits/base-ta.apk
    11195  01-01-1970 01:00   splits/base-nb.apk
    12001  01-01-1970 01:00   splits/base-be.apk
    11420  01-01-1970 01:00   splits/base-de.apk
    13041  01-01-1970 01:00   splits/base-ne.apk
    12674  01-01-1970 01:00   splits/base-te.apk
 43366615  01-01-1970 01:00   standalones/standalone-x86_64_xxhdpi.apk
    11179  01-01-1970 01:00   splits/base-af.apk
    12151  01-01-1970 01:00   splits/base-bg.apk
    12353  01-01-1970 01:00   splits/base-th.apk
    11228  01-01-1970 01:00   splits/base-fi.apk
    12537  01-01-1970 01:00   splits/base-si.apk
    12551  01-01-1970 01:00   splits/base-hi.apk
    11939  01-01-1970 01:00   splits/base-kk.apk
    11615  01-01-1970 01:00   splits/base-vi.apk
    12059  01-01-1970 01:00   splits/base-mk.apk
    11440  01-01-1970 01:00   splits/base-sk.apk
    11961  01-01-1970 01:00   splits/base-uk.apk
    12344  01-01-1970 01:00   splits/base-el.apk
    11342  01-01-1970 01:00   splits/base-gl.apk
    13334  01-01-1970 01:00   splits/base-ml.apk
    11350  01-01-1970 01:00   splits/base-nl.apk
    11371  01-01-1970 01:00   splits/base-pl.apk
    11311  01-01-1970 01:00   splits/base-sl.apk
    11428  01-01-1970 01:00   splits/base-tl.apk
    11825  01-01-1970 01:00   splits/base-am.apk
    12685  01-01-1970 01:00   splits/base-km.apk
    12615  01-01-1970 01:00   splits/base-bn.apk
    11223  01-01-1970 01:00   splits/base-in.apk
    12832  01-01-1970 01:00   splits/base-kn.apk
    11958  01-01-1970 01:00   splits/base-mn.apk
    12621  01-01-1970 01:00   splits/base-lo.apk
    11425  01-01-1970 01:00   splits/base-ko.apk
    11395  01-01-1970 01:00   splits/base-ro.apk
    11438  01-01-1970 01:00   splits/base-sq.apk
    13612  01-01-1970 01:00   splits/base-fr.apk
    11647  01-01-1970 01:00   splits/base-ar.apk
    11278  01-01-1970 01:00   splits/base-hr.apk
    12447  01-01-1970 01:00   splits/base-mr.apk
    12943  01-01-1970 01:00   splits/base-or.apk
    14244  01-01-1970 01:00   splits/base-sr.apk
    11316  01-01-1970 01:00   splits/base-tr.apk
    11973  01-01-1970 01:00   splits/base-ur.apk
    11308  01-01-1970 01:00   splits/base-bs.apk
    12525  01-01-1970 01:00   splits/base-as.apk
    13704  01-01-1970 01:00   splits/base-es.apk
    11367  01-01-1970 01:00   splits/base-cs.apk
    11222  01-01-1970 01:00   splits/base-is.apk
    11360  01-01-1970 01:00   splits/base-ms.apk
    11323  01-01-1970 01:00   splits/base-et.apk
    11283  01-01-1970 01:00   splits/base-it.apk
    11550  01-01-1970 01:00   splits/base-lt.apk
    14605  01-01-1970 01:00   splits/base-pt.apk
    11377  01-01-1970 01:00   splits/base-eu.apk
    12409  01-01-1970 01:00   splits/base-gu.apk
    11651  01-01-1970 01:00   splits/base-hu.apk
    12048  01-01-1970 01:00   splits/base-ru.apk
    11616  01-01-1970 01:00   splits/base-lv.apk
    11314  01-01-1970 01:00   splits/base-zu.apk
    11260  01-01-1970 01:00   splits/base-sv.apk
    11539  01-01-1970 01:00   splits/base-iw.apk
    11283  01-01-1970 01:00   splits/base-sw.apk
    12110  01-01-1970 01:00   splits/base-hy.apk
 43370609  01-01-1970 01:00   standalones/standalone-x86_64_xxxhdpi.apk
    11904  01-01-1970 01:00   splits/base-ky.apk
    11430  01-01-1970 01:00   splits/base-az.apk
    13395  01-01-1970 01:00   splits/base-my.apk
    11296  01-01-1970 01:00   splits/base-uz.apk
    15398  01-01-1970 01:00   splits/base-zh.apk
    23877  01-01-1970 01:00   splits/base-en.apk
   107757  01-01-1970 01:00   splits/base-armeabi.apk
   134023  01-01-1970 01:00   splits/base-x86.apk
   127969  01-01-1970 01:00   splits/base-x86_64.apk
 42926206  01-01-1970 01:00   splits/base-master.apk
 21480838  01-01-1970 01:00   splits/base-arm64_v8a_2.apk
 17508309  01-01-1970 01:00   splits/base-armeabi_v7a_2.apk
   217751  01-01-1970 01:00   splits/base-armeabi_2.apk
   311771  01-01-1970 01:00   splits/base-x86_2.apk
   308537  01-01-1970 01:00   splits/base-x86_64_2.apk
  7136923  01-01-1970 01:00   splits/base-armeabi_v7a.apk
  7447993  01-01-1970 01:00   splits/base-arm64_v8a.apk
 42926200  01-01-1970 01:00   splits/base-master_2.apk
    16537  01-01-1970 01:00   toc.pb
---------                     -------
1759809847                     129 files
➜  PROJECT_NAME git:(master) ✗ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, v1.6.1-pre.68, on Mac OS X 10.14.5 18F132, locale en-GB)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] iOS toolchain - develop for iOS devices (Xcode 10.2.1)
[!] Android Studio (version 3.3)
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
[✓] VS Code (version 1.34.0)
[✓] Connected device (1 available)

! Doctor found issues in 1 category.

@jereksel @ndusart
Na verdade, isso é chamado de Assets Targeting e permite que você direcione / divida diretórios em ativos com base na API de gráficos, linguagem e compressão de textura.
Conforme visto aqui: ... / bundletool / model / targeting / TargetedDirectorySegment.java

Em relação ao flutter@master atual do AAB funciona para mim localmente - usando bundletool para testar e instalar em um dispositivo real. Desativei a divisão em densidade e idioma em meu build.gradle então build-apks me deu o seguinte:

  Length      Date    Time    Name
---------  ---------- -----   ----
  6872466  1970-01-01 01:00   splits/base-arm64_v8a.apk
  6726824  1970-01-01 01:00   splits/base-master.apk
 13289718  1970-01-01 01:00   standalones/standalone-armeabi_v7a.apk
 13594392  1970-01-01 01:00   standalones/standalone-arm64_v8a.apk
  6567785  1970-01-01 01:00   splits/base-armeabi_v7a.apk
      429  1970-01-01 01:00   toc.pb
---------                     -------
 47051614                     6 files

Testando no Test Lab, também tenho tudo verde.
Ainda estou esperando a Play Store processar esta versão para testar este canal.

@Tokenyet você conseguiu baixar o aplicativo da Play Store e executá-lo depois de enviar .aab ? Se for esse o caso, você se importaria de colar a saída de flutter doctor ?

Posso baixar o aplicativo da Play Store e executá-lo. Você poderia [tentar] (https://play.google.com/store/apps/details?id=com.bumbystudio.starry_clock). (Editar: Ops, não está funcionando ... da PlayStore)

Abaixo está meu flutter doctor conforme necessário. Espero que tenha ajudado.

[√] Flutter (Canal mestre, v1.6.1-pre.88, no Microsoft Windows [versão 10.0.17134.765], local zh-TW)

[√] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
[√] Android Studio (versão 3.3)
[√] VS Code, edição de 64 bits (versão 1.30.2)
[!] Dispositivo conectado
! Nenhum dispositivo disponível

Este trabalho é bom para mim !

buildTypes {
lançamento {
// TODO: Adicione sua própria configuração de assinatura para a versão de lançamento.
// Assinando com as chaves de depuração por enquanto, então flutter run --release funciona.
SignConfig SignConfigs.debug
}
debug {
ndk {
abiFilters 'armeabi-v7a'
}
}
}

@SPodjasek ainda, precisamos dividir assets/ base na ABI. Como isso pode ser feito atualmente?

Instalei no meu dispositivo e parece que não está funcionando. Tudo que eu consegui foi um
tela preta.

Obrigado,

Purusothaman Ramanujam

Em quinta-feira, 23 de maio de 2019, 18:43, Tokenyet, [email protected] escreveu:

@Tokenyet https://github.com/Tokenyet você conseguiu fazer o download do aplicativo
da Play Store e execute-o após fazer o upload do .aab? Se este for o
caso, você se importaria de colar a saída do médico de vibração?

Posso baixar o aplicativo da Play Store e executá-lo. Você poderia dar isto
uma tentativa
https://play.google.com/store/apps/details?id=com.bumbystudio.starry_clock
.

Abaixo está o meu médico vibrante conforme você precisa. Espero que tenha ajudado.

[√] Flutter (Canal mestre, v1.6.1-pre.88, no Microsoft Windows [versão
10.0.17134.765], local zh-TW)

[√] Conjunto de ferramentas Android - desenvolver para dispositivos Android (versão Android SDK
28.0.3)
[√] Android Studio (versão 3.3)
[√] VS Code, edição de 64 bits (versão 1.30.2)
[!] Dispositivo conectado
! Nenhum dispositivo disponível

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/18494?email_source=notifications&email_token=AAIHDZYY47H6PUQQJYEO4J3PW2J7RA5CNFSM4FFE2B7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWCFLKY#issuecomment-495211947 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAIHDZZXV67JCNVJYLVA3WLPW2J7RANCNFSM4FFE2B7A
.

@ndusart Neste ponto, é impossível - talvez registre uma solicitação de recurso no bundletool e o Google irá considerar a implementação.

@SPodjasek então é isso que estou dizendo, todo esse problema está indo para o lado errado.

Todas as discussões parecem terminar em "mas não se preocupe, quando pudéssemos criar pacotes de aplicativos, tudo ficaria bem", mas não é totalmente o caso agora e em um futuro próximo.
É um pouco decepcionante ver a equipe flutter deixar as pessoas pensarem que é possível dessa forma.

flutter deve ser capaz de fornecer uma maneira de construir facilmente o APK dividido ao fazer a própria divisão ou gerenciar mover os instantâneos da VM para a pasta lib/ e deixar a divisão funcionar (poderíamos então usar pacotes de aplicativos também )

Vamos recapitular:

  1. O Flutter suportará APKs gordos por meio de flutter build apk ... .
  2. Se você quiser experimentar este recurso _ agora_ tente flutter build appbundle no branch master. Se os pacotes de aplicativos não funcionam para o seu caso de uso, então (1) deve abranger os casos restantes.

Ok @blasten, eu olhei no código mestre e os instantâneos foram movidos para a pasta lib:
https://github.com/flutter/flutter/blob/dc28ba8919604ff19ea7cbad8d9400516347b08a/packages/flutter_tools/gradle/flutter.gradle#L470 -L481

Portanto, não se trata apenas de adicionar suporte para pacote de aplicativos. Está mais claro agora.
Um pouco de explicação teria sido apreciado, no entanto, já que foi afirmado que o problema era a pasta de ativos e nenhuma informação foi fornecida, um trabalho foi feito neste sentido, uma vez que este problema e o suporte do pacote de aplicativos são bastante independentes.

Obrigado pelo seu trabalho.

@ndusart - @blasten fez alterações na incorporação do Android para que procure os blobs binários na pasta lib agora, para que você possa agrupar em ambos os tipos, se não me engano ...

Se os instantâneos forem movidos para lib, talvez # 30846 também seja corrigido?

@blasten
Mudei para o canal master, atualizei e construí o appbundle. Infelizmente, o aplicativo falha após o download da loja Google Play com o seguinte logcat

2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings.
2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm.cc(241)] Could not setup VM data to bootstrap the VM from.
2019-05-22 09:42:14.824 6995-6995/? E/flutter: [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance.
2019-05-22 09:42:14.824 6995-6995/? A/flutter: [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.

flutter build appbundle agora está no mestre, alguma pessoa voluntária deseja tentar?
Discutimos para oferecer suporte a uma lista de plataformas em build apk , então você poderia fazer algo assim: flutter build apk --target-platform android-arm,android-arm64

Tenho o mesmo problema, embora ainda não tenha nenhum registro.

Mesmo aqui. Estava tendo erro. Mestre atualizado e executou flutter build appbundle . Livrou-se do erro, mas o aplicativo trava ao ser aberto.

Tentei fazer upload de um appbundle usando a versão master do flutter mais recente para a app store com as alterações mais recentes. O erro de 64 bits se foi agora, mas meu aplicativo trava imediatamente.

O que é realmente estranho é que rodar a versão de 64 bits usando os comandos abaixo funciona bem.
flutter build apk --target-platform android-arm64
flutter install api

Ele só falha quando o aplicativo é instalado por meio do appbundle na appstore. Por enquanto, reverti o appstore de volta para o apk de 32 bits.

Não tenho nada de especial no meu gradle.build

minSdkVersion 21
targetSdkVersion 28
versionCode flutterVersionCode.toInteger ()
versionName flutterVersionName
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
multiDexEnabled true

Estou executando o Flutter (canal mestre, v1.6.4-pre.13, no Mac OS X 10.14.5 18F132, local en-US)

Existe alguma maneira de testar esses pacotes antes de carregá-los na appstore? Este é um problema conhecido no qual o Google está trabalhando ou preciso fazer algumas alterações no meu arquivo Gradle?

@blasten Estou tendo um problema com a ferramenta bundle que não está relacionado a esse problema.

eu recebo
Erro: falha ao iniciar o servidor ADB

Ao correr
build-apks --connected-device --bundle =. / app.aab --output =. / my_app.apks --adb

Eu tenho o adb instalado corretamente. Quando tento adb logcat, ele funciona bem.

Vai ser um comentário longo, mas resolveu completamente o problema

Esta foi a minha solução:

  1. em app gradle
splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }
  1. execute flutter build apk --release --target-platform=android-arm
  2. carregue app-armeabi-v7a-release.apk para a Play Store
  3. incremento versionCode
  4. execute flutter build apk --release --target-platform=android-arm64
  5. carregue app-arm64-v8a-release.apk para a Play Store

A Google Play Store servirá o aplicativo de acordo com a arquitetura do dispositivo. Dispositivos de 32 bits estão felizes, dispositivos de 64 bits estão felizes e estou feliz em saber que o tamanho do meu APK permanece relativamente pequeno, embora ainda atenda às duas arquiteturas.

Se incluirmos suporte para ambas as arquiteturas no mesmo APK, espera-se que o tamanho do seu aplicativo seja de mais de 10 MB

Seguir essas etapas era dar "a compilação do Gradle falhou em produzir um pacote Android." erro
_ Depois de uma hora de depuração, descobri a correção. _

Para criar aplicativos diferentes para x86 e x64, siga estas etapas:

Etapa 1: inclua o snippet de código no arquivo app/build.gradle . O arquivo será semelhante a:

....
    lintOptions {
        disable 'InvalidPackage'
    }

    splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }

    defaultConfig {
....

Etapa 2: crie um apk de lançamento usando flutter build apk --release
Isso criará o apk baseado em x86 na pasta build/app/outputs/apk/app.apk
Envie este apk para a loja do Google Play.
x86 feito até agora

Neste ponto, não execute flutter clean
Eu estava fazendo isso e recebendo erros ao construir o apk x64

Etapa 3: agora abra pubspec.yaml e altere version de
version: 1.0.0+1 a version: 1.0.0+2

O número próximo a + é o código da versão

Etapa 4: agora execute o comando
flutter build apk --release --target-platform=android-arm64

Após a conclusão deste comando, vá para build/app/outputs/apk/release/ . Lá você encontrará um apk com o nome app-arm64-v8a-release.apk . Este é o seu arquivo apk de 64 bits com código de versão diferente.

Agora carregue este apk x64 para a Play Store .... e aqui está. Você carregou os aplicativos x86 e x64 para a Play Store.

Vai ser um comentário longo, mas resolveu completamente o problema

[...]
Para criar aplicativos diferentes para x86 e x64, siga estas etapas:

Etapa 1: inclua o snippet de código no arquivo app/build.gradle . O arquivo será semelhante a:

....
    lintOptions {
        disable 'InvalidPackage'
    }

    splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }

    defaultConfig {
....

Etapa 2: crie um apk de lançamento usando flutter build apk --release
[...]

Concorde com sua resposta. Funciona para mim, embora eu não tenha que seguir a Etapa 1 (usei um build.gradle padrão)

Então, você só precisa incrementar seu número de compilação e versão para que o Google Play aceite.

Ainda estou tendo problemas com flutter build appbundle na minha mão.

Vai ser um comentário longo, mas resolveu completamente o problema

[...]
Para criar aplicativos diferentes para x86 e x64, siga estas etapas:
Etapa 1: inclua o snippet de código no arquivo app/build.gradle . O arquivo será semelhante a:

....
    lintOptions {
        disable 'InvalidPackage'
    }

    splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }

    defaultConfig {
....

Etapa 2: crie um apk de lançamento usando flutter build apk --release
[...]

Concorde com sua resposta. Funciona para mim, embora eu não tenha que seguir a Etapa 1 (usei um build.gradle padrão)

Então, você só precisa incrementar seu número de compilação e versão para que o Google Play aceite.

Ainda estou tendo problemas com flutter build appbundle na minha mão.

Não está funcionando. Estou muito chateado. O aplicativo travou ao tentar implantar no emulador x86, bem como no dispositivo real arm. Tentei com canal mestre / beta / estável. Sem lançamento pronto. Ainda é um obstáculo para nós. O comando Appbundle gera um pacote instalável para jogar, mas durante a execução do aplicativo mostra apenas a tela inicial e, em seguida, congela. Equipe Flutter forneça uma solução clara ou WA.

@mormih obrigado por sua paciência - estamos trabalhando na reprodução. Se não se importar, você poderia me enviar um e-mail ([email protected]) incluindo o seguinte, isso ajudaria:

  • Sua plataforma host que você está usando para construir.
  • O comando que você está usando para construir o aplicativo.
  • Execute o comando de compilação com --bug-report (por exemplo, flutter build appbundle --bug-report ) e anexe o arquivo bugreport.zip associado
  • Anexe o pacote de aplicativos gerado para que possamos tentar executá-lo em dispositivos locais
  • Anexe os resultados de adb bugreport depois de tentar executar o aplicativo

Obrigado!

@tvolkert Também tenho o problema de travar com a seguinte mensagem:

A verificação falhou: vm. Deve ser capaz de inicializar a VM.

Minha plataforma host é um mac e macOS 10.14.5. Você conseguiu reproduzi-lo ou gostaria que eu seguisse as etapas que escreveu acima? Além disso, talvez este deva ter um tíquete dedicado, pois é um problema separado do OP.

@mormih Não tenho certeza, mas você tentou incluir x86 também na lista abi?

include "armeabi-v7a", "arm64-v8a", "x86"

flutter build appbundle (no master) também não funcionou para mim, a tela de abertura travou exatamente como os outros notaram ...

A única solução que encontrei para o lançamento (na Play Store) para 32 e 64 bits até agora é a seguinte. (Parcialmente coberto pelo tópico, mas pode ajudar alguém):

  1. Crie um apk com o filtro v7 + o comando padrão de compilação do apk:
    Em seu arquivo app / build.gradle:
    defaultConfig { ... ndk{ abiFilters "armeabi-v7a" } }
    e então correr
    flutter build apk
    (o padrão é --release)

  2. Aumente o número da sua versão em pubspec.yaml.
    Por exemplo, de version: 1.1.0+6 a version: 1.1.0+7

  3. Crie um apk com o filtro v8 + build com arm64 como plataforma de destino:
    agora atualize o build.gradle como:
    defaultConfig { ... ndk{ abiFilters "arm64-v8a" } }
    e então correr
    flutter build apk --release --target-platform android-arm64

Inclui a sobrecarga de ter que fazer upload de 2 apks (e, assim, criar 2 números de compilação), mas pelo menos parece funcionar e posso liberar para dispositivos de 32 e 64 bits ...

Nota: Abandonei o x86, pois ele envolve apenas um grupo muito pequeno de dispositivos móveis (e potencialmente nenhum dos meus usuários), além disso, não preciso de um build de lançamento no emulador (a depuração é suficiente para o teste). Mas é claro que isso pode não ser o caso de outros.

O método

Em algum lugar nos comentários, alguém deixou isso.

image

Isso tem funcionado para mim e é apenas um código de terminal.
Ele produz 2 arquivos que eu odeio e cria 2 versões.

@ezmegy Obrigado! Você salva meu dia

Obrigado @ezmegy , seu "truque" funciona!

Obrigado @ezmegy !
Gostaria de compartilhar meu fluxo de trabalho atual, que pode ser útil:


Crie alguns sabores de compilação em app/build.gradle por arquitetura

flavorDimensions 'arch'
    productFlavors {
        arm32 {
            dimension 'arch'
            ndk {
                abiFilters 'armeabi-v7a'
            }
        }
        arm64 {
            dimension 'arch'
            ndk {
                abiFilters 'arm64-v8a'
            }
        }

Então posso construir ambos com:
flutter build apk --flavor arm32
e
flutter build apk --flavor arm64 --target-platform android-arm64
sem modificar o gradle em cada construção


Em relação ao código da versão, prefiro definir um por padrão e derivar os outros daquele
Por exemplo, defina arm32 com 1.0.0 + 10000 e gere o código de versão para arm64 que é 1.0.0 + 10001
Deve ser fácil de gerar usando bash (ou dentro de fastfile se você estiver usando fastlane)

Você pode definir o número da compilação usando argumentos --build-number ou via fastlane se estiver usando um

Este script de código de versão me ajuda em CI / CD 😄

CMIIW

Para mim isso funcionou muito bem
https://github.com/flutter/flutter/issues/10728#issuecomment -461375218

Vai ser um comentário longo, mas resolveu completamente o problema

Esta foi a minha solução:

  1. em app gradle
splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }
  1. execute flutter build apk --release --target-platform=android-arm
  2. carregue app-armeabi-v7a-release.apk para a Play Store
  3. incremento versionCode
  4. execute flutter build apk --release --target-platform=android-arm64
  5. carregue app-arm64-v8a-release.apk para a Play Store

A Google Play Store servirá o aplicativo de acordo com a arquitetura do dispositivo. Dispositivos de 32 bits estão felizes, dispositivos de 64 bits estão felizes e estou feliz em saber que o tamanho do meu APK permanece relativamente pequeno, embora ainda atenda às duas arquiteturas.
Se incluirmos suporte para ambas as arquiteturas no mesmo APK, espera-se que o tamanho do seu aplicativo seja de mais de 10 MB

Seguir essas etapas era dar "a compilação do Gradle falhou em produzir um pacote Android." erro
_ Depois de uma hora de depuração, descobri a correção. _

Para criar aplicativos diferentes para x86 e x64, siga estas etapas:

Etapa 1: inclua o snippet de código no arquivo app/build.gradle . O arquivo será semelhante a:

....
    lintOptions {
        disable 'InvalidPackage'
    }

    splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }

    defaultConfig {
....

Etapa 2: crie um apk de lançamento usando flutter build apk --release
Isso criará o apk baseado em x86 na pasta build/app/outputs/apk/app.apk
Envie este apk para a loja do Google Play.
x86 feito até agora

Neste ponto, não execute flutter clean
Eu estava fazendo isso e recebendo erros ao construir o apk x64

Etapa 3: agora abra pubspec.yaml e altere version de
version: 1.0.0+1 a version: 1.0.0+2

O número próximo a + é o código da versão

Etapa 4: agora execute o comando
flutter build apk --release --target-platform=android-arm64

Após a conclusão deste comando, vá para build/app/outputs/apk/release/ . Lá você encontrará um apk com o nome app-arm64-v8a-release.apk . Este é o seu arquivo apk de 64 bits com código de versão diferente.

Agora carregue este apk x64 para a Play Store .... e aqui está. Você carregou os aplicativos x86 e x64 para a Play Store.

Está funcionando para mim também sem a etapa 1. Obrigado a todos. Eu usei filtros ndk ndk {
abiFilters "armeabi-v7a", "x86"
}
no arquivo gradle de compilação. Não sei se é obrigatório ou não. Além disso, segui todos os passos do passo 2 e carreguei dois apk, um para 32 bits e outro para 64 bits.

Anteriormente, eu tinha carregado o appbundle, desta vez carregado os arquivos apk. Trabalhando bem. Eu tenho que verificar com appbundle e também tentando consertar sem fazer o upload de dois apk.

Observação :
Antes de fazer este processo, meu aplicativo travou nos seguintes dispositivos arm-64 bits
Redmi MI,
Redmi 3S Prime
Honor 8x

Trabalhou nos seguintes dispositivos arm-64 bits
Samsung Galaxy J4
Samsung On8

Olá, equipe do Flutter,

Por favor também considere outros mercados de aplicativos, como os da China. Na China, não temos permissão para usar a Google Play Store; em vez disso, temos muitos mercados de aplicativos, como o XiaoMi's, o HuaWei's e o Ali's ... etc.

Nesses mercados de aplicativos, NÃO temos permissão para fornecer versões de apk em arquiteturas diferentes, só podemos fazer upload de UM E SÓ UM apk por versão, e essa versão substituirá o apk da versão anterior. O que significa que a solução atual é usar "armeabi-v7a".

Corrija-me se eu estiver errado, usando "armeabi-v7a", todos os dispositivos de 64 bits estarão executando libflutter.so de 32 bits, e acho que será mais lento.

Portanto, eu sugeriria se a equipe de flutter pode fornecer um método que nos permita construir um apk que inclua libflutter.so de 32 e 64 bits, embora o tamanho do apk seja maior. (Na China, geralmente temos uma velocidade de Internet muito rápida e pagamos pouco para ter planos de uso 4G infinitos, e as pessoas geralmente não se importam com o tamanho do apk)

Olá, equipe do Flutter,

Por favor também considere outros mercados de aplicativos, como os da China. Na China, não temos permissão para usar a Google Play Store; em vez disso, temos muitos mercados de aplicativos, como o XiaoMi's, o HuaWei's e o Ali's ... etc.

Nesses mercados de aplicativos, NÃO temos permissão para fornecer versões de apk em arquiteturas diferentes, só podemos fazer upload de UM E SÓ UM apk por versão, e essa versão substituirá o apk da versão anterior. O que significa que a solução atual é usar "armeabi-v7a".

Corrija-me se eu estiver errado, usando "armeabi-v7a", todos os dispositivos de 64 bits estarão executando libflutter.so de 32 bits, e acho que será mais lento.

Portanto, eu sugeriria se a equipe de flutter pode fornecer um método que nos permita construir um apk que inclua libflutter.so de 32 e 64 bits, embora o tamanho do apk seja maior. (Na China, geralmente temos uma velocidade de Internet muito rápida e pagamos pouco para ter planos de uso 4G infinitos, e as pessoas geralmente não se importam com o tamanho do apk)

No seu caso, você pode fornecer o padrão de 32 bits e vai dar tudo certo, certo?
O aviso de 64 bits é apenas para o Google Play. Acredito que isso não seja um problema para a China.
(Por favor corrija-me se eu estiver errado.)

@ KunalT6569 Acho que a etapa 3 foi declarada por você:

Etapa 3: agora abra pubspec.yaml e altere a versão de
versão: 1.0.0 + 1 para a versão: 1.0.0 + 2

é necessário para permitir o upload de ambos os arquivos apk para o console do Google Play, não é?

Tenho mais uma pergunta - quando os dois arquivos apk estiverem prontos, basta enviá-los por meio da seção App releases\New Release\Browse Files , não é?

@ angel1st Sim, a etapa 3 é necessária, pois o Google play não permite o upload de dois apks com os mesmos códigos de versão.

Para enviar vários apks para o Google Play, referi-me a este vídeo.
https://www.youtube.com/watch?v=rMl_oLlf_g0

PARA SUA INFORMAÇÃO:

Nosso plano atual é lançar um beta usando um dos lançamentos dev recentes nos próximos 10 ou mais dias. Então, nosso plano é esperar até que tenhamos um processo documentado atualizado sobre como enviar no Android que não acione os avisos sobre compilações de 64 bits da Play Store, para ter uma maneira de empacotar um APK que suporte 64 bits e provar podemos lançar a galeria usando esse processo e, assim que tivermos feito isso, seguir o processo de lançamento de um novo beta que, em seguida, enviaremos para estável mais ou menos uma semana depois.

Isso significa que provavelmente teremos um beta no início de junho e um beta no final de junho ou início de julho, que ficará estável logo em seguida.

@Hixie, surgiu outro problema aqui
pacote de aplicativos pelo flutter mais recente (mestre a partir de agora) não gerando versões x86, x86_64
Arquivos produzidos pelo branch master
WinRAR_2019-05-30_02-55-34

Arquivos gerados pela versão antiga com o Android Studio
WinRAR_2019-05-30_03-03-15

O comportamento esperado é incluir as versões x86, x86_64, bem como no arquivo produzido pela nova versão

@canewsin independente deste problema, não fornecemos binários de lançamento x86 (https://github.com/flutter/flutter/issues/9253) - é a "versão antiga" em https://github.com/flutter/ flutter / issues / 18494 # issuecomment -497118805 referindo-se a uma compilação de depuração?

Eu tenho o mesmo problema, construir para 32 bits excluirá dispositivos de 64 bits, embora seja executado neles. Construir para 64 especificando --target-platform android-arm64 funciona em dispositivos de 64 bits, mas trava em dispositivos de 32 bits. Além disso, o Google restringirá o upload de apks para 64 bits em 2019.

Equipe Flutter, resolva este problema básico!

defaultConfig {
....
versionName flutterVersionName
ndk.abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64'
}
// pronto!

Compilei meu aplicativo com o último branch master do flutter e carreguei a Play Store como pacote de aplicativos, mas o aplicativo está travando no dispositivo. Este registro foi retirado do laboratório de teste

05-31 07:50:28.384: D/AndroidRuntime(11036): --------- beginning of crash
05-31 07:50:28.384: E/AndroidRuntime(11036): FATAL EXCEPTION: main
05-31 07:50:28.384: E/AndroidRuntime(11036): Process: in.canews.social, PID: 11036
05-31 07:50:28.384: E/AndroidRuntime(11036): java.lang.RuntimeException: Unable to create application in.canews.social.App: java.lang.NullPointerException: Attempt to get length of null array
05-31 07:50:28.384: E/AndroidRuntime(11036):    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5794)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at android.app.ActivityThread.-wrap1(Unknown Source:0)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1661)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at android.os.Handler.dispatchMessage(Handler.java:105)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at android.os.Looper.loop(Looper.java:164)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at android.app.ActivityThread.main(ActivityThread.java:6541)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at java.lang.reflect.Method.invoke(Native Method)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)
05-31 07:50:28.384: E/AndroidRuntime(11036): Caused by: java.lang.NullPointerException: Attempt to get length of null array
05-31 07:50:28.384: E/AndroidRuntime(11036):    at io.flutter.view.FlutterMain.listLibs(FlutterMain.java:381)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at io.flutter.view.FlutterMain.initAot(FlutterMain.java:412)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at io.flutter.view.FlutterMain.startInitialization(FlutterMain.java:164)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at io.flutter.view.FlutterMain.startInitialization(FlutterMain.java:143)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at io.flutter.app.FlutterApplication.onCreate(FlutterApplication.java:22)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1118)
05-31 07:50:28.384: E/AndroidRuntime(11036):    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5791)
05-31 07:50:28.384: E/AndroidRuntime(11036):    ... 8 more
05-31 07:50:28.392: W/ActivityManager(897):   Force finishing activity in.canews.social/.MainActivity

Doutor Flutter -v

C:\flutter\flutter\bin>flutter doctor -v
[√] Flutter (Channel master, v1.6.7-pre.7, on Microsoft Windows [Version 10.0.17763.503], locale en-IN)
    • Flutter version 1.6.7-pre.7 at C:\flutter\flutter
    • Framework revision 6884146925 (2 days ago), 2019-05-29 12:52:05 -0700
    • Engine revision 8dc3a4cde2
    • Dart version 2.3.2 (build 2.3.2-dev.0.0 e3edfd36b2)


[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at C:\Users\PramUkesh\AppData\Local\Android\sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
    • All Android licenses accepted.

[√] Android Studio (version 3.4)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 35.3.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[√] VS Code (version 1.34.0)
    • VS Code at C:\Users\PramUkesh\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.0.2

[√] Connected device (1 available)
    • Z2 Plus • 2e9087c2 • android-arm64 • Android 9 (API 28)

• No issues found!

@canewsin parece que esse problema foi corrigido em https://github.com/flutter/engine/pull/9078. Em sua árvore Flutter, atualize seu branch master local, git fetch upstream && git merge upstream/master

Depois de ver perguntas repetidas, que já foram respondidas em comentários anteriores, escrevi um pequeno artigo documentando quais opções temos agora https://medium.com/@truongsinh/flutter -android-64-bit-so-what-the-fuss -15da6f8e3a46. Aqui está o TLDR:
1_Awm6pB8jR3wGdHMC4DsatQ

@truongsinh , também estamos finalizando o suporte para usar flutter build appbundle para construir um pacote de aplicativos contendo binários de 32 e 64 bits para implantação na Play Store. Consulte https://github.com/flutter/flutter/issues/31922 para obter mais informações - experimente e nos informe se encontrar algum problema.

@truongsinh , também estamos finalizando o suporte para usar flutter build appbundle para construir um pacote de aplicativos contendo binários de 32 e 64 bits para implantação na Play Store. Consulte # 31922 para obter mais informações - experimente e informe-nos se encontrar algum problema.

Sim, ainda estou esperando flutter build appbundle para produzir o aplicativo que não travou ou travou: D

Sim, ainda estou esperando o appbundle de criação de flutter para produzir o aplicativo que não travou ou travou: D

Reconhecido 🙂. Se você tiver um caso reproduzível desse acontecimento que possamos dar uma olhada, isso seria ótimo. Se você quisesse criar um arquivo .aab não assinado a partir da versão 1.7.1 e enviá-lo para mim por e-mail ([email protected]), eu agradeceria!

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

Eu também estou tendo esse problema.

Quando eu crio um pacote de aplicativos no Android Studios, posso carregá-lo bem no meu simulador, mas ele trava o aplicativo quando faço o download da Play Store

Olá, pessoal, que está usando o Flutter Master Branch e criando pacotes de aplicativos
se você estiver depurando seu aplicativo, seu aplicativo funcionará bem
Algumas falhas de rosto ao baixar da Play Store, se isso acontecer, você deve verificar se o pacote do seu aplicativo está funcionando no seu dispositivo, porque o modo de depuração produz binários JIT e o modo de liberação produz binários AOT.
produza apk do pacote de aplicativos apenas para configuração específica com base no seu dispositivo e desinstale completamente o aplicativo de depuração do seu dispositivo e instale este novo aplicativo de saída do pacote de aplicativos se ele travar, irá travar quando baixado da Play Store ou de outra forma, espero que isso ajude outros. .

Ref para saída para APK de seu pacote de aplicativos da linha cmd
https://developer.android.com/studio/command-line/bundletool

Para sua informação, as falhas nos pacotes de aplicativos são mais bem monitoradas em https://github.com/flutter/flutter/issues/31922. No entanto, postagem cruzada aqui:

Olá a todos,

TLDR:

Identificamos o problema com os travamentos quando baixados 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, para começar, os arquivos .so necessários nunca foram verdadeiras bibliotecas - eles eram apenas blobs binários de dados que carregamos no Dart VM. Portanto, 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).

4. flutter build apk --release --target-platform = android-arm64

Recebo este erro depois de adicionar o snippet de código a build.gradle
Gradle build failed to produce an Android package.

  1. flutter build apk --release --target-platform = android-arm64

Recebo este erro depois de adicionar o snippet de código a build.gradle
Gradle build failed to produce an Android package.

https://developer.android.com/distribute/best-practices/develop/64-bit

Alguém poderia resolver o problema? Eu tenho um aplicativo no flutter que funciona apenas no apk de 32 bits, mas o 64 não funciona ou não instala. Estou testando em um telefone celular de 64 bits

@CgarciaTC consulte https://github.com/flutter/flutter/issues/18494#issuecomment -500101807 para a atualização mais recente

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 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

@tvolkert - neste cenário específico, o que dizer de cada número de versão de lançamento? Pelo que estou ciente, eles devem ser diferentes, para que possamos fazer o upload de ambos para o Google Play. Essa parte é gerenciada de alguma forma, quando os apks são construídos? Se não, como deve ser tratado?

@ angel1st é gerenciado automaticamente quando os APKs são construídos, de acordo com a orientação em https://developer.android.com/studio/build/configure-apk-splits#configure -APK-versions

@tvolkert existe alguma informação sobre quando isso vai

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

@tvolkert Muito obrigado. Qualquer cronograma para colocar isso no Flutter estável?

@ harsha973 você está seriamente marcando e fazendo exatamente a mesma pergunta que ele respondeu a 2 postagens acima da sua. Não apenas ignorante, mas à beira do desrespeito.

@PerLycke, desculpe por isso.

Eu verifiquei o canal master, atualizei o flutter e agora não consigo construir o aplicativo usando o comando:
flutter build apk --release --flavor production -t lib/main.dart
o resultado é:

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

Respostas de problemas semelhantes de StackOverflow não ajudam muito.

@MichaelRFairhurst flutter build apk --release funcionou bem para mim, então talvez as novas atualizações no master também requeiram uma atualização das configurações de sabor.

Eu sei que não é uma resposta, desculpe, mas pelo menos um ponto na direção certa.

Quando a correção será beta?

@derolf , consulte https://github.com/flutter/flutter/issues/18494#issuecomment -498880287 como a atualização mais recente com prazos de destino.

Olá a todos,

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

Ao tentar descobrir essas coisas de 64 bits, estou tendo o mesmo problema que @michalsuryntequiqo e não consigo construir nada agora via CLI. Ele é compilado e executado perfeitamente por meio do Android Studio ....
executar flutter build apk --flavor=dev -t lib/main-dev.dart

[   +3 ms] FAILURE: Build failed with an exception.
[   +1 ms] * What went wrong:
[        ] Execution failed for task ':app:transformNativeLibsWithMergeJniLibsForDevRelease'.
[        ] > More than one file was found with OS independent path 'lib/armeabi-v7a/libapp.so'
[        ] * Try:
[        ] Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
[        ] * Get more help at https://help.gradle.org
[        ] BUILD FAILED in 1m 3s
[ +370 ms] Running Gradle task 'assembleDevRelease'... (completed in 64.0s)
[   +4 ms] "flutter apk" took 69,789ms.
[        ] "flutter apk" took 69,789ms.

médico

Editar:
apenas tentei com o commit antes de 8627ff433b4658195e66b9c0034902116f53d580 e produz o apk com o erro usual Gradle build failed to produce an Android package. por causa de https://github.com/flutter/flutter/issues/24106

@blasten Alguma idéia de como fazer isso funcionar novamente com suas alterações?

Editar 2:
Novo problema aberto para isso: https://github.com/flutter/flutter/issues/34598

Eu li a documentação do flutter hoje e descobri:

Na linha de comando:

Digite cd
(Substituircom o diretório do seu aplicativo.)
Execute o apk flutter build --split-per-abi
(O padrão do comando flutter build é --release.)
Este comando resulta em dois arquivos APK:

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

https://flutter.dev/docs/deployment/android#build -an-apk

@ eugenio-tesio quais códigos de versão são usados, ao usar --split-per-abi ?

Vi na documentação e pensei em publicá-lo aqui. Eu não testei.
Eu executei o comando e não funcionou. Diz:

Não foi possível encontrar uma opção chamada "split-per-abi".

Execute 'flutter -h' (ou 'flutter-h ') para comandos e opções de vibração disponíveis.

doutor palpitante:

Flutter 1.6.3 • canal beta • https://github.com/flutter/flutter.git
Estrutura • revisão bc7bc94083 (4 semanas atrás) • 23/05/2019 10:29:07 -0700
Motor • revisão 8dc3a4cde2
Ferramentas • Dart 2.3.2 (build 2.3.2-dev.0.0 e3edfd36b2)

Executando "flutter pub upgrade" em consumos_app ... 19,8s

Doutor em atividade ...
Resumo médico (para ver todos os detalhes, execute flutter doctor -v):
[√] Flutter (Canal beta, v1.6.3, no Microsoft Windows [Versión 10.0.17134.829], local es-AR)
[√] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
[√] Android Studio (versão 3.4)
[√] IntelliJ IDEA Ultimate Edition (versão 2019.1)
[√] Código VS (versão 1.26.1)
[√] VS Code, edição de 64 bits (versão 1.33.1)
[!] Dispositivo conectado
! Nenhum dispositivo disponível

Acho que essa função estará disponível em breve.

Vi na documentação e pensei em publicá-lo aqui. Eu não testei.
Eu executei o comando e não funcionou. Diz:

Não foi possível encontrar uma opção chamada "split-per-abi".
Execute 'flutter -h' (ou 'flutter -h') para comandos e opções de flutter disponíveis.

doutor palpitante:

Flutter 1.6.3 • canal beta • https://github.com/flutter/flutter.git
Estrutura • revisão bc7bc94 (4 semanas atrás) • 2019-05-23 10:29:07 -0700
Motor • revisão 8dc3a4cde2
Ferramentas • Dart 2.3.2 (build 2.3.2-dev.0.0 e3edfd36b2)
Executando "flutter pub upgrade" em consumos_app ... 19,8s
Doutor em atividade ...
Resumo médico (para ver todos os detalhes, execute flutter doctor -v):
[√] Flutter (Canal beta, v1.6.3, no Microsoft Windows [Versión 10.0.17134.829], local es-AR)
[√] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
[√] Android Studio (versão 3.4)
[√] IntelliJ IDEA Ultimate Edition (versão 2019.1)
[√] Código VS (versão 1.26.1)
[√] VS Code, edição de 64 bits (versão 1.33.1)
[!] Dispositivo conectado
! Nenhum dispositivo disponível

Acho que essa função estará disponível em breve.

Lembre-se de que este é apenas no canal dev / versão 1.7.4 em diante. Você está executando beta channel / versão 1.6.3

Eu apenas tentei (construir e publicar usando Codemagic) e funcionou muito bem. Obrigado!

O Google ainda reclama que eu não estou usando o appbundle. Dado este aviso, publicar apks talvez não faça muito sentido?

Eu usaria o appbundle - mas isso impede que os testes automatizados do Google (gerando o relatório de pré-lançamento) funcionem. Devo abrir uma nova edição para isso?

@nohli Atualizamos os documentos para refletir as últimas novidades sobre app bundles / APKs: https://flutter.dev/docs/deployment/android#building -the-app-for-release.

Sinta-se à vontade para registrar o problema sobre os testes automatizados do Google.

Eu construí meu aplicativo a partir do bundle, mas depois de rodar em dispositivos de 64 bits, diz que libflutter.so está faltando ao construir o aplicativo para dispositivos de 32 e 64 bits. Como adicionar libflutter.so para ambas as arquiteturas em um único arquivo de pacote?

@nohli Atualizamos os documentos para refletir as últimas novidades sobre app bundles / APKs: https://flutter.dev/docs/deployment/android#building -the-app-for-release.

Sinta-se à vontade para registrar o problema sobre os testes automatizados do Google.

@blasten O procedimento fornecido no link não produziu o APK de 64 bits no pacote. Quando fiz o upload do pacote, a Google Play Store apresentou o mesmo erro intacto dizendo que seu APK não é compatível com 64 bits.

@ wal33d006 veja a isenção de responsabilidade no topo da página - ela se aplica apenas a v1.7.4 ou posterior (atualmente canais dev ou master).

@ wal33d006 veja a isenção de responsabilidade no topo da página - ela se aplica apenas a v1.7.4 ou posterior (atualmente canais dev ou master).

@tvolkert Não consigo nem mesmo criar meu aplicativo por meio dos canais dev ou master.

Esta é a minha saída quando crio em canais dev ou master:

Mensagem do compilador:
file: ///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image. dardo: 199 : 38: Erro: O tipo de argumento 'void Function (ImageInfo, bool)' não pode ser atribuído ao tipo de parâmetro 'ImageStreamListener'.

  • 'ImageInfo' vem de ' package: flutter / src / painting / image_stream.dart ' ('file: ///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
  • 'ImageStreamListener' é de ' package: flutter / src / painting / image_stream.dart ' ('file: ///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
    Tente alterar o tipo do parâmetro ou converter o argumento para 'ImageStreamListener'.
    oldImageStream? .removeListener (_handleImageChanged);
    ^
    file: ///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image. dardo: 200 : 32: Erro: O tipo de argumento 'void Function (ImageInfo, bool)' não pode ser atribuído ao tipo de parâmetro 'ImageStreamListener'.
  • 'ImageInfo' vem de ' package: flutter / src / painting / image_stream.dart ' ('file: ///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
  • 'ImageStreamListener' é de ' package: flutter / src / painting / image_stream.dart ' ('file: ///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
    Tente alterar o tipo do parâmetro ou converter o argumento para 'ImageStreamListener'.
    _imageStream.addListener (_handleImageChanged);
    ^
    file: ///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image. dardo: 210 : 34: Erro: O tipo de argumento 'void Function (ImageInfo, bool)' não pode ser atribuído ao tipo de parâmetro 'ImageStreamListener'.
  • 'ImageInfo' vem de ' package: flutter / src / painting / image_stream.dart ' ('file: ///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
  • 'ImageStreamListener' é de ' package: flutter / src / painting / image_stream.dart ' ('file: ///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
    Tente alterar o tipo do parâmetro ou converter o argumento para 'ImageStreamListener'.
    _imageStream? .removeListener (_handleImageChanged);
    ^
    file: ///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image. dardo: 465 : 31: Erro: O tipo de argumento 'Função nula (StringBuffer)' não pode ser atribuído ao tipo de parâmetro 'IterávelFunção()'.
  • 'StringBuffer' é de ' dart: core '.
  • 'Iterable' é de ' dart: core '.
  • 'DiagnosticsNode' vem de ' package: flutter / src / Foundation / diagnostics.dart ' ('file: ///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/foundation/diagnostics.dart ').
    Tente alterar o tipo do parâmetro ou converter o argumento para 'IterableFunção()'.
    informationCollector: (StringBuffer information) {
    ^
    O compilador foi encerrado inesperadamente.

FALHA: a compilação falhou com uma exceção.

  • Onde:
    Linha '/Users/waleed/Developer/flutter-sdk/flutter/packages/flutter_tools/gradle/flutter.gradle' do script: 638

  • O que deu errado:
    A execução falhou para a tarefa ': app: compileflutterBuildReleaseArm '.

    Processo 'command' / Users / waleed / Developer / flutter-sdk / flutter / bin / flutter '' terminado com valor de saída diferente de zero 1

  • Experimentar:
    Execute com a opção --stacktrace para obter o rastreamento da pilha. Execute com a opção --info ou --debug para obter mais saída de log. Execute com --scan para obter informações completas.

  • Obtenha mais ajuda em https://help.gradle.org

FALHA NA CONSTRUÇÃO em 14s
Executando tarefa Gradle 'bundleRelease' ...
Executando tarefa Gradle 'bundleRelease' ... Concluído 15.0s
A tarefa do Gradle bundleRelease falhou com o código de saída 1

@ wal33d006 package:cached_network_image agora é a versão 0.8.0 e você está usando 0.5.1 - parece que ao executar contra a versão mais recente do Flutter, você precisa atualizar sua restrição de versão em seus pubspec.yaml e flutter packages upgrade

@tvolkert, você está dizendo que na v1.7.4 o arquivo libflutter.so é adicionado automaticamente para o dispositivo de 64 bits quando construímos o pacote usando o comando flutter build appbundle ?

@ nimesh1997 sim, embora a versão que o torna estável provavelmente seja uma versão mais recente.

@tvolkert Mudei meu canal para ### canal mestre e também atualizei a versão do pacote ###: cached_network_image para 0.8.0 alterando dentro do pubspec.yaml. Mas ao executar atualização de pacotes flutter. O erro é mostrado abaixo assim:
** Como cached_network_image> = 0.7.0 depende de flutter_cache_manager ^ 0.3.2 que depende de path_provider ^ 0.5.0 + 1, cached_network_image> = 0.7.0 requer path_provider ^ 0.5.0 + 1.

@ nimesh1997 você pode registrar um problema separado e me enviar uma

@tvolkert Quando o flutter versão 1.7.4 estará disponível no canal estável e quando o erro mencionado abaixo for resolvido no flutter versão 1.7.4 por causa desse erro ele não roda em dispositivos de 64 bits (libflutter.so está faltando)?

Esta é a saída que obtenho quando executo o flutter v1.7.4 ou posterior: -

Mensagem do compilador:
file: ///home/zunroof-dev-4/package_flutter/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_image-1.0.0/lib/network. dardo: 75 : 31:
Erro: o tipo de argumento 'Função nula (StringBuffer)' não pode ser atribuído ao tipo de parâmetro 'IterableFunção()'.

  • 'StringBuffer' é de ' dart: core '.
  • 'Iterable' é de ' dart: core '.
  • 'DiagnosticsNode' vem de ' package: flutter / src / Foundation / diagnostics.dart ' ('file: ///home/zunroof-dev-4/package_flutter/flutter/packages/flutter/lib/src/foundation/diagnostics.dart ').
    Tente alterar o tipo do parâmetro ou converter o argumento para 'IterableFunção()'.
    informationCollector: (StringBuffer information) {
    ^
    file: ///home/zunroof-dev-4/package_flutter/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_image-1.0.0/lib/network. dardo: 168 : 65: Erro: O tipo de argumento 'String' não pode ser atribuído ao tipo de parâmetro 'DiagnosticsNode'.
  • 'DiagnosticsNode' vem de ' package: flutter / src / Foundation / diagnostics.dart ' ('file: ///home/zunroof-dev-4/package_flutter/flutter/packages/flutter/lib/src/foundation/diagnostics.dart ').
    Tente alterar o tipo do parâmetro ou converter o argumento para 'DiagnosticsNode'.
    contexto: '$ runtimeType falhou ao carregar $ {instruções.uri}',
    ^
    O compilador foi encerrado inesperadamente.

Erro ao compilar, não gera logs e flutter doctor -v não aponta para erros. O que devo fazer?

Se você estiver implantando o aplicativo na Play Store, é recomendável usar o aplicativo
agrupa ou divide o APK para reduzir o tamanho do APK.
Para gerar um pacote de aplicativos, execute:
flutter build appbundle --target-platform android-arm, android-arm64
Saiba mais em: https://developer.android.com/guide/app-bundle
Para dividir os APKs por ABI, execute:
flutter build apk --target-platform android-arm, android-arm64
--split-per-abi
Saiba mais em:
https://developer.android.com/studio/build/configure-apk-splits#configur
e-abi-split
Inicializando gradle ... 7,4s
Resolvendo dependências ... 4,3s
registerResGeneratingTask está obsoleto, use registerGeneratedResFolders (FileCollection)
registerResGeneratingTask está obsoleto, use registerGeneratedResFolders (FileCollection)
registerResGeneratingTask está obsoleto, use registerGeneratedResFolders (FileCollection)
Executando tarefa Gradle 'assembleRelease' ...
Executando tarefa Gradle 'assembleRelease' ... Concluído 9,0s

A compilação do Gradle falhou ao produzir um pacote Android.

@ leonardop21 tente com

vibração correr -v

@canewsin

OH MEU DEUS. Não tenho a menor ideia do que fazer agora

A compilação do Gradle falhou ao produzir um pacote Android.

0 throwToolExit (pacote: flutter_tools / src / base / common.dart: 28: 3)

1 _buildGradleProjectV2

(pacote: flutter_tools / src / android / gradle.dart: 514: 7)

2 _asyncThenWrapperHelper.

(dardo: async-patch / async_patch.dart: 77: 64)

3 _rootRunUnary (dardo: async / zone.dart: 1132: 38)

4 _CustomZone.runUnary (dardo: async / zone.dart: 1029: 19)

5 _FutureListener.handleValue (dardo: async / future_impl.dart: 126: 18)

6 Future._propagateToListeners.handleValueCallback

(dardo: async / future_impl.dart: 639: 45)

7 Future._propagateToListeners (dardo: async / future_impl.dart: 668: 32)

8 Future._complete (dardo: async / future_impl.dart: 473: 7)

9 _SyncCompleter.complete (dardo: async / future_impl.dart: 51: 12)

10 _AsyncAwaitCompleter.complete (dardo: async-patch / async_patch.dart: 28: 18)

11 _completeOnAsyncReturn (dardo: async-patch / async_patch.dart: 294: 13)

12 runCommandAndStreamOutput (pacote: flutter_tools / src / base / process.dart)

13 _asyncThenWrapperHelper.

(dardo: async-patch / async_patch.dart: 77: 64)

14 _rootRunUnary (dardo: async / zone.dart: 1132: 38)

15 _CustomZone.runUnary (dardo: async / zone.dart: 1029: 19)

16 _FutureListener.handleValue (dardo: async / future_impl.dart: 126: 18)

17 Future._propagateToListeners.handleValueCallback

(dardo: async / future_impl.dart: 639: 45)

18 Future._propagateToListeners (dardo: async / future_impl.dart: 668: 32)

19 Future._completeWithValue (dardo: async / future_impl.dart: 483: 5)

20 Future._asyncComplete.

(dardo: async / future_impl.dart: 513: 7)

21 _rootRun (dardo: async / zone.dart: 1124: 13)

22 _CustomZone.run (dardo: async / zone.dart: 1021: 19)

23 _CustomZone.runGuarded (dardo: async / zone.dart: 923: 7)

24 _CustomZone.bindCallbackGuarded.

(dardo: async / zone.dart: 963: 23)

25 _microtaskLoop (dardo: async / schedule_microtask.dart: 41: 21)

26 _startMicrotaskLoop (dardo: async / schedule_microtask.dart: 50: 5)

27 _runPendingImmediateCallback

(dardo: isolate-patch / isolate_patch.dart: 116: 13)

28 _RawReceivePortImpl._handleMessage

(dardo: isolate-patch / isolate_patch.dart: 173: 5)

Atualizamos nossos documentos para indicar como você pode criar APKs com binários de 32 e 64 bits. https://flutter.dev/docs/deployment/android#building -the-app-for-release.

Use o canal dev : v1.7.9 ou superior. A equipe está trabalhando para promover as últimas mudanças para beta até esta sexta-feira (28/06/2019).

Mensagem do compilador:
file: ///Users/systemgnk/Desktop/flutter/.pub-cache/hosted/pub.dartlang.org/flare_flutter-1.5.2/lib/flare. dardo: 1033 : 18: Erro: O tipo de argumento 'Int32List' não pode ser atribuído ao tipo de parâmetro 'Uint16List'.

  • 'Int32List' é de ' dart: typed_data '.
  • 'Uint16List' é de 'dart: typed_data'.
    Tente alterar o tipo do parâmetro ou converter o argumento em 'Uint16List'.
    índices: _indices, textureCoordinates: _uvBuffer);
    ^
    O compilador foi encerrado inesperadamente.

FALHA: a compilação falhou com uma exceção.

  • Onde:
    Linha '/Users/systemgnk/Desktop/flutter/packages/flutter_tools/gradle/flutter.gradle' do script: 631

  • O que deu errado:
    A execução falhou para a tarefa ': app: compileflutterBuildReleaseArm '.

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

  • Experimentar:
    Execute com a opção --stacktrace para obter o rastreamento da pilha. Execute com a opção --info ou --debug para obter mais saída de log. Execute com --scan para obter informações completas.

  • Obtenha mais ajuda em https://help.gradle.org

FALHA NA CONSTRUÇÃO em 22s
Executando tarefa Gradle 'assembleRelease' ...
Executando tarefa Gradle 'assembleRelease' ... Concluído 23.3s
A tarefa Gradle assembleRelease falhou com o código de saída 1

[✓] Flutter (Channel dev, v1.7.10, no Mac OS X 10.13.6 17G65, localidade en-US)
• Flutter versão 1.7.10 em / Users / systemgnk / Desktop / flutter
• Revisão da estrutura 9a3a7490c8 (2 dias atrás), 25/06/2019 15:59:15 +0200
• Revisão do motor ae8e6d9f46
• Dart versão 2.4.0

[✓] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
• Android SDK em / Users / systemgnk / Library / Android / sdk
• Localização do Android NDK não configurada (opcional; útil para suporte nativo de criação de perfil)
• Plataforma android-28, build-tools 28.0.3
• Binário Java em: / Applications / Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java versão OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)
• Aceita todas as licenças do Android.

[✓] Xcode - desenvolvido para iOS e macOS (Xcode 10.1)
• Xcode em /Applications/Xcode.app/Contents/Developer
• Xcode 10.1, Build versão 10B61
• CocoaPods versão 1.6.0

[✓] Ferramentas iOS - desenvolver para dispositivos iOS
• ios-deploy 1.9.4

[✓] Chrome - desenvolver para a web
• Chrome em / Applications / Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (versão 3.3)
• Android Studio em / Applications / Android Studio.app/Contents
• Plugin Flutter versão 33.3.1
• Plugin Dart versão 182.5215
• Java versão OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)

[✓] Dispositivo conectado (4 disponíveis)
• Android SDK desenvolvido para x86 • emulador-5554 • android-x86 • Android 7.0 (API 24) (emulador)
• iPhone do sistema • 73145c33ee6d180a2db3d4a96b908ceb4c49065b • ios • iOS 12.3.1
• macOS • macOS • darwin-x64 • Mac OS X 10.13.6 17G65
• Chrome • chrome • web-javascript • Google Chrome 75.0.3770.100

• Nenhum problema encontrado!

Ainda estou tendo problemas com a construção de apk.
Eu só estava disponível para construir um apk de 32 bits no canal estável.

Acho que preciso esperar até que a equipe do flutter corrija esse bug, em vez de usar dev ou master channel sdk.

Obrigada.

@JaeyoungChu Consulte 2d-inc / Flare-Flutter # 79

@ctrysbita Obrigado pelo link. Mudei o canal para master e mudei o tipo de _indices de Int32List para Uint16List.
O apk que é carregado na Play Store não tem aviso para 64 bits e está sendo executado após a instalação a partir da página de teste da Play Store.

Tenho outros problemas com sdk de flutter do canal dev, como caixa de diálogo de permissão não pop-up para localização e mapa do google não mostra no ios e não pode mostrar o arquivo de imagem grande por http (imagem de rede em cache). Esses problemas não são certos devido ao canal dev, mas quando eu voltei para o estável e compilei novamente, todos os problemas desapareceram. Não tenho muito tempo para me aprofundar nessas questões, então não tenho 100% de certeza. Desculpe por isso, mas talvez alguém tenha entendido esses problemas.

Esta foi a minha solução:

  1. em app gradle
splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }
  1. execute flutter build apk --release --target-platform=android-arm
  2. carregue app-armeabi-v7a-release.apk para a Play Store
  3. incremento versionCode
  4. execute flutter build apk --release --target-platform=android-arm64
  5. carregue app-arm64-v8a-release.apk para a Play Store

A Google Play Store servirá o aplicativo de acordo com a arquitetura do dispositivo. Dispositivos de 32 bits estão felizes, dispositivos de 64 bits estão felizes e estou feliz em saber que o tamanho do meu APK permanece relativamente pequeno, embora ainda atenda às duas arquiteturas.

Se incluirmos suporte para ambas as arquiteturas no mesmo APK, espera-se que o tamanho do seu aplicativo seja de mais de 10 MB

ONDE? ONDE adicionamos a seção de divisões ao arquivo gradle ?? Eu o adicionei entre flutter {} e dependências {} e ele não criará o primeiro APK como diz:

Revise a configuração do projeto Gradle na pasta android /.

Então, claramente isso não está certo, pois esta é a única alteração que fiz no projeto desde minha última construção.

@ ArtfulDodgerB92 Obrigado pela solução. qual canal você usou para construir apk e versão?

ONDE? ONDE adicionamos a seção de divisões ao arquivo gradle ?? Eu o adicionei entre flutter {} e dependências {} e ele não criará o primeiro APK como diz:

Revise a configuração do projeto Gradle na pasta android /.

Então, claramente isso não está certo, pois esta é a única alteração que fiz no projeto desde minha última construção.

@ ArtfulDodgerB92 deve estar dentro da seção android{} , conforme escrito aqui: https://developer.android.com/studio/build/configure-apk-splits.html

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

alguma notícia sobre um próximo lançamento beta?

@nohli atrasamos o lançamento beta por alguns dias para pegar uma correção (reverter commit) para https://github.com/flutter/flutter/issues/35291. Estamos trabalhando para lançar a versão beta o mais rápido possível.

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

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

Сool como gerar apk versão?

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

Сool como gerar apk versão?

Aqui está a instrução https://flutter.dev/docs/deployment/android

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

Сool como gerar apk versão?

Aqui está a instrução https://flutter.dev/docs/deployment/android

Eu tentei, mas não estou trabalhando aos 32

Eu tentei, mas não estou trabalhando aos 32

O que você quer dizer com 32 ? Como "Posso gerar um apk grande e esse apk está funcionando em um dispositivo de 64 bits, mas travando em um dispositivo de 32 bits"?

Você pode postar o resultado de flutter doctor , seu passo a passo (por exemplo, esta é a etapa 2 do progard https://flutter.dev/docs/deployment/android#step-2---enable- ofuscação-e-minimização), você está gerando APK ou AAB e qual dispositivo está testando?

ainda precisamos colocar
ndk { abiFilters 'armeabi-v7a' , 'x86', 'armeabi' } no gradle não é mais necessário após a correção do beta ??

@ksamj que não é necessário.

Eu tentei, mas não estou trabalhando aos 32

O que você quer dizer com 32 ? Como "Posso gerar um apk grande e esse apk está funcionando em um dispositivo de 64 bits, mas travando em um dispositivo de 32 bits"?

Você pode postar o resultado de flutter doctor , seu passo a passo (por exemplo, esta é a etapa 2 do progard https://flutter.dev/docs/deployment/android#step-2---enable- ofuscação-e-minimização), você está gerando APK ou AAB e qual dispositivo está testando?

Resumo médico (para ver todos os detalhes, execute flutter doctor -v):
[✓] Flutter (Canal beta, v1.7.8 + hotfix.2, no Mac OS X 10.14.5 18F132, local ru-RU)

[✓] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
[✓] Xcode - desenvolvido para iOS e macOS (Xcode 10.2.1)
[✓] Ferramentas iOS - desenvolver para dispositivos iOS
[✓] Android Studio (versão 3.4)
[✓] Dispositivo conectado (1 disponível)

• Nenhum problema encontrado!

Resumo médico (para ver todos os detalhes, execute flutter doctor -v):
[✓] Flutter (Canal beta, v1.7.8 + hotfix.2, no Mac OS X 10.14.5 18F132, local ru-RU)

[✓] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
[✓] Xcode - desenvolvido para iOS e macOS (Xcode 10.2.1)
[✓] Ferramentas iOS - desenvolver para dispositivos iOS
[✓] Android Studio (versão 3.4)
[✓] Dispositivo conectado (1 disponível)

• Nenhum problema encontrado!
Resumo médico (para ver todos os detalhes, execute flutter doctor -v):
[✓] Flutter (Canal beta, v1.7.8 + hotfix.2, no Mac OS X 10.14.5 18F132, local ru-RU)

[✓] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
[✓] Xcode - desenvolvido para iOS e macOS (Xcode 10.2.1)
[✓] Ferramentas iOS - desenvolver para dispositivos iOS
[✓] Android Studio (versão 3.4)
[✓] Dispositivo conectado (1 disponível)

• Nenhum problema encontrado!
construir apk
Fiz tudo conforme as instruções mas não instala em 32 bits

Fiz tudo conforme as instruções mas não instala em 32 bits

Qualquer captura de tela / log mostrando que a instalação do apk de 32 bits no dispositivo de 32 bits não foi bem-sucedida e que modelo de dispositivo é esse?

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!

Fiz tudo conforme as instruções mas não instala em 32 bits

Qualquer captura de tela / log mostrando que a instalação do apk de 32 bits no dispositivo de 32 bits não foi bem-sucedida e que modelo de dispositivo é esse?

obrigado pela ajuda, tentei construir o appbundle e funcionou.

@tvolkert Mesmo problema, verifique. https://github.com/flutter/flutter/issues/31962#issuecomment -509458960

@ nimesh1997 esse problema não tem nada a ver com este. Se você não achou úteis as respostas fornecidas no problema vinculado, talvez possa postar uma pergunta Stackoverflow com o seu problema.

@tvolkert - só para esclarecer - o hotfix acima pode ser usado para construir apks separados de acordo com as instruções do flutter docs , correto?
Portanto, não será necessário fazer nenhuma outra alteração no arquivo gradle, conforme descrito nas soluções parciais anteriores
Obrigado pelo excelente trabalho de você e do restante da equipe e no prazo de entrega!

Acabei de compilar um de meus aplicativos com o hot fix mais recente. Como resultado, o app-production-armeabi-v7a-release.apk compilado não pode ser executado no Galaxy S3 mini (Android OS 4.1.2) - após a tela inicial, o aplicativo fecha sem qualquer notificação.
No entanto, consigo executar com êxito o mesmo apk em 64 telefones, por exemplo, Galaxy S8.
aqui está como eu executo a vibração na linha de comando:

flutter build apk --target = "lib / config / main_production.dart" --flavor = produção --split-per-abi

e aqui está meu flutter doctor -v

[√] Flutter (Canal estável, v1.7.8 + hotfix.2, no Microsoft Windows [Versão 10.0.17763.557], localidade en-US)
• Flutter versão 1.7.8 + hotfix.2 em E: \ DevToolsflutter
• Revisão da estrutura 2e540931f7 (7 dias atrás), 02/07/2019 09:31:07 -0700
• Revisão do motor b1cb0d9e9b
• Dart versão 2.4.0

[√] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 28.0.3)
• Android SDK em E: \ DevTools \ Android \ Sdk
• Localização do Android NDK não configurada (opcional; útil para suporte nativo de criação de perfil)
• Plataforma android-28, build-tools 28.0.3
• ANDROID_SDK_ROOT = E: \ DevTools \ Android \ Sdk
• Binário Java em: E: \ DevTools \ android-studio \ jre \ bin \ java
• Java versão OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
• Aceita todas as licenças do Android.

[√] Android Studio (versão 3.4)
• Android Studio em E: \ DevTools \ android-studio
• Plugin Flutter versão 37.0.1
• Plugin Dart versão 183.6270
• Java versão OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[√] Dispositivo conectado (1 disponível)
• Android SDK desenvolvido para x86 • emulador-5554 • android-x86 • Android 8.1.0 (API 27) (emulador)

• Nenhum problema encontrado!

Além disso - o apk gordo também não pode ser executado - após a instalação (no mesmo dispositivo arm-32) e executá-lo apenas fecha.
Diga-me como proceder e resolver o problema, obrigado!

@ angel1st, é possível que você compartilhe seu arquivo AAB e / ou APK aqui para que possamos ajudá-lo na solução de problemas?

@truongsinh - claro, aqui estão eles:

app-production-releases.zip

Fiz upload de ambos os APKs, embora o suposto problema seja com a versão arm-32, conforme declarado acima.

Pessoal, nesse ínterim, alguém seria tão gentil e diria (se souberem), o que aconteceria depois de 1º de agosto na Google Play Store, caso vocês não tenham a versão arm-64 do seu aplicativo - será que o apk irá parar para ser servido para dispositivos arm64 ou você não será capaz de fazer upload da versão arm32 apenas ou ambos?

@ angel1st Consegui executar o aplicativo (app-production-armeabi-v7a-release.apk) no Android 4.4.2 Galaxy S4. Bom app!

Suspeito que isso seja muito específico para o Galaxy S3 mini / Android OS 4.1.2. Nesse ínterim, solicitei essa configuração para ver se posso reproduzir o problema.

@ angel1st aqui está a fonte mais informativa: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

O requisito [material de 64 bits] não se aplica a:

  • APKs ou pacotes de apps que visam explicitamente Wear OS ou Android TV, que são fatores de forma que atualmente não são compatíveis com o código de 64 bits.
  • APKs ou pacotes de aplicativos que não são distribuídos a dispositivos que executam o Android 9 Pie ou posterior.

A partir de 1º de agosto de 2019:

  • Todos os novos aplicativos e atualizações de aplicativos que incluem código nativo são obrigados a fornecer versões de 64 bits, além das versões de 32 bits, ao publicar no Google Play.

Em outras palavras, os aplicativos continuam a ser distribuídos, embora você não possa carregar uma nova versão do aplicativo existente ou publicar um novo aplicativo sem conformidade.

@ angel1st Consegui reproduzir esse problema em um mini Galaxy S3 executando o sistema operacional Android 4.1.2.

O logcat é:

[ERROR:flutter/fml/platform/posix/native_library_posix.cc(16)] Could not open library 'libapp.so' due to error 'Cannot load library: load_library[1093]: Library 'libapp.so' not found'.
07-10 00:16:50.298 8739-8739/? E/flutter: [ERROR:flutter/fml/platform/posix/native_library_posix.cc(16)] Could not open library 'libapp.so' due to error 'Cannot load library: load_library[1093]: Library 'libapp.so' not found'.
07-10 00:16:50.298 8739-8739/? E/flutter: [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings.
07-10 00:16:50.298 8739-8739/? E/flutter: [ERROR:flutter/runtime/dart_vm.cc(238)] Could not setup VM data to bootstrap the VM from.
07-10 00:16:50.298 8739-8739/? E/flutter: [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance.
07-10 00:16:50.298 8739-8739/? A/flutter: [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.

Eu preenchi https://github.com/flutter/flutter/issues/35838 entretanto.

cc @ jason-simmons

@truongsinh - obrigado pela visão geral.

@blasten - obrigado pelo feedback imediato. Pelo que eu entendi, não há nada que eu possa fazer no caixa eletrônico, exceto monitorar o número 35838 com os dedos cruzados. Será resolvido em algum momento deste mês? Acredito que o mesmo problema aparecerá em qualquer outro apk para Android 4.1.2 compilado com o hot fix mais recente.
Para sua informação - o aplicativo apk compilado com a versão estável anterior do flutter não tem esse problema (S3 mini com Android 4.1.2 é um dos meus dispositivos de teste).

Qualquer outra pessoa recebeu um e-mail do Google hoje, dizendo

"Ação necessária: atualize seus aplicativos para compatibilidade com 64 bits até 1º de agosto de 2019"

embora já publique versões de 32 bits e 64 bits?

Diz

Em 1º de agosto de 2019, todos os aplicativos que usam código nativo devem fornecer uma versão de 64 bits para publicar uma atualização. No momento do envio deste e-mail, pelo menos um de seus aplicativos * ainda não atende ao requisito

* Nota: Esta lista de aplicativos reflete a melhor estimativa do Google a partir do envio deste e-mail. (...)

Eu acho que a "melhor estimativa" do Google não está correta?

Obrigado pela equipe Flutter. Eu atualizo o Flutter e construo em um canal estável e o aviso desaparece.
espero não ter um bug com testadores, mas até agora não encontrei nenhum bug com dispositivo real!

Obrigado Team Flutter, atualizar o Flutter com o hotfix corrige esse problema durante a criação de .aab

Obrigado à equipe de flutter por esta conquista. Agora para continuar programado!

@ angel1st Também estou tendo problemas com alguns dispositivos Samsung.

https://github.com/flutter/flutter/issues/36128

@ abdullayev007 - obrigado! Eu sugiro que você dê uma olhada em # 35838, ele pode estar de alguma forma relacionado.

Fiz tudo conforme as instruções mas não instala em 32 bits

Qualquer captura de tela / log mostrando que a instalação do apk de 32 bits no dispositivo de 32 bits não foi bem-sucedida e que modelo de dispositivo é esse?
IMG-20190710-WA0000

O dispositivo é Samsung M10

@tvolkert Dê-me qualquer solução para corrigir o seguinte problema:
https://github.com/flutter/flutter/issues/36063

Obrigado

Tentei a última versão do flutter do canal dev - v1.8.4. Eu criei um novo projeto também - projeto vanilla flutter e tentei construir uma versão com lançamento assinado a partir dele. Ele cria e o tamanho do aplicativo é de apenas 10,4 MB. Mas tentei todas as etapas acima nesta trilha, nada ajudando. Alguém pode dar um conjunto claro de sequência de etapas para fazer uma construção que podemos enviar para playstore com aab ou apk com emulador e dispositivo local de flutter. Já se passou mais de uma semana, temos um projeto construído em flutter sem mover para prod no android, mas podemos publicar na appstore no ios. Alguma ajuda será ótima.

`[✓] Flutter (Channel dev, v1.8.4, no Mac OS X 10.14.5, localidade en-US)
• Flutter versão 1.8.4 em / Users / muthu / muthu / devapps / flutter
• Revisão da estrutura 954714c967 (7 dias atrás), 02/08/2019 10:10:39 -0700
• Revisão do motor 26368225b5
• Dart versão 2.5.0 (build 2.5.0-dev.1.0 bd049f5b53)

[!] Conjunto de ferramentas Android - desenvolver para dispositivos Android (Android SDK versão 29.0.1)
• Android SDK em ../Library/Android/sdk
• Localização do Android NDK não configurada (opcional; útil para suporte nativo de criação de perfil)
• Plataforma android-29, build-tools 29.0.1
• Binário Java em: / Applications / Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java versão OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
✗ Status da licença do Android desconhecido.
Tente reinstalar ou atualizar seu Android SDK Manager.
Consulte https://developer.android.com/studio/#downloads ou visite https://flutter.dev/setup/#android -setup
para obter instruções detalhadas.

[✓] Xcode - desenvolvido para iOS e macOS (Xcode 10.3)
• Xcode em /Applications/Xcode.app/Contents/Developer
• Xcode 10.3, Build versão 10G8
• CocoaPods versão 1.7.3

[✓] Android Studio (versão 3.4)
• Android Studio em / Applications / Android Studio.app/Contents
• Plugin Flutter versão 38.2.1
• Plugin Dart versão 183.6270
• Java versão OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[✓] Código VS (versão 1.36.1)
• Código VS em / Applications / Visual Studio Code.app/Contents
• Extensão Flutter versão 3.3.0

[✓] Dispositivo conectado (3 disponíveis)
• Android SDK desenvolvido para x86 • emulador-5554 • android-x86 • Android 9 (API 28)
(emulador) `

@muthufmass , registre um novo problema com detalhes do que não está funcionando e como reproduzir a falha. Obrigado!

Alguém pode dar um conjunto claro de sequência de etapas para criar uma versão que podemos enviar para a playstore

https://flutter.dev/docs/deployment/android

Alguém pode dar um conjunto claro de sequência de etapas para criar uma versão que podemos enviar para a playstore

https://flutter.dev/docs/deployment/android

Essas etapas já foram seguidas, não está funcionando na versão do produto. debug build funciona! Eu claramente encontro uma diferença, na compilação de depuração, os arquivos .so de flutter estão presentes, mas não com a versão de lançamento. Esses são alguns, criando problema para instalar o apk no emulador ou em dispositivos com o apk assinado.

@muthufmass , registre um novo problema com detalhes do que não está funcionando e como reproduzir a falha. Obrigado!

Espero ter compartilhado as etapas apagadas acima. Criação de aplicativo fresco usando flutter create - código vanilla com o mais recente flutter sdk. Incapaz de construir uma versão de lançamento, enquanto as versões de depuração funcionam sem problemas. Diferença significativa entre as versões prod e dev do apk no tamanho. Tentei todas as etapas acima, incapaz de construir uma versão de lançamento que funcione. A compilação acontece super rápido e o arquivo vem com menos de 11 MB com o lançamento, enquanto com o apk de depuração vem em torno de 40 MB +. O apk de depuração funciona, enquanto o apk assinado com a liberação do produto nem mesmo instala.

Screen Shot 2019-08-09 at 8 29 12 PM

@muthufmass ao registrar o novo problema, inclua a versão do Android SDK, o modelo do dispositivo, a saída do médico e as etapas a partir de flutter create .

@muthufmass , bem como saída adb logcat.

Este problema foi resolvido - registre um novo problema para que possamos rastreá-lo corretamente.

levantou um tíquete separado agora https://github.com/flutter/flutter/issues/37935

Se você tinha sabores em seu projeto e deseja oferecer suporte a x64 e x32, basta adicionar a pasta jniLibs à sua pasta de sabores e funciona muito bem, como este
image

como posso fazer isso no adobe animate cc
preciso de mais informações

O console do Google Play recentemente começou a desabilitar o botão de distribuição por causa de vários avisos. E um desses avisos é usar apk em vez do arquivo .aab. Existem soluções para fazer arquivo .aab se o projeto foi criado no Android Studio ou Unity. Mas e se o apk foi criado pelo Animate CC ou Haxe / Flash Develop? Existe alguma maneira de converter?

@newapproach não está claro para mim se seu comentário tem algo a ver com Flutter? Você estaria disposto a registrar um novo problema com mais detalhes? Obrigado!

Tenho o mesmo problema - mas flutter.so não está incluído na pasta "armeabi-v7a.
Possui apenas bibliotecas de terceiros para x86 e armeabi-v7a - mas não arm64.
Gostaria de construir flutter apenas para "armeabi-v7a com
ndk {
abiFilters "armeabi-v7a" // também não funciona "armeabi", "x86",
}
e definir como plataforma de destino como @ mravn-google sugere para android-arm.

APK sem especificar o arco e não inclui bibliotecas
screen shot 2018-07-26 at 21 06 53

APK com bibliotecas e nenhuma especificação de braço
screen shot 2018-07-26 at 21 10 30

APK com arco específico e bibliotecas incluídas
screen shot 2018-07-26 at 21 12 58

Alguma sugestão de como depurar etapas adicionais?

Também encontrei este erro, está corrigido ?? Poderia me ajudar?

Eu recomendo perguntar no Stack Overflow, ou abrir um novo bug. Duvido que esse bug fechado seja o lugar certo para ajudar você a resolver o problema acima. Obrigado!

Esta foi a minha solução:

  1. em app gradle
splits {
        // Configures multiple APKs based on ABI.
        abi {
            // Enables building multiple APKs per ABI.
            enable true
            // By default all ABIs are included, so use reset() and include to specify that we only
            // want APKs for armeabi-v7a and arm64-v8a.

            // Resets the list of ABIs that Gradle should create APKs for to none.
            reset()

            // Specifies a list of ABIs that Gradle should create APKs for.
            include "armeabi-v7a", "arm64-v8a"

            // Specifies that we do not want to also generate a universal APK that includes all ABIs.
            universalApk false
        }
    }
  1. execute flutter build apk --release --target-platform=android-arm
  2. carregue app-armeabi-v7a-release.apk para a Play Store
  3. incremento versionCode
  4. execute flutter build apk --release --target-platform=android-arm64
  5. carregue app-arm64-v8a-release.apk para a Play Store

A Google Play Store servirá o aplicativo de acordo com a arquitetura do dispositivo. Dispositivos de 32 bits estão felizes, dispositivos de 64 bits estão felizes e estou feliz em saber que o tamanho do meu APK permanece relativamente pequeno, embora ainda atenda às duas arquiteturas.

Se incluirmos suporte para ambas as arquiteturas no mesmo APK, espera-se que o tamanho do seu aplicativo seja de mais de 10 MB

não funciona .. quando eu vejo na playstore no pixel 2 diz que não é compatível com este dispositivo

Funciona, muitos aplicativos conhecidos têm implantado vários APKs dessa forma e permitem que a Play Store sirva o apropriado para o dispositivo apropriado por um longo tempo.

No entanto, os pacotes de aplicativos são a maneira moderna de fazer isso.

Funciona, muitos aplicativos conhecidos têm implantado vários APKs dessa forma e permitem que a Play Store sirva o apropriado para o dispositivo apropriado por um longo tempo.

No entanto, os pacotes de aplicativos são a maneira moderna de fazer isso.

Não sei por que não está aparecendo no pixel 2 playstore para mim então ... Eu segui exatamente, duas vezes, apenas no caso ...
Usei o pacote de aplicativos e meu aplicativo está travando, portanto, estou procurando alternativas

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que ele foi fechado. Se você ainda estiver enfrentando um problema semelhante, abra um novo bug, incluindo a saída de flutter doctor -v e uma reprodução mínima do problema.

Esta página foi útil?
0 / 5 - 0 avaliações