Flutter: Prend en charge les bundles d'applications contenant des binaires 32 bits et 64 bits

non

J'ai eu le même avertissement. Quelqu'un de l'équipe Flutter pourrait-il commenter ou expliquer la même chose, et que pouvons-nous faire pour nous assurer que l'appbundle généré avec flutter build appbundle --release également le code 64 bits. @zoechi Peux-tu nous en dire quelque chose ?

Je vois aussi ça. Voici une capture d'écran :

Et la documentation "en savoir plus" est ici : https://developer.android.com/distribute/best-practices/develop/64-bit

J'attends avec impatience une réponse de l'équipe Flutter.

J'ai aussi reçu ce message d'avertissement aujourd'hui.

Même problème ici.

Moi aussi

Moi aussi

Existe-t-il encore une solution pour cela?

Regardez ceci : https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

Cela a fonctionné pour moi.

le bouton [démarrer le déploiement vers le test interne] est désactivé dans la page des versions d'applications de la console Google Play (l'écran où le message d'avertissement 64 bits ci-dessus apparaît)

l'exigence du bundle 64 bits est désormais un point d'orgue pour les projets flutter.

/ cc @mklim @cbracken

Il semble que le Play Store ait commencé à émettre un avertissement qui se déclenche si vous utilisez les instructions de publication par défaut de Flutter.
https://flutter.dev/docs/deployment/android

Il est possible de soumettre des APK pour ARM 32 et 64 bits avec Flutter, cela ne nécessite actuellement que quelques étapes supplémentaires. Diverses approches pour résoudre ces problèmes sont discutées dans :
https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

Nous cherchons également en ce moment à voir comment nous devrions au mieux mettre à jour les étapes de modèle/outils/version par défaut pour éviter cet avertissement.

Merci pour votre patience.

@eseidelGoogle - moi si je me trompe, mais je pensais que le point de l' ensemble d'un faisceau d'application devait emballer le tout dans un seul fichier et laisser le Play Store transportons seulement l'APK nécessaire pour chaque utilisateur.

Comme je l'ai souligné dans ma question initiale, j'utilise flutter build appbundle . Dans ce cas, la solution que vous avez proposée ne s'appliquerait pas, non ?

Hier, nous avons essayé Flutter build appbundle et nous recevions des messages d'erreur du Play Store indiquant qu'il s'agissait d'une version de débogage ...

bien sûr, il doit également fonctionner dans les scénarios add2app où les instructions de flutter.dev ne sont pas utilisées, mais à la place Android Studio build->Generate Signed APK est utilisé

Merci de l'avoir qualifié de critique

Nous venons d'en discuter en personne. @tvolkert va trouver quelqu'un pour l'aider à clore ce

Je reçois également cet avertissement, existe-t-il un moyen de passer par défaut à 64 bits ?

Une petite modification de build.gradle peut forcer l'inclusion de bibliothèques natives 64 bits dans les versions apk et aab - jetez un œil ici pour une solution de contournement

Pour l'amour de Google, veuillez nous donner une visibilité sur le nombre de téléphones qui utilisent encore le 32 bits.
Si vous ajoutez des bibliothèques 64 bits et 32 ​​bits, vous augmentez la taille finale de l'apk.

J'ai un projet sans flutter, dans lequel je divise l'APK par ABI, j'ai donc des apks séparés pour 32 bits et 64 bits pour réduire la taille. Maintenant, cette étape semble me forcer à augmenter la taille de l'apk à l'avenir.
Mais pourquoi ?

Je n'ai pas de statistiques sur le nombre de téléphones 32 bits uniquement disponibles en Inde/Afrique... Je suis certain que c'est presque rien en Europe, aux États-Unis et dans certaines parties de l'Asie.
Qu'en est-il de x86 / x86_64 vs armeabi / arm64-v8a ? Avons-nous besoin d'ajouter libflutter.so pour les 4 ABI dans l'apk de production final ?
.. aussi mips ... y a-t-il des téléphones utilisant encore mips ? Seul google le sait.

@VarolOkan Utilisez AAB et laissez Google générer des APK pour toutes les combinaisons ABI et dpi d'écran dont il a besoin.

le bouton [démarrer le déploiement vers le test interne] est désactivé dans la page des versions d'applications de la console Google Play (l'écran où le message d'avertissement 64 bits ci-dessus apparaît)

l'exigence du bundle 64 bits est désormais un point d'orgue pour les projets flutter.

@eseidelGoogle ou n'importe qui - quelqu'un peut-il confirmer si c'est
a) un bouchon de spectacle
ou b) un avertissement jusqu'en août
voir : https://forums.expo.io/t/warning-with-the-google-play-64-bit-requirement/22305
Il indique qu'il y a des cases à cocher sur la gauche pour que cela fonctionne, et si l'avertissement dit août, cela semble être un gros problème si c'est en fait début mai.

Aussi - très utile de savoir s'il n'y a en fait approximativement aucune machine 32 bits et l'utilisation d'un abiFilter à une seule ligne pour le bras 64 bits est une option viable pour prendre en charge 99,5% des utilisateurs ou quelque chose du genre ; J'ai vu quelqu'un nettoyer il y a un an "tous les téléphones sur le marché" étaient en 64 bits... peut-être que cela signifie qu'il y a beaucoup de vieux téléphones ?

Je crois comprendre que ce n'est pas un obstacle, mais plutôt un avertissement commun. Nous avons demandé à @blasten d'examiner ce que nous pouvons faire ici pour que la configuration par défaut de Flutter évite cet avertissement. Je pense que nous aurons des mises à jour dans les prochains jours.

Comme @eseidelGoogle l'a dit, je vais m'occuper de ce problème. En attendant, avez-vous essayé de suivre ces étapes https://github.com/flutter/flutter/issues/18494#issuecomment -489807239 ?

N'est-ce plus un problème ? https://github.com/flutter/flutter/issues/18494#issuecomment -482795450

Ce n'est pas un écueil. J'ai reçu l'avertissement, mais j'ai pu publier mon application pour
le magasin de jeux.

Kr Morten

Le mar. 7 mai 2019 à 17h46, Audrius Karosevicius [email protected]
a écrit:

N'est-ce plus un problème ? #18494 (commentaire)
https://github.com/flutter/flutter/issues/18494#issuecomment-482795450

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/31922#issuecomment-490135779 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA4B4J5BY3BJVIELNEPC4N3PUGP7BANCNFSM4HJU7TZA
.

>

;-)
/Mort

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

Résumer:

1) Plus tôt cette année, Play a annoncé aux développeurs qu'il exigerait que les applications téléchargées sur le magasin fournissent des versions 64 bits à partir d'août (https://android-developers.googleblog.com/2019/01/get-your-apps-ready -pour-64-bit.html). Cette semaine, le Play Store a commencé à afficher un message d'information pour les applications téléchargées pour avertir de l'exigence à venir. Cependant, les exigences du Play Store n'ont pas changé pour le moment.

2) L'exigence de l'APK 64 bits avec laquelle les références d'avertissement peuvent être respectées maintenant avec un petit effort manuel pour modifier les fichiers gradle dans leur projet Flutter : https://github.com/flutter/flutter/issues/18494#issuecomment - 489807239 pour un exemple de comment.

3) Nous travaillons à rendre le comportement par défaut de Flutter conforme aux prochaines mises à jour des directives Play concernant la prise en charge 64 bits sans aucun effort supplémentaire de la part des utilisateurs. Je m'attends à ce que les travaux soient terminés dans les prochains jours/semaines, bien avant les échéances d'août.

Si j'ai raté quelque chose ci-dessus, n'hésitez pas à commenter ou à me contacter. Nous nous excusons de ne pas avoir mis cela à jour avant que Play n'active l'avertissement. Merci à tous pour votre aide et vos retours !

@eseidelGoogle

1. Je ne peux pas publier l'application créée par flutter build apk . Play Store n'accepte pas les versions 32 bits uniquement sur mon profil.
2. La solution de #18494 (commentaire) échoue sur les appareils 32 bits comme OnePlus One.

À mon avis, c'est un écueil.

@eseidelGoogle

1. Résolu. Google Play n'accepte aucune version si l'évaluation et les pays ne sont pas configurés. Seul le message est trompeur.

L'exigence de l'APK 64 bits avec laquelle les références d'avertissement peuvent être respectées maintenant avec un petit effort manuel pour modifier les fichiers gradle dans leur projet Flutter : #18494 (commentaire) pour un exemple de comment.

après quelques bonnes heures d'essais et d'erreurs, je n'étais __pas__ capable de produire un apk ni un appbundle signé contenant un libflutter.so 64 bits

le seul libflutter.so inclus dans le bundle est le
armeabi-v7a (32 bits)
, lors de l'utilisation
Android Studio 3.4
Build # AI-183.5429.30.34.5452501, construit le 10 avril 2019

menu : Construire > Générer un ensemble signé/APK

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

les deux échouent @> Tâche : app:validateSigningRelease ÉCHEC

@ciez Cela a produit un

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

@adriank
Oui cela fonctionne.
compris quel était le problème : "~" dans le chemin d'accès au keystore.jks devait être remplacé par /home/user

désolé pour la fausse alerte.

il semble que chaque lot construit comme celui-ci ne puisse cibler qu'une seule arche au maximum ?

J'attends la mise à jour de Flutter car la solution de contournement vient de casser mes builds.

@mulderpf quelle solution de contournement avez-vous appliquée et comment votre build cassée ?

Voir ce commentaire pour la dernière mise à jour de l'équipe Flutter.

J'ai eu une mise à jour : j'ai ceci qui fonctionne dans ma branche !
La suggestion est d'utiliser flutter build appbundle --release --target-platform=android-arm-all (recommandé pour obtenir le split APK prêt à l'emploi) ou flutter build apk --release --target-platform=android-arm-all dans une future version.

Est-ce que quelqu'un dans le fuseau horaire PST est prêt à l'essayer ? Si tel est le cas, veuillez contacter Gitter ou Slack :)

@blasten Malheureusement, je n'ai pas pu produire d'appbundle avec votre succursale. Gradle échoue d'une manière ou d'une autre sur app:properties , mais en regardant le code, cela semble prometteur.
Avez-vous réussi à vérifier que flutter/engine chargera les instantanés AOT à partir du répertoire ./lib/ ? En regardant le code du moteur, il utilise des actifs partout... Si cela fonctionne, cela résoudra le problème global des App Bundles, car pour l'instant, ils ne prennent pas en charge le ciblage des répertoires d'actifs par ABI.

@SPodjasek correct, il faudrait également une version locale du moteur, donc les classes de l'APK recherchent les nouveaux instantanés.

@blasten J'ai réussi à réparer mon arbre de construction et maintenant je peux créer avec succès un App Bundle qui contient des instantanés AOT dans base/lib/${abi}/

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

Et je me demande s'il suffirait de modifier ça...

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

à quelque chose comme :

getContext().getApplicationInfo().nativeLibraryDir;

Bien sûr, ce ne serait pas si simple, mais pour avoir une idée générale...

Voici comment essayer flutter build appbundle avec le support 32 et 64 bits :

1. Téléchargez flutter.jar depuis https://drive.google.com/open?id=1yAkfhPKfhdd8MwW39qfkZDePc66SMA_z et placez-le sous {flutterInstallationPath}/bin/cache/artifacts/engine/android-arm-release . Pour vérifier le chemin d'installation de Flutter, utilisez which flutter

Si vous souhaitez voir les modifications apportées à FlutterMain.java, consultez : https://github.com/blasten/engine/commit/b3ab9def28a414ffa53bf10ad6a3249f31ed00e3

1. Découvrez le patch de cette branche :

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

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

Faites-moi savoir ce que vous trouvez.

+1

@danysz Au lieu d'écrire +1, si vous aviez voté pour ce problème, cela aurait eu plus de sens (pas de rancune pour vous). Pour les autres, s'ils lisent ce message, veuillez ne pas écrire "moi aussi", "même ici", "+1", à la place, votez pour ce problème.

Merci!

Les applications

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

Cela va à mon appareil physique et à mon appareil 9/10 Test Lab - nous avons un résultat incohérent pour Pixel-Q-beta.

@danysz Au lieu d'écrire +1, si vous aviez voté pour ce problème, cela aurait eu plus de sens (pas de rancune pour vous). Pour les autres, s'ils lisent ce message, veuillez ne pas écrire "moi aussi", "même ici", "+1", à la place, votez pour ce problème.

Merci!

terminé

@blasten En parcourant vos modifications, j'ai constaté que pour les applications existantes, il fallait modifier AndroidManifest.xml

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

Néanmoins, il échoue toujours...

@blasten

git build

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

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

Malheureusement, je n'ai pas pu produire d'appbundle avec vos instructions. Gradle échoue d'une manière ou d'une autre sur app:properties (après un "Building flutter tool..." et quelques téléchargements d'android-arm-*....).

Il semble que le processus de téléchargement ait écrasé flutter.jar

@MoacirSchmidt J'ai eu des problèmes similaires, mais le nettoyage des flutter clean ) et des caches gradle ( ~/.gradle/caches & ${projectRoot}/android/.gradle ) m'a aidé

Pour les personnes ayant un problème lors de la création d'un apk 64 bits.
Ce paramètre a fonctionné pour moi.

build.gradle

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

incrémenter le code de version

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

plus de discussion sur https://github.com/flutter/flutter/issues/18494

flutter build appbundle est maintenant en master, une personne volontaire veut-elle l'essayer ?

Pour les personnes, comme moi, qui ont peur de changer les fichiers gradle - si vous ne voulez que la version 64 bits, flutter build apk --release --target-platform=android-arm64 fonctionne même sans modifier build.gradle.

@blasten J'ai essayé flutter build appbundle dans le canal beta . Lorsque j'essaie de télécharger sur le Play Store, j'obtiens toujours l'erreur 32/64.

Je sais que vous avez dit master mais j'ai encore quelques erreurs sur cette branche. Je voulais juste vous donner cette information !

Je reçois aussi cet avertissement !

Existe-t-il un moyen de créer un ensemble d'applications pour toutes les architectures ?

Une mise à jour sur la façon de le réparer?

Je ferme ce bogue car il fait référence aux bundles d'applications. Si vous passez à la branche principale, vous pouvez utiliser flutter build appbundle pour générer des bundles d'applications prenant en charge les architectures de processeur 32 et 64 bits. Si vous préférez ou ne pouvez pas utiliser les bundles d'applications, suivez ce fil pour une assistance supplémentaire via de gros APK.

@blasten - pourriez-vous s'il vous plaît fournir une sorte d'instructions sur la façon de l'utiliser à partir d'Android Studio ?
Voici ma config flutter actuelle :

Résumé du docteur (pour voir tous les détails, exécutez flutter doctor -v) :
[√] Flutter (Channel stable, v1.2.1, sur Microsoft Windows [Version 10.0.17763.503], locale en-US)
[√] Chaîne d'outils Android - développer pour les appareils Android (Android SDK version 28.0.3)
[√] Android Studio (version 3.4)

Quand ce changement ira-t-il à la branche stable ?

@blasten fonctionne- t-il avec Add2App ?

@blasten comment signer le bundle d'applications créé par flutter build appbundle ?

@blasten est-ce un bon moyen d'utiliser la branche master pour les applications de production ?

@dblokhin, vous pouvez utiliser flutter channel master pour passer au canal principal. Notez que ceci est désormais également disponible sur le canal de développement.

@tvolkert - quel délai sera-t-il fusionné avec la branche stable ?

@angel1st Je serais invité dans environ 3 mois.

@truongsinh - étant donné que le 1er août est dans environ deux mois, je m'attendrais à une adoption beaucoup plus rapide, en fait...

@angel1st c'est déjà dans l'écurie ! je vais en savoir plus...

@angel1st c'est déjà dans l'écurie !

Êtes-vous sûr de cela? L'écurie actuelle est la 1.5.4-hotfix 2 et elle ne génère pas de bundles avec 32 et 64. Ou est-ce que j'ai raté quelque chose ?

@shinayser ce n'est pas encore le cas, désolé. Je vais en savoir plus et mettre à jour le fil. Comme Todd l'a mentionné, le canal master est la seule option à ce stade.

J'ai essayé l'appbundle. J'avais la version 1.6.1-pre de Flutter dans le master
canaliser.

La sortie du bundle était d'environ 12 Mo, ce qui n'a pas généré l'avertissement
et les tailles d'APK individuelles étaient d'environ 7. Jusqu'à présent, tout va bien.

Mais lorsque j'ai ouvert l'application après la mise à jour via Play Store, mon application a
coincé dans l'écran de démarrage.

Je n'avais pas le choix de revenir à flutter build apk qui fonctionnait bien, idk comment
et pourquoi.

Je ne pense donc pas que ce problème soit encore clos, car même si l'avertissement
est parti avec l'appbundle, tout comme l'application elle-même. L'appbundle est
rendant l'application inutile car elle est bloquée dans l'écran de démarrage.

Dans ce cas, n'hésitez pas à me contacter directement sur Gitter : https://gitter.im/flutter/flutter. Si possible, il sera utile d'envoyer le fichier .aab que l'outil a généré.

Je crois que nous avons besoin de l'utilisation documentée d' une manière ou d'une autre. De plus, je pense que cela a fusionné à stable avant la fin du mois de juin est vital si l'équipe Flutter veut garder les développeurs autour.

@angel1st, nous travaillons dur pour que ce travail soit promu à stable ici la fin juin.

Quelques mises à jour :

Nous avons pu reproduire des applications bloquées dans l'écran de démarrage après le déploiement d'un APK à partir d'un bundle d'applications (généré à l'aide de flutter build appbundle partir du canal principal).

Cela semble être causé par notre placement des instantanés AOT ( vm-snapshot-data , vm-snapshot-instr , isolate-snapshot-data , isolate-snapshot-instr ) en tant que bibliothèques dans /lib/{abi}/lib_{snapshot}.so pour obtenir la division ABI pour les bundles d'applications.

EDIT : La cause première s'est avérée être que le code dans l'embedder Android attend un répertoire nommé flutter_assets dans cette ligne , mais ma récente modification pour prendre en charge les bundles d'applications a désactivé la création d'un tel répertoire, ce qui a empêché l'application de démarrer. Ce commit de @jason-simmons https://github.com/flutter/engine/compare/7f4f52f95294...e8db5dfd52ee résout le problème.

Conclusion

Le plan actuel est de permettre à l'outil Flutter de générer des bibliothèques partagées ELF au lieu d'instantanés AOT. Cette fonctionnalité vient d'être ajoutée au SDK Dart dans https://github.com/dart-lang/sdk/commit/af93ebcf4cb55ae5f0f39a183ad2d42ca13ae51f.

Cela signifie que nous obtiendrons une division ABI pour les bundles d'applications et les gros APK en utilisant de vraies bibliothèques.

Je mettrai à jour ce bogue et https://github.com/flutter/flutter/issues/18494 une fois le problème résolu. En attendant, passer un --target-platform à build appbundle vous permettra de créer des bundles d'applications sans déplacer les instantanés AOT vers lib/ .

Quelques mises à jour :

Nous avons pu reproduire des applications bloquées dans l'écran de démarrage après le déploiement d'un APK à partir d'un bundle d'applications (généré à l'aide de flutter build appbundle partir du canal principal).

Cela semble être causé par notre placement des instantanés AOT ( vm-snapshot-data , vm-snapshot-instr , isolate-snapshot-data , isolate-snapshot-instr ) en tant que bibliothèques dans /lib/{abi}/lib_{snapshot}.so pour obtenir la division ABI pour les bundles d'applications. Après tout, les instantanés ne sont pas de vraies bibliothèques et notre hack pour obtenir ce comportement n'a pas fonctionné.

Le plan actuel est de permettre à l'outil Flutter de générer des bibliothèques partagées ELF au lieu d'instantanés AOT. Cette fonctionnalité vient d'être ajoutée au SDK Dart dans dart-lang/ sdk@af93ebc .

Cela signifie que nous obtiendrons une division ABI pour les bundles d'applications et les gros APK en utilisant de vraies bibliothèques.

Je mettrai à jour ce bug et #18494 une fois le problème résolu. En attendant, passer un --target-platform à build appbundle vous permettra de créer des bundles d'applications sans déplacer les instantanés AOT vers lib/ .

@blasten cela fonctionnera-t-il correctement lorsque vous aurez une autre bibliothèque qui utilise également du code natif ? Par exemple : VLC. Il produit quelque .so lorsque nous construisons l'APK.

Oui - vous pouvez utiliser d'autres bibliothèques de code natif dans votre APK.

Dans le nouveau format d'emballage, une application Flutter inclura la bibliothèque du moteur libflutter.so ainsi qu'un autre .so contenant les données d'instantané AOT compilées à partir du code Dart de votre application. L'application peut ajouter d'autres bibliothèques .so sans rapport avec Flutter si nécessaire.

Pour info, la solution au problème de blocage sur l'écran de démarrage devrait se trouver dans la version (à venir) du canal de développement 1.7.0 (https://github.com/flutter/flutter/wiki/Bad-Builds#v161--- v167)

Salut tout le monde. Le correctif du problème de blocage de l'écran de démarrage a atterri sur le canal de développement - vous devriez le voir si vous flutter upgrade à v1.7.0. Veuillez l'essayer et nous faire savoir si vous rencontrez des problèmes avec flutter build appbundle .

@tvolkert Ne fonctionnait pas pour moi auparavant et ne fonctionne pas pour moi maintenant. Ni sur le développement du canal (1.7.0) ni sur le maître du canal (1.7.1). L'application avec flutter build appbundle bloque après sa publication via Play Store et son exécution sur un appareil réel.
Edit: Cela fonctionne maintenant sur le développement de canal (1.7.0) après avoir supprimé l'application de l'appareil et l'avoir réinstallée à partir du Play Store.
Edit2 : Cela ne fonctionne pas. Play Store était un peu plus lent que la normale lors de la distribution de la bonne version. Que puis-je faire pour aider à reproduire?

@masewo pouvez-vous récupérer la pierre tombale de l'appareil, ainsi que la version de Flutter qui fonctionnait dessus à l'époque ?

@jason-simmons @blasten autre chose que vous voudriez aider à retrouver ?

@tvolkert

pierre tombale:

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

battement:

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

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

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

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

@jason-simmons @blasten c'est cette affirmation qui provoque le crash dans le cas de @masewo

@masewo, nous ne sommes pas en mesure de reproduire le plantage de notre côté sans applications - seriez-vous prêt à créer un fichier .aab non signé à partir de la version 1.7.1 qui illustre ce comportement et à me l'envoyer par e-mail (tvolkert@google .com) ? Si c'est le cas, ça m'aiderait énormément !

Pour info, l'annonce suivante a été envoyée à [email protected] concernant notre support 64 bits.

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

@tvolkert est-ce que l'équipe travaille également à rendre https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps compatible avec tous les points que vous énumériez ?

1. Fournir un moyen (par défaut) de créer un ensemble d'applications prenant en charge à la fois 32 bits et 64 bits. (déjà disponible pour tester sur le canal dev)

2. Fournir un moyen (par défaut) de créer un APK qui prend en charge à la fois 32 bits et 64 bits. (en cours)

@truongsinh Oui, voir ce commentaire dans le PR en attente : https://github.com/flutter/flutter/pull/33696#issuecomment -498934359

@masewo et tous les autres : nous avons pu reproduire le crash décrit dans https://github.com/flutter/flutter/issues/31922#issuecomment -498541765 et le traçons.

tldr : accrochez-vous - nous y sommes

Salut tout le monde,

TLDR :

Nous avons identifié le problème des plantages lors du téléchargement depuis le Play Store et travaillons sur un correctif, à livrer dans le même délai que celui décrit ci-dessus dans https://github.com/flutter/flutter/issues/31922#issuecomment -498880614

Explication de haut niveau

Pour ceux que cela intéresse, l'explication un peu longue est qu'avec les appareils exécutant Android Marshmallow ou une version ultérieure, le Play Store détectera les applications qui sont conditionnées en tant que bundles d'applications contenant plusieurs ABI - et il installera ces applications sur l'appareil sous la forme de "split APK". Lorsqu'il le fait, les fichiers .so qu'il contient ne sont pas extraits de l'archive zip APK, ce qui est différent du comportement des APK non divisés. Étant donné que le mécanisme actuel du moteur Flutter

La solution consiste simplement à dlopen les bibliothèques, et Android résout où se trouvent les bibliothèques (c'est-à-dire dans une archive ou non). Cependant, les fichiers .so nécessaires n'ont jamais été de véritables bibliothèques au départ - ils n'étaient que des gouttes binaires de données que nous avons chargées dans la machine virtuelle Dart. Donc, dans le cadre de cela, nous en faisons des bibliothèques ELF (par exemple https://github.com/dart-lang/sdk/commit/6d608fb52bc1926a73d986d73ab228b77cfb7ca2 et https://github.com/flutter/flutter/pull/33696).

Salut tout le monde,

Nous pensons que les correctifs ont tous atterri sur la pointe de l'arbre sur le canal master . Si vous souhaitez les essayer, voici comment :

• flutter build appbundle

  Par défaut, l'App Bundle contient votre code Dart et le runtime Flutter compilé pour armeabi-v7a (32 bits) et arm64-v8a (64 bits)

• flutter build apk --split-per-abi

  Cette commande générera deux APK :

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

• flutter build apk

  Cela se traduira par un gros APK contenant votre code compilé pour toutes les ABI cibles. Ces APK seront plus volumineux que leurs homologues divisés, ce qui obligera l'utilisateur à télécharger des binaires natifs qui ne sont pas applicables à l'architecture de son appareil.

flutter build appbundle fonctionne maintenant pour moi. Merci @tvolkert !

Peut confirmer que cela fonctionne (après être passé au maître) sur plusieurs appareils Android. Quelle bouée de sauvetage, merci.

Super! Merci à @blasten , @jason-simmons et @rmacnak-google - je ne suis que le messager 🙂

Merci à toute l'équipe Flutter et aux contributeurs pour cette réponse si rapide. J'espère que celui-ci arrivera sur le canal bêta d'ici 1,5 mois :)

@tomaszpolanski, le plan est de le faire passer en version bêta d'ici la fin juin et de le stabiliser d'ici début juillet 🙂

@tvolkert existe-t-il un indicateur de commande flutter build appbundle nous pouvons transmettre pour inclure également x86 ?

@athornz pas en mode de sortie atm. Voir : https://github.com/flutter/flutter/issues/9253. Il sera cependant possible d'ajouter des instantanés AOT pour x86_64 dans un proche avenir.

Le passage à la branche master me donne l'erreur suivante. Builds stables mais ne parvient pas à inclure 64 bits dans le bundle de version.

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

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

@xinoxapps , pouvez-vous envoyer la sortie complète de flutter build appbundle -v (en tant que lien gist.github.com s'il vous plaît, pour la lisibilité de ce fil 🙂) ?

@xinoxapps , je n'ai pas pu reproduire ce problème localement. Maintenant, en regardant les avertissements que vous recevez, il semble qu'il y ait une logique de configuration build.gradle , qui peut ou non être à l'origine du problème. Serait-il possible d'arriver à un cas de repro minimal ? par exemple, essayez de supprimer une partie de cette configuration Gradle personnalisée jusqu'à ce que cela fonctionne, puis partagez la cause exacte du problème. Voici comment j'ai défini la saveur:

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

Salut tout le monde,

Ces correctifs sont désormais disponibles dans le canal dev , à la version v1.7.4 ou ultérieure.

Je suis passé aux bundles d'applications et poussé vers le Play Store, et la plupart des utilisateurs semblent satisfaits. Cependant, j'ai deux rapports indiquant que l'application ne démarre pas du tout sur un appareil x86 prenant en charge l'émulation ARM, l'Asus ZenFone 2 ZE551ML : https://www.gsmarena.com/asus_zenfone_2_ze551ml-6917.php. Malheureusement, les utilisateurs n'ont pas été en mesure de fournir la sortie adb logcat. Le nouveau format ELF est-il destiné à fonctionner sur de tels appareils ?

Passer aux canaux master et dev me donne cette erreur avec flutter build appbundle :

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

@darioielardi pouvez-vous inclure des liens gist.google.com avec le résultat de flutter build appbundle -v , ainsi que le contenu de vos fichiers android/build.gradle et android/app/build.gradle ?

@tvolkert bien sûr, https://gist.github.com/darioielardi/f7497398a39b2c12d4ea1767ca6b6e69

Je suis passé aux bundles d'applications et poussé vers le Play Store, et la plupart des utilisateurs semblent satisfaits. Cependant, j'ai deux rapports indiquant que l'application ne démarre pas du tout sur un appareil x86 prenant en charge l'émulation ARM, l'Asus ZenFone 2 ZE551ML : https://www.gsmarena.com/asus_zenfone_2_ze551ml-6917.php. Malheureusement, les utilisateurs n'ont pas été en mesure de fournir la sortie adb logcat. Le nouveau format ELF est-il destiné à fonctionner sur de tels appareils ?

oui, j'ai le même problème. cela fonctionne avec flutter build appbundle et la plupart des appareils exécutent bien mes applications. mais pas pour cet asus

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

@blasten Oui, je comprends que x86 natif n'est pas pris en charge, mais je pense que le problème ici est que les bundles d'applications ARM/ARM64 sont installés par Google Play sur des appareils x86 qui annoncent la prise en charge d'ARM via la traduction, mais les nouveaux appbundles ne le font pas d'une manière ou d'une autre fonctionner correctement sur de tels appareils (peut-être parce que les nouveaux formats ELF confondent le traducteur ARM). Les APK ARM (non ARM64) d'origine semblent cependant fonctionner dessus, comme le confirme le retour à une branche principale de deux semaines (e1a784ae pour être précis) et en notant que les deux utilisateurs qui rencontraient des problèmes ont maintenant mon application fonctionner à nouveau sur leurs appareils ZenFone 2. Cela va m'empêcher de passer à la version 1.7.4.

@xinoxapps , pouvez-vous envoyer la sortie complète de flutter build appbundle -v (en tant que lien gist.github.com s'il vous plaît, pour la lisibilité de ce fil 🙂) ?

Cela fonctionne pour moi maintenant sur le canal de développement. Avez-vous encore besoin d'informations?

@xinoxapps non - heureux d'apprendre que cela fonctionne pour vous.

@darioielardi, le problème est maintenant résolu dans le maître. Veuillez exécuter flutter upgrade dans le canal principal.

@darioielardi, le problème est maintenant résolu dans le maître. Veuillez exécuter flutter upgrade dans le canal principal.

@blasten Je suis passé au master et j'ai eu cette erreur lors de l'exécution de flutter build appbundle
Execution failed for task ':app:transformClassesAndResourcesWithProguardForRelease'.

c'est mon gradle et ma sortie complète https://gist.github.com/julindra/80cd2e588cf11bdd0df3f34239b07409

Salut tout le monde,

Nous visons à obtenir quelques corrections de bogues supplémentaires pour les ajouts à l'application et les versions - et à supprimer une version de développement de v1.7.5 . En tant que tel, nous suspendons la promotion en version bêta pour récupérer ces correctifs. Nous nous attendons toujours à ce que cela soit stable début juillet.

flutter build appbundle fonctionné pour moi. Merci beaucoup @tvolkert .

@julindra ajoutant -ignorewarnings à 'proguard-rules.pro résout ce problème. Nous n'incluons actuellement pas le package android.arch.*. Une autre option consiste à modifier votre android/app/build.gradle et à ajouter les éléments suivants :

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

cc @matthew-carroll

J'ai téléchargé le bundle app.aab sur Play Store. L'avertissement concernant le 64 bits manquant avait disparu, mais l'application s'est écrasée au lancement après l'installation à partir du Play Store. Aucune suggestion?

Est-il également sûr d'utiliser flutter build appbundle pour sortir en production ?

@sulaysumaria pouvez-vous poster le résultat de l'exécution de flutter doctor ?

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

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

! Doctor found issues in 2 categories.

@truongsinh

J'ai également essayé de générer un apk à partir de l'app bundle et de l'installer. Il plante également au lancement.

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

Essayez de passer à la chaîne dev et vérifiez.

J'ai essayé de créer dev canal

Est-il également sûr d'utiliser le canal dev pour la version de production ?

Oops désolé. Je serais plus prudent si c'était pour la production.

Je vais créer des APK pour le moment. Bien que Google suggère de télécharger des bundles au lieu d'apks, ce sera bien si cela est corrigé dans la prochaine version sur la branche stable.

J'ai trouvé ceci en utilisant adb logcat:

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

Je suis sur la chaîne stable .

La solution de https://github.com/flutter/flutter/issues/19865 a fonctionné.

J'ai également dû supprimer la section splits de build.gradle.

L'application fonctionne bien maintenant lorsqu'elle est installée via bundletool. Je vais essayer de télécharger sur Playstore et vérifier si tout se passe bien.

@sulaysumaria le correctif n'est encore disponible que sur la branche master. Si vous êtes sur stable – comme indiqué sur votre sortie flutter doctor

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

le correctif n'est pas appliqué. Vous devez attendre que le correctif soit sur stable si vous voulez compiler avec stable. On dirait que c'est quelque part autour de 1.7.x jusque-là, vous devez télécharger les apk séparément.

Ohh... Merci @pythoneer . Savez-vous quand sera-t-il disponible sur la chaîne stable ?

@sulaysumaria pas de problème. C'est mentionné plusieurs fois dans ce fil

Nous nous attendons toujours à ce que cela soit stable début juillet.

Cela a fonctionné sur la chaîne dev . J'ai utilisé flutter build appbundle --target-platform android-arm,android-arm64 et téléchargé un bundle sur Play Store et cela a parfaitement fonctionné.

@sulaysumaria - vous devez utiliser des instructions déjà préparées avec le canal maître ou dev .

@julindra ajoutant -ignorewarnings à 'proguard-rules.pro résout ce problème. Nous n'incluons actuellement pas le package android.arch.*. Une autre option consiste à modifier votre android/app/build.gradle et à ajouter les éléments suivants :

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

cc @matthew-carroll

Merci. Je viens d'utiliser le canal de développement et d'ajouter -ignorewarnings , cela fonctionne parfaitement.

travaillé pour moi avec flutter build appbundle
https://github.com/flutter/flutter/issues/18494#issuecomment -489807239

@blasten est-il fermable à ce stade, ou reste-t-il du travail ?

@cbracken , je pense que cela peut être fermé maintenant ou après la prochaine version stable.

Envisagez-vous toujours de résoudre le problème d'incompatibilité avec l'appareil ZenFone 2 et les appareils x86 similaires qui permettent l'installation d'applications ARM à partir du Play Store et utilisent libhoudini pour les exécuter ?

J'ai essayé de créer dev canal

Est-il également sûr d'utiliser le canal dev pour la version de production ?

Je n'ai jamais utilisé de branche plutôt que de développement et mes applications fonctionnent de manière transparente. Alors faites confiance à la succursale, elle ne déçoit jamais. @sulaysumaria

@matthewlloyd, l'équipe du Play Store nous a dit qu'il était préférable d'ajouter un binaire x86 explicite plutôt que d'essayer de faire fonctionner nos binaires existants avec le traducteur arm->x86. - Cependant, l'équipe a récemment amélioré le code généré par le compilateur Dart, et je me demande si cela a peut-être permis à la traduction de fonctionner. Essayez-le et faites le moi savoir. Sinon, selon la situation, vous devrez peut-être créer la version JIT pour x86, qui est généralement utilisée pour le débogage/le profilage dans les émulateurs.

@blasten Merci pour l'info. Cela me met un peu dans une impasse parce que je n'ai pas l'un de ces appareils moi-même - juste deux critiques anonymes du Play Store d'utilisateurs mécontents de ZenFone 2 - donc je n'ai aucun moyen de tester. Le risque de casser des choses est trop grand pour pousser une autre version d'appbundle jusqu'à ce que quelqu'un confirme que le code amélioré fonctionne réellement sur ces appareils. À moins qu'il n'y ait un moyen de dire au Play Store d'exclure de tels appareils, je continuerai à publier des versions créées avec une ancienne version de Flutter (et des APK 32 bits), jusqu'à ce qu'elles soient testées et confirmées corrigées par Google, ou confirmées comme n'étant plus un problème. Je suppose que ce ne sera pas le cas tant que davantage d'applications ne seront pas transférées dans le magasin à l'aide du nouveau format appbundle/.so. J'attendrai...

pour ceux qui cherchent encore, voici la solution qui a fonctionné pour moi :

flutter build apk --split-per-abi
n'a pas fonctionné, même après avoir modifié le gradle de construction
de https://flutter.dev/docs/deployment/android#build-an-apk

à la place, utilisez :

1. flutter build appbundle
2. puis téléchargez app.aab

problème résolu pour les 32 et 64 bits, et l'alerte "la version n'est pas conforme à l'exigence Play 64 bits." a disparu.

Merci @juliengit2 , flutter build appbundle fonctionne.

Il convient également de mentionner la version flutter, car j'avais la v1.5.0 jusqu'à présent et cela ne fonctionnait pas.
J'ai dû mettre à jour (actuellement vers la v1.7.9) pour que cela fonctionne.

@PerechicK , par dernier, vous vouliez dire canal stable ou canal de développement ?

Canal DEV, tel qu'il apparaît aujourd'hui ici : https://flutter.dev/docs/development/tools/sdk/releases?tab=windows

Je ne sais toujours pas depuis quelle version ce problème est résolu.

Lorsque j'utilise autre chose que la branche stable, je rencontre l'un de mes plugins en lançant l'erreur "Les méthodes marquées avec @UiThread doivent être exécutées sur le thread principal", qui a été introduite avec ce flutter sdk commit https://github. com/flutter/engine/commit/2c9e37c34e79475bbde7c8163eb5e56cdb9662a1.

Existe-t-il un moyen de créer l'appbundle 64 bits en utilisant la branche stable 1.5.4-hotfix.2 ?

@uj ce problème https://github.com/flutter/flutter/issues/33562 peut être lié à votre erreur si vous utilisez firebase_database .

et pas de 64 bits introduit dans 1.7.4+ selon Flutter Docs

Non, ce n'est pas firebase_database, c'est en fait OneSignal, mais leur seule solution est d'"utiliser la branche stable de Flutter"

Existe-t-il un moyen de créer l'appbundle 64 bits en utilisant la branche stable 1.5.4-hotfix.2 ?

@uj même si vous ne pouvez pas créer d'appbundle 64 bits avec 1.5.4-hotfix.2 , vous pouvez créer 2 apks, un avec 32 bits, un avec 64 bits, téléchargez les deux apks sur Google Store pour résoudre l'avertissement.

L'appbundle Flutter 1.5.4-hotfix.2 cible actuellement Android-arm qui ne construit que du code natif 32 bits ( flutter build appbundle -h ). Pour changer cela, exécutez flutter build appbundle --target-platform=android-arm64 pour changer la cible par défaut.

Ceci est maintenant en direct sur la version bêta, dans la version v1.7.8+hotfix.2

@tvolkert - excellente nouvelle, merci. Seriez-vous plus précis quand nous pourrions nous attendre à ce que le correctif soit disponible dans stable , par exemple une date à laquelle cela se produira?

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

(nous travaillons pour que cela se produise le plus tôt possible)

@tvolkert - étant donné que nous sommes à environ trois semaines de la date limite de Google concernant les apks 64 bits, je m'attendrais également à une date limite de votre part. De plus, en tant que développeurs, nous aurons besoin d'un délai entre votre publication et la date limite mentionnée ci-dessus afin de pouvoir créer, tester et publier nos applications sans déranger nos clients.
En dehors de cela, j'apprécie vraiment les efforts et les résultats des deux derniers mois, mais j'espère que vous pourrez vous mettre à notre place et voir à quoi ressemblent les choses de ce point de vue. Merci pour votre compréhension et tous vos efforts jusqu'à présent !

@ angel1st absolument. Selon l' annonce précédente , nous visons à ce que cela se stabilise d'ici début juillet (donc très bientôt) - je ne peux tout simplement pas prédire la date exacte.

J'ai ce problème dans l'unité 2017.4.20 ou 2019.1.2 , comment puis-je le résoudre ? cette
est en lien de coup: https://stackoverflow.com/questions/56687339/what-is-this-error-in-build-adroid-and-build-app-bundle-in-unity-2017-4-17 s'il vous plaît Aidez moi parce que je suis dans ce problème depuis 2 mois merci

J'espère voir celui-ci résolu au plus vite. Le délai est serré

@DoubleHub, vous pouvez passer au canal bêta pour le résoudre.
Ou attendez la sortie de la version stable le 8 juillet.

@ abc873693 J'ai lu à ce sujet, je pense que j'attendrai la version stable. Je suis heureux que ce problème soit enfin résolu officiellement !

@abc873693 J'ai rencontré des problèmes lors de la tentative de publication d'applications Android sur le Play Store à l'aide du canal _beta_. Les rapports de pré-lancement affichaient des avertissements pour l'accessibilité. Il semble que l'application n'ait pas dépassé l'écran de démarrage. Toutes les captures d'écran de tous les appareils sont restées sur l'écran de démarrage.

La solution pour moi consistait simplement à passer au canal STABLE et à créer l'app-bundle à l'aide de l'indicateur --target-platform.

Salut tout le monde,

v1.7.8+hotfix.2 a été publié sur le canal stable, donc ce correctif est maintenant disponible dans tous les canaux. Merci à tous pour votre patience et votre aide en cours de route !

@tvolkert Merci ! Je viens de confirmer que le constat que j'évoquais ici n'est plus là avec le canal stable !

@tvolkert comment appliquer ce v1.7.8+hotfix.2 sur un projet existant ? Dois-je tout recréer ?

@jaasaria ce problème concerne la création de votre application pour publication. si vous êtes sur stable, vous devrez mettre à niveau votre installation de flutter. le problème signalé ici concerne la création d'un ensemble d'applications selon ce lien

@jaasaria vient d'exécuter : $ flutter channel stable && flutter upgrade

@MaikuB J'ai créé mon fichier src il y a un mois et chaque fois que je construis mon projet, je dois exécuter la commande flutter build appbundle --target-platform=android-arm64 au lieu de flutter build appbundle pour éviter l'erreur Playstore x64.

@dblokhin Je échoué . :) Merci

Merci @juliengit2 , flutter build appbundle fonctionne.

Il convient également de mentionner la version flutter, car j'avais la v1.5.0 jusqu'à présent et cela ne fonctionnait pas.
J'ai dû mettre à jour (actuellement vers la v1.7.9) pour que cela fonctionne.

Merci pour l'avertissement !

J'ai la version 1.7.8 + hotfix.3 flottante, "flutter build appbundle" se traduira par app.aab avec 32 et 64 bits à la fois ?

étrange j'ai essayé avec 1.7.8+hotfix.3 avec channel stable et je reçois à nouveau l'avertissement playstore :

"Cette version n'est pas conforme à l'exigence Google Play 64 bits..."

lors du téléchargement d'un bundle après : _flutter build appbundle_

J'ai également essayé de mettre à niveau le flutter mais le même résultat.
et avec une nouvelle installation de Flutter : même résultat

Voici ma conf :

Une idée??

@juliengit2 Ouvrez le .aab en tant que zip normal, allez dans le dossier base/lib et vérifiez s'il y a des dossiers armeabi-v7a et arm64-v8a

J'ai essayé de le faire avec le dossier lib de mon application "flutter build appbundle" contenant les deux versions v8a et v7a. Puis-je pousser la mise à jour maintenant, je ne veux pas qu'un autre avertissement arrive dans mon e-mail.

Un autre cas similaire d'un APK lointain recevant un avertissement https://github.com/flutter/flutter/issues/18494#issuecomment -509937209

pour ceux qui ont le même problème, j'ai supprimé dans build.gradle :

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

et l'avertissement a disparu.

(si vous conservez les aabifilters, vous obtiendrez toujours "la version n'est pas conforme" même avec _flutter build appbundle_

Salut, j'ai construit mon appbundle avec succès, mais lorsque j'essaie de le télécharger sur le Play Store, j'ai reçu cette erreur...
Pour télécharger un Android App Bundle, vous devez être inscrit à App Signing par Google Play.
Exportez votre clé depuis Android Studio. Dans le menu Générer, sélectionnez Générer un ensemble/APK signé. Sélectionnez l'option Ensemble et appuyez sur Suivant. Sélectionnez Exporter la clé cryptée et appuyez sur Suivant.

j'essaie d'exporter la clé cryptée comme ça, directement depuis le module Android mais je n'ai pas pu terminer le processus car j'obtiens cette erreur

Processus 'commande '/Users/oaacelasu/Documents/flutter/bin/flutter'' terminé avec une valeur de sortie non nulle 1

bref, j'ai supposé que ce n'était pas la bonne méthode... Existe-t-il une autre solution de contournement pour obtenir la clé cryptée pour l'inscription de l'application directement à partir de la commande flutter build appbundle ?

J'ai essayé d'utiliser appbundle dans Playstore,
mais dans Android 6.0 arm 64, il s'est écrasé au démarrage à cause de libflutter.so introuvable, et après avoir vérifié libflutter.so a été inclus dans aab arm 64

@matthewlloyd , j'ai reproduit cela avec un chromebook local (bien que ce chromebook puisse partir en voyage pendant trois semaines lundi. Je dois vérifier). Je pense qu'il _devrait_ se reproduire contre la plupart des Chromebooks x86 - je pense qu'il y en a probablement plus que les téléphones x86.

l'équipe a récemment amélioré le code généré par le compilateur Dart, et je me demande si cela a peut-être permis à la traduction de fonctionner. Essayez-le et faites le moi savoir. Sinon, selon la situation, vous devrez peut-être créer la version JIT pour x86, qui est généralement utilisée pour le débogage/le profilage dans les émulateurs.

@blasten , y a-t-il une version particulière de Dart à laquelle vous pensiez ? J'ai reproduit avec 2.3.1 (avec flutter 1.7.8+hotfix.2) Dois-je tester avec 2.4.0 ?

De plus, j'ai reproduit lorsque nous avons publié une version alpha. Je dois encore chercher comment tester un appbundle sans passer par le play store.

@wreppun Merci pour l'

@matthewlloyd Voici ce qui s'est affiché dans le journal des plantages du Play Store :

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

Cela peut apparaître dans certains de vos (anciens) journaux de plantage si l'un de vos utilisateurs a choisi de partager les statistiques.

L'appareil était un Chromebook HP x360.

Je suis désolé que cela ne fonctionne pas sur 100% des configurations. Nous travaillons pour obtenir une meilleure couverture de test sur une variété de SDK et d'appareils. En attendant, je vais mettre en place quelques tests sur Firebase test lab.

À ce stade, je pense que le moyen le plus efficace pour nous de résoudre tous ces problèmes est probablement de déposer de nouveaux problèmes et de revenir à celui-ci. @tvolkert et moi veillerons à ce que chacun soit examiné, mais cela nous aiderait si nous pouvions les trier dans des compartiments séparés et suivre leurs correctifs individuellement.

Il est très possible que nous ayons besoin de faire de petits ajustements au compilateur Dart, comme nous l'avons fait dans le passé pour les processeurs ou les émulateurs qui ont des bizarreries de processeur spécifiques. Sans tester moi-même sur un Chromebook x86 (ce que je n'ai pas encore fait), je ne peux pas le dire avec certitude.

Ceux qui rencontrent des problèmes pourraient-ils nous aider à régler les problèmes restants en signalant de nouveaux problèmes pour chacun ? Ce serait d'une grande aide pour nous assurer que nous répondons à chacun d'eux. Merci!

@wreppun Merci - J'ai vérifié les rapports de plantage de mon application et aucun des utilisateurs Asus ZenFone 2 concernés n'a rien envoyé.

@blasten Pas de soucis, c'est super. Si quelqu'un peut montrer que les nouveaux appbundles fonctionnent sur un appareil Asus ZenFone 2, ce serait suffisant pour me faire avancer. Malheureusement, je n'y ai pas accès, mais j'espère que les laboratoires de tests mobiles de Google le feront.

@matthewlloyd pas de "Asus ZenFone" sur le laboratoire de test Firebase. Quelle version du SDK ? La plupart du temps, le problème peut être reproduit en exécutant simplement une version spécifique du SDK Android.

Quelle version du SDK ? La plupart du temps, le problème peut être reproduit en exécutant simplement une version spécifique du SDK Android.

??

Bonjour l'équipe Flutter,
Je voudrais insister sur le statut de ce sujet. De mon point de vue, il y a deux problèmes graves :

• La version actuelle de flutter stable 1.7.8+hotfix.3 ne construit pas d'apks stables - au moins split-per-abi ne fonctionne pas comme il se doit - arm32 a un problème de régression et ne peut pas fonctionner sur certains appareils arm32 . On ne sait pas encore quand cela sera corrigé ;
• Date limite du 1er août - dans environ une semaine, en tant que développeurs, nous ne pourrons ni mettre à jour ni publier de nouvelles applications flutter sur Google Play Store - aussi simple que cela. Compte tenu du problème actuel de la version flottante (comme mentionné ci-dessus) et du temps restant, je ne pense pas qu'il soit possible de s'attendre à avoir le correctif dans le canal stable avant la fin du mois (à moins que quelqu'un d'entre vous n'ait une baguette magique :- ))

Compte tenu des deux problèmes ci-dessus, je voudrais suggérer le plan d'urgence suivant, que l'OMI nous servirait le mieux en tant que développeurs :

• Restauration du canal stable flutter à sa version antérieure au hotfix.2
• Reporter la date limite du 1er août de quelques mois - Je comprends que cela nécessitera une certaine escalade du problème, mais j'espère que vous comprendrez à quel point les développeurs ne peuvent pas publier une application flutter

Je ne peux parler qu'en mon nom, mais j'ai des clients avec des contrats et j'ai décidé de passer de React Native à Flutter, car je pensais que Google fournirait un meilleur support pour leurs propres produits. J'ai des projets en cours et des candidatures à soutenir.
Maintenant, je me retrouve dans un cas absurde, lorsque Google m'oblige à sortir la version apk 64 bits et en même temps Google ne me fournit pas l'outil pour le faire (et oui, je sais que l'équipe Flutter n'est pas la même que Google Play équipe mais d'où je viens - vous êtes la même entité commerciale).
Si Google ne livre pas à temps, cela entraînera un fort recul de Flutter, car chaque jour après le 1er août réduira la crédibilité du cadre.
Je m'excuse si mes mots sonnent un peu plus fort, j'espère seulement que vous pourrez vous mettre à ma place pour le moment.

N'importe qui - s'il vous plaît, votez là-dessus, et j'espère que notre voix sera entendue !

Je suis également d'accord avec cela... Mais en tant que plan d'urgence, je suggérerais de ne pas revenir à la version précédente, mais plutôt de passer au canal dev ....

D'après mon expérience personnelle, je n'étais pas non plus à l'aise d'utiliser la chaîne dev départ. Je pensais à coller à stable canal, parce que vous savez, son écurie! ... Mais maintenant j'utilise dev canal et libérant des applications à l' aide de faisceaux d'applications sur la boutique de jeu sans aucun problème .. ..

La situation est quelque chose qui ne devrait pas se produire car les deux sont des produits Google...

Ce que j'ai présenté est juste une solution de contournement plus simple, car vous pouvez commencer à pousser les mises à jour en utilisant des aab s et non des apk s, ce qui est suggéré par Google...

@ angel1st même problème, mêmes problèmes, mêmes chaussures
@sulaysumaria si nous passons au canal de développement, le problème libapp.so sera-t-il résolu ?
Parce que ni le canal maître ne semble fonctionner

Ce que j'ai présenté n'est qu'une solution de contournement plus simple, car vous pouvez commencer à pousser les mises à jour en utilisant aabs et non apks, ce qui est suggéré par Google...

@sulaysumaria - il est pas aussi simple qu'il y paraît, croyez - moi ... Aussi re le passage à canal dev semble conduire à des complications avec des paquets tiers et plugins qui conduiront à un ensemble différent de questions.

@campioncino Je pense que oui parce que je n'ai jamais rencontré ce problème.... Je crée simplement l'appbundle de version et le télécharge sur Play Store... Il n'affiche jamais d'avertissement... et l'application fonctionne bien lorsqu'elle est installée à partir de Play Store ( au moins ce que mon client utilise jusqu'à présent...)

@angel1st , je peux comprendre .. dans ce cas, la

@sulaysumaria Je n'ai jamais rencontré ce problème aussi ... jusqu'à la dernière version.
Je vais essayer mais ce n'est pas si simple à tester, car cela n'arrive que sur certains appareils.

Par exemple sur Samsung Galaxy Tab 2 7.0 P3110, Android 4.2.2, et sur une autre ancienne tablette avec Android 4.1.2

Ohhh... Mon application n'est pas pour les tablettes c'est sûr... Ce serait mieux si vous la testiez une fois...

Salut tout le monde,

Voici l'état actuel :

1. Les indications sont que https://github.com/flutter/flutter/issues/35838 affecte Android 4.2 et versions antérieures, ce qui signifie qu'il affecte environ 3 % des téléphones Android . Nous travaillons avec les personnes concernées sur ce bogue pour identifier l'étendue du correctif et rechercher les éventuels problèmes auxiliaires qui n'affectent probablement que certaines applications (comme un éventuel bogue non lié dans la machine virtuelle Dart qui ne se manifeste pas sur toutes les applications). Sur la base de cette enquête et de sa conclusion, nous déciderons s'il est préférable de patcher la version stable actuelle ou de pousser une nouvelle version à travers les canaux vers la version stable.

2. Si quelqu'un préfère construire à partir d'une version antérieure de Flutter et créer manuellement des APK 32 et 64 bits, il peut le faire en téléchargeant une version antérieure de Flutter ici . Revenir à notre version stable n'est pas une option - cela causerait beaucoup plus de problèmes qu'il n'en résoudrait.

3. Si quelqu'un rencontre des problèmes de construction pour Android _autres_ que https://github.com/flutter/flutter/issues/35838 , veuillez déposer un problème séparé et me mettre en copie, car nous voulons vraiment suivre ces problèmes.

4. Séparément, nous travaillons activement à augmenter notre matrice de test pour mieux détecter les problèmes sur une plus grande variété d'appareils/versions Android plus tôt dans le processus (afin que les rapports de bogues ne soient pas notre première ligne de défense).

@tvolkert - merci pour les commentaires. Juste pour être sûr que nous sommes sur la même longueur d'onde - revenir à la version précédente de Flutter n'a pas de sens avant que la

@angel1st cette option conviendrait-elle à votre cas ?

1. Rétablir le SDK Flutter en v1.5.4-hotfix.2 ( flutter version v1.5.4-hotfix.2 )
2. Créez 2 APK séparés (un sur flutter build apk --target-platform android-arm 32 bits et un sur flutter build apk --target-platform android-arm64 64 bits)
3. Téléchargez ces deux APK sur Google Play Store

Je sais que c'est une solution de contournement, mais au moins cela résout à la fois le problème de stabilité et celui d'"avertissement".

@truongsinh - merci pour la suggestion - cela vaut la peine d'être pris en compte. Auriez-vous la gentillesse de confirmer que l'étape 2 de votre suggestion ci-dessus ne nécessitera pas de modifications comme dans la suggestion précédente, par exemple des app gradle ?

@angel1st tant que vous avez toute l'application en flutter (c'est-à-dire pas https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps), et que vous n'avez rien modifié dans Gradle (c'est-à-dire les fichiers vanille de flutter create ), je pense que nous n'avons rien à faire.

Vous pouvez faire la vérification rapide vous-même (en supposant que la version "3.4.5", suivant https://github.com/flutter/flutter/issues/31922#issuecomment-512292798, mon choix personnel de format pour "build number" est bbxxyyzz , dans lequel bb est juste le pour identifier 32- ou 64-bit, xx est majeur, yy est mineur, zz est patch , mais il existe également d'autres formats recommandés, voir https://developer.android.com/google/play/publishing/multiple-apks#using-a-version-code-scheme):

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

J'inclus les 2 APK ici. Ils fonctionnent avec mon Pixel 2. En regardant également l'analyse APK, nous pouvons clairement voir que chaque APK a différents libflutter.so et 4 fichiers snapshot/aot

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

Juste une note pour le téléchargement de deux apks... Google n'autorise pas le téléchargement de plusieurs fichiers ayant le même numéro de build, vous voudrez donc peut-être modifier le numéro de build avant de créer un apk pour 64 bits.

Juste une note pour le téléchargement de deux apks... Google n'autorise pas le téléchargement de plusieurs fichiers ayant le même numéro de build, vous voudrez donc peut-être modifier le numéro de build avant de créer un apk pour 64 bits.

Ah, c'est vrai que (réf https://developer.android.com/google/play/publishing/multiple-apks#Rules) . Assurez-vous simplement que pour chaque version, le numéro de build de 64 bits est supérieur à 32 bits (j'ai mis à jour mon exemple précédent https://github.com/flutter/flutter/issues/31922#issuecomment-512223030).

Hé, je reçois un message d'erreur lorsque j'essaie de compiler avec appbundle . flutter build apk fonctionne bien mais je souhaite publier une nouvelle version sur Play Store. Quelqu'un peut-il m'aider quelle pourrait en être la raison?

Le résultat de l'exécution de flutter build appbundle --target-platform android-arm,android-arm64 --flavor my_flavor --release -t "bin/main.dart est le suivant :

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

Malheureusement, le message d'erreur n'est pas vraiment utile. Aussi la sortie de Flutter Doctor :

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

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

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

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

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

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

• No issues found!

Éditer
Si j'essaie d'utiliser --split-per abi la construction échoue également avec flutter build apk .

@wreppun Merci - J'ai vérifié les rapports de plantage de mon application et aucun des utilisateurs Asus ZenFone 2 concernés n'a rien envoyé.

@blasten Pas de soucis, c'est super. Si quelqu'un peut montrer que les nouveaux appbundles fonctionnent sur un appareil Asus ZenFone 2, ce serait suffisant pour me faire avancer. Malheureusement, je n'y ai pas accès, mais j'espère que les laboratoires de tests mobiles de Google le feront.

Même moi, je suis confronté à un problème avec Asus Zenfone. Lorsque j'utilise flutter build apk l'application s'exécute sur le téléphone. Mais lorsque je le télécharge sur l'App Store à l'aide d'appbundle, il ne dépasse pas l'écran de démarrage.

Toute solution ??

J'ai essayé de compiler et de publier une nouvelle version d'une de mes applications (app) dans "Play Store", mais j'ai eu quelques problèmes.

1-) Lorsque je télécharge 32 et 64 bits, le site se récuse, à cause de la version 32 bits.

2-) Lorsque je ne télécharge que 32 bits, le site se récuse, car j'ai besoin des 64 bits.

3-) Lorsque je ne télécharge que 64 bits, le site fonctionne, mais mes clients n'ont peut-être pas Android 64 bits. Dans mon téléphone portable par exemple, j'utilise cette même application, mais dans mon téléphone portable, cela ne fonctionne que lorsque j'utilise l'apk 32 bits. Lorsque j'installe l'apk 64 bits dans mon téléphone portable, il s'arrête sur l'écran de démarrage.

Comment dois-je faire maintenant pour libérer ??

Tigerclaw1980 utilise l'option flutter appbundle

Tigerclaw1980 utilise l'option flutter appbundle @MoacirSchmidt

J'ai utilisé Delphi Beta pour créer des fichiers apk pour 32 et 64 bits. je ne sais pas si cette option est disponible

J'ai essayé de compiler et de publier une nouvelle version d'une de mes applications (app) dans "Play Store", mais j'ai eu quelques problèmes.

1-) Lorsque je télécharge 32 et 64 bits, le site se récuse, à cause de la version 32 bits.

2-) Lorsque je ne télécharge que 32 bits, le site se récuse, car j'ai besoin des 64 bits.

3-) Lorsque je ne télécharge que 64 bits, le site fonctionne, mais mes clients n'ont peut-être pas Android 64 bits. Dans mon téléphone portable par exemple, j'utilise cette même application, mais dans mon téléphone portable, cela ne fonctionne que lorsque j'utilise l'apk 32 bits. Lorsque j'installe l'apk 64 bits dans mon téléphone portable, il s'arrête sur l'écran de démarrage.

Comment dois-je faire maintenant pour libérer ??

@ Tigerclaw1980 avez-vous