AFAIK, Flutter fügt libflutter.so derzeit nur einem ausgewählten Plattformordner in der Release-APK hinzu. Die Problemumgehung, die für mich funktionierte, bestand darin, build.gradle zu zwingen, nur 32-Bit zu verwenden (ohne alle 64-Bit-Bibliotheken + Intel).

release {

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

cc @Hixie

@swavkulinski wie würdest du die to apks für den Playstore freigeben?

Ähnlich wie https://github.com/flutter/flutter/issues/18939

Habe das gleiche Problem - aber flatter.so nicht im Ordner "armeabi-v7a" enthalten.
Hat nur Bibliotheken von Drittanbietern für x86 und armeabi-v7a - aber kein arm64.
Möchte Flattern nur für "armeabi-v7a mit bauen
ndk{
abiFilters "armeabi-v7a" // funktioniert auch nicht "armeabi", "x86",
}
und als Zielplattform festlegen, wie @mravn-google android-arm vorschlägt.

APK ohne Arch angeben und keine Bibliotheken einschließen

APK mit Bibliotheken und ohne Armspezifikation

APK mit Arch angeben und Bibliotheken einschließen

Irgendwelche Vorschläge, wie man weitere Schritte debuggen kann?

@xxseabxx ich habe das gleiche Problem

Ich habe das gleiche Problem, das Erstellen für 32-Bit schließt 64-Bit-Geräte aus, es läuft jedoch darauf. Das Erstellen für 64 durch Angabe von --target-platform android-arm64 funktioniert auf 64-Bit-Geräten, stürzt jedoch auf 32-Bit-Geräten ab. Außerdem wird Google 2019 den Upload von APKs auf 64-Bit beschränken.

Flutter-Team, bitte lösen Sie dieses grundlegende Problem!

Flutter-Team, bitte lösen Sie dieses grundlegende Problem!

Liege ich also falsch, wenn ich sage, dass Flutter nur Release-APKs für 32 oder 64 Bit unterstützen kann, aber nicht für beide?

hast du hier glück?

Ich denke, der Kommentar von xxseabxx könnte funktionieren, aber ich habe es nicht ausprobiert ...

Ich habe auch das gleiche Problem.

In all meinen Abhängigkeiten habe ich mindestens ein Paket isoliert, das das Problem verursacht, ich habe einen entsprechenden Fehlerbericht ausgefüllt: https://github.com/azihsoyn/flutter_mlkit/issues/36

Um das Problem zu isolieren, für jede meiner Abhängigkeiten / Plugins:

1) Erstellen Sie ein leeres Flatterprojekt

2) Ersetze main.dart durch

der Paket-Beispielcode (zB: https://pub.dartlang.org/packages/flutter_html_view#-example-tab-)

3) Aktualisieren Sie pubspec.yaml entsprechend

4) laufen

$ flutter build apk

Es stellte sich heraus, dass flatter_mlkit derjenige war, der erstellt wurde.

Ich möchte in der Lage sein, sowohl 32- als auch 64-Architekturen anzusprechen.

Habe das gleiche Problem. --target-platform=android-arm64 funktioniert bei mir, aber ich möchte 32 Bit unterstützen, bis Google den Stecker auf 32 Bit zieht

Flutter-Team, bitte lösen Sie dieses grundlegende Problem!

Viele dritte SDKs funktionieren nicht, ich denke es ist dringend

Ich kann dies reproduzieren, wenn ich Mapbox zur Android-Anwendung hinzufüge.

Ich habe das gleiche Problem auch. Ich verwende BaiduMap in meinem Projekt, Bebug-Modell ist ok, Release-Absturz.
user flatter build apk --release --target-platform=android-arm64 in meinem Telefon ist in Ordnung, aber das 32-Bit-Telefon stürzt ab. Flutter-Team, bitte beheben Sie dieses Problem so schnell wie möglich.

Ähnlich wie bei https://github.com/azihsoyn/flutter_mlkit/issues/36 funktioniert es bei mir, die apk kann sowohl auf 32-Bit- als auch auf 64-Bit-Telefonen ausgeführt werden. @peace2knowledge

Dies sollte ein sehr wichtiges Problem für die Veröffentlichung von APK sein

gibt es eine Lösung für dieses Problem?

1. extrahiere lib/armeabi-v7a/libflutter.so aus $<FLUTTER>/bin/cache/artifacts/engine/android-arm-release/flutter.jar
2. kopiere die Datei armeabi-v7a/libflutter.so in $<project>/android/jniLibs/armeabi-v7a/
3. Ändern Sie $<project>/android/app/build.gradle wie folgt:

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

Für NDK erfordert die 64-Bit-Toolchain minSdkVersion >= 21.

Dies hat mich entsperrt (mit dem richtigen minSdkVersion-Set):

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

Löschen Sie alle abiFilter, bei mir funktioniert es.

@zoechi @Hixie sanfte Beule. Ich stoße auch darauf, wenn ich versuche, eine bestehende App zu integrieren, was derzeit unser wichtigster Anwendungsfall ist.

mindsdk=21, aber Zielplattform noch nicht aktualisiert

@neiljaywarner ein Daumen hoch auf den ersten Kommentar wäre effektiver, um die Priorität zu erhöhen

1. extrahiere lib/armeabi-v7a/libflutter.so aus $<FLUTTER>/bin/cache/artifacts/engine/android-arm-release/flutter.jar
2. kopiere die Datei armeabi-v7a/libflutter.so in $<project>/android/jniLibs/armeabi-v7a/
3. Ändern Sie $<project>/android/app/build.gradle wie folgt:

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

Dies funktionierte bei mir nicht - es generierte ein APK, dem der lib-Ordner fehlte (und somit halb so groß war wie mein vorheriges APK).

Wir haben auch festgestellt, dass, wenn wir die nur 32-Bit-Lösung implementieren, die einige gepostet haben (zB https://medium.com/flutterpub/flutter-app-couldnt-find-libflutter-so-c95ad81cbccd), dies zu einem Nicht- -performante App. Insbesondere bei einem Test auf einem Samsung S6 & S9 sehen wir sehr langsames Scrollen auf einer großen Liste.

Ich glaube nicht, dass das Problem nur der fehlende Arm ist64 libflutter.so .

Ich habe versucht, die fehlende Bibliothek zum APK hinzuzufügen, indem ich für arm64 erstellte, libflutter.so herauskopierte und dann die arm64-Bibliothek neu erstellte und manuell zum APK hinzufügte, neu ausrichtete und neu signierte:

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

Das resultierende APK hat libflutter.so sowohl für armeabi-v7a als auch für arm64-v8a, stürzt jedoch beim Start mit dem folgenden Fehler ab:

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'

Ich nehme an, dass für jeden Bogen auch separate Snapshot-Assets geliefert werden müssen. Im Moment ist das Erstellen von zwei separaten APKs die einzige Lösung, die für mich funktioniert.

Dies ist ein ziemlich beschissenes Problem, auf das man stoßen kann, nachdem man Zeit damit verbracht hat, ein Frontend im Flattern zu schreiben, nur um festzustellen, dass die Veröffentlichung die APK nicht richtig erstellt.

Werde ich auf das gleiche Problem stoßen, wenn ich dazu komme, iOS zu verwenden?

Wann kann dieses Problem gelöst werden?

Ist das nur so, dass unsere Gradle-Dateien nicht wissen, wie sie die richtigen Bits für beide bündeln? @jason-simmons @cbracken könnte es wissen?

Oder könnte @FaisalAbid ?

Ist das nur so, dass unsere Gradle-Dateien nicht wissen, wie sie die richtigen Bits für beide bündeln? @jason-simmons @cbracken könnte es wissen?

Oder könnte @FaisalAbid ?

Ich gehe davon aus, dass Sie mit richtigen Bits mehr meinen als libflutter.so, gemäß diesem Kommentar: https://github.com/flutter/flutter/issues/18494#issuecomment -449557182

Im Moment denke ich, dass die einzige Lösung darin besteht, 32-Bit-APKs zu erstellen, bis es eine Lösung gibt. Beachten Sie jedoch, dass wir bei 32-Bit (wenn auch nicht optimaler Code mit großen Listen) Leistungsprobleme gesehen haben.

Es funktioniert gut für mich, separate 64-Bit- und 32-Bit-APKs zu erstellen und beide auf Google hochzuladen (sie kümmern sich um die automatische Bereitstellung des richtigen APKs für die richtigen Geräte).

Du machst einen Build mit abiFilters auf armeabi-v7a und --target-platform=android-arm , lädst dieses APK hoch und machst dann einen weiteren Build mit abiFilters auf arm64-v8a und --target-platform=android-arm64 und laden Sie diese ebenfalls hoch.

Beachten Sie, dass Sie für jedes APK auch einen anderen Versionscode verwenden müssen. Fügen Sie also etwas in den Versionscode ein, um anzugeben, dass es sich um 64 oder 32 Bit handelt, genau wie bei der DPI- oder API-Ebene.

Derzeit ist die beste Option, abiFilters bedingt von der Zielplattform aus zu setzen

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

Das Problem, das ich habe, ist, dass ich jetzt zwei APKs mit unterschiedlichen Versionscodes hochladen muss
Die eigentliche Lösung hierfür besteht darin, Android-Bundles mit mehreren Zielplattformen erstellen zu können. App Bundles befindet sich derzeit in Flatter Master, aber ich konnte es dafür nicht zum Laufen bringen

Der Play Store wird ab dem 1. August 64 Bit benötigen.

Angenommen, es wird noch 32-Bit-Geräte geben, die unsere Apps nach dem 1. August ausführen möchten, wie stellen Sie dann sicher, dass 32-Bit UND 64-Bit in Release-Builds enthalten sind?

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

_Alle neuen Apps und App-Updates, die nativen Code enthalten, müssen beim Veröffentlichen auf Google Play zusätzlich zu den 32-Bit-Versionen auch 64-Bit-Versionen bereitstellen._

Diese Anforderung lässt sich mit Flutter-Apps derzeit problemlos erfüllen, indem einfach zwei APKs erstellt werden – eine für 32-Bit-Geräte und eine für 64-Bit-Geräte – und beide als Teil derselben Version hochgeladen werden. Google Play stellt dem entsprechenden Gerät automatisch das entsprechende APK zur Verfügung. Ich mache das und es funktioniert gut. Ich stimme anderen Kommentatoren zu, dass es nicht _ideal_ ist, aber IMO ist es wirklich kein großes Problem, dies zu einem Teil Ihres Workflows zu machen.

Es wäre toll, wenn dies in naher Zukunft behoben werden könnte. Der Multi-APK-Ansatz ist nur eine vorübergehende Lösung, bis Flutter APKs mit mehreren .so-Architekturversionen erstellt, genau wie andere Android-Projekte.

Es erfordert viel manuelles Handling (Versionscodes, Build-System, Automatisierung) und Android App Bundles sollten Entwicklern die manuellen Build-Schritte abnehmen.

Derzeit werden in dieser Ausgabe nur 32- und 64-Bit-Versionen erwähnt, aber es gibt auch x86, x64 und einige Entwickler in China sprechen immer noch über die Unterstützung von Mips.

Sollte Flattern nicht so viele der 7 Android-Architekturen mit der kleinsten APK-Größe wie möglich unterstützen?

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

@MarcelEdward Es sollte - aber IMHO ist die APK-Größe nicht der wichtigste Aspekt, da Android jetzt App Bundles (aab) vollständig unterstützt und Endbenutzer sowieso einen optimierten Build für ihr Telefon herunterladen.

Für die Größe einer plattformspezifischen APK, die so optimiert/klein wie möglich sein sollte.

Während der Entwicklung kann es schmerzhaft sein, jedes Mal, wenn Sie den nativen Code ändern, ein APK in voller Größe neu zu installieren. Ein Trick besteht darin, abifilter zu verwenden, um den Debug-Build auf die Architektur Ihres Testtelefons zu beschränken. Ich bin mir jedoch nicht sicher, ob dies jetzt so relevant ist, da Flutter das Hot Reload unterstützt.

https://github.com/flutter/flutter/issues/17829 Geht um die aap App Bundels, aber ich kann beim Kompilieren nur 32bit finden Mit flatter build apk

Wenn ich also richtig verstehe, müssen wir zwei verschiedene Versionen erstellen, mit mindestens 32 und 64, beide hochladen und dann wird die App-Stre auf wundersame Weise eine AAP erstellen, damit der Verbraucher die optimierte Version für seine spezifische Architektur erhält

@MarcelEdward Der Play Store erstellt kein App Bundle. Es stellt dem Gerät nur das entsprechende APK basierend auf der Gerätearchitektur bereit. Dies wurde schon lange vor der Einführung von App Bundles unterstützt, nicht nur für die Architektur, sondern auch für Bildschirmgröße/Auflösung, API-Ebene und andere Unterscheidungsmerkmale. Sie können mehr über das lesen hier .

Sie können mit einem Blick auf die 13 Varianten von Google Maps ein gutes Beispiel dafür zu sehen hier (beachten Sie, dass APKMirror nichts mit dieser Funktionalität zu tun hat , andere als eine einfache Möglichkeit ist , um eine Auflistung der Varianten für eine gegebene Anwendung zu bekommen). Der Play Store bietet aus diesen Varianten die passende APK für Ihr Gerät basierend auf seinen Eigenschaften an.

Wenn Sie ein App Bundle verwendet haben, müssen Sie das Bundle nur einmal hochladen, anstatt mehrere APKs hochzuladen, aber mein Verständnis ist, dass der Play Store dann die verschiedenen APK-Varianten für Sie generiert, also ist das Endergebnis ähnlich, aber es ist weniger Arbeit damit Sie sich automatisieren können. (App Bundles unterstützen auch die neuen dynamisch geladenen Module, aber das ist eine andere Geschichte.)

Es scheint also, dass die gewünschte Funktion hier in der Lage ist, flutter build mit zwei --target-platform Argumenten auszuführen und flutter automatisch beide Architekturen in das APK einfügen zu lassen, ist das richtig?

@Hixie wird

Die Architektur eines Telefons ist ziemlich niedrig, ich habe keine Ahnung, welche Architektur die Leute haben, die unsere Apps verwenden. Flutter kompiliert 32bit, wenn keine Architektur angegeben ist, also würde ich annehmen, dass 32bit für alle passt. Aber jetzt das Spiel Store wird im August 64bit benötigen. Wenn also 32bits für alle passen und 64bit erforderlich sind, sollten diese beiden in einen Release-Build aufgenommen werden?

Ich habe selbst kein Android-Handy, daher gehe ich davon aus, dass es in einem Simulator funktioniert. Bis unsere App-Benutzer etwas anderes sagen.

@MarcelEdward2 Es ist nicht nur 32-Bit vs. 64-Bit. Es gibt vier Architekturen, die vom modernen Android NDK unterstützt werden:

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

Im Moment erstellt Flutter standardmäßig ein APK, das nativen Code enthält, der nur für armeabi-v7a kompiliert wurde. Dies wird auf arm64-v8a problemlos laufen, allerdings mit einer Leistungseinbuße im Vergleich zu etwas, das nativ für arm64-v8a kompiliert wurde. Es läuft jedoch unter einem ARM-Emulator auf x86 oder x86_64, vorausgesetzt, das Gerät bündelt einen. Wenn das x86/x86_64-Gerät keinen ARM-Emulator hat, wird es überhaupt nicht ausgeführt.

Auch hier erfordert die August-Anforderung nicht, dass Sie ein universelles APK oder AAB erstellen, das beide Architekturen enthält. Es erfordert lediglich, dass jede von Ihnen erstellte Version (mindestens) ein APK enthält, das für 64-Bit-Geräte geeignet ist. Änderungen in Flutter, die es ermöglichen, ein universelles APK/AAB mit Unterstützung für mehrere Architekturen zu erstellen, wären in Bezug auf den Entwickler-Workflow schön, aber Sie können diese Anforderung mit oder ohne solche Verbesserungen erfüllen.

Bearbeitet um hinzuzufügen: Ich persönlich denke, dass erstklassiger Support für App Bundles der beste Weg ist, um die Multi-Arch-Situation zu verbessern.

appbundle sieht aus wie die Lösung für die Zukunft ... Ich denke, der nächste Schritt ist dieser: #29303

Wie ich diesen Fehler verstehe, ist er sehr daran gebunden, zu .aab als Standardausgabeformat für flutter build zu wechseln und zu veranlassen, dass .aab dann sowohl 32- als auch 64-Bit-Builds enthält:
https://developer.android.com/studio/projects/dynamic-delivery

Meines Wissens war einige dieser Arbeiten möglicherweise bereits im Gange. @dnfield weiß es vielleicht.

/cc @mklim

Es scheint, als würde .aab helfen, ist aber möglicherweise nicht wirklich notwendig. Ist das Problem so einfach wie das Hinzufügen der 32- und 64-Bit-Arm-Binärdateien zum APK?

Ah, ich verstehe. Dies liegt daran, dass wir möglicherweise auch den AOT-Snapshot für den Zielbogen einschließen müssten. Und im Moment legen wir das einfach unter Assets, wir schreiben keine Version pro Architektur unter libs . Wenn wir den AOT-Snapshot in den architekturspezifischen libs-Ordner ablegen könnten, könnte das funktionieren, ansonsten würden wir aus diesem Grund das .aab-Format verwenden wollen.

Wir wollen dies trotzdem tun, um das Erstellen von .AARs für add2app-Anwendungsfälle zu unterstützen. Ich werde daran stochern.

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

Das hat bei mir nach tagelanger Fehlerbehebung funktioniert

Die von @AppleEducate gepostete

Legen Sie es in den Release-Bereich

Das war meine Lösung:

1. in 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. flutter build apk --release --target-platform=android-arm ausführen

2. app-armeabi-v7a-release.apk in den Play Store hochladen

3. inkrementieren versionCode

4. flutter build apk --release --target-platform=android-arm64 run ausführen

5. app-arm64-v8a-release.apk in den Play Store hochladen

Der Google Play Store wird die App entsprechend der Gerätearchitektur bereitstellen. 32-Bit-Geräte sind glücklich, 64-Bit-Geräte sind glücklich, und ich bin glücklich zu wissen, dass meine APK-Größe relativ klein bleibt und trotzdem beide Architekturen bedient.

Wenn wir beide Architekturen im selben APK unterstützen, rechnen Sie mit einer App-Größe von über 10 MB

@edTheGuy00 Ich bezweifle, dass es interessant ist, wie groß der Upload in den Play Store ist. Die Android-Telefone werden sowieso nach 125+ temporär freiem Speicherplatz fragen und sich weigern, externen Speicher zum Auspacken zu verwenden. Das ist alles, was Benutzer über die App-Größe wissen. Es spielt keine Rolle, wie viel eine App nach der Installation verbraucht. Es wird nach mehr als 125 MB freiem Speicherplatz für die Installation gefragt.

Bitte ermöglichen Sie die Aufnahme aller möglichen Architekturen. Es ist mir egal, ob der Upload in den Play Store 250 MB groß ist.

Es wäre schön, wenn flatter den Gigabit-Speicherplatz auf dem externen Speicher für die Installation auf einem Android-Handy nutzen würde. Das heißt, wenn Flattern die Installation auf einem Android-Handy beeinflussen kann

Ich denke, das flutter.gradle Skript sollte alle ABIs in das endgültige APK (Universal APK) einschließen und dann standardmäßig geteilte APKs aktivieren. Die Android-Tools wählen das richtige APK zum Hochladen auf das verbundene Gerät aus und alles ist gut. Das endgültige universelle APK kann dann in den Play-Store hochgeladen werden, oder entweder die geteilten APKs für jede ABI.

In der Zwischenzeit können Sie dies als Lösung am Ende Ihres build.gradle android\app Verzeichnisses in Ihrem

// 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/"
        }
    }
}

Ich empfehle auch, dies zu Ihrem Abschnitt buildTypes > release hinzuzufügen. Dadurch wird sichergestellt, dass Ihr Release-APK beide ABIs enthält.

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

Nach einer Zusammenarbeit mit @slightfoot kamen wir darauf, aber es ist immer noch nicht ganz richtig, da Sie anfangs zweimal bauen müssen, um die Libs aufzunehmen, die in Ihr src-Verzeichnis eingefügt werden.

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/", "")
            }
        }
    }
}

Update: Nach dem Versuch, dieses APK auf dem Gerät auszuführen, schlägt es fehl und ist daher keine praktikable Lösung. Der Fehler lautet "Fehler beim Initialisieren der Dart-VM: Snapshot nicht kompatibel mit der aktuellen VM-Konfiguration:
der Snapshot erfordert 'product use_bare_instructions no-"asserts" causal_async_stacks arm-eabi softfp'
aber die VM hat 'product use_bare_instructions no-"asserts" causal_async_stacks arm64-sysv'"

Ah, ich verstehe. Dies liegt daran, dass wir möglicherweise auch den AOT-Snapshot für den Zielbogen einschließen müssten. Und im Moment legen wir das einfach unter Assets, wir schreiben keine Version pro Architektur unter libs . Wenn wir den AOT-Snapshot in den architekturspezifischen libs-Ordner ablegen könnten, könnte das funktionieren, ansonsten würden wir aus diesem Grund das .aab-Format verwenden wollen.

Wir wollen dies trotzdem tun, um das Erstellen von .AARs für add2app-Anwendungsfälle zu unterstützen. Ich werde daran stochern.

@dnfield warst du damit schon erfolgreich?

Im Moment das Steckstück durcharbeiten. Wir haben versucht, Teile davon zu priorisieren, um die Android X-Probleme zu beheben, aber es sollten noch mehr daraus werden.

@gerryhigh und ich haben das untersucht. Bitte ignoriere meine letzten Antworten. Das Problem ist nur die Tatsache, dass libflutter.so für 64bit nicht enthalten ist, aber für AOT muss man den Build-Prozess zweimal ausführen, einmal für 32bit und noch einmal für 64bit. Sie erhalten dann zwei Sätze kompilierten Dart-Codes in Ihren Anwendungsressourcen sowie zwei Versionen von libflutter.so. Ich denke, das letztendliche Ziel wäre es, Kompilierungsaufgaben für Flutter einzurichten, damit die beiden separaten Build-Schritte ausgeführt werden und die APKs automatisch eingerichtet werden.

Aber im Moment besteht die einzige Lösung darin, den Build zweimal auszuführen und mehrere APKs in den Play Store hochzuladen.

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

Dies kann besser erreicht werden, indem Split-APKs aktiviert werden. Weitere Details finden Sie hier: https://developer.android.com/studio/build/configure-apk-splits

@slightfoot ja, das ist die beste Lösung, die ich bisher gefunden habe, wie in meinem Kommentar dort oben erwähnt https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

@slightfoot Wenn ich das richtig verstehe, wäre es nicht möglich, ein universelles APK zu erstellen, da sich einige Codes im Assets-Ordner befinden, die es nicht ermöglichen, Dateien gemäß der Zielarchitektur wie dem lib-Ordner aufzuteilen?

Der für jede Architektur erstellte Snapshot ist unterschiedlich. Kopieren Sie einfach die Engine libflutter.so , wodurch der Snapshot nicht geladen werden kann, wenn die Architektur des Snapshots nicht mit der Architektur der Flatter-Engine übereinstimmt.
Derzeit gibt es für uns keine Möglichkeit, eine universelle APK zu erstellen, die alle Architekturen enthält, es sei denn, die Snapshot-Dateien trennen und die Snapshot-Datei für jede Architektur einschließen.

Ich bin ein bisschen verwirrt, warum das überhaupt ein Problem ist.

Debug-Builds erstellen libflutter.so in x86_64, x86, armeabi-v7a und arm64-v8a.

Release-Builds sollten genau das gleiche tun.

AGP (Android Gradle Plugin) enthält bereits die Funktionalität zum Herausfiltern von Architekturen. Wenn ein Benutzer dies für einen Release-Build wünscht, kann er seine build.gradle ändern.

@eseidel @dnfield Ich glaube nicht wirklich, dass dies durch Android App Bundles gelöst wird - sie sind noch nicht die Standard-Android-Ausgabe und wenn sie von der IDE ausgeführt werden, werden APKs noch eine ganze Weile verwendet, da bin ich mir sicher.

AABs sind ein weiterer Grund, warum Flutter alle Architekturen von libflutter.so einbeziehen sollte, da der Play Store herausfiltern kann, welche Architektur er an Geräte liefert.

@athornz das Problem liegt nicht bei libflutter.so sondern wenn Ihr Dart-Code auf AOT snapshot kompiliert wird. Debug-Builds enthalten die Dart-VM, sodass Ihr gesamter Dart-Code nur JIT auf der VM läuft , aber Release-Builds kompilieren Ihren Dart-Code zu einem Snapshot und platzieren diesen Snapshot in einem Asset-Ordner. Idealerweise sollte der Snapshot für jede Architektur kompiliert und neben libflutter.so aber das ist im Moment nicht der Fall. Während Sie also libflutter.so für alle Architekturen einfügen können, funktioniert der Snapshot nur für die Architektur, für die er kompiliert wurde.

Irgendein Plan, um dieses Problem zu beheben?

Der Google Play Store bittet den Entwickler, nach dem 1. August 2019 64-Bit-Unterstützung bereitzustellen.

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

Die 64-Bit-Anforderung: Was sie für Entwickler bedeutet
Ab 1. August 2019:
_Alle neuen Apps und App-Updates, die nativen Code enthalten, müssen beim Veröffentlichen auf Google Play zusätzlich zu den 32-Bit-Versionen auch 64-Bit-Versionen bereitstellen._
Erweiterung: Google Play akzeptiert bis August 2021 weiterhin nur 32-Bit-Updates für vorhandene Spiele, die Unity 5.6.6 oder älter verwenden.
Ab 1. August 2021:
Google Play stellt die Bereitstellung von Apps ohne 64-Bit-Versionen auf 64-Bit-fähigen Geräten ein, was bedeutet, dass sie auf diesen Geräten nicht mehr im Play Store verfügbar sind.
Dazu gehören Spiele, die mit Unity 5.6.6 oder älter erstellt wurden.

@trevorwang können wir bereits 64bit bauen und zusammen mit 32bit in den Play Store hochladen. Das ist also kein Problem.

@slightfoot Meinst du, ich muss ein weiteres 64-Bit-APK erstellen und bei Google Play hochladen?

Wie Sie wissen, ist Google Play auf dem chinesischen Festland nicht verfügbar. Wir bevorzugen ein universelles APK, um alle Plattformen zu unterstützen.

@trevorwang so ziemlich. So mache ich es https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

Das Split-Ding funktioniert in der Gradfle-Datei nicht. Sie müssen etwas mit einer der build.gradle-Dateien machen, damit Flutter verschiedene Architekturen kompilieren kann. Oder Google Play lehnt die zweite Kompilierung ab.

Danke @edTheGuy00

Aber wir brauchen wirklich eine universelle APK, die alle Abis für den China-Markt enthält.

@trevorwang können Sie für jedes Ziel erstellen und explizit gedacht ist. So wird es für die meisten APK-Spiegelseiten gemacht.

Die 64-Bit-Beschränkung ist nur eine Einschränkung des Google Play Store. Sie können weiterhin nur das armeabi-v7a-APK bereitstellen und jeder kann Ihre App ausführen.

Das Erstellen separater APKs pro Architektur ist eine Problemumgehung und definitiv keine Lösung für jeden.

Sobald die 64-Bit-Beschränkung von Google Play in Kraft tritt, wird dieses Problem die meisten Flutter-Entwickler betreffen, daher brauchen wir wirklich eine Lösung, die mehrere Architekturen innerhalb einer APK/einem Bundle zulässt.

Nur eine kurze Erinnerung

Das Flutter-Team verwendet die Anzahl der "Daumen hoch" bei einer GitHub-Ausgabe als Anhaltspunkt für seine Priorität.

Ich denke, diesem Thema sollte eine hohe Priorität eingeräumt werden.

Danke für die Arbeit von @gerryhigh und @slightfoot

Ich habe Flatter zu einer bestehenden App hinzugefügt und dieses Problem durch die folgende Problemumgehung behoben.
_Bitte fügen Sie dies Ihrem App-Modul des Hostprojekts hinzu._

Dies ist das Skript für den Debug-Modus, bitte ändern Sie es für die Veröffentlichung entsprechend.

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/", "")
                }
            }
        }
    }
}

Irgendwelche aktuellen Entwicklungen?

Was ich am Ende tat, da ich wollte

• separate apks für jede architektur
• den versionCode nicht manuell ändern zu müssen
• Führen Sie einen einzigen Befehl aus, um die APKs zu erstellen

1. Dies wurde zu Gradle hinzugefügt. Es fügt 1 oder 2 am Ende des versionCodes hinzu, so dass aus Version 1004 10041 für arm und 10042 für arm64 wird.

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. Um die APKs zu erstellen, verwende ich einen längeren Terminalbefehl (den Sie in ein Skript einfügen können). Es führt den Build zweimal aus und erstellt am Ende Kopien der APKs:

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;

Hoffe das hilft.

Dies ist also ein Problem, das ich auch habe. Ich habe ein App-Bundle anstelle einer APK erstellt und wenn ich es auf Google hochgeladen habe, gibt es mir die Warnung und lässt es mich nicht alpha testen.

Ich habe Codemagic verwendet, um dies zu tun. Gibt es eine Möglichkeit, es zu signieren und in einem Bündel zusammenzufassen? oder Codemagic verwenden, um es zu tun?

Ich stehe vor dem gleichen Problem, von dem ich dachte, dass es überhaupt nicht existieren sollte.

Wie kommt es, dass dies auf dem Meilenstein "Goals" steht.

P2: Dies sind Aufgaben, von denen wir meinen, dass sie es wert sind, in den kommenden Jahren gelöst zu werden. Es enthält von uns identifizierte Probleme, die den vollständigen Versand von breiten verbraucherorientierten Apps blockieren könnten, Korrektheitsprobleme und Fehler in Bezug auf Politur und Qualität. Das Datum auf diesem Meilenstein ist völlig willkürlich und dient nur dazu, den Meilenstein entsprechend zu sortieren.

Es ist bereits ein kritisches Problem und wird noch in diesem Jahr zu einem ausgewachsenen Showstopper, sobald Google die 64-Bit-Beschränkung durchsetzt.

Damit habe ich den Meilenstein erreicht. Noch kein festes Datum.

Um es klar zu sagen: Es ist möglich, aber schwierig, die neuen Richtlinien heute einzuhalten. Das wollen wir einfacher machen.

Also hat die @andreidiaconu- Methode für mich funktioniert, solange ich die App manuell baue.

Aber ich habe Codemagic zum Erstellen und Bereitstellen verwendet.

Das ist also eine Verschwendung, Flutter muss es bauen.

Im Moment ist es mir persönlich egal, ob es kompliziert ist. Wenn es kompliziert ist, wird es durch ein Skript automatisiert. Die Frage ist, ob es möglich ist und wie, denn die Google Play Console warnt mich:

Diese Version entspricht nicht der 64-Bit-Anforderung von Google Play
Die folgenden APKs oder App Bundles sind für 64-Bit-Geräte verfügbar, aber sie haben nur 32-Bit-nativen Code: 6.
Ab dem 1. August 2019 müssen alle Releases der 64-Bit-Anforderung von Google Play entsprechen.
Fügen Sie nativen 64-Bit- und 32-Bit-Code in Ihre App ein. Verwenden Sie das Android App Bundle-Veröffentlichungsformat, um automatisch sicherzustellen, dass jede Gerätearchitektur nur den nativen Code erhält, den sie benötigt. Dadurch wird vermieden, dass die Gesamtgröße Ihrer App erhöht wird.

Ich möchte keine Lösung, die unterschiedliche Versionscodes benötigt, und ich möchte eine Lösung, die mit Android App Bundles (AAB) funktioniert.

Warnung
Diese Version entspricht nicht der 64-Bit-Anforderung von Google Play

Die folgenden APKs oder App Bundles sind für 64-Bit-Geräte verfügbar, haben jedoch nur 32-Bit-nativen Code: 3.

Irgendeine Lösung?

Damit habe ich den Meilenstein erreicht. Noch kein festes Datum.

Um es klar zu sagen: Es ist möglich, aber schwierig, die neuen Richtlinien heute einzuhalten. Das wollen wir einfacher machen.

Sollten die Dokumente mit Anweisungen dazu aktualisiert werden, wie dies sowohl für APK- als auch für App-Bundles geht? Alles, was ich bisher gesehen habe, sind eine Menge Code und Konfigurationen, bei denen ich nicht genau weiß, wo ich sie einfügen soll. Ich könnte es wahrscheinlich mit etwas Versuch und Irrtum herausfinden, aber es ist nicht ideal.

gleicher Fehler

Danke für die Arbeit von @gerryhigh und @slightfoot

Ich habe Flatter zu einer bestehenden App hinzugefügt und dieses Problem durch die folgende Problemumgehung behoben.
_Bitte fügen Sie dies Ihrem App-Modul des Hostprojekts hinzu._

Dies ist das Skript für den Debug-Modus, bitte ändern Sie es für die Veröffentlichung entsprechend.

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/", "")
                }
            }
        }
    }
}

Diese Lösung/Workaround sieht am vielversprechendsten aus, danke @trevorwang ! Ich habe jedoch Probleme, dies in einem bestehenden Flatter-Projekt zu implementieren. Haben Sie eine Beispieldatei build.gradle oder etwas Ähnliches, die dies demonstrieren würde?

BITTE BEACHTEN SIE, DASS DIES IHR PROBLEM WAHRSCHEINLICH NICHT LÖSEN WIRD - SIEHE UNTEN

Dank der @trevorwang- Antwort und dem @noinskit- Vorschlag ist es mir gelungen, 64-Bit-native Libs in Release-Builds ./android/app/build.gradle , die unten gezeigt wird.
Sie können die gesamte Datei auch hier einsehen.

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 danke! Ich bin auf etwas ähnliches gekommen. In meinem Fall muss ich assembleRelease in Ihrem Snippet in mergeReleaseJniLibFolders ändern, sonst landet die zusätzliche *.so-Datei unter "intermediates/...", aber nicht in der endgültigen apk.

@noinskit Es scheint, dass meine vorherige Lösung fehleranfällig war. Nachdem flutter clean , wurden aabs mit nur 32-Bit-Bibliotheken generiert. Das Ersetzen von assembleRelease durch mergeReleaseJniLibFolders scheint auch nach der Bereinigung des Builds zu funktionieren.

@SPodjasek müssen Sie andere Optionen optimieren?

Hier ist mein 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/", "")
                }
            }
        }
    }
}

Beide meiner Intermediates/jniLibs/release/ arm64-v8a- und armeabi-v7a- Verzeichnisse haben wie erwartet libflutter.so , aber in der endgültigen APK-Version fehlt noch libflutter.so in arm64-v8a.

Hier ist der Screenshot

@function1983 Sie können mein komplettes build.gradle hier sehen .
Zu meiner Flatterversion:

[✓] 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)

Ich habe versucht , @SPodjasek ‚s - Lösung zu verwenden , um eine appbundle zu bauen , die beide 64 und 32 - Bit - Versionen enthalten. Es wird erfolgreich erstellt, ich kann es in die Google Play Console hochladen und auf 32- und 64-Bit-Telefonen installieren. Aber die App stürzt aus irgendeinem Grund ab, wenn sie auf einem Android-arm64-Gerät gestartet wird (scheint jedoch auf einem alten 32-Bit-Android-Telefon zu funktionieren, mit dem ich getestet habe).

Hier ist der Fehler, den ich auf dem 64-Bit-Gerät erhalte:

Abbruchmeldung: '[ FATAL:flatter/runtime/dart_vm.cc (416)] Fehler beim Initialisieren der Dart-VM: Snapshot nicht kompatibel mit der aktuellen VM-Konfiguration: Der Snapshot erfordert 'product use_bare_instructions no-"asserts" causal_async_stacks arm-eabi softfp ' aber die VM hat 'product use_bare_instructions no-"asserts" causal_async_stacks arm64-sysv'

Ich bin mir nicht sicher, was ich tun kann ... Vielleicht muss ich vorerst nur 64-Bit-Geräte unterstützen.

@Torrunt Dieser Fehler liegt daran, dass die Engine versucht, den AOT-Snapshot für 32-Bit zu laden und einen für 64 zu finden.

Wir arbeiten daran, einen AAB produzieren zu können, der beides hat, damit der Laden diese richtig aufteilen kann.

@SPodjasek Mit dieser meiner app-release.apk Dateigröße 15,7 MB von 11,1 MB erhöht

@SPodjasek Mit dieser meiner app-release.apk Dateigröße 15,7 MB von 11,1 MB erhöht

Ja, da es zwingend libflutter.so für 32 und 64bit enthält. Wenn Sie das nicht benötigen, bleiben Sie bei der aktuellen Standardeinstellung, die nur 32 Bit enthält, und warten Sie, bis das Flatter-Team dies ordnungsgemäß erledigt.

es sieht so aus als ob es mehrere möglichkeiten gibt:

• Warten Sie, bis das Flatter-Team das Problem mit der 32-gegen-64-Architektur gelöst hat, damit der Google Play Store die Flatter-Builds wieder akzeptiert
• Wir müssen die verwendeten Android-Geräte auf nur 32-Bit beschränken, damit Flatter-Apps nur auf 32-Bit-Geräten laufen
• Wir müssen Google irgendwie davon überzeugen, 64 Bit im Play Store nicht durchzusetzen. (Ich frage mich, was der Unterschied zwischen 32 und 64 Bit ist, so etwas wie größere Zahlen?)
• installiere die 32 Apps irgendwie auf 64 Bit Geräten aber nicht im Play Store...

Hinweis für Leute, die --target-platform , um für android-arm und android-arm64 separat zu bauen und zwei APKs hochzuladen.
Beachten Sie, dass einige Plugins native Bibliotheken verwenden, die auf beide abzielen können, und dass Flutter die Bibliotheksordner nicht filtert, sodass Ihr "32-Bit"-APK tatsächlich auch auf arm64 abzielt und abstürzt, da libflutter.so nicht vorhanden ist und AOT-Schnappschüsse sind gebaut für armv7.

Sie müssen also das Ziel-Abi in Ihrer Datei build.gradle tatsächlich explizit filtern.

Ich denke, die flutter build apk --target-platform ... sollten diese Filterung logischerweise durchführen.

Mit der Lösung von @SPodjasek habe ich einen Fehler beim Abgleichen von arm-eabi arm64-sysv . Ich denke, die beste Lösung, die für mich funktioniert hat, ist vorerst nur für 32 Bit zu bauen, bis das alles geklärt ist ( hier ):

In Ihrem app Level build.gradle :

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

Zusammenfassendes Problem aus dem Thema - es wird nicht möglich sein, ein solches APK sowohl für armeabi-v7a als auch für arm64-v8a zu erstellen. Flutter verwendet AOT-Snapshots, die ABI-abhängig sind, so dass mit APK die einzige mögliche Lösung darin besteht, mehrere APK-Builds zu verwenden.
Die Lösung wäre die Verwendung von App Bundles, die derzeit auch einige Probleme haben (#31922).
Nachdem #32787 zusammengeführt wurde, ist es nun möglich, App Bundles zu verwenden.

Wie stelle ich den Flavor und meine Zieldatei (z. B. -t lib/another_main.dart) ein, wenn ich ein Android-App-Bundle über Android Studio erzeuge? oo

Dies wird über flutter build appbundle nachdem https://github.com/flutter/flutter/pull/32787 zusammengeführt wurde!

@swavkulinski wie würdest du die to apks für den Playstore freigeben?

Damals war es noch möglich. Jetzt müssen Sie auf 64bit beschränken. Wir wurden von der NDK-Bibliothek eines Drittanbieters gesperrt, die nur 32-Bit war.

@blasten
Wird dadurch auch Unterstützung für flutter build apk --release hinzugefügt? Oder ist geplant, den APK-Support langfristig zugunsten von App Bundles auslaufen zu lassen? Ich mag die relative Einfachheit der fetten APK sehr.

@zimmi Richtig. App Bundles sollten der Weg in die Zukunft sein. Sie können bei Bedarf weiterhin flutter build apk --release . Was ist bei einer fetten APK einfacher als bei AAB?

Was ist bei einer fetten APK einfacher als bei AAB?

AAB ist keine Installationsdatei. Android selbst kann es nicht verwenden. Es ist nur ein Dateiformat für den Google Play Store. Brauche also apk, wenn:

• Direkte Installation auf dem Gerät.
• Direkt verteilende App.
• Vertrieb über jeden anderen App-Markt außer Google Play Store. (Amazon & ganz China).

Ich verstehe. Danke für den Hintergrund.

Sie können die APKs auch mit Bundletool aus dem AAB extrahieren .

@blasten
Vielen Dank für die Bestätigung!
Bezüglich des Einfachheitskommentars: Was @audkar gesagt hat. Auch bei AABs muss der Entwickler über mögliche Ausfallszenarien durch fehlende Assets nachdenken. Das Testen aller möglichen Gerätekonfigurationen ist schwierig. Wenn diese Fehler auftreten, ist dies wahrscheinlich in der Produktion.

Die App-Größe könnte ein Preis sein, den einige für diese Sicherheit zu zahlen bereit sind.

Ich bin mir sicher, dass es bessere Orte gibt, um die Vorzüge jedes Ansatzes zu diskutieren, als dieses Thema, aber ich möchte es nicht entgleisen.

/cc @jonahwilliams Wir müssen möglicherweise fette APKs in build apk .
Sollten wir auch die Standardeinstellung für build apk ändern?

Fat APK-Unterstützung ist definitiv erforderlich. Es gibt viele Tools (Beta-Verteilung usw.), die noch nicht mit App-Bundles funktionieren.

flutter build appbundle ist jetzt im Master, möchte eine freiwillige Person es versuchen?

Wir hatten einige Diskussionen, um eine Liste von Plattformen in build apk , also könnten Sie so etwas tun: flutter build apk --target-platform android-arm,android-arm64

@blasten Ich habe auf den Master-Kanal umgestellt, das Appbundle aktualisiert und gebaut, es hat gut funktioniert. Dann auf die Spielkonsole hochgeladen und alle Warnungen sind weg. (macOS 10.14.4)

Genial! Ich werde meinen Build heute Abend kompilieren, nachdem ich meine Änderungen vorgenommen habe.

Das Bundle scheint nicht zu funktionieren, die App stürzt beim Download ab.

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

Scheint, als wäre com.mattetti.sounds.MainActivity nicht im Paket enthalten?

Ich weiß nicht warum, wie kann ich überprüfen, warum es entfernt wurde?

@mattetti Verwenden Sie ein Flutter-Modul ? Wird MainActivity FlutterActivity ?

@blasten
Hier sind meine Abhängigkeiten

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

Aber mir ist auch gerade aufgefallen, dass ich das Paket meiner App umbenannt habe, aber den Pfad zu meiner MainActivity.java Datei nicht geändert habe, die immer noch android/app/src/main/java/com/example/old_name/ , die möglicherweise das Problem ist. Morgen werde ich versuchen, den Pfad zu ändern und ein weiteres Bündel zu schieben.

hallo @blasten , ich habe versucht, das Appbundle zu erstellen und habe diesen Fehler erhalten

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

Mein Projekt verwendet Flavor und dies ist der Befehl, den ich ausführe

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

Wird das App Bundle auch die Mapping.txt enthalten? Beim Hochladen von App Bundles in die Google Play Console über Codemagic ist keine Mapping.txt enthalten, also keine automatisierten Tests oder Pre-Launch-Berichte - die Sie beim Hochladen einer APK haben :(

also die frage ist:

Wird das Flutter-Team vor August ein Update für die 64-Bit-Version vornehmen oder nicht, damit wir unsere Apps hochladen und aktualisieren können, die mit Flutter erstellt wurden oder nicht?

@ YazeedAlKhalaf Ja. Sie können heute flutter build appbundle und erhalten ein App-Bundle, das 32 und 64 Bit enthält.

@mattetti ist das Problem behoben?

@nohli mapping.txt klingt wie eine Funktionsanfrage. Fühlen Sie sich frei, einen neuen Fehler zu melden.

@skybur kannst du flutter doctor ausführen? Ist Ihr Flutter-Projekt eine App oder ein Modul?

@blasten Mein Projekt ist eine App.

Hier ist das Flatter Doctor Ergebnis

[√] 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 :

Versuchen, flutter build appbundle dann in den Store hochzuladen und dann von einem Android-Telefon aus zu öffnen:
Sofortiger Absturz beim Öffnen.

adb-Protokoll:
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 es ist mir sehr unklar, warum die Leute immer wieder sagen, dass das App Bundle dieses Problem löst.

App Bundle ist nichts anderes als ein automatisiertes geteiltes APK, und es gibt keine Aufteilung des Assets-Ordners. Die Snapshots zielen also immer noch nur auf eine einzige Architektur ab.

Mir fehlt wahrscheinlich etwas, aber meiner Meinung nach besteht die einzige Lösung jetzt darin, APK für jede Architektur mit entsprechender ndk-Filterung in der Gradle-Datei zu erstellen. Und laden Sie dann jedes dieser APKs hoch.

Wenn wir dieses Problem nicht mit APK lösen können, besteht auch keine Chance, dass App Bundle funktioniert.

@ndusart Ich glaube nicht, dass das stimmt. App Bundle-Dokumente sagt:

res/, lib/ und Assets/: Diese Verzeichnisse sind mit denen in einem typischen APK identisch. Wenn Sie Ihr App Bundle hochladen, überprüft Google Play diese Verzeichnisse und verpackt nur die Dateien, die der Konfiguration des Zielgeräts entsprechen, wobei die Dateipfade beibehalten werden.

Es kann also Vermögenswerte irgendwie aufteilen.

@jereksel Dies sagt nur, dass diese Verzeichnisse im App Bundle genauso funktionieren wie in apk und der Ordner assets/ nicht aufgeteilt ist. Es wird verwendet, um Assets in einer sehr spezifischen Dateistruktur in der Anwendung zu speichern, es ist nicht dafür gedacht, vom Betriebssystem oder ähnlichem geparst zu werden.

Wenn ich falsch liege, sagen Sie mir einfach, wie wir diesen Ordner basierend auf dem Ziel-ABI aufteilen können.

Und dieses Zitat bestätigt nur, was ich sage. Wenn dies derzeit mit APK nicht möglich ist, wird dies mit App Bundle nicht möglich sein, da diese Ordner in beiden Richtungen genau gleich funktionieren.

Ich habe nicht gesehen, wie sich Vermögenswerte geteilt haben, aber ich habe Folgendes gefunden:

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

Assets.pb – Dies ist das Äquivalent einer Ressourcentabelle für Anwendungsassets und ist nur vorhanden, wenn Sie Assets in Ihrer Anwendung verwenden.

Ich vermute also, dass Android Studio Assets nicht aufteilt, aber App-Bundles selbst unterstützen dies.

Hast du eine offizielle Dokumentation? Das alles wirkt sehr unzuverlässig.
Der folgende Artikel, https://medium.com/mindorks/android-app-bundle-aab-98de6dad8ba8 , besagt, dass wir dem Namen von Ordnern in assets/ ein Suffix anhängen können, um es aufzuteilen, aber derzeit kann dies nur an der Sprache gemacht werden.

Dies scheint also noch nicht stabil zu sein und sollte im Moment nicht darauf basieren. Die VM-Snapshots sollten entweder in den Ordner lib/ deportiert werden, wenn dies möglich ist, oder der Befehl flutter sollte mit einer vollständigen Funktion zum Erstellen eines APK für ein bestimmtes Ziel ausgestattet sein (daran muss noch gearbeitet werden .) um für viele Menschen zugänglich zu sein) und verzögern die Produktion eines App Bundles, wenn es dazu bereit ist.

@blasten

Ich wechselte zum Master-Channel, aktualisierte und baute das Appbundle. Leider stürzt die App ab, nachdem sie aus dem Google Play Store heruntergeladen wurde, mit folgendem 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 ist jetzt im Master, möchte eine freiwillige Person es versuchen?

Wir hatten einige Diskussionen, um eine Liste von Plattformen in build apk , also könnten Sie so etwas tun: flutter build apk --target-platform android-arm,android-arm64

@blasten

Ich wechselte zum Master-Channel, aktualisierte und baute das Appbundle. Leider stürzt die App ab, nachdem sie aus dem Google Play Store heruntergeladen wurde, mit folgendem 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 ist jetzt im Master, möchte eine freiwillige Person es versuchen?
Wir hatten einige Diskussionen, um eine Liste von Plattformen in build apk , also könnten Sie so etwas tun: flutter build apk --target-platform android-arm,android-arm64

Habe das gleiche Problem, obwohl ich noch keine Logs habe.

@skybur das Problem, das Sie hatten, könnte mit https://github.com/flutter/flutter/issues/33119 zusammenhängen. Wenn dies der Fall ist, sollte dieser Patch es beheben.

@ndusart
Ja, du hast recht. Ich habe den Quellcode von Bundletool überprüft und die Aufteilung der Assets ist tatsächlich nur nach Sprache:
https://github.com/google/bundletool/blob/master/src/main/java/com/android/tools/build/bundletool/splitters/ModuleSplitter.java#L286

Das war meine Lösung:

1. in 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. flutter build apk --release --target-platform=android-arm ausführen
2. app-armeabi-v7a-release.apk in den Play Store hochladen
3. inkrementieren versionCode
4. flutter build apk --release --target-platform=android-arm64 run ausführen
5. app-arm64-v8a-release.apk in den Play Store hochladen

Der Google Play Store wird die App entsprechend der Gerätearchitektur bereitstellen. 32-Bit-Geräte sind glücklich, 64-Bit-Geräte sind glücklich, und ich bin glücklich zu wissen, dass meine APK-Größe relativ klein bleibt und trotzdem beide Architekturen bedient.

Wenn wir beide Architekturen im selben APK unterstützen, rechnen Sie mit einer App-Größe von über 10 MB

Es gibt eine wichtige Sache zu erzählen. Wenn Sie die von mir zitierte Methode verwenden. Möglicherweise müssen Sie die Einstellung auskommentieren, wenn Sie Ihre App weiterhin debuggen möchten. Ich stehe vor dem Fehler, dass Gradle build kein Android-Paket erstellen konnte , und blieb für einige Stunden hängen, was gradlew clean ...etc. erzeugte, und fand schließlich heraus, dass dies auskommentiert werden sollte!

Hoffe, das hat jemandem geholfen, herauszuspringen.

flutter build appbundle ist jetzt im Master, möchte eine freiwillige Person es versuchen?

Wir hatten einige Diskussionen, um eine Liste von Plattformen in build apk , also könnten Sie so etwas tun: flutter build apk --target-platform android-arm,android-arm64

flutter build appbundle funktioniert! Ich muss diese Einstellung nicht hinzufügen und mache einfach den Code. Das Kompilieren dauert jedoch etwas lange, aber es ist die einzige Möglichkeit, Google Play jetzt zu bestehen.

@Tokenyet konnten Sie die App aus dem Play Store herunterladen und ausführen, nachdem Sie die .aab hochgeladen haben? Wenn dies der Fall ist, würde es Ihnen etwas ausmachen, die Ausgabe von flutter doctor einzufügen?

@blasten

Ich wechselte zum Master-Channel, aktualisierte und baute das Appbundle. Leider stürzt die App ab, nachdem sie aus dem Google Play Store heruntergeladen wurde, mit folgendem 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 ist jetzt im Master, möchte eine freiwillige Person es versuchen?
Wir hatten einige Diskussionen, um eine Liste von Plattformen in build apk , also könnten Sie so etwas tun: flutter build apk --target-platform android-arm,android-arm64

Genau das gleiche hier, wenn ich versuche, meine App aus dem Play Store auszuführen (als Appbundle erstellt). Welche Protokolle brauchen Sie, um das zu beheben?

Dies wird hilfreich sein:

1. Laden Sie bundletool von https://developer.android.com/studio/command-line/bundletool herunter
2. Führen Sie flutter build appbundle (Bitte geben Sie an, ob Sie ein Flag übergeben oder ob Sie _benutzerdefinierte_ Änderungen an einem Gradle-Skript vorgenommen haben)
3. Führen Sie bundletool build-apks --bundle=build/app/outputs/bundle/release/app.aab --output=out.apks , um das APK-Set zu extrahieren.
4. Führen Sie unzip -l out.apks und zuletzt flutter doctor und fügen Sie die Ausgabe beider Befehle in Ihren Kommentar ein.

Wenn möglich:

Testen Sie lokal auf dem Gerät mit dem bundletool und dem APK-Set. Dies sind die Schritte , fügen Sie den Logcat in Ihren Kommentar ein.

Ich kann das Problem nicht reproduzieren, obwohl ich nur lokal mit bundletool getestet habe.

@blasten Der vorherige Fehler ist also behoben, aber ich bin auf einen anderen Fehler

[+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 Ich folge all deinen Schritten meine 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
Tatsächlich heißt dies Assets Targeting und ermöglicht Ihnen das Targeting/Aufteilen von Verzeichnissen in Assets basierend auf Graphics API, Language & Texture Compression.
Wie hier zu sehen: .../bundletool/model/targeting/TargetedDirectorySegment.java

In Bezug auf AAB funktioniert das aktuelle flutter@master für mich lokal - mit bundletool zum Testen und Installieren auf einem echten Gerät. Ich habe die Aufteilung nach Dichte und Sprache in meinem build.gradle deaktiviert, also gibt mir build-apks Folgendes:

  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

Beim Testen auf Test Lab habe ich auch alles grün.
Warte noch darauf, dass der Play Store diese Version verarbeitet, um diesen Kanal zu testen.

@Tokenyet konnten Sie die App aus dem Play Store herunterladen und ausführen, nachdem Sie die .aab hochgeladen haben? Wenn dies der Fall ist, würde es Ihnen etwas ausmachen, die Ausgabe von flutter doctor einzufügen?

Ich kann die App aus dem Play Store herunterladen und ausführen. Sie könnten es [versuchen] (https://play.google.com/store/apps/details?id=com.bumbystudio.starry_clock). (Edit: Ups, es funktioniert nicht ... aus dem PlayStore)

Unten ist mein flutter doctor wie Sie es brauchen. Hoffe es hat geholfen.

[√] Flutter (Kanalmaster, v1.6.1-pre.88, unter Microsoft Windows [Version 10.0.17134.765], Gebietsschema zh-TW)

[√] Android-Toolchain - für Android-Geräte entwickeln (Android SDK Version 28.0.3)
[√] Android Studio (Version 3.3)
[√] VS Code, 64-Bit-Edition (Version 1.30.2)
[!] Verbundenes Gerät
! Keine Geräte verfügbar

Das funktioniert bei mir gut!

buildTypes {
Freisetzung {
// TODO: Fügen Sie Ihre eigene Signaturkonfiguration für den Releasebuild hinzu.
// Vorerst mit den Debug-Schlüsseln signieren, damit flutter run --release funktioniert.
signingConfig signingConfigs.debug
}
debuggen {
ndk {
abiFilter 'armeabi-v7a'
}
}
}

@SPodjasek immer noch, wir müssen assets/ basierend auf ABI aufteilen. Wie kann dies derzeit erfolgen?

Ich habe es auf meinem Gerät installiert und es scheint nicht zu funktionieren. Alles was ich bekam war ein
schwarzer Bildschirm.

Danke,

Purusothaman Ramanujam

Am Do, 23. Mai 2019, 18:43 Uhr schrieb Tokenyet, [email protected] :

@Tokenyet https://github.com/Tokenyet konnten Sie die App herunterladen ?
aus dem Play Store und führen Sie es nach dem Hochladen der .aab? Wenn das der ist
Fall, würde es Ihnen etwas ausmachen, die Ausgabe von Flatter Doctor einzufügen?

Ich kann die App aus dem Play Store herunterladen und ausführen. Du könntest es geben
ein Versuch
https://play.google.com/store/apps/details?id=com.bumbystudio.starry_clock
.

Unten ist mein Flatterarzt, wie Sie es brauchen. Hoffe es hat geholfen.

[√] Flutter (Kanalmaster, v1.6.1-pre.88, unter Microsoft Windows [Version
10.0.17134.765], Gebietsschema zh-TW)

[√] Android-Toolchain - für Android-Geräte entwickeln (Android SDK-Version
28.0.3)
[√] Android Studio (Version 3.3)
[√] VS Code, 64-Bit-Edition (Version 1.30.2)
[!] Verbundenes Gerät
! Keine Geräte verfügbar

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/flutter/flutter/issues/18494?email_source=notifications&email_token=AAIHDZYY47H6PUQQJYEO4J3PW2J7RA5CNFSM4FFE2B7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW6KTPNWW2HZ47
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAIHDZZXV67JCNVJYLVA3WLPW2J7RANCNFSM4FFE2B7A
.

@ndusart An diesem Punkt ist es unmöglich - vielleicht stellen Sie eine Funktionsanfrage bei Bundletool und Google wird erwägen, sie zu implementieren.

@SPodjasek das ist es, was ich sage, all dieses Problem geht in die falsche Richtung.

Alle Diskussionen scheinen zu enden mit "keine Sorge, wenn wir App-Bundles bauen könnten, wäre alles in Ordnung", aber das ist jetzt und in naher Zukunft absolut nicht der Fall.
Es ist ein bisschen enttäuschend zu sehen, wie das Flatter-Team die Leute glauben lässt, dass es auf diese Weise möglich ist.

flatter sollte in der Lage sein, einfach ein geteiltes APK zu erstellen, indem es entweder die Aufteilung selbst durchführt oder es schafft, die VM-Snapshots in den Ordner lib/ und die Aufteilung einfach funktionieren zu lassen (wir könnten dann auch App Bundles verwenden )

Lassen Sie uns rekapitulieren:

1. Flutter unterstützt fette APKs über flutter build apk ... .
2. Wenn Sie diese Funktion _jetzt_ ausprobieren möchten, versuchen Sie es mit flutter build appbundle im Master-Zweig. Wenn App Bundles für Ihren Anwendungsfall nicht funktionieren, sollte (1) die verbleibenden Fälle abdecken.

Okay @blasten Ich habe im
https://github.com/flutter/flutter/blob/dc28ba8919604ff19ea7cbad8d9400516347b08a/packages/flutter_tools/gradle/flutter.gradle#L470 -L481

Es wird also nicht nur App-Bundle-Unterstützung hinzugefügt. Es ist jetzt klarer.
Eine kleine Erklärung wäre jedoch wünschenswert gewesen, da angegeben wurde, dass das Problem der Asset-Ordner war und keine Informationen gegeben wurden. In dieser Richtung wurde gearbeitet, da dieses Problem und die App-Bundle-Unterstützung ziemlich unabhängig sind.

Danke für deine Arbeit.

@ndusart - @blasten hat Änderungen an der Android-Einbettung vorgenommen, sodass jetzt nach den binären Blobs im Ordner lib gesucht wird, sodass Sie beide Typen bündeln können, wenn ich mich nicht irre ...

Wenn Snapshots in die lib verschoben werden, wird #30846 vielleicht auch behoben?

@blasten
Ich wechselte zum Master-Channel, aktualisierte und baute das Appbundle. Leider stürzt die App ab, nachdem sie aus dem Google Play Store heruntergeladen wurde, mit folgendem 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 ist jetzt im Master, möchte eine freiwillige Person es versuchen?
Wir hatten einige Diskussionen, um eine Liste von Plattformen in build apk , also könnten Sie so etwas tun: flutter build apk --target-platform android-arm,android-arm64

Habe das gleiche Problem, obwohl ich noch keine Logs habe.

Hier gilt das gleiche. Hatte Fehler. Master aktualisiert und flutter build appbundle . Fehler behoben, aber App stürzt beim Öffnen ab.

Ich habe versucht, ein Appbundle mit der neuesten Flatter-Master-Version mit den neuesten Änderungen in den App Store hochzuladen. Der 64-Bit-Fehler ist jetzt weg, aber meine App stürzt sofort ab.

Was wirklich seltsam ist, ist, dass die 64-Bit-Version mit den folgenden Befehlen funktioniert.
flatter build apk --target-platform android-arm64
flattern install api

Es stürzt nur ab, wenn die App über das Appbundle im Appstore installiert wird. Im Moment habe ich den Appstore wieder auf die 32-Bit-APK zurückgesetzt.

Ich habe nichts besonderes in meinem gradle.build

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

Ich verwende Flutter (Channel Master, v1.6.4-pre.13, auf Mac OS X 10.14.5 18F132, locale en-US)

Gibt es diese Bundles irgendwie zu testen, bevor man sie in den Appstore hochlädt? Ist dies ein bekanntes Problem, an dem Google arbeitet, oder muss ich einige Änderungen an meiner Gradle-Datei vornehmen?

@chitwoob Bitte folge den Schritten: https://github.com/flutter/flutter/issues/18494#issuecomment -495049530

@blasten Ich habe ein Problem mit dem Bundle-Tool, das nichts mit diesem Problem zu

Ich bekomme
Fehler: Fehler beim Starten des ADB-Servers

Beim Laufen
build-apks --connected-device --bundle=./app.aab --output=./my_app.apks --adb

Ich habe adb richtig installiert. Wenn ich adb logcat versuche, funktioniert es einwandfrei.

Wird ein langer Kommentar, aber das hat das Problem komplett behoben

Das war meine Lösung:

1. in 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. flutter build apk --release --target-platform=android-arm ausführen
2. app-armeabi-v7a-release.apk in den Play Store hochladen
3. inkrementieren versionCode
4. flutter build apk --release --target-platform=android-arm64 run ausführen
5. app-arm64-v8a-release.apk in den Play Store hochladen

Der Google Play Store wird die App entsprechend der Gerätearchitektur bereitstellen. 32-Bit-Geräte sind glücklich, 64-Bit-Geräte sind glücklich, und ich bin glücklich zu wissen, dass meine APK-Größe relativ klein bleibt und trotzdem beide Architekturen bedient.

Wenn wir beide Architekturen im selben APK unterstützen, rechnen Sie mit einer App-Größe von über 10 MB

Das Befolgen dieser Schritte bedeutete "Gradle build konnte kein Android-Paket erstellen". Error
_ Nach einer Stunde Debugging die Lösung gefunden. _

Gehen Sie folgendermaßen vor, um verschiedene Apps für x86 und x64 zu erstellen:

Schritt 1: Fügen Sie das Code-Snippet in die app/build.gradle Datei ein. Die Datei wird wie folgt aussehen:

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

Schritt 2: Erstellen Sie eine Release-Apk mit flutter build apk --release
Dadurch wird die x86-basierte APK im Ordner build/app/outputs/apk/app.apk
Laden Sie diese APK in den Google Play Store hoch.
x86 bis jetzt fertig

Führen Sie zu diesem Zeitpunkt nicht flutter clean
Ich habe dies getan und beim Erstellen von x64 apk Fehler erhalten

Schritt 3: Öffnen Sie nun pubspec.yaml und ändern Sie die version von
version: 1.0.0+1 bis version: 1.0.0+2

Die Zahl neben + ist der Versionscode

Schritt 4: Führen Sie nun den Befehl aus
flutter build apk --release --target-platform=android-arm64

Nachdem dieser Befehl abgeschlossen ist, gehen Sie zu build/app/outputs/apk/release/ . Darin finden Sie eine apk mit dem Namen app-arm64-v8a-release.apk . Dies ist Ihre 64-Bit-APK-Datei mit einem anderen Versionscode.

Laden Sie nun diese x64-APK in den Play Store hoch ... und los geht's. Sie haben sowohl x86- als auch x64-Apps in den Play Store hochgeladen.

Wird ein langer Kommentar, aber das hat das Problem komplett behoben

[…]
Gehen Sie folgendermaßen vor, um verschiedene Apps für x86 und x64 zu erstellen:

Schritt 1: Fügen Sie das Code-Snippet in die Datei app/build.gradle . Die Datei wird wie folgt aussehen:

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

Schritt 2: Erstellen Sie eine Release-Apk mit flutter build apk --release
[…]

Stimme deiner Antwort zu. Funktioniert für mich, obwohl ich Schritt 1 nicht befolgen musste (ich habe eine Standardbuild.gradle verwendet)

Dann müssen Sie nur Ihre Build-Nummer und Version erhöhen, damit Google Play sie akzeptiert.

Ich habe immer noch Probleme mit flutter build appbundle auf meiner Hand.

Wird ein langer Kommentar, aber das hat das Problem komplett behoben

[…]
Gehen Sie folgendermaßen vor, um verschiedene Apps für x86 und x64 zu erstellen:
Schritt 1: Fügen Sie das Code-Snippet in die Datei app/build.gradle . Die Datei wird wie folgt aussehen:

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

Schritt 2: Erstellen Sie eine Release-Apk mit flutter build apk --release
[…]

Stimme deiner Antwort zu. Funktioniert für mich, obwohl ich Schritt 1 nicht befolgen musste (ich habe eine Standardbuild.gradle verwendet)

Dann müssen Sie nur Ihre Build-Nummer und Version erhöhen, damit Google Play sie akzeptiert.

Ich habe immer noch Probleme mit flutter build appbundle auf meiner Hand.

Funktioniert nicht. Ich bin so traurig. Die Anwendung stürzte ab, wenn versucht wurde, auf dem x86-Emulator sowie auf einem echten Armgerät bereitzustellen. Versucht mit Master/Beta/Stable-Kanal. Keine Freigabe bereit. Es ist immer noch Showstopper für uns. Der Appbundle-Befehl generiert ein installierbares Bundle zum Spielen, aber während der Laufzeit zeigt die Anwendung nur den Begrüßungsbildschirm an und friert dann ein. Flutter-Team bitte klare Lösung oder WA bereitstellen.

@mormih danke für deine Geduld - wir arbeiten an der Reproduktion. Wenn es Ihnen nichts ausmacht, könnten Sie mir eine E-Mail ([email protected]) mit folgendem Inhalt senden, es würde helfen:

• Ihre Hostplattform, die Sie zum Erstellen verwenden.
• Der Befehl, den Sie zum Erstellen der App verwenden.
• Führen Sie Ihren Build-Befehl mit --bug-report (zB flutter build appbundle --bug-report ) und hängen Sie die zugehörige bugreport.zip Datei an
• Hängen Sie das generierte App Bundle an, damit wir versuchen können, es auf lokalen Geräten auszuführen
• Hängen Sie die Ergebnisse von adb bugreport an, nachdem Sie versucht haben, die App auszuführen

Danke!

@tvolkert Ich habe auch das Problem, dass es mit der folgenden Meldung abstürzt:

Prüfung fehlgeschlagen: VM. Die VM muss initialisiert werden können.

Meine Host-Plattform ist ein Mac und macOS 10.14.5. Konnten Sie es reproduzieren oder möchten Sie, dass ich die oben beschriebenen Schritte befolge? Vielleicht sollte dies auch ein spezielles Ticket haben, da es sich um ein separates Problem vom OP-Problem handelt. Prost

@mormih Ich bin mir nicht sicher, aber hast du versucht, auch x86 in die Abi-Liste aufzunehmen?

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

flutter build appbundle (auf Master) hat bei mir auch nicht funktioniert, lasse den Splashscreen hängen, wie andere es bemerkt haben ...

Die einzige Problemumgehung, die ich bisher für die Veröffentlichung (im Play Store) für 32- und 64-Bit gefunden habe, ist die folgende. (Teilweise im Thread behandelt, könnte aber jemandem helfen):

1. Erstellen Sie eine APK mit dem v7-Filter auf + dem Standard-Build-APK-Befehl:
   In Ihrer app/build.gradle-Datei:
   defaultConfig { ... ndk{ abiFilters "armeabi-v7a" } }
   und dann lauf
   flutter build apk
   (standardmäßig --release)

2. Verbessern Sie Ihre Build-Nummer in pubspec.yaml.
   ZB von version: 1.1.0+6 bis version: 1.1.0+7

3. Erstellen Sie eine APK mit dem v8-Filter auf + Build mit arm64 als Zielplattform:
   Aktualisieren Sie nun die build.gradle wie folgt:
   defaultConfig { ... ndk{ abiFilters "arm64-v8a" } }
   und dann lauf
   flutter build apk --release --target-platform android-arm64

Beinhaltet den Aufwand für das Hochladen von 2 APKs (und damit das Erstellen von 2 Build-Nummern), aber zumindest scheint es die Aufgabe zu erfüllen und ich kann sowohl für 32- als auch für 64-Bit-Geräte veröffentlichen ...

Hinweis: Ich lasse x86 los, da dies nur eine sehr kleine Gruppe von Mobilgeräten betrifft (und möglicherweise keine meiner Benutzer), und ich brauche keinen Release-Build im Emulator (Debugging reicht zum Testen). Aber das mag bei anderen natürlich nicht der Fall sein.

Die @ezmegy- Methode ist die einzige, die für mich funktioniert hat. Danke

Irgendwo oben in den Kommentaren hat das jemand hinterlassen.

Dies hat für mich funktioniert und es ist nur 1 Terminalcode.
Es gibt 2 Dateien aus, die ich jedoch hasse, und es werden 2 Versionen erstellt.

@ezmegy Danke! Du rettest meinen Tag

Danke @ezmegy , dein "Trick" funktioniert!

Danke @ezmegy !
Ich möchte meinen aktuellen Workflow teilen, der hilfreich sein könnte:

Erstellen Sie einige Build-Varianten auf app/build.gradle pro Architektur

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

Dann kann ich beides bauen mit:
flutter build apk --flavor arm32
und
flutter build apk --flavor arm64 --target-platform android-arm64
ohne das Gradle bei jedem Build zu ändern

Was den Versionscode betrifft, würde ich es vorziehen, einen standardmäßig festzulegen und die anderen davon abzuleiten
ZB arm32 mit 1.0.0+10000 setzen und Versionscode für arm64 generieren, der 1.0.0+10000 ist
Dies sollte einfach mit bash zu generieren sein (oder innerhalb von fastfile, wenn Sie fastlane verwenden).

Sie können die Build-Nummer mit --build-number Argumenten oder über Fastlane festlegen, wenn Sie eines verwenden

Dieses Versionscode-Scripting hilft mir in CI/CD 😄

CMIIW

Bei mir hat das ganz gut geklappt
https://github.com/flutter/flutter/issues/10728#issuecomment -461375218

Wird ein langer Kommentar, aber das hat das Problem komplett behoben

Das war meine Lösung:

1. in 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. flutter build apk --release --target-platform=android-arm ausführen
2. app-armeabi-v7a-release.apk in den Play Store hochladen
3. inkrementieren versionCode
4. flutter build apk --release --target-platform=android-arm64 run ausführen
5. app-arm64-v8a-release.apk in den Play Store hochladen

Der Google Play Store wird die App entsprechend der Gerätearchitektur bereitstellen. 32-Bit-Geräte sind glücklich, 64-Bit-Geräte sind glücklich, und ich bin glücklich zu wissen, dass meine APK-Größe relativ klein bleibt und trotzdem beide Architekturen bedient.
Wenn wir beide Architekturen im selben APK unterstützen, rechnen Sie mit einer App-Größe von über 10 MB

Das Befolgen dieser Schritte bedeutete "Gradle build konnte kein Android-Paket erstellen". Error
_ Nach einer Stunde Debugging die Lösung gefunden. _

Gehen Sie folgendermaßen vor, um verschiedene Apps für x86 und x64 zu erstellen:

Schritt 1: Fügen Sie das Code-Snippet in die app/build.gradle Datei ein. Die Datei wird wie folgt aussehen:

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

Schritt 2: Erstellen Sie eine Release-Apk mit flutter build apk --release
Dadurch wird die x86-basierte APK im Ordner build/app/outputs/apk/app.apk
Laden Sie diese APK in den Google Play Store hoch.
x86 bis jetzt fertig

Führen Sie zu diesem Zeitpunkt nicht flutter clean
Ich habe dies getan und beim Erstellen von x64 apk Fehler erhalten

Schritt 3: Öffnen Sie nun pubspec.yaml und ändern Sie die version von
version: 1.0.0+1 bis version: 1.0.0+2

Die Zahl neben + ist der Versionscode

Schritt 4: Führen Sie nun den Befehl aus
flutter build apk --release --target-platform=android-arm64

Nachdem dieser Befehl abgeschlossen ist, gehen Sie zu build/app/outputs/apk/release/ . Darin finden Sie eine apk mit dem Namen app-arm64-v8a-release.apk . Dies ist Ihre 64-Bit-APK-Datei mit einem anderen Versionscode.

Laden Sie nun diese x64-APK in den Play Store hoch ... und los geht's. Sie haben sowohl x86- als auch x64-Apps in den Play Store hochgeladen.

Bei mir funktioniert es auch ohne Schritt 1. Danke an alle. Ich habe ndk-Filter verwendet ndk {
abiFilter "armeabi-v7a", "x86"
}
in der Build-Gradle-Datei. Ich weiß nicht, ob es erforderlich ist oder nicht. Ansonsten hatte ich alle Schritte ab Schritt 2 befolgt und zwei APKs hochgeladen, eine für 32 Bit und eine für 64 Bit.

Früher hatte ich Appbundle hochgeladen, diesmal APK-Dateien. Funktioniert gut. Ich muss mit Appbundle überprüfen und auch versuchen, das Problem zu beheben, ohne zwei APKs hochzuladen.

Notiz :
Bevor dieser Vorgang ausgeführt wurde, ist meine App bei folgenden Arm-64-Bit-Geräten abgestürzt
Redmi MI,
Redmi 3S Prime
Ehre 8x

Eingearbeitet in folgenden Arm-64-Bit-Geräten
Samsung Galaxy J4
Samsung On8

Hallo Flutter-Team,

Bitte Berücksichtigen Sie auch andere App-Märkte wie beispielsweise in China. In China dürfen wir den Google Play Store nicht nutzen, stattdessen haben wir viele App-Märkte wie die XiaoMi's, die HuaWei's und die Ali's ...etc.

In diesen App-Märkten dürfen wir KEINE APK-Versionen in verschiedenen Architekturen bereitstellen, wir können nur EINE UND NUR EINE APK pro Version hochladen, und diese Version überschreibt die APK der vorherigen Version. Das bedeutet, dass die aktuelle Problemumgehung darin besteht, "armeabi-v7a" zu verwenden.

Korrigieren Sie mich, wenn ich falsch liege, indem Sie "armeabi-v7a" verwenden, werden alle 64-Bit-Geräte 32-Bit-libflutter.so ausführen, und ich denke, es wird langsamer.

Ich würde daher vorschlagen, ob das Flutter-Team eine Methode bereitstellen kann, die es uns ermöglicht, eine APK zu erstellen, die sowohl 32-Bit- als auch 64-Bit-libflutter.so enthält, obwohl die Größe der APK größer sein wird. (In China haben wir normalerweise eine sehr schnelle Internetgeschwindigkeit und wir zahlen wenig, um unbegrenzte 4G-Nutzungspläne zu haben, und die Leute kümmern sich normalerweise nicht um die Größe der APK)

Hallo Flutter-Team,

Bitte Berücksichtigen Sie auch andere App-Märkte wie beispielsweise in China. In China dürfen wir den Google Play Store nicht nutzen, stattdessen haben wir viele App-Märkte wie die XiaoMi's, die HuaWei's und die Ali's ...etc.

In diesen App-Märkten dürfen wir KEINE APK-Versionen in verschiedenen Architekturen bereitstellen, wir können nur EINE UND NUR EINE APK pro Version hochladen, und diese Version überschreibt die APK der vorherigen Version. Das bedeutet, dass die aktuelle Problemumgehung darin besteht, "armeabi-v7a" zu verwenden.

Korrigieren Sie mich, wenn ich falsch liege, indem Sie "armeabi-v7a" verwenden, werden alle 64-Bit-Geräte 32-Bit-libflutter.so ausführen, und ich denke, es wird langsamer.

Ich würde daher vorschlagen, ob das Flutter-Team eine Methode bereitstellen kann, die es uns ermöglicht, eine APK zu erstellen, die sowohl 32-Bit- als auch 64-Bit-libflutter.so enthält, obwohl die Größe der APK größer sein wird. (In China haben wir normalerweise eine sehr schnelle Internetgeschwindigkeit und wir zahlen wenig, um unbegrenzte 4G-Nutzungspläne zu haben, und die Leute kümmern sich normalerweise nicht um die Größe der APK)

In Ihrem Fall können Sie die Standard-32-Bit-Datei bereitstellen und alles wird gut, oder?
Die 64-Bit-Warnung gilt nur für Google Play. Ich glaube, das ist kein Thema für China.
(Bitte korrigiert mich, wenn ich falsch liege.)

@ KunalT6569 Ich denke, Schritt 3 wie von Ihnen angegeben:

Schritt 3: Öffnen Sie nun pubspec.yaml und ändern Sie die Version von
Version: 1.0.0+1 bis Version: 1.0.0+2

ist erforderlich, um das Hochladen beider APK-Dateien auf die Google Play Console zu ermöglichen, nicht wahr?

Ich habe noch eine Frage - sobald beide APK-Dateien fertig sind, laden Sie sie einfach über den Abschnitt App releases\New Release\Browse Files hoch, nicht wahr?

@angel1st Ja, Schritt 3 ist erforderlich, da Google Play das Hochladen von zwei APKs mit denselben Versionscodes nicht zulässt.

Um mehrere APKs bei Google Play hochzuladen, habe ich auf dieses Video verwiesen.
https://www.youtube.com/watch?v=rMl_oLlf_g0

Zu Ihrer Information:

Unser derzeitiger Plan ist es, in den kommenden 10 Tagen eine Beta mit einer der jüngsten Entwicklerversionen zu veröffentlichen. Dann planen wir zu warten, bis wir einen aktualisierten dokumentierten Prozess für den Versand auf Android haben, der die Warnungen zu 64-Bit-Builds aus dem Play Store nicht auslöst, eine Möglichkeit zu haben, ein APK zu verpacken, das 64-Bit unterstützt, und zu beweisen Wir können die Galerie mit diesem Prozess veröffentlichen und sobald wir dies getan haben, um dem Prozess zu folgen, um eine neue Beta zu veröffentlichen, die wir dann etwa eine Woche später in den Stable verschieben werden.

Dies bedeutet, dass wir wahrscheinlich Anfang Juni eine Beta und Ende Juni oder Anfang Juli eine Beta haben werden, die kurz darauf stabil wird.

@Hixie Hier ist ein weiteres Problem
App Bundle von neuestem Flutter (Master ab sofort) generiert keine x86-, x86_64-Versionen
Von Master-Zweig erstellte Dateien

Von der alten Version mit Android Studio generierte Dateien

Erwartetes Verhalten ist, auch x86-, x86_64-Versionen in die Datei aufzunehmen, die von der neuen Version erzeugt wird

@canewsin Unabhängig von diesem Problem stellen wir keine x86-Release-Binärdateien bereit (https://github.com/flutter/flutter/issues/9253) - ist die "alte Version" in https://github.com/flutter/ flatter/issues/18494#issuecomment -497118805 bezieht sich auf einen Debug-Build?

Ich habe das gleiche Problem, das Erstellen für 32-Bit schließt 64-Bit-Geräte aus, es läuft jedoch darauf. Das Erstellen für 64 durch Angabe von --target-platform android-arm64 funktioniert auf 64-Bit-Geräten, stürzt jedoch auf 32-Bit-Geräten ab. Außerdem wird Google 2019 den Upload von APKs auf 64-Bit beschränken.

Flutter-Team, bitte lösen Sie dieses grundlegende Problem!

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

Ich habe meine App mit dem neuesten Flatter-Master-Zweig kompiliert und als App-Bundle in den Play Store hochgeladen, aber die App stürzt auf dem Gerät ab. Dieses Protokoll stammt aus dem Testlabor

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

Flatterarzt -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 sieht so aus, als ob dieses Problem in https://github.com/flutter/engine/pull/9078 behoben wurde git fetch upstream && git merge upstream/master

Nachdem ich wiederholte Fragen gesehen habe, die in früheren Kommentaren bereits beantwortet wurden, habe ich einen kurzen Artikel geschrieben, der dokumentiert, welche Möglichkeiten wir jetzt haben https://medium.com/@truongsinh/flutter -android-64-bit-so-what-the-fuss -15da6f8e3a46. Hier ist das TLDR:

@truongsinh , wir stellen auch die Unterstützung für die Verwendung von flutter build appbundle zum Erstellen eines App-Bundles mit 32- und 64-Bit-Binärdateien für die Bereitstellung im Play Store fertig. Weitere Informationen finden Sie unter https://github.com/flutter/flutter/issues/31922 - bitte probieren Sie es aus und lassen Sie es uns wissen, wenn Probleme auftreten.

@truongsinh , wir stellen auch die Unterstützung für die Verwendung von flutter build appbundle zum Erstellen eines App-Bundles mit 32- und 64-Bit-Binärdateien für die Bereitstellung im Play Store fertig. Weitere Informationen finden Sie unter #31922 - bitte probieren Sie es aus und lassen Sie es uns wissen, wenn Probleme auftreten.

Ja, ich warte immer noch darauf, dass flutter build appbundle die App produziert, die nicht hängen bleibt oder abstürzt :D

Ja, ich warte immer noch darauf, dass das Flatter-Build-Appbundle eine App produziert, die nicht hängen bleibt oder abstürzt :D

Bestätigt 🙂 . Wenn Sie einen reproduzierbaren Fall von diesem Ereignis haben, den wir uns ansehen können, wäre das großartig. Wenn Sie bereit wären, eine unsignierte .aab-Datei aus der Version 1.7.1 zu erstellen und sie mir per E-Mail ([email protected]) zu senden, würde ich mich freuen!

Zu Ihrer Information , die folgende Ankündigung wurde bezüglich unserer 64-Bit-Unterstützung an

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

Ich habe dieses Problem auch.

Wenn ich ein App-Bundle in Android Studios erstelle, kann ich es gut auf meinen Simulator laden, aber es stürzt die App ab, wenn ich es aus dem Play Store herunterlade

Hallo Leute, die den Flatter-Master-Zweig verwenden und App-Bundles erstellen
Wenn Sie Ihre App debuggen, läuft Ihre App einwandfrei
einige Gesichter stürzen beim Herunterladen aus dem Play Store ab Wenn dies passiert, müssen Sie Ihr App-Bundle überprüfen, ob es auf Ihrem Gerät funktioniert, da der Debug-Modus JIT-Binärdateien und der Release-Modus AOT-Binärdateien erzeugt. Derzeit sind ihre Platzierungen auch unterschiedlich
Produzieren Sie APK aus dem App-Bundle für nur eine bestimmte Konfiguration basierend auf Ihrem Gerät und deinstallieren Sie die Debug-App vollständig von Ihrem Gerät und installieren Sie diese neue Ausgabe-App aus dem App-Bundle. .

Ref für Ausgabe an APK von Ihrem App Bundle aus der cmd-Zeile
https://developer.android.com/studio/command-line/bundletool

Zu Ihrer Information, die Abstürze in den App-Bundles werden in https://github.com/flutter/flutter/issues/31922 besser verfolgt

Hallo zusammen,

TLDR:

Wir haben das Problem mit den Abstürzen beim Herunterladen aus dem Play Store identifiziert und arbeiten an einer Lösung, die innerhalb des gleichen Zeitraums wie oben in https://github.com/flutter/flutter/issues/31922#issuecomment beschrieben geliefert werden soll -498880614

Erklärung auf hohem Niveau

Für Interessierte ist die etwas lange Erklärung, dass der Play Store bei Geräten mit Android Marshmallow oder höher Apps erkennt, die als App Bundles mit mehreren ABIs verpackt sind – und diese Apps auf dem Gerät in Form von "split" installiert APKs". Dabei werden die darin enthaltenen .so-Dateien nicht aus dem APK-Zip-Archiv extrahiert, was sich vom Verhalten nicht geteilter APKs unterscheidet. Da der aktuelle Mechanismus der Flutter-Engine

Die Lösung besteht darin, nur dlopen die Bibliotheken zu

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

Ich erhalte diese Fehlermeldung, nachdem ich das Code-Snippet zu build.gradle hinzugefügt habe
Gradle build failed to produce an Android package.

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

Ich erhalte diese Fehlermeldung, nachdem ich das Code-Snippet zu build.gradle hinzugefügt habe
Gradle build failed to produce an Android package.

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

Könnte jemand das Problem lösen? Ich habe eine App auf Flatter, die nur ihre 32-Bit-APK funktioniert, aber die 64er funktionieren nicht oder werden nicht installiert. Ich teste auf einem 64-Bit-Handy

@CgarciaTC siehe https://github.com/flutter/flutter/issues/18494#issuecomment -500101807 für das neueste Update

Hallo zusammen,

Wir glauben, dass die Fixes alle auf dem Kanal master gelandet sind. Wenn Sie sie ausprobieren möchten, gehen Sie wie folgt vor:

• flutter build appbundle

  Standardmäßig enthält das App Bundle Ihren Dart-Code und die Flutter-Laufzeit, die für armeabi-v7a (32-Bit) und arm64-v8a (64-Bit)

• flutter build apk --split-per-abi

  Dieser Befehl führt zu zwei APKs:

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

• flutter build apk

  Dies führt zu einem fetten APK, das Ihren für alle Ziel-ABIs kompilierten Code enthält. Solche APKs sind größer als ihre geteilten Gegenstücke, was dazu führt, dass der Benutzer native Binärdateien herunterlädt, die nicht für die Architektur ihres Geräts geeignet sind.

flatter build apk --split-per-abi
Dieser Befehl führt zu zwei APKs:
build/app/outputs/apk/release/app-armeabi-v7a-release.apk
build/app/outputs/apk/release/app-arm64-v8a-release.apk

@tvolkert -

@angel1st es wird automatisch verwaltet, wenn die APKs erstellt werden, gemäß der Anleitung in https://developer.android.com/studio/build/configure-apk-splits#configure -APK-versions

@tvolkert Gibt es Informationen darüber, wann dies im stabilen Kanal landen wird?

@ndusart , ja - siehe https://github.com/flutter/flutter/issues/18494#issuecomment -498880287

Kann bestätigen, dass dies (nach dem Wechsel zum Master) auf mehreren Android-Geräten funktioniert. Was für ein Lebensretter, danke.

@tvolkert Vielen Dank. Gibt es einen Zeitplan, um dies in Flutter Stable zu bekommen?

@harsha973 siehe https://github.com/flutter/flutter/issues/18494#issuecomment -498880287

@harsha973 Sie markieren und stellen genau die gleiche Frage, die er 2 Posts über Ihnen beantwortet hat. Nicht nur ignorant, sondern am Rande der Respektlosigkeit.

@PerLycke tut

Ich habe den Master-Kanal ausgecheckt, Flatter aktualisiert und kann die App jetzt nicht wirklich mit dem Befehl erstellen:
flutter build apk --release --flavor production -t lib/main.dart
Das Ergebnis ist:

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

Die Antworten zu ähnlichen StackOverflow-Problemen helfen nicht wirklich.

@MichaelRFairhurst flutter build apk --release hat bei mir gut funktioniert, daher erfordern die neuen Updates für Master möglicherweise auch eine Aktualisierung Ihrer Geschmackseinstellungen.

Ich weiß, es ist keine Antwort, sorry, aber zumindest ein Hinweis in die richtige Richtung.

Wann wird der Fix in die Beta-Phase gehen?

@derolf siehe https://github.com/flutter/flutter/issues/18494#issuecomment -498880287 als neuestes Update mit Zielzeitplänen.

Hallo zusammen,

Diese Fixes sind jetzt live im dev Kanal, ab der Version v1.7.4 oder höher.

Während ich versuche, dieses 64-Bit-Zeug herauszufinden, habe ich das gleiche Problem wie @michalsuryntequiqo und kann jetzt nichts über die CLI erstellen. Es baut und läuft gut über Android Studio....
flutter build apk --flavor=dev -t lib/main-dev.dart ausführen

[   +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.

Arzt

Bearbeiten:
habe es gerade mit dem Commit kurz vor 8627ff433b4658195e66b9c0034902116f53d580 versucht und es erzeugt die APK mit dem üblichen Fehler Gradle build failed to produce an Android package. wegen https://github.com/flutter/flutter/issues/24106

@blasten Hast du eine Idee, wie du das mit deinen Änderungen wieder zum

Bearbeiten 2:
Dazu eine neue Ausgabe geöffnet :

Ich habe heute die Flatterdokumentation gelesen und gefunden:

Von der Befehlszeile:

CD eingeben
(Ersetzenmit dem Verzeichnis Ihrer Anwendung.)
Flatter build apk ausführen --split-per-abi
(Der Befehl flatter build ist standardmäßig --release.)
Dieser Befehl führt zu zwei APK-Dateien:

/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 Welche Versionscodes werden verwendet, wenn --split-per-abi ?

Ich habe es in der Dokumentation gesehen und dachte, es hier zu veröffentlichen. Ich habe es nicht getestet.
Ich hatte den Befehl ausgeführt und funktionierte nicht. Es sagt:

Eine Option namens "split-per-abi" konnte nicht gefunden werden.

Führen Sie 'flattern -h' (oder 'flattern-h') für verfügbare Flatterbefehle und Optionen.

flattern arzt:

Flutter 1.6.3 • Kanal-Beta • https://github.com/flutter/flutter.git
Framework • Überarbeitung bc7bc94083 (vor 4 Wochen) • 2019-05-23 10:29:07 -0700
Motor • Revision 8dc3a4cde2
Werkzeuge • Dart 2.3.2 (build 2.3.2-dev.0.0 e3edfd36b2)

"Flatter Pub Upgrade" in consumos_app ausführen... 19,8s

Laufender Flatterarzt...
Zusammenfassung des Arztes (um alle Details zu sehen, führen Sie flatter doctor -v aus):
[√] Flutter (Channel Beta, v1.6.3, auf Microsoft Windows [Version 10.0.17134.829], Gebietsschema es-AR)
[√] Android-Toolchain - für Android-Geräte entwickeln (Android SDK Version 28.0.3)
[√] Android Studio (Version 3.4)
[√] IntelliJ IDEA Ultimate Edition (Version 2019.1)
[√] VS-Code (Version 1.26.1)
[√] VS Code, 64-Bit-Edition (Version 1.33.1)
[!] Verbundenes Gerät
! Keine Geräte verfügbar

Ich denke, diese Funktion wird bald verfügbar sein.

Ich habe es in der Dokumentation gesehen und dachte, es hier zu veröffentlichen. Ich habe es nicht getestet.
Ich hatte den Befehl ausgeführt und funktionierte nicht. Es sagt:

Eine Option namens "split-per-abi" konnte nicht gefunden werden.
Führen Sie 'flatter -h' (oder 'flatter -h') aus, um die verfügbaren Flatter-Befehle und -Optionen anzuzeigen.

flattern arzt:

Flutter 1.6.3 • Kanal-Beta • https://github.com/flutter/flutter.git
Framework • Überarbeitung bc7bc94 (vor 4 Wochen) • 2019-05-23 10:29:07 -0700
Motor • Revision 8dc3a4cde2
Werkzeuge • Dart 2.3.2 (build 2.3.2-dev.0.0 e3edfd36b2)
"Flatter Pub Upgrade" in consumos_app ausführen... 19,8s
Laufender Flatterarzt...
Zusammenfassung des Arztes (um alle Details zu sehen, führen Sie flatter doctor -v aus):
[√] Flutter (Channel Beta, v1.6.3, auf Microsoft Windows [Version 10.0.17134.829], Gebietsschema es-AR)
[√] Android-Toolchain - für Android-Geräte entwickeln (Android SDK Version 28.0.3)
[√] Android Studio (Version 3.4)
[√] IntelliJ IDEA Ultimate Edition (Version 2019.1)
[√] VS-Code (Version 1.26.1)
[√] VS Code, 64-Bit-Edition (Version 1.33.1)
[!] Verbundenes Gerät
! Keine Geräte verfügbar

Ich denke, diese Funktion wird bald verfügbar sein.

Bitte beachten Sie, dass dies nur auf dem Kanal dev / ab Version 1.7.4 möglich ist. Du betreibst beta Kanal / Version 1.6.3

Ich habe es gerade ausprobiert (Erstellen und Veröffentlichen mit Codemagic) und es hat wirklich gut funktioniert. Danke!

Google beschwert sich immer noch, dass ich Appbundle nicht verwende. Angesichts dieser Warnung macht die Veröffentlichung von APKs vielleicht nicht viel Sinn?

Ich würde Appbundle verwenden - aber dies verhindert, dass die automatisierten Tests von Google (Erzeugung des Pre-Launch-Berichts) funktionieren. Soll ich dafür eine neue Ausgabe eröffnen?

@nohli Wir haben die Dokumentation aktualisiert, um die neuesten Informationen zu App Bundles/APKs zu berücksichtigen: https://flutter.dev/docs/deployment/android#building -the-app-for-release.

Fühlen Sie sich frei, das Problem zu den automatisierten Tests von Google zu melden.

Ich baue meine App aus dem Bundle, aber nach der Ausführung auf 64-Bit-Geräten sagt libflutter.so fehlt, indem ich eine App für 32-Bit-Geräte und 64-Bit-Geräte erstelle. Wie füge ich libflutter.so für beide Architekturen in einer einzelnen Bundle-Datei hinzu?

@nohli Wir haben die Dokumentation aktualisiert, um die neuesten Informationen zu App Bundles/APKs zu berücksichtigen: https://flutter.dev/docs/deployment/android#building -the-app-for-release.

Fühlen Sie sich frei, das Problem zu den automatisierten Tests von Google zu melden.

@blasten Das im Link angegebene Verfahren hat kein 64-Bit-APK im Bundle erzeugt. Als ich das Bundle hochgeladen habe, hatte der Google Play Store den gleichen Fehler, der besagt, dass Ihr APK nicht 64-Bit-kompatibel ist.

@wal33d006 siehe Haftungsausschluss oben auf der Seite – er gilt nur für v1.7.4 oder höher (derzeit Entwickler- oder Masterkanäle).

@wal33d006 siehe Haftungsausschluss oben auf der Seite – er gilt nur für v1.7.4 oder höher (derzeit Entwickler- oder Masterkanäle).

@tvolkert Ich kann meine Anwendung nicht einmal über Entwicklungs- oder

Dies ist meine Ausgabe, wenn ich sie auf Dev- oder Master-Kanälen baue:

Compiler-Meldung:
file:///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image. dart:199 :38: Fehler: Der Argumenttyp 'void Function(ImageInfo, bool)' kann dem Parametertyp 'ImageStreamListener' nicht zugewiesen werden.

• 'ImageInfo' ist von ' package:flutter/src/painting/image_stream.dart ' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
• 'ImageStreamListener' ist von ' package:flutter/src/painting/image_stream.dart ' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
  Versuchen Sie, den Typ des Parameters zu ändern oder das Argument in 'ImageStreamListener' umzuwandeln.
  oldImageStream?.removeListener(_handleImageChanged);
  ^
  file:///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image. dart:200 :32: Fehler: Der Argumenttyp 'void Function(ImageInfo, bool)' kann dem Parametertyp 'ImageStreamListener' nicht zugewiesen werden.
• 'ImageInfo' ist von ' package:flutter/src/painting/image_stream.dart ' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
• 'ImageStreamListener' ist von ' package:flutter/src/painting/image_stream.dart ' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
  Versuchen Sie, den Typ des Parameters zu ändern oder das Argument in 'ImageStreamListener' umzuwandeln.
  _imageStream.addListener(_handleImageChanged);
  ^
  file:///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image. dart:210 :34: Fehler: Der Argumenttyp 'void Function(ImageInfo, bool)' kann dem Parametertyp 'ImageStreamListener' nicht zugewiesen werden.
• 'ImageInfo' ist von ' package:flutter/src/painting/image_stream.dart ' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
• 'ImageStreamListener' ist von ' package:flutter/src/painting/image_stream.dart ' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart ').
  Versuchen Sie, den Typ des Parameters zu ändern oder das Argument in 'ImageStreamListener' umzuwandeln.
  _imageStream?.removeListener(_handleImageChanged);
  ^
  file:///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image. dart:465 :31: Fehler: Der Argumenttyp 'Null Function(StringBuffer)' kann dem Parametertyp 'Iterable . nicht zugewiesen werdenFunktion()'.
• 'StringBuffer' ist von ' dart:core '.
• 'Iterable' ist von ' dart:core '.
• 'DiagnosticsNode' ist von ' package:flutter/src/foundation/diagnostics.dart ' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/foundation/diagnostics.dart ').
  Versuchen Sie, den Typ des Parameters zu ändern oder das Argument in "Iterable" umzuwandelnFunktion()'.
  informationCollector: (StringBuffer-Informationen) {
  ^
  Compiler wurde unerwartet beendet.

FAILURE: Build ist mit einer Ausnahme fehlgeschlagen.

• Wo:
  Skript '/Users/waleed/Developer/flatter-sdk/flatter/packages/flatter_tools/gradle/flutter.gradle' Zeile: 638

• Was schief gelaufen ist:
  Ausführung für Aufgabe ': app:compileflutterBuildReleaseArm '

  Prozess 'Befehl '/Users/waleed/Developer/flatter-sdk/flatter/bin/flatter'' beendet mit einem Ausgangswert ungleich Null 1

• Versuchen:
  Führen Sie die Option mit der Option --stacktrace aus, um den Stacktrace abzurufen. Führen Sie die Option mit --info oder --debug aus, um mehr Protokollausgaben zu erhalten. Führen Sie mit --scan aus, um vollständige Einblicke zu erhalten.

• Weitere Hilfe erhalten Sie unter https://help.gradle.org

BAUEN FEHLGESCHLAGEN in 14 s
Gradle-Aufgabe 'bundleRelease' wird ausgeführt...
Gradle-Aufgabe 'bundleRelease' wird ausgeführt... Fertig 15.0s
Gradle-AufgabenbündelRelease fehlgeschlagen mit Exit-Code 1

@wal33d006 package:cached_network_image ist jetzt Version 0.8.0 und Sie verwenden 0.5.1 -- es sieht so aus, als ob Sie Ihre Versionseinschränkung aktualisieren müssen, wenn Sie gegen die neuere Version von Flutter laufen deine pubspec.yaml und flutter packages upgrade

@tvolkert Sie sagen, dass in v1.7.4 die Datei libflutter.so automatisch für 64-Bit-Geräte hinzugefügt wird, wenn wir das Bundle mit dem Befehl flattern build appbundle erstellen ?

@nimesh1997 yep, obwohl der Build, der es stabil macht, wahrscheinlich eine neuere Version sein wird.

@tvolkert Ich habe meinen Kanal in ### Master-Channel geändert und auch die ### package:cached_network_image-Version auf 0.8.0 aktualisiert, indem ich innerhalb der pubspec.yaml geändert habe. Aber beim Ausführen von Flatterpaketen upgraden. Fehler wird unten wie folgt angezeigt:
**Da cached_network_image >=0.7.0 von flatter_cache_manager ^0.3.2 abhängt, der von path_provider ^0.5.0+1 abhängt, erfordert cached_network_image >=0.7.0 path_provider ^0.5.0+1.

@nimesh1997 können Sie ein separates Problem CC setzen ? Es gibt Hunderte von Leuten, die diesen Fehler abonniert haben.

@tvolkert Wann wird die Flutter-Version 1.7.4 im stabilen Kanal verfügbar sein und wenn der unten erwähnte Fehler in der Flutter-Version 1.7.4 behoben ist, läuft sie aufgrund dieses Fehlers nicht auf 64-Bit-Geräten (libflutter.so fehlt)?

Dies ist die Ausgabe, die ich erhalte, wenn ich auf Flatter v1.7.4 oder höher laufe

Compiler-Meldung:
file:///home/zunroof-dev-4/package_flutter/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_image-1.0.0/lib/network. Pfeil:75 :31:
Fehler: Der Argumenttyp 'Null Function(StringBuffer)' kann dem Parametertyp 'Iterable . nicht zugewiesen werdenFunktion()'.

• 'StringBuffer' ist von ' dart:core '.
• 'Iterable' ist von ' dart:core '.
• 'DiagnosticsNode' ist von ' package:flutter/src/foundation/diagnostics.dart ' ('file:///home/zunroof-dev-4/package_flutter/flutter/packages/flutter/lib/src/foundation/diagnostics.dart ').
  Versuchen Sie, den Typ des Parameters zu ändern oder das Argument in "Iterable" umzuwandelnFunktion()'.
  informationCollector: (StringBuffer-Informationen) {
  ^
  file:///home/zunroof-dev-4/package_flutter/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_image-1.0.0/lib/network. dart:168 :65: Fehler: Der Argumenttyp 'String' kann dem Parametertyp 'DiagnosticsNode' nicht zugewiesen werden.
• 'DiagnosticsNode' ist von ' package:flutter/src/foundation/diagnostics.dart ' ('file:///home/zunroof-dev-4/package_flutter/flutter/packages/flutter/lib/src/foundation/diagnostics.dart ').
  Versuchen Sie, den Typ des Parameters zu ändern oder das Argument in 'DiagnosticsNode' umzuwandeln.
  Kontext: '$runtimeType konnte ${instructions.uri} nicht laden',
  ^
  Compiler wurde unerwartet beendet.

Fehler beim Kompilieren, erzeugt keine Protokolle und flatterdoctor -v weist nicht auf Fehler hin. was sollte ich tun?

Wenn Sie die App im Play Store bereitstellen, wird empfohlen, App . zu verwenden
bündelt oder teilt das APK, um die APK-Größe zu reduzieren.
Um ein App Bundle zu generieren, führen Sie Folgendes aus:
flatter build appbundle --target-platform android-arm,android-arm64
Erfahren Sie mehr auf: https://developer.android.com/guide/app-bundle
Führen Sie Folgendes aus, um die APKs pro ABI aufzuteilen:
flatter build apk --target-platform android-arm,android-arm64
--split-per-abi
Erfahren Sie mehr über:
https://developer.android.com/studio/build/configure-apk-splits#configur
e-abi-split
Gradle initialisieren... 7,4s
Abhängigkeiten auflösen... 4,3s
registerResGeneratingTask ist veraltet, verwenden Sie registerGeneratedResFolders(FileCollection)
registerResGeneratingTask ist veraltet, verwenden Sie registerGeneratedResFolders(FileCollection)
registerResGeneratingTask ist veraltet, verwenden Sie registerGeneratedResFolders(FileCollection)
Gradle-Aufgabe 'assembleRelease' wird ausgeführt...
Gradle-Aufgabe 'assembleRelease' wird ausgeführt... Fertig 9,0s

Gradle build konnte kein Android-Paket erstellen.

@leonardop21 versuch es mit

Flatterlauf -v

@canewsin

OMG. ich hab keine ahnung was ich jetzt machen soll

Gradle build konnte kein Android-Paket erstellen.

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

1 _buildGradleProjectV2

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

2 _asyncThenWrapperHelper.

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

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

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

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

6 Future._propagateToListeners.handleValueCallback

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

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

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

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

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

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

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

13 _asyncThenWrapperHelper.

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

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

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

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

17 Future._propagateToListeners.handleValueCallback

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

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

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

20 Future._asyncComplete.

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

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

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

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

24 _CustomZone.bindCallbackGuarded.

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

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

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

27 _runPendingImmediateCallback

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

28 _RawReceivePortImpl._handleMessage

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

Wir haben unsere Dokumentation aktualisiert, um anzugeben, wie Sie APKs mit 32-Bit- und 64-Bit-Binärdateien erstellen können. https://flutter.dev/docs/deployment/android#building -the-app-for-release .

Bitte verwenden Sie den Kanal dev : v1.7.9 oder höher. Das Team arbeitet daran, die neuesten Beta-Änderungen bis Freitag (28.06.2019) bekannt zu geben.

Compiler-Meldung:
file:///Users/systemgnk/Desktop/flutter/.pub-cache/hosted/pub.dartlang.org/flare_flutter-1.5.2/lib/flare. dart:1033 :18: Fehler: Der Argumenttyp 'Int32List' kann dem Parametertyp 'Uint16List' nicht zugewiesen werden.

• 'Int32List' ist von ' dart:typed_data '.
• 'Uint16List' stammt von 'dart:typed_data'.
  Versuchen Sie, den Typ des Parameters zu ändern oder das Argument in 'Uint16List' umzuwandeln.
  Indizes: _indices, textureCoordinates: _uvBuffer);
  ^
  Compiler wurde unerwartet beendet.

FAILURE: Build ist mit einer Ausnahme fehlgeschlagen.

• Wo:
  Skript '/Users/systemgnk/Desktop/flutter/packages/flutter_tools/gradle/flutter.gradle' Zeile: 631

• Was schief gelaufen ist:
  Ausführung für Aufgabe ': app:compileflutterBuildReleaseArm '

  Prozess 'Befehl '/Users/systemgnk/Desktop/flatter/bin/flatter'' mit Nicht-Null-Ausgangswert 1 abgeschlossen

• Versuchen:
  Führen Sie die Option mit der Option --stacktrace aus, um den Stacktrace abzurufen. Führen Sie die Option mit --info oder --debug aus, um mehr Protokollausgaben zu erhalten. Führen Sie mit --scan aus, um vollständige Einblicke zu erhalten.

• Weitere Hilfe erhalten Sie unter https://help.gradle.org

BAUEN FEHLGESCHLAGEN in 22 s
Gradle-Aufgabe 'assembleRelease' wird ausgeführt...
Gradle-Aufgabe 'assembleRelease' wird ausgeführt... Fertig 23.3s
Gradle-Aufgabe AssembleRelease fehlgeschlagen mit Exit-Code 1

[✓] Flutter (Kanalentwicklung, v1.7.10, unter Mac OS X 10.13.6 17G65, Gebietsschema en-US)
• Flutter-Version 1.7.10 unter /Users/systemgnk/Desktop/flatter
• Framework-Revision 9a3a7490c8 (vor 2 Tagen), 25.06.2019 15:59:15 +0200
• Motorrevision ae8e6d9f46
• Dart-Version 2.4.0

[✓] Android-Toolchain – Entwicklung für Android-Geräte (Android SDK Version 28.0.3)
• Android SDK unter /Users/systemgnk/Library/Android/sdk
• Android NDK-Standort nicht konfiguriert (optional; nützlich für native Profilerstellung)
• Plattform Android-28, Build-Tools 28.0.3
• Java-Binärdatei unter: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java-Version OpenJDK Runtime Environment (Build 1.8.0_152-release-1248-b01)
• Alle Android-Lizenzen werden akzeptiert.

[✓] Xcode - Entwickeln für iOS und macOS (Xcode 10.1)
• Xcode unter /Applications/Xcode.app/Contents/Developer
• Xcode 10.1, Build-Version 10B61
• CocoaPods-Version 1.6.0

[✓] iOS-Tools – für iOS-Geräte entwickeln
• iOS-Bereitstellung 1.9.4

[✓] Chrome – für das Web entwickeln
• Chrome unter /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (Version 3.3)
• Android Studio unter /Applications/Android Studio.app/Contents
• Flutter-Plugin-Version 33.3.1
• Dart-Plugin-Version 182.5215
• Java-Version OpenJDK Runtime Environment (Build 1.8.0_152-release-1248-b01)

[✓] Verbundenes Gerät (4 verfügbar)
• Android SDK für x86 gebaut • Emulator-5554 • android-x86 • Android 7.0 (API 24) (Emulator)
• iPhone des Systems • 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

• Keine Probleme gefunden!

Ich habe immer noch Probleme mit dem Erstellen von APK.
Ich war nur verfügbar, um 32-Bit-APK im stabilen Kanal zu erstellen.

Ich denke, ich muss warten, bis das Flatter-Team diesen Fehler behoben hat, anstatt dev oder Master Channel SDK zu verwenden.

Danke schön.

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

@ctrysbita Danke für den Link. Ich habe den Kanal auf Master geändert und den Typ von _indices von Int32List auf Uint16List geändert.
apk, das im Play Store hochgeladen wird, hat keine Warnung für 64-Bit und wird nach der Installation von der Play Store-Testseite ausgeführt.

Ich habe andere Probleme mit dem Dev Channel Flatter sdk, wie z. Diese Probleme sind aufgrund des Entwicklungskanals nicht sicher, aber als ich wieder zu Stable und Build zurückkehrte, sind alle Probleme verschwunden. Ich habe nicht viel Zeit, mich mit diesen Themen zu beschäftigen, daher ist es nicht 100% sicher. Tut mir leid, aber vielleicht bekommt jemand einen Hinweis zu diesem Thema.

Das war meine Lösung:

1. in 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. flutter build apk --release --target-platform=android-arm ausführen
2. app-armeabi-v7a-release.apk in den Play Store hochladen
3. inkrementieren versionCode
4. flutter build apk --release --target-platform=android-arm64 run ausführen
5. app-arm64-v8a-release.apk in den Play Store hochladen

Der Google Play Store wird die App entsprechend der Gerätearchitektur bereitstellen. 32-Bit-Geräte sind glücklich, 64-Bit-Geräte sind glücklich, und ich bin glücklich zu wissen, dass meine APK-Größe relativ klein bleibt und trotzdem beide Architekturen bedient.

Wenn wir beide Architekturen im selben APK unterstützen, rechnen Sie mit einer App-Größe von über 10 MB

WO? WO fügen wir der Gradle-Datei den Abschnitt "Splits" hinzu? Ich habe es zwischen Flattern {} und Abhängigkeiten {} hinzugefügt und es wird nicht das erste APK erstellen, wie es sagt:

Bitte überprüfen Sie die Einrichtung Ihres Gradle-Projekts im Ordner android/.

Dies ist also eindeutig nicht richtig, da dies die einzige Änderung ist, die ich seit meinem letzten Build an dem Projekt vorgenommen habe.

@ArtfulDodgerB92 Danke für die Lösung. Welchen Kanal hast du zum Erstellen von APK und Version verwendet?

WO? WO fügen wir der Gradle-Datei den Abschnitt "Splits" hinzu? Ich habe es zwischen Flattern {} und Abhängigkeiten {} hinzugefügt und es wird nicht das erste APK erstellen, wie es sagt:

Bitte überprüfen Sie die Einrichtung Ihres Gradle-Projekts im Ordner android/.

Dies ist also eindeutig nicht richtig, da dies die einzige Änderung ist, die ich seit meinem letzten Build an dem Projekt vorgenommen habe.

@ArtfulDodgerB92 es sollte sich im Abschnitt android{} , wie hier geschrieben: https://developer.android.com/studio/build/configure-apk-splits.html

Zu Ihrer Information , die folgende Ankündigung wurde bezüglich unserer 64-Bit-Unterstützung an

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

Gibt es Neuigkeiten zu einem bevorstehenden Beta-Release?

@nohli wir haben die Beta-Version um ein paar Tage verschoben, um einen Fix (Revert Commit) auf https://github.com/flutter/flutter/issues/35291 zu finden. Wir arbeiten daran, so schnell wie möglich eine Betaversion zu veröffentlichen.

Dies ist jetzt live im Beta-Kanal, in der Version v1.7.8+hotfix.2

Dies ist jetzt live im Beta-Kanal, in der Version v1.7.8+hotfix.2

Сool, wie man eine Release-APK generiert?

Dies ist jetzt live im Beta-Kanal, in der Version v1.7.8+hotfix.2

Сool, wie man eine Release-APK generiert?

Hier ist die Anleitung https://flutter.dev/docs/deployment/android

Dies ist jetzt live im Beta-Kanal, in der Version v1.7.8+hotfix.2

Сool, wie man eine Release-APK generiert?

Hier ist die Anleitung https://flutter.dev/docs/deployment/android

Ich habe es versucht, aber nicht bei 32

Ich habe es versucht, aber nicht bei 32

Was meinst du mit 32 ? Wie "Ich kann eine fette APK generieren, und diese APK funktioniert auf einem 64-Bit-Gerät, stürzt aber auf einem 32-Bit-Gerät ab"?

Können Sie das Ergebnis von flutter doctor posten, Ihrer Schritt-für-Schritt-Anleitung (zB dies ist der Schritt 2 von progard https://flutter.dev/docs/deployment/android#step-2---enable- obfuscation-andor-minification), generieren Sie APK oder AAB und welches Gerät testen Sie?

müssen wir noch setzen
ndk { abiFilters 'armeabi-v7a' , 'x86', 'armeabi' } im Gradle wird nach dem Fix auf Beta nicht mehr benötigt??

@ksamj das wird nicht benötigt.

Ich habe es versucht, aber nicht bei 32

Was meinst du mit 32 ? Wie "Ich kann eine fette APK generieren, und diese APK funktioniert auf einem 64-Bit-Gerät, stürzt aber auf einem 32-Bit-Gerät ab"?

Können Sie das Ergebnis von flutter doctor posten, Ihrer Schritt-für-Schritt-Anleitung (zB dies ist der Schritt 2 von progard https://flutter.dev/docs/deployment/android#step-2---enable- obfuscation-andor-minification), generieren Sie APK oder AAB und welches Gerät testen Sie?

Zusammenfassung des Arztes (um alle Details zu sehen, führen Sie flatter doctor -v aus):
[✓] Flattern (Channel Beta, v1.7.8+hotfix.2, unter Mac OS X 10.14.5 18F132, Gebietsschema ru-RU)

[✓] Android-Toolchain – Entwicklung für Android-Geräte (Android SDK Version 28.0.3)
[✓] Xcode - Entwickeln für iOS und macOS (Xcode 10.2.1)
[✓] iOS-Tools – für iOS-Geräte entwickeln
[✓] Android Studio (Version 3.4)
[✓] Verbundenes Gerät (1 verfügbar)

• Keine Probleme gefunden!

Zusammenfassung des Arztes (um alle Details zu sehen, führen Sie flatter doctor -v aus):
[✓] Flattern (Channel Beta, v1.7.8+hotfix.2, unter Mac OS X 10.14.5 18F132, Gebietsschema ru-RU)

[✓] Android-Toolchain – Entwicklung für Android-Geräte (Android SDK Version 28.0.3)
[✓] Xcode - Entwickeln für iOS und macOS (Xcode 10.2.1)
[✓] iOS-Tools – für iOS-Geräte entwickeln
[✓] Android Studio (Version 3.4)
[✓] Verbundenes Gerät (1 verfügbar)

• Keine Probleme gefunden!
Zusammenfassung des Arztes (um alle Details zu sehen, führen Sie flatter doctor -v aus):
[✓] Flattern (Channel Beta, v1.7.8+hotfix.2, unter Mac OS X 10.14.5 18F132, Gebietsschema ru-RU)

[✓] Android-Toolchain – Entwicklung für Android-Geräte (Android SDK Version 28.0.3)
[✓] Xcode - Entwickeln für iOS und macOS (Xcode 10.2.1)
[✓] iOS-Tools – für iOS-Geräte entwickeln
[✓] Android Studio (Version 3.4)
[✓] Verbundenes Gerät (1 verfügbar)

• Keine Probleme gefunden!
APK erstellen
Ich habe alles wie in der Anleitung gemacht, aber es wird nicht auf 32 Bit installiert

Ich habe alles wie in der Anleitung gemacht, aber es wird nicht auf 32 Bit installiert

Irgendein Screenshot/Protokoll, das zeigt, dass die Installation von 32-Bit-APK auf dem 32-Bit-Gerät nicht erfolgreich war, und welches Gerätemodell ist das?

Hallo zusammen,

v1.7.8+hotfix.2 wurde für den stabilen Kanal freigegeben, daher ist dieser Fix jetzt in allen Kanälen verfügbar. Vielen Dank an alle für Ihre Geduld und Hilfe auf dem Weg!

Ich habe alles wie in der Anleitung gemacht, aber es wird nicht auf 32 Bit installiert

Irgendein Screenshot/Protokoll, das zeigt, dass die Installation von 32-Bit-APK auf dem 32-Bit-Gerät nicht erfolgreich war, und welches Gerätemodell ist das?

danke für die hilfe, ich habe versucht, appbundle zu bauen und es hat funktioniert.

@tvolkert Gleiches Problem, bitte überprüfen Sie es. https://github.com/flutter/flutter/issues/31962#issuecomment -509458960

@nimesh1997 Dieses Problem hat nichts mit diesem zu tun. Wenn Sie die Antworten im verlinkten Problem nicht hilfreich fanden, könnten Sie vielleicht eine Stackoverflow-Frage mit Ihrem Problem posten.

@tvolkert - nur zur Verdeutlichung - der obige Hotfix kann verwendet werden, um separate APKs gemäß den Anweisungen in den
Daher müssen keine weiteren Änderungen an der Gradle-Datei vorgenommen werden, wie in früheren Teillösungen beschrieben
Vielen Dank für Sie und den Rest des Teams ausgezeichnete Arbeit und pünktliche Lieferung!

Ich habe gerade eine meiner Apps mit dem neuesten Hotfix kompiliert. Dadurch ist das kompilierte app-production-armeabi-v7a-release.apk auf dem Galaxy S3 mini (Android OS 4.1.2) nicht lauffähig - nach dem Splash-Screen schließt sich die App ohne Benachrichtigung.
Ich bin jedoch in der Lage, dieselbe APK auf einem 64-Telefon, z. B. Galaxy S8, erfolgreich auszuführen.
So führe ich das Flattern über die Befehlszeile aus:

flatter build apk --target="lib/config/main_production.dart" --flavor=production --split-per-abi

und hier ist mein flutter doctor -v

[√] Flutter (Kanal stabil, v1.7.8+hotfix.2, unter Microsoft Windows [Version 10.0.17763.557], locale en-US)
• Flutter-Version 1.7.8+hotfix.2 unter E:\DevToolsflutter
• Framework-Revision 2e540931f7 (vor 7 Tagen), 02.07.2019 09:31:07 -0700
• Motorrevision b1cb0d9e9b
• Dart-Version 2.4.0

[√] Android-Toolchain - für Android-Geräte entwickeln (Android SDK Version 28.0.3)
• Android SDK unter E:\DevTools\Android\Sdk
• Android NDK-Standort nicht konfiguriert (optional; nützlich für native Profilerstellung)
• Plattform Android-28, Build-Tools 28.0.3
• ANDROID_SDK_ROOT = E:\DevTools\Android\Sdk
• Java-Binärdatei unter: E:\DevTools\android-studio\jre\bin\java
• Java-Version OpenJDK Runtime Environment (Build 1.8.0_152-release-1343-b01)
• Alle Android-Lizenzen werden akzeptiert.

[√] Android Studio (Version 3.4)
• Android Studio unter E:\DevTools\android-studio
• Flutter-Plugin-Version 37.0.1
• Dart-Plugin-Version 183.6270
• Java-Version OpenJDK Runtime Environment (Build 1.8.0_152-release-1343-b01)

[√] Verbundenes Gerät (1 verfügbar)
• Android SDK für x86 gebaut • Emulator-5554 • android-x86 • Android 8.1.0 (API 27) (Emulator)

• Keine Probleme gefunden!

Außerdem - die fat apk kann auch nicht ausgeführt werden - nach der Installation (auf demselben arm-32-Gerät) und dem Ausführen wird sie einfach geschlossen.
Bitte lassen Sie mich wissen, wie Sie vorgehen und das Problem lösen können, danke!

@angel1st ist es möglich, dass Sie Ihre AAB- und/oder APK-Datei hier teilen, damit wir Ihnen bei der Fehlerbehebung helfen können?

@truongsinh -

app-production-releases.zip

Ich habe beide APKs hochgeladen, obwohl das angebliche Problem mit der Arm-32-Version wie oben beschrieben auftritt.

Leute, wäre in der Zwischenzeit jemand so nett und würde sagen (wenn er es weiß), was nach dem 1. August im Google Play Store passieren würde, falls Sie keine Arm-64-Version Ihrer App haben - würde die APK aufhören? auf arm64-Geräten bereitgestellt werden oder können Sie nicht nur die arm32-Version oder beide hochladen?

@angel1st Ich konnte die App (app-production-armeabi-v7a-release.apk) auf Android 4.4.2 Galaxy S4 ausführen. Schöne App!

Ich vermute, dass dies sehr spezifisch für Galaxy S3 mini / Android OS 4.1.2 ist. In der Zwischenzeit habe ich diese Konfiguration angefordert, um zu sehen, ob ich das Problem reproduzieren kann.

@angel1st hier ist die informativste Quelle: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

Die Anforderung [64-Bit-Sachen] gilt nicht für:

• APKs oder App Bundles, die explizit auf Wear OS oder Android TV ausgerichtet sind, sind Formfaktoren, die derzeit keinen 64-Bit-Code unterstützen.
• APKs oder App Bundles, die nicht an Geräte mit Android 9 Pie oder höher verteilt werden.

Ab 1. August 2019:

• Alle neuen Apps und App-Updates, die nativen Code enthalten, müssen beim Veröffentlichen bei Google Play zusätzlich zu den 32-Bit-Versionen auch 64-Bit-Versionen bereitstellen.

Mit anderen Worten, Apps werden weiterhin verteilt, obwohl Sie keine neue Version einer vorhandenen App hochladen oder neue Apps ohne Compliance veröffentlichen können.

@angel1st Ich konnte dieses Problem auf einem Galaxy S3 mini mit Android OS 4.1.2 reproduzieren.

Der Logcat ist:

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

Ich habe in der Zwischenzeit https://github.com/flutter/flutter/issues/35838 eingereicht.

cc @jason-simmons

@truongsinh - danke für die Übersicht.

@blasten - danke für das prompte Feedback. Soweit ich das verstanden habe, kann ich am Geldautomaten nichts tun, außer #35838 mit gedrückten Daumen zu überwachen. Wird es irgendwann in diesem Monat behoben? Ich glaube, das gleiche Problem wird bei jeder anderen APK für Android 4.1.2 auftreten, die mit dem neuesten Hotfix kompiliert wurde.
Zu Ihrer Information - die App apk, die mit der vorherigen flatter stable-Version kompiliert wurde, hat dieses Problem nicht (S3 mini mit Android 4.1.2 ist eines meiner Testgeräte).

Jeder andere hat heute eine E-Mail von Google bekommen, in der es heißt:

"Aktion erforderlich: Aktualisieren Sie Ihre Apps bis zum 1. August 2019, damit sie 64-Bit-kompatibel sind."

obwohl bereits sowohl 32bit als auch 64bit Versionen veröffentlicht wurden?

Es sagt

Bis zum 1. August 2019 müssen alle Apps, die nativen Code verwenden, eine 64-Bit-Version bereitstellen, um ein Update zu veröffentlichen. Zum Zeitpunkt des Versands dieser E-Mail erfüllt mindestens eine Ihrer Apps* noch nicht die Anforderung

*Hinweis: Diese App-Liste spiegelt die beste Schätzung von Google zum Zeitpunkt des Versands dieser E-Mail wider. (...)

Ich denke, Googles "beste Schätzung" ist nicht korrekt?

Danke an das Flutter-Team. Ich aktualisiere Flutter und baue auf einem stabilen Kanal und die Warnung ist weg.
Ich hoffe, keinen Fehler bei den Testern zu haben, aber bisher habe ich noch keine Fehler mit echten Geräten gefunden!

Danke an Team Flutter, das Upgrade von Flutter mit dem Hotfix behebt dieses Problem beim Erstellen von .aab

Danke an das Flutter-Team für diesen Erfolg. Jetzt weiter programmiert!

@angel1st Ich habe auch Probleme mit einigen Samsung-Geräten.

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

@abdullayev007 - danke! Ich würde dir empfehlen, einen Blick auf #35838 zu werfen, es könnte irgendwie damit zusammenhängen.

Ich habe alles wie in der Anleitung gemacht, aber es wird nicht auf 32 Bit installiert

Irgendein Screenshot/Protokoll, das zeigt, dass die Installation von 32-Bit-APK auf dem 32-Bit-Gerät nicht erfolgreich war, und welches Gerätemodell ist das?

Das Gerät ist Samsung M10

@tvolkert Bitte geben Sie mir eine Lösung zur Behebung des folgenden Problems:
https://github.com/flutter/flutter/issues/36063

Danke

Ich habe die neueste Version von Flatter vom Entwicklerkanal ausprobiert - v1.8.4. Ich habe auch ein neues Projekt erstellt - Vanilla Flutter Project und versucht, daraus eine Release-signierte Version zu erstellen. Es erstellt und die App-Größe beträgt nur 10,4 MB. Aber alle oben genannten Schritte auf diesem Weg ausprobiert, nichts hat geholfen. Kann jemand eine klare Abfolge von Schritten geben, um einen Build zu erstellen, den wir mit aab oder apk mit Emulator und lokalem Gerät von flattern in den Playstore verschieben können? Es ist mehr als eine Woche her, wir haben ein auf Flattern aufgebautes Projekt, das nicht auf Android umgestellt wird, aber wir können es im Appstore auf iOS veröffentlichen. Etwas Hilfe wird großartig sein.

`[✓] Flutter (Channel dev, v1.8.4, auf Mac OS X 10.14.5, locale en-US)
• Flutter-Version 1.8.4 unter /Users/muthu/muthu/devapps/flatter
• Framework-Revision 954714c967 (vor 7 Tagen), 02.08.2019 10:10:39 -0700
• Motorrevision 26368225b5
• Dart-Version 2.5.0 (Build 2.5.0-dev.1.0 bd049f5b53)

[!] Android-Toolchain - für Android-Geräte entwickeln (Android SDK Version 29.0.1)
• Android SDK unter ../Library/Android/sdk
• Android NDK-Standort nicht konfiguriert (optional; nützlich für native Profilerstellung)
• Plattform Android-29, Build-Tools 29.0.1
• Java-Binärdatei unter: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java-Version OpenJDK Runtime Environment (Build 1.8.0_152-release-1343-b01)
✗ Android-Lizenzstatus unbekannt.
Versuchen Sie, Ihren Android SDK Manager neu zu installieren oder zu aktualisieren.
Siehe https://developer.android.com/studio/#downloads oder besuchen Sie https://flutter.dev/setup/#android -setup
für detaillierte Anweisungen.

[✓] Xcode - Entwickeln für iOS und macOS (Xcode 10.3)
• Xcode unter /Applications/Xcode.app/Contents/Developer
• Xcode 10.3, Build-Version 10G8
• CocoaPods-Version 1.7.3

[✓] Android Studio (Version 3.4)
• Android Studio unter /Applications/Android Studio.app/Contents
• Flutter-Plugin-Version 38.2.1
• Dart-Plugin-Version 183.6270
• Java-Version OpenJDK Runtime Environment (Build 1.8.0_152-release-1343-b01)

[✓] VS-Code (Version 1.36.1)
• VS Code unter /Applications/Visual Studio Code.app/Contents
• Flatter-Erweiterungsversion 3.3.0

[✓] Verbundenes Gerät (3 verfügbar)
• Android SDK für x86 gebaut • Emulator-5554 • android-x86 • Android 9 (API 28)
(Emulator)`

@muthufmass ,

Kann jemand eine klare Abfolge von Schritten geben, um einen Build zu erstellen, den wir in den Playstore übertragen können?

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

Kann jemand eine klare Abfolge von Schritten geben, um einen Build zu erstellen, den wir in den Playstore übertragen können?

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

Diese Schritte wurden bereits befolgt, sie funktionieren nicht beim Prod-Release-Build. Debugbuild funktioniert! Ich finde eindeutig einen Unterschied, beim Debug-Build sind die .so-Dateien von Flatter vorhanden, aber nicht mit der Release-Version. Dies sind diejenigen, die Probleme bei der Installation der APK auf dem Emulator oder auf Geräten mit signierter APK verursachen.

@muthufmass ,

Ich hoffe, ich habe oben die gelöschten Schritte geteilt. Neue App-Erstellung mit Flutter Create - Vanilla-Code mit dem neuesten Flutter-SDK. Eine Release-Version kann nicht erstellt werden, während die Debug-Versionen reibungslos laufen. Signifikanter Unterschied zwischen Prod- und Dev-Version von APK in Bezug auf die Größe. Alle oben genannten Schritte ausprobiert, konnte keine lauffähige Release-Version erstellen. Der Build erfolgt superschnell und die Datei hat bei der Veröffentlichung weniger als 11 MB, während sie bei der Debug-APK ungefähr 40 MB + hat. Debug apk funktioniert, während prod release signiertes apk nicht einmal installiert wird.

@muthufmass Wenn Sie das neue Problem flutter create .

@muthufmass sowie adb logcat-Ausgabe.

Dieses Problem ist geschlossen. Bitte reichen Sie ein neues Problem ein, damit wir es ordnungsgemäß verfolgen können.

jetzt ein separates Ticket erstellt https://github.com/flutter/flutter/issues/37935

Wenn Sie Flavors in Ihrem Projekt hatten und sowohl x64 als auch x32 unterstützen möchten, fügen Sie einfach den Ordner jniLibs zu Ihrem Flavor-Ordner hinzu und es funktioniert großartig, so wie hier

wie kann ich das in adobe animate cc . machen
brauche mehr infos

Die Google Play Console hat vor kurzem begonnen, die Rollout-Schaltfläche aufgrund verschiedener Warnungen zu deaktivieren. Und eine dieser Warnungen verwendet apk anstelle der .aab-Datei. Es gibt Lösungen zum Erstellen einer .aab-Datei, wenn das Projekt in Android Studio oder Unity erstellt wurde. Aber was ist, wenn die APK von Animate CC oder Haxe/Flash Develop erstellt wurde? Gibt es eine Möglichkeit zu konvertieren?

@newapproach Mir ist nicht klar, ob Ihr Kommentar etwas mit Flutter zu tun hat? Wären Sie bereit, eine neue Ausgabe mit mehr Details einzureichen? Danke!

Habe das gleiche Problem - aber flatter.so nicht im Ordner "armeabi-v7a" enthalten.
Hat nur Bibliotheken von Drittanbietern für x86 und armeabi-v7a - aber kein arm64.
Möchte Flattern nur für "armeabi-v7a mit bauen
ndk{
abiFilters "armeabi-v7a" // funktioniert auch nicht "armeabi", "x86",
}
und als Zielplattform festlegen, wie @mravn-google android-arm vorschlägt.

APK ohne Arch angeben und keine Bibliotheken einschließen

APK mit Bibliotheken und ohne Armspezifikation

APK mit Arch angeben und Bibliotheken einschließen

Irgendwelche Vorschläge, wie man weitere Schritte debuggen kann?

Ich habe diesen Fehler auch gefunden, ist er behoben?? Könnte mir helfen?

Ich empfehle, bei Stack Overflow nachzufragen oder einen neuen Fehler zu öffnen. Ich bezweifle, dass dieser geschlossene Fehler der richtige Ort für Leute ist, um Ihnen bei der Lösung des oben genannten Problems zu helfen. Danke!

Das war meine Lösung:

1. in 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. flutter build apk --release --target-platform=android-arm ausführen
2. app-armeabi-v7a-release.apk in den Play Store hochladen
3. inkrementieren versionCode
4. flutter build apk --release --target-platform=android-arm64 run ausführen
5. app-arm64-v8a-release.apk in den Play Store hochladen

Der Google Play Store wird die App entsprechend der Gerätearchitektur bereitstellen. 32-Bit-Geräte sind glücklich, 64-Bit-Geräte sind glücklich, und ich bin glücklich zu wissen, dass meine APK-Größe relativ klein bleibt und trotzdem beide Architekturen bedient.

Wenn wir beide Architekturen im selben APK unterstützen, rechnen Sie mit einer App-Größe von über 10 MB

funktioniert nicht.. wenn ich es im Playstore auf Pixel 2 ansehe, wird es für dieses Gerät nicht unterstützt

Es funktioniert, viele bekannte Apps stellen auf diese Weise mehrere APKs bereit und lassen den Play Store schon seit langer Zeit das passende auf dem entsprechenden Gerät bereitstellen.

App Bundles sind jedoch der moderne Weg, dies zu tun.

Es funktioniert, viele bekannte Apps stellen auf diese Weise mehrere APKs bereit und lassen den Play Store schon seit langer Zeit das passende auf dem entsprechenden Gerät bereitstellen.

App Bundles sind jedoch der moderne Weg, dies zu tun.

Ich weiß nicht, warum es für mich dann nicht im Pixel-2-Playstore angezeigt wird ... Ich folge genau zweimal, nur für den Fall.
Ich habe App Bundle verwendet und meine App stürzt ab, daher suche ich nach Alternativen

Dieser Thread wurde automatisch gesperrt, da nach dem Schließen in letzter Zeit keine Aktivität stattgefunden hat. Wenn immer noch ein ähnliches Problem auftritt, öffnen Sie bitte einen neuen Fehler, einschließlich der Ausgabe von flutter doctor -v und einer minimalen Reproduktion des Problems.