AFAIK, currently, Flutter will only add libflutter.so to one selected platform folder in the release APK. The workaround which worked for me was to force build.gradle to do 32bit only (excluding all 64bit libraries + Intel)

release {

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

cc @Hixie

@swavkulinski how would you release the to apks to the playstore?

Similar to https://github.com/flutter/flutter/issues/18939

Have the same problem - but flutter.so not included in "armeabi-v7a folder.
Has only third party libraries for x86 and armeabi-v7a - but no arm64.
Would like to build flutter only for "armeabi-v7a with
ndk{
abiFilters "armeabi-v7a" // also not work"armeabi", "x86",
}
and set as target-platform as @mravn-google suggest to android-arm.

APK without specify arch and not include libraries

APK with libraries and no arm spec

APK with specify arch and include libraries

Any suggestion how to debug further steps?

@xxseabxx i have the same problem

I have the same problem, building for 32-bit will exclude 64-bit devices, it runs on them though. Building for 64 by specifying --target-platform android-arm64 works on 64-bit devices, but crashes on 32-bit devices. Also Google will be restricting upload of apks to be 64-bit in 2019.

Flutter Team, please resolve this basic issue!

Flutter Team, please resolve this basic issue!

So am I wrong by saying that flutter can only support release apk’s for either 32 or 64 bit, but not both?

any luck here?

I think xxseabxx's comment might work but I haven't tried it...

I am also having the same issue.

In all of my dependencies, I isolated at least one package causing the issue, I filled a bug report accordingly: https://github.com/azihsoyn/flutter_mlkit/issues/36

To isolate the problem, for each of my dependency / plugin:

1) Create an empty flutter project

2) Replace main.dart with

the package example code (ex: https://pub.dartlang.org/packages/flutter_html_view#-example-tab-)

3) Update pubspec.yaml accordingly

4) run

$ flutter build apk

It turned out that the one creating was flutter_mlkit.

I want to be able to target both 32 & 64 architectures.

Have the same issue. --target-platform=android-arm64 works for me but I would like to support 32 bit until Google pulls the plug on 32 bit

Flutter Team, please resolve this basic issue!

lots of third SDK not working, i think it's urgent

I can reproduce this when adding Mapbox to the android application.

I have the same problem too.I use baiduMap in my Project,bebug model is ok,release crash.
user flutter build apk --release --target-platform=android-arm64 in my phone is ok,but 32 bit phone will crash.Flutter Team,please resolve this issue as soon as possible.

Similar to https://github.com/azihsoyn/flutter_mlkit/issues/36 , it works for me , the apk can run in both 32bit and 64bit phone. @peace2knowledge

this should be very important problem for release apk

is there a work around for this issue?

1. extract lib/armeabi-v7a/libflutter.so from $<FLUTTER>/bin/cache/artifacts/engine/android-arm-release/flutter.jar
2. copy file armeabi-v7a/libflutter.so into $<project>/android/jniLibs/armeabi-v7a/
3. modify $<project>/android/app/build.gradle as below:

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

For NDK, the 64-bit toolchain requires minSdkVersion >= 21.

This unblocked me (with proper 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

Delete all abiFilters, it works for me.

@zoechi @Hixie gentle bump. I also am running into this when trying to integrate with existing app, which is our most important use case at the moment.

mindsdk=21, but haven't updated target platform yet

@neiljaywarner a thumbs-up on the initial comment would be more effective to raise priority

1. extract lib/armeabi-v7a/libflutter.so from $<FLUTTER>/bin/cache/artifacts/engine/android-arm-release/flutter.jar
2. copy file armeabi-v7a/libflutter.so into $<project>/android/jniLibs/armeabi-v7a/
3. modify $<project>/android/app/build.gradle as below:

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

This didn't work for me--it generated an APK that was missing the lib folder (and thus was half the size of my previous apk).

We've also found that if we implement the 32-bit only solution that some have posted (e.g. https://medium.com/flutterpub/flutter-app-couldnt-find-libflutter-so-c95ad81cbccd) it results in a non-performant app. In particular in one test on a Samsung S6 & S9 we are seeing very slow scrolling on a big list.

I don't think the problem is only the missing arm64 libflutter.so.

I tried adding the missing library to the APK by building for arm64, copying out libflutter.so and then re-building and manually adding the arm64 library to the APK, re-aligning and re-signing:

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

The resulting APK has libflutter.so for both armeabi-v7a and arm64-v8a, but crashes on launch with the following error:

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'

I suppose that separate snapshot assets need to be shipped for each arch too. For now building two separate APKs is the only solution that works for me.

this is a pretty shitty issue to run into after spending time actually writing a frontend in flutter only to find the release doesn't properly build the apk.

am I going to run into the same issue once I get around to doing iOS?

What time can solve this problem?

Is this just that our gradle files don't know how to bundle all the right bits for both? @jason-simmons @cbracken might know?

Or @FaisalAbid might?

Is this just that our gradle files don't know how to bundle all the right bits for both? @jason-simmons @cbracken might know?

Or @FaisalAbid might?

By right bits I assume you mean more than the libflutter.so, per this comment: https://github.com/flutter/flutter/issues/18494#issuecomment-449557182

Right now I think the only solution is to build 32-bit APKs until there is a fix. Note however that we've seen performance issues with 32-bit (albeit non-optimal code with large lists).

It's working fine for me to build separate 64-bit and 32-bit APKs and upload both to Google (they handle providing the correct APK to the correct devices automatically).

You do one build with abiFilters set to armeabi-v7a and --target-platform=android-arm, upload that APK, then do another build with abiFilters set to arm64-v8a and --target-platform=android-arm64 and upload that one too.

Note that you also need to use a different version code for each APK, so include something in the version code to indicate that it's 64 or 32 bit, same as you would for DPI or API level.

Currently the best option is to set abiFilters conditionally from target-platform

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

The problem I have is that now I need to upload two apks with different version codes
The real fix for this is being able to build android bundles with multiple target platforms. App bundles is in flutter master currently but I couldn't get it to work for this

The play store will require 64 bit starting on the 1 August.

Assuming there will still be 32bit devices wanting to run our apps after 1 august, how to make sure 32bit AND 64bit is included in release builds ?

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

_All new apps and app updates that include native code are required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play._

This requirement is easily met right now with Flutter apps by simply building two APKs – one for 32-bit devices and one for 64-bit devices – and uploading both as part of the same release. Google Play will automatically provide the appropriate APK to the appropriate device. I'm doing this and it works well. I agree with other commenters that it's not _ideal_, but IMO it's really not much of a problem to make this part of your workflow.

It would be great if this can be fixed in the near future. The multi-APK approach is only a temporary solution until Flutter builds APKs with multiple .so architecture versions, just like other Android projects do.

It requires a lot of manual handling (version codes, build system, automation) plus Android App Bundles were supposed to relieve developers of the manual build steps.

Currently this issue only mentions 32 & 64 bit versions, but there is also x86, x64 plus some developers in China still talk about supporting mips.

Shouldn't flutter support as much of the 7 android architectures with the smallest apk size as possible out of the box ?

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

@MarcelEdward It should - however IMHO the APK size is not the most important aspect, given that Android now fully supports App Bundles (aab) and end-users will download an optimized build for their phone anyway.

For the size of a platform-specific APK that should be as optimized/small as possible.

During development it may be painful to reinstall a full-size APK every time you change native code. A trick is to use abifilters to limit the debug build to your test phones' architecture. I'm not sure if this is as relevant now though, given that Flutter supports the hot reload.

https://github.com/flutter/flutter/issues/17829 Is about the aap app bundels, but i can only find 32bit when compile With flutter build apk

So when i understanding richt then we have to build two serperate versions with at least 32 and 64 upload them both and then the app stroe Will miraculously build an aap so that the consumer Gets the optimized Version for their specific archtecture

@MarcelEdward The play store doesn't build an app bundle. It just serves the appropriate APK to the device based on the device architecture. This has been supported since long before app bundles came along, not only for architecture but also for screen size/resolution, API level, and other differentiators. You can read more about this here.

You can see a good example of this by having a look at the 13 variants of Google Maps here (note that APKMirror has nothing to do with this functionality other than being an easy way to get a listing of the variants for a given app). The Play Store serves up the appropriate APK from these variants for your device based on its characteristics.

If you used an app bundle, then you would only have to upload the bundle once instead of uploading multiple APKs, but my understanding is that the Play Store then generates the various APK variants for you, so the end result is similar but there's less work for you to automate yourself. (App bundles also support the new dynamically-loaded modules, but that's another story.)

So it seems like the desired feature here is to be able to run flutter build with two --target-platform arguments and have flutter automatically put both architectures into the APK, is that right?

@Hixie isn’t libflutter.so only generated once per flutter version and release type? In which case you’d have 8 variants (32,64,x86,x86_64). I think those should simply be selected when a flutter app is built and filtered out depending on what the target phone or use case is. Gradle can do the filtering pretty well.

What atchitecture an phone has got is something pretty low level, I haven"t got a clue wich architecture the people have got who use our apps. Flutter compiles 32bit when no architecture is specified so I would assume 32bit fits all. But now the play store will require 64bit in august, so when 32bits fits all and 64bit is required then those two should go into a release build ?

I haven"t got an android phone myself, so I will assume it will work when it does on a simulator. Until our app users state otherwise.

@MarcelEdward2 It's not just 32-bit vs. 64-bit. There are four architectures supported by modern Android NDK:

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

At the moment Flutter defaults to building an APK containing native code compiled for armeabi-v7a only. This will run fine on arm64-v8a, though with a performance penalty compared to something compiled for arm64-v8a natively. However, it will run under an ARM emulator on x86 or x86_64, assuming the device bundles one. If the x86/x86_64 device doesn't have an ARM emulator, it won't run at all.

Once again, the August requirement doesn't require you to produce one universal APK or AAB containing both architectures. It simply requires that each release you make contains (at least) one APK suitable for 64-bit devices. Modifications in Flutter to make it possible to build one universal APK/AAB with support for several architectures would be nice in terms of developer workflow, but you can meet this requirement with or without such improvements.

Edited to add: personally I think first-class support for app bundles is the best way to improve the multi-arch situation.

appbundle looks like the solution going forward ... I guess next step is this: #29303

As I understand this bug, it's very tied with moving to .aab as the default output format for flutter build and making that .aab include then both 32 and 64-bit builds:
https://developer.android.com/studio/projects/dynamic-delivery

My understanding was some of this work may already be in progress. @dnfield might know.

/cc @mklim

It seems like .aab would help, but may not really be necessary. Is the problem as simple as just adding both the 32 and 64 bit arm binaries to the APK?

Ahh I see. It's because we'd need to potentially include the AOT snapshot for the target arch as well. And right now we just put that under assets, we don't put a per-architecture version under libs. If we could put the AOT snapshot into the architecture specific libs folder that might work, otherwise we'd want to use the .aab format for that reason.

We want to do this anyway to support building .AARs for add2app use cases. I'll poke at it.

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

This worked for me after days of troubleshooting

The solution posted by @AppleEducate does not work when I try to run the app on the emulator.

Put it in the release section

This was my solution:

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. run flutter build apk --release --target-platform=android-arm

2. upload app-armeabi-v7a-release.apk to the play store

3. increment versionCode

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

5. upload app-arm64-v8a-release.apk to the play store

Google play store will serve App according to device architecture. 32bit devices are happy, 64bit devices are happy and I'm happy knowing that my APK size remains relatively small while still serving both architectures.

If we include support for both architectures in the same APK, expect the size of your app to be 10MB+

@edTheGuy00 I doubt it is interesting how big the upload to the play store is. The android phones will ask for a 125+ temporay free space anyhow and wil refuse to use external storage for unpacking. That is all users will know about the app size, It does not really matter how much an app uses after installing. It will ask for the 125mb+ free space for installing.

Please make it possible to include all possible architectures. I don"t care if the upload to the play store will be 250mb.

It would be nice if flutter would use the gigabites space on the external storage for installling on an android phone. That is if flutter can influence the installation on an android phone

I think the flutter.gradle script should include all ABIs into the final APK (Universal APK) and then default turn split APKs on. The android tools will select the right APK to upload to the connected device and all is well. The final universal APK can then be uploaded to the play-store, or either the split APKs for each ABI.

In the meantime as a solution you can add this to the bottom of your build.gradle in your android\app directory.

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

I also recommend adding this to your buildTypes > release section. This will ensure your release APK contains both ABIs.

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

After a collab with @slightfoot we came up with this but it's still not quite right as you have to build twice initially to pick up the libs that get inserted into your src directory.

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: After trying to run this APK on the device it fails and thus is not a viable solution. The error is "Error while initializing the Dart VM: Snapshot not compatible with the current VM configuration:
the snapshot requires 'product use_bare_instructions no-"asserts" causal_async_stacks arm-eabi softfp'
but the VM has 'product use_bare_instructions no-"asserts" causal_async_stacks arm64-sysv'"

Ahh I see. It's because we'd need to potentially include the AOT snapshot for the target arch as well. And right now we just put that under assets, we don't put a per-architecture version under libs. If we could put the AOT snapshot into the architecture specific libs folder that might work, otherwise we'd want to use the .aab format for that reason.

We want to do this anyway to support building .AARs for add2app use cases. I'll poke at it.

@dnfield did you have some success at this, yet?

Working through the plug-in piece at the moment. We've been trying to get parts of it prioritized to fix the Android X issues but should see some more come out of that.

@gerryhigh and myself were looking into this. Please ignore my last replies. The problem is just the fact that libflutter.so is not included for 64bit but for AOT you have to run the build process twice, once for 32bit and again for 64bit. You then get two sets of compiled Dart code in your application assets as well as two versions of libflutter.so. I think the eventual goal would be to setup compilation tasks for Flutter so that it runs the two separate build steps and have split APKs setup automatically.

But for the moment, the only solution is to run the build twice and uploading multiple-APKs to the Play Store.

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

This can be better be achieved with enabling split-APKs. More details can be found here: https://developer.android.com/studio/build/configure-apk-splits

@slightfoot yes this is the best solution I have found so far as mentioned in my comment up there https://github.com/flutter/flutter/issues/18494#issuecomment-477502287

@slightfoot if I understand correctly, it would not be possible to build an universal APK as some code are located in the assets folder which does not allow to split files according to targeted archtecture as the lib folder ?

The snapshot built for each architecture is different. Simply copy the engine libflutter.so will cause the snapshot cannot be loaded if the architecture of snapshot doesn't match the architecture of flutter engine.
So currently there is no way for us to build a universal apk that contains all architectures unless separate the snapshot files and include the snapshot file for every architecture.

I'm a bit confused as to why this is even a problem.

Debug builds create libflutter.so in x86_64, x86, armeabi-v7a, and arm64-v8a.

Release builds should do exactly the same.

AGP (Android Gradle Plugin) already includes the functionality to filter out architectures, so if a user wishes to do that for a release build they can modify their build.gradle.

@eseidel @dnfield I don't really think this is solved by Android App Bundles - they are not the default Android output yet and when running from the IDE apks will be used for quite a while yet I'm sure.

AABs are another reason why Flutter should include all architectures of libflutter.so as the Play Store can filter out which architecture it delivers to devices.

@athornz the problem is not with libflutter.so but with your dart code compiling down to a AOT snapshot debug builds include the Dart VM so all your dart code just runs JIT on the VM, but release builds compile your dart code into a snapshot and place that snapshot into an assets folder. Ideally the snapshot should be compiled for each architecture and placed alongside libflutter.so but that is not the case at the moment. So while you can include libflutter.so for all the architectures, the snapshot will only work for whatever architecture it was compiled for.

Any plan to fix this issue?

Google Play store ask developer to provide 64-bit support after August 1, 2019.

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

The 64-bit requirement: what it means for developers
Starting August 1, 2019:
_All new apps and app updates that include native code are required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play._
Extension: Google Play will continue to accept 32-bit only updates to existing games that use Unity 5.6.6 or older until August 2021.
Starting August 1, 2021:
Google Play will stop serving apps without 64-bit versions on 64-bit capable devices, meaning they will no longer be available in the Play Store on those devices.
This will include games built with Unity 5.6.6 or older.

@trevorwang we can already build 64bit and upload them along with 32bit to the Play Store. So that isn't a problem.

@slightfoot Do you mean I have to build another 64-bit APK and upload it to Google Play?

As you know, Google Play is not available in China mainland. We prefer a universal APK to support all platforms.

@trevorwang pretty much. This is how I do it https://github.com/flutter/flutter/issues/18494#issuecomment-477502287

The split thing does not work in the gradfle file. You have to do something with one of the build.gradle files so flutter knows how to compile different architectures. Or google play will reject the second compile.

Thanks @edTheGuy00

But we really need a universal APK including all abis for China Market.

@trevorwang you can build for each targets and explicitely state for which architecture each APK is for. This is how it is done for a lot majority of APK mirror sites.

The 64bit limitation is just a limitation of the Google Play Store. You can still deploy the armeabi-v7a only APK and everyone would be able to run your app.

Building separate APKs per architecture is a workaround and definitely not a solution for everyone.

Once the Google Play 64bit limitation comes into effect this issue will impact most Flutter developers so we really do need a solution that allows for multiple architectures within one apk/bundle.

Just a quick reminder

The Flutter team uses the number of "Thumbs-up" on a GitHub issue as a guide to its priority.

I think this issue should be high up in priority.

Thanks for the work of @gerryhigh and @slightfoot

I have added flutter to an existed app and fixed this issue by the following workaround.
_Please add this to your app module of the host project._

This is the script for Debug mode, please change accordingly for release.

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

Any recent developments?

What I ended up doing, since I wanted

• separate apks for each architecture
• not to have to modify the versionCode manually
• run a single command to produce the apks

1. Added this to gradle. It adds 1 or 2 at the end of the versionCode, so version 1004 becomes 10041 for arm and 10042 for arm64.

ext.platformCodes = ['android-arm': 1, 'android-arm64' : 2]
android.applicationVariants.all { variant ->
    variant.outputs.each { output ->
        int code = 0
        if (project.hasProperty('target-platform')) {
            code = project.ext.platformCodes.get(project.property('target-platform'))
        }
        output.versionCodeOverride = variant.versionCode * 10 + code
    }
}

1. To produce the apks I use a longer terminal command (which you can put in a script). It runs the build twice and creates copies of the apks at the end:

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;

Hope this helps.

So this is an issue that I am having as well.. I have building an app bundle instead of an apk and when i have been uploading it to google it gives me the warning and wont let me alpha test it.

Ive been using codemagic to do it, is there a way to sign it and put it in a bundle? or use codemagic to dot it?

Im facing the same issue which I thought shouldn't exist at all.

How come this is on the Milestone "Goals".

P2: These are tasks we think are worth fixing in the coming years. It includes issues we've identified that might block fully shipping broad consumer-facing apps, correctness issues, and bugs relating to polish and quality. The date on this milestone is utterly arbitrary and just intended to sort the milestone appropriately.

It's a critical issue already and will become a full blown show-stopper later this year once Google enforces the 64bit limitation.

I've bumped the milestone on this. No solid date yet.

To be clear: it is possible, but difficult, to comply with the new guidelines today. We want to make that easier.

So @andreidiaconu method worked for me as long as I manually build the app.

But I have been using codemagic to build and deploy.

So this is a waste, Flutter needs to get this built it.

At the moment I personally do not really care if it is complicated. If it is complicated it will get automated by a script. The question is if it is possible and how because Google Play Console warns me:

This release is not compliant with the Google Play 64-bit requirement
The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: 6.
From 1. August 2019 all releases must be compliant with the Google Play 64-bit requirement.
Include 64-bit and 32-bit native code in your app. Use the Android App Bundle publishing format to automatically ensure that each device architecture receives only the native code it needs. This avoids increasing the overall size of your app.

I do not want a solution that needs different version codes and I want a solution that works with Android App Bundles (AAB).

Warning
This release is not compliant with the Google Play 64-bit requirement

The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: 3.

Any solution?

I've bumped the milestone on this. No solid date yet.

To be clear: it is possible, but difficult, to comply with the new guidelines today. We want to make that easier.

Should the docs be updated with instructions on how to do this for both apk and app bundles? All I’ve seen so far are bunchs of code and config which I’m not exactly sure where to put. I could probably figure it out with some trial and error, but it’s less than ideal.

same issue

Thanks for the work of @gerryhigh and @slightfoot

I have added flutter to an existed app and fixed this issue by the following workaround.
_Please add this to your app module of the host project._

This is the script for Debug mode, please change accordingly for release.

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

This solution/workaround looks most promising, thanks @trevorwang ! I do have problems implementing this in an existing flutter project, though. Do you have an example build.gradle file or something equivalent that would demo this?

PLEASE NOTE THAT THIS PROBABLY WON'T SOLVE YOUR PROBLEM - SEE BELOW

Thanks to @trevorwang answer & @noinskit suggestion I've managed to include 64bit native libs in release builds with a small addition to ./android/app/build.gradle shown below.
You can also view the whole file here.

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 thanks! I arrived at something similar. In my case, I need to change assembleRelease in your snippet to mergeReleaseJniLibFolders, otherwise the extra *.so file ends up under "intermediates/...", but not in the final apk.

@noinskit It seems that my previous solution was error prone. After running flutter clean it generated aab's with just 32bit libs. Replacing assembleRelease with mergeReleaseJniLibFolders seems to work also after cleaning of the build true.

@SPodjasek do you have to tweak any other options?

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

Both of my intermediates/jniLibs/release/arm64-v8a and armeabi-v7a directories have libflutter.so as expected but the final release APK still missing libflutter.so in arm64-v8a.

Here is the screenshot

@function1983 You can see my complete build.gradle here.
As of my flutter version:

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

I've been trying to use @SPodjasek's solution to build an appbundle that includes both 64 and 32 bit versions. It successfully builds, I can upload it to Google Play Console and I can install it on both 32 and 64 bit phones. But the app crashes when launched on an android-arm64 device for some reason (seems to work on an old 32bit android phone I was testing with though).

Here is the error I get on the 64bit device:

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

Not sure what I can do... Might have to stick with only supporting 64bit devices for now.

@Torrunt that error is because the Engine is trying to loat the AOT snapshot for 32bit and finding one for 64.

We're working on being able to produce an AAB that has both so that the store can correctly split these out.

@SPodjasek Using this increased my app-release.apk file size from 11.1 MB to 15.7 MB

@SPodjasek Using this increased my app-release.apk file size from 11.1 MB to 15.7 MB

Yes, as it forcefully includes libflutter.so for 32 & 64bit. If you don't need that, stick with current default to include 32bit only and wait for flutter team to deal with this properly.

looks like there are a few possibilities:

• wait till the flutter team resolves the 32 vs 64 architecture thing making google play store accept the flutter builds again
• we have to limit the android devices used to 32 bit only, so flutter apps will only run on 32 bit devices
• we have to somehow convice google not to enforce 64 bit on the play store. (I wonder what the difference is between 32 and 64 bit, somthing like bigger numbers ?)
• install the 32 apps somehow on 64 bit devices but not in the play store ...

Note for people using --target-platform to build for android-arm and android-arm64 separately and upload two APK.
Pay attention that some plugins use native libraries that may target both, and flutter does not filter the libraries folders so your "32 bits" APK will actually still target arm64 as well and it will crash as libflutter.so is not present and AOT snapshots are built for armv7.

So, you'll need to actually explicitely filter the target abi in your build.gradle file.

I think the flutter build apk --target-platform ... should logically do this filtering.

Using @SPodjasek's solution, I got an error about matching arm-eabi versus arm64-sysv. I think the best solution, that worked for me, is just building for 32 bit for the time being until this is all sorted out (@swavkulinski's solution here):

In your app level build.gradle:

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

Summarising issue from the subject - it won't be possible to build such APK for both armeabi-v7a and arm64-v8a. Flutter uses AOT snapshots which are ABI dependant, so with APK only possible solution would be to use multiple APK builds.
The solution would be to use App Bundles, which, as for now also has some issues (#31922).
After #32787 got merged it's now possible to use App Bundles.

How do I set the flavor and my target file (-t lib/another_main.dart, for example) when generating an Android app Bundle via Android Studio? o.o

This will be supported via flutter build appbundle after https://github.com/flutter/flutter/pull/32787 is merged!

@swavkulinski how would you release the to apks to the playstore?

It was still possible back then. Now you have to limit to 64bit. We were lockdown by the third party NDK library which was 32bit only.

@blasten
Will this also add support for flutter build apk --release? Or is it planned to phase out support for APKs in favor of app bundles in the long term? I quite like the relative simplicity of the fat APK.

@zimmi Correct. App bundles should be the way going forward. You can still use flutter build apk --release when necessary. What is simpler in a fat APK compared to AAB?

What is simpler in a fat APK compared to AAB?

AAB is not installation file. Android itself can't use it. It's file format for Google Play store only. So need apk when:

• Installing directly to device.
• Directly distributing app.
• Distributing via any other app market except Google Play store. (amazon & all China).

I see. Thanks for the background.

Also, you can extract the APKs from the AAB using bundletool.

@blasten
Thank you for confirming!
Regarding the simplicity comment: What @audkar said. Also with AABs, the developer has to think about potential failure scenarios caused by missing assets. Testing on all possible device configurations is hard, so if those failures occur, it's likely in production.

App size might be a price some are willing to pay for that peace of mind.

I'm sure there are better places to discuss the merits of each approach than this issue though, I don't want to derail it.

/cc @jonahwilliams we may need to support fat APKs in build apk.
Should we also change the default for build apk?

Fat apk support is definitely needed. There a lots of tools (beta distribution etc) that don't yet work with app bundles.

flutter build appbundle is now in master, does any voluntary person want to give it try?

We had some discussion to support a list of platforms in build apk, so you could do something like this: flutter build apk --target-platform android-arm,android-arm64

@blasten I switched to the master channel, upgraded and build the appbundle, it worked well. Then uploaded it to the play console and all warnings are gone. (macOS 10.14.4)

Awesome! I will compile my build tonight after I make my changes.

The bundle doesn't to seem to work tho, the app crashes when being downloaded.

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

It seems like com.mattetti.sounds.MainActivity isn't in the bundle?

Not sure why, how can I check why it's removed?

@mattetti Are you using a Flutter module? Is MainActivity extending FlutterActivity?

@blasten
Here are my dependencies

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

But I also just noticed that I renamed the package of my app but didn't change the path to my MainActivity.java file which is still android/app/src/main/java/com/example/old_name/ that might be the issue. Tomorrow, I'll try to change the path and push another bundle.

hello @blasten , I tried to build the appbundle and got this error

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

My project uses flavor and this is the command I run

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

Will the app bundle also include mapping.txt? When uploading app bundles to Google Play Console via Codemagic, there is no mapping.txt included, so no automated testing or pre-launch-reports - which you have when uploading an apk :(

so the question is:

Will Flutter team make an update for 64-bit release or not before August so we can upload and update our apps that are made with flutter or not?

@YazeedAlKhalaf Yes. You can use flutter build appbundle today and you will get an app bundle that contains 32 and 64 bits.

@mattetti is the issue fixed?

@nohli mapping.txt sounds like a feature request. Feel free to file a new bug.

@skybur can you run flutter doctor? Is your Flutter project an app or module?

@blasten My project is an app.

Here is the flutter doctor result

[√] 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: getting the same error as skybur

Trying to use flutter build appbundle then upload to the store, then open from a Android phone:
Instant crash on opening.

adb log:
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 it is very unclear to me why people keep saying that app bundle is solving this issue.

App bundle is nothing more than an automated split APK, and there is no split on the assets folder. So the snapshots are still only targeting a single architecture.

I'm probably missing something but in my opinion, the only solution now is to build APK for each architectures with corresponding ndk filtering in the gradle file. And then upload each of these APK.

if we cannot solve this issue with APK, there is no chance that app bundle could work either.

@ndusart I don't think that's true. App bundle docs says:

res/, lib/, and assets/: These directories are identical to those in a typical APK. When you upload your app bundle, Google Play inspects these directories and packages only the files that satisfy the target device configuration, while preserving file paths.

So it can somehow split assets.

@jereksel this just tell that these directories are working exactly the same way in app bundle than in apk and assets/ folder is not split. It is used to have assets stored in a very specific file structure in the application, it is not meant to be parsed by the OS or anything.

If I'm wrong, just tell me how we can split this folder based on target ABI.

And this quote just confirm what I say, if this is not possible right now with APK, this will not be possible using app bundle as these folders work exactly the same in both ways.

I haven't seen assets split myself, but I found this:

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

assets.pb — This is the equivalent of a resource table for application assets and will only be present if you are using assets in your application.

So my guess is that Android Studio doesn't split assets, but app bundles themselves have support for that.

Have you any official documentation ? All that seems very unreliable.
The following article, https://medium.com/mindorks/android-app-bundle-aab-98de6dad8ba8, states that we can append a suffix the name of folders in assets/ to split it but currently this can only be done on language.

So still, this does not seems stable yet and should not be based on right now. The VM snapshots should be either deported in the lib/ folder if that's possible or flutter command should come with a complete feature to build an APK for a specific target (there is still work to do on that for being accessible to a lot of people) and delay the production of an app bundle when it is ready to.

@blasten

I switched to the master channel, upgraded and build the appbundle. Unfortunately app chashes after downloaded from google play store with following 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 is now in master, does any voluntary person want to give it try?

We had some discussion to support a list of platforms in build apk, so you could do something like this: flutter build apk --target-platform android-arm,android-arm64

@blasten

I switched to the master channel, upgraded and build the appbundle. Unfortunately app chashes after downloaded from google play store with following 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 is now in master, does any voluntary person want to give it try?
We had some discussion to support a list of platforms in build apk, so you could do something like this: flutter build apk --target-platform android-arm,android-arm64

Have the same problem, although I do not have any logs yet.

@skybur the issue you were having might be related to https://github.com/flutter/flutter/issues/33119. If that is case, this patch should fix it.

@ndusart
Yeah, you're right. I've checked bundletool source code and assets split is only by language indeed:
https://github.com/google/bundletool/blob/master/src/main/java/com/android/tools/build/bundletool/splitters/ModuleSplitter.java#L286

This was my solution:

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. run flutter build apk --release --target-platform=android-arm
2. upload app-armeabi-v7a-release.apk to the play store
3. increment versionCode
4. run flutter build apk --release --target-platform=android-arm64
5. upload app-arm64-v8a-release.apk to the play store

Google play store will serve App according to device architecture. 32bit devices are happy, 64bit devices are happy and I'm happy knowing that my APK size remains relatively small while still serving both architectures.

If we include support for both architectures in the same APK, expect the size of your app to be 10MB+

There is an important thing to tell you guys. If you use the method I quote. You might need to comment out the setting, when you want to keep debugging your App. I face the error Gradle build failed to produce an Android package, and stuck for few hours, making some gradlew clean...etc, and finally found out this should be commented out!

Hope this helped someone to jump out.

flutter build appbundle is now in master, does any voluntary person want to give it try?

We had some discussion to support a list of platforms in build apk, so you could do something like this: flutter build apk --target-platform android-arm,android-arm64

flutter build appbundle is working! I don't need to add that setting, and just do the code. However, It takes a bit much time to compile, but It's the only way to pass Google Play now.

@Tokenyet were you able to download the app from the Play Store and run it after uploading the .aab? If this is the case, would you mind pasting the output of flutter doctor?

@blasten

I switched to the master channel, upgraded and build the appbundle. Unfortunately app chashes after downloaded from google play store with following 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 is now in master, does any voluntary person want to give it try?
We had some discussion to support a list of platforms in build apk, so you could do something like this: flutter build apk --target-platform android-arm,android-arm64

Exactly the same thing here, when trying to run my app from the Play Store (created as appbundle). What logs do you guys need to resolve this?

This will be helpful:

1. Download bundletool from https://developer.android.com/studio/command-line/bundletool
2. Run flutter build appbundle (Please indicate if you pass any flag or if you made _custom_ changes to any Gradle script)
3. Run bundletool build-apks --bundle=build/app/outputs/bundle/release/app.aab --output=out.apks to extract the APK set.
4. Run unzip -l out.apks and lastly flutter doctor and paste the output from both commands in your comment.

If possible:

Test locally on the device using the bundletool and the APK set. These are the steps, paste the logcat in your comment.

I'm unable to reproduce the issue although I only tested locally using bundletool.

@blasten So the previous error is fixed but I ran into another error. I assume this is caused by something in my project. Is there any way I could debug this?

[+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 I follow all your steps my 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
Actually this is called Assets Targeting and it allows you to target/split directories in assets based on Graphics API, Language & Texture Compression.
As seen here: .../bundletool/model/targeting/TargetedDirectorySegment.java

Regarding AAB's current flutter@master works for me locally - using bundletool to test and install on real device. I've disabled splitting on density & language in my build.gradle so build-apks gives me this:

  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

Testing it on Test Lab I also have all green.
Still waiting for Play Store to process this version to test this channel.

@Tokenyet were you able to download the app from the Play Store and run it after uploading the .aab? If this is the case, would you mind pasting the output of flutter doctor?

I can download the app from the Play Store, and run It. You could [give It a try] (https://play.google.com/store/apps/details?id=com.bumbystudio.starry_clock). (Edit: Oops, It's not wokring...from PlayStore)

Below is my flutter doctor as you need. Hope It helped.

[√] Flutter (Channel master, v1.6.1-pre.88, on Microsoft Windows [Version 10.0.17134.765], locale zh-TW)

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[√] Android Studio (version 3.3)
[√] VS Code, 64-bit edition (version 1.30.2)
[!] Connected device
! No devices available

This works fine for me !

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
}
debug {
ndk {
abiFilters 'armeabi-v7a'
}
}
}

@SPodjasek still, we need to split assets/ based on ABI. How can this be done currently ?

I installed in my device and it seems it's not working. All I got was a
black screen.

Thanks,

Purusothaman Ramanujam

On Thu, 23 May, 2019, 6:43 PM Tokenyet, notifications@github.com wrote:

@Tokenyet https://github.com/Tokenyet were you able to download the app
from the Play Store and run it after uploading the .aab? If this is the
case, would you mind pasting the output of flutter doctor?

I can download the app from the Play Store, and run It. You could give It
a try
https://play.google.com/store/apps/details?id=com.bumbystudio.starry_clock
.

Below is my flutter doctor as you need. Hope It helped.

[√] Flutter (Channel master, v1.6.1-pre.88, on Microsoft Windows [Version
10.0.17134.765], locale zh-TW)

[√] Android toolchain - develop for Android devices (Android SDK version
28.0.3)
[√] Android Studio (version 3.3)
[√] VS Code, 64-bit edition (version 1.30.2)
[!] Connected device
! No devices available

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/18494?email_source=notifications&email_token=AAIHDZYY47H6PUQQJYEO4J3PW2J7RA5CNFSM4FFE2B7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWCFLKY#issuecomment-495211947,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIHDZZXV67JCNVJYLVA3WLPW2J7RANCNFSM4FFE2B7A
.

@ndusart At this point it's impossible - maybe file a feature request on bundletool and Google will consider implementing it.

@SPodjasek so that's what I'm saying, all this issue is going the wrong way.

All the discussions seems to end to "ho don't worry, when we could build app bundles, all would be fine" but it is totally not the case right now and in a close future.
It's a bit disappointing to see flutter team let people think it is possible this way.

flutter should be able to provide a way to easily build split APK either by doing the split itself or manage to move the VM snapshots to the lib/ folder and let the split just work (we could then use app bundles as well)

Let’s recap:

1. Flutter will support fat APKs via flutter build apk ....
2. If you want to try this feature _right now_ try flutter build appbundle in the master branch. If app bundles don’t work for your use case, then (1) should cover the remaining cases.

Okay @blasten I did look in the master code and the snapshots are moved to the lib folder:
https://github.com/flutter/flutter/blob/dc28ba8919604ff19ea7cbad8d9400516347b08a/packages/flutter_tools/gradle/flutter.gradle#L470-L481

So it is not just adding app bundle support. It is more clear now.
A bit of explanation would have been appreciated though as it was stated that the problem was the assets folder and no information was given work was done in this direction since this problem and app bundle support are pretty independant.

Thanks for your work.

@ndusart - @blasten has made changes to the Android embedding so that it will look for the binary blobs in the lib folder now, so that you can bundle in both types if I'm not mistaken...

If snapshotes are moved into lib, then maybe #30846 will be also fixed?

@blasten
I switched to the master channel, upgraded and build the appbundle. Unfortunately app chashes after downloaded from google play store with following 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 is now in master, does any voluntary person want to give it try?
We had some discussion to support a list of platforms in build apk, so you could do something like this: flutter build apk --target-platform android-arm,android-arm64

Have the same problem, although I do not have any logs yet.

Same here. Was having error. Upgraded master and ran flutter build appbundle . Got rid of the error but app crashes when opened.

I tried uploading an appbundle using the latest flutter master version to the app store with the latest changes. The 64 bit error is gone now, but my app immediately crashes.

What's really odd is running the 64 bit version using the commands below works fine.
flutter build apk --target-platform android-arm64
flutter install api

It's only crashing when the app is installed through the appbundle in the appstore. For now I've reverted the appstore back to the 32 bit apk.

I don't have anything special in my gradle.build

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

I'm running Flutter (Channel master, v1.6.4-pre.13, on Mac OS X 10.14.5 18F132, locale en-US)

Is there anyway to test these bundles before uploading to the appstore? Is this a known issue that google is working on or do I need to make some changes to my gradle file?

@chitwoob Please follow the steps: https://github.com/flutter/flutter/issues/18494#issuecomment-495049530

@blasten I'm running into an issue with the bundle tool that's unrelated to this issue.

I get
Error: Failed to start ADB server

When running
build-apks --connected-device --bundle=./app.aab --output=./my_app.apks --adb

I have adb properly installed. When I try adb logcat it works fine.

Gonna be a long comment, but this completely fixed the problem

This was my solution:

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. run flutter build apk --release --target-platform=android-arm
2. upload app-armeabi-v7a-release.apk to the play store
3. increment versionCode
4. run flutter build apk --release --target-platform=android-arm64
5. upload app-arm64-v8a-release.apk to the play store

Google play store will serve App according to device architecture. 32bit devices are happy, 64bit devices are happy and I'm happy knowing that my APK size remains relatively small while still serving both architectures.

If we include support for both architectures in the same APK, expect the size of your app to be 10MB+

Following these steps was giving "Gradle build failed to produce an Android package." error
_After an hour of debugging, found out the fix._

To create different apps for x86 and x64, follow these steps:

Step 1: Include the code snippet in app/build.gradle file. The file will look like:

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

Step 2: Create a release apk using flutter build apk --release
This will create the x86 based apk in folder build/app/outputs/apk/app.apk
Upload this apk to google play store.
x86 done till now

At this point don't run flutter clean
I was doing this and getting errors when building x64 apk

Step 3: Now open pubspec.yaml and change the version from
version: 1.0.0+1 to version: 1.0.0+2

The number next to + is version code

Step 4: Now run the command
flutter build apk --release --target-platform=android-arm64

After this command completes, go to build/app/outputs/apk/release/. In there you will find an apk with name app-arm64-v8a-release.apk. This is your 64 bit apk file with different version code.

Now upload this x64 apk to play store....and here you go. You have uploaded both x86 and x64 apps to play store.

Gonna be a long comment, but this completely fixed the problem

[...]
To create different apps for x86 and x64, follow these steps:

Step 1: Include the code snippet in app/build.gradle file. The file will look like:

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

Step 2: Create a release apk using flutter build apk --release
[...]

Agree with your answer. Works for me, even though I didn't have to follow Step 1 (I used a default build.gradle)

Then, you just need to increment your build number and version so that Google Play accepts it.

I'm still having troubles with flutter build appbundle on my hand.

Gonna be a long comment, but this completely fixed the problem

[...]
To create different apps for x86 and x64, follow these steps:
Step 1: Include the code snippet in app/build.gradle file. The file will look like:

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

Step 2: Create a release apk using flutter build apk --release
[...]

Agree with your answer. Works for me, even though I didn't have to follow Step 1 (I used a default build.gradle)

Then, you just need to increment your build number and version so that Google Play accepts it.

I'm still having troubles with flutter build appbundle on my hand.

Not working. I am so upset. Application crashed when attempted to deploy on x86 emulator as well as on real arm device. Tried with master/beta/stable channel. No release ready. It is still show stopper for us. Appbundle command generates installable bundle for play but during runtime application shows just splash screen and then freezes. Flutter team please provide clear solution or WA.

@mormih thanks for your patience -- we're working on reproducing. If you wouldn't mind, could you send me an email ([email protected]) including the following, it would help:

• Your host platform you're using to build.
• The command you're using to build the app.
• Run your build command with --bug-report (e.g. flutter build appbundle --bug-report) and attach the associated bugreport.zip file
• Attach the generated app bundle so we can try running it on local devices
• Attach the results of adb bugreport after having tried to run the app

Thanks!

@tvolkert I also have the issue where it's crashing with the following message:

Check failed: vm. Must be able to initialize the VM.

My host platform is a mac and macOS 10.14.5. Were you able to reproduce it, or would you like me to follow the steps you wrote above? Also, maybe this should have a dedicated ticket as it's a separate issue from the OP one.. Cheers

@mormih I am not sure but have you tried including x86 as well in the abi list?

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

flutter build appbundle (on master) didn't work for me either, have the splashscreen stuck just like others have noted...

The only workaround I found for releasing (in the Play store) for both 32- and 64bit so far is the following. (Partly covered in the thread but might help someone):

1. Create an apk with the v7 filter on + the default build apk command:
   In your app/build.gradle file:
   defaultConfig { ... ndk{ abiFilters "armeabi-v7a" } }
   and then run
   flutter build apk
   (defaults to --release)

2. Bump your build number in pubspec.yaml.
   E.g. from version: 1.1.0+6 to version: 1.1.0+7

3. Create an apk with the v8 filter on + build with arm64 as the target platform:
   now update the build.gradle like:
   defaultConfig { ... ndk{ abiFilters "arm64-v8a" } }
   and then run
   flutter build apk --release --target-platform android-arm64

Does include the overhead of having to upload 2 apks (and thus creating 2 build numbers) but at least it seems to do the job and I can release for both 32 and 64bit devices...

Note: I let go of x86 as that only involves a very minor group of mobile devices (and potentially none of my users), plus I don't need a release build in the emulator (debug is enough for testing). But this of course might not be the case for others.

@ezmegy method is the only one that worked for me. Thanks

Somewhere up in the comments someone left this.

This has been working for me and its only 1 terminal code.
It outputs 2 files which I hate though and it creates 2 versions.

@ezmegy Thank you! You save my day

Thanks @ezmegy, your "trick" works!

Thanks @ezmegy !
I'd like to share my current workflow which might be helpful:

Create some build flavors on app/build.gradle per architecture

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

Then I can build both with:
flutter build apk --flavor arm32
and
flutter build apk --flavor arm64 --target-platform android-arm64
without modifying gradle on every build

Regarding version code, I'd prefer set one by default and derived the others from that one
E.g. set arm32 with 1.0.0+10000 and generate version code for the arm64 which is 1.0.0+10001
This should be easy to generate using bash (or within fastfile if you're using fastlane)

You could set the build number using --build-number arguments or via fastlane if you're using one

This version code scripting helps me in CI/CD 😄

CMIIW

For me this worked out pretty well
https://github.com/flutter/flutter/issues/10728#issuecomment-461375218

Gonna be a long comment, but this completely fixed the problem

This was my solution:

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. run flutter build apk --release --target-platform=android-arm
2. upload app-armeabi-v7a-release.apk to the play store
3. increment versionCode
4. run flutter build apk --release --target-platform=android-arm64
5. upload app-arm64-v8a-release.apk to the play store

Google play store will serve App according to device architecture. 32bit devices are happy, 64bit devices are happy and I'm happy knowing that my APK size remains relatively small while still serving both architectures.
If we include support for both architectures in the same APK, expect the size of your app to be 10MB+

Following these steps was giving "Gradle build failed to produce an Android package." error
_After an hour of debugging, found out the fix._

To create different apps for x86 and x64, follow these steps:

Step 1: Include the code snippet in app/build.gradle file. The file will look like:

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

Step 2: Create a release apk using flutter build apk --release
This will create the x86 based apk in folder build/app/outputs/apk/app.apk
Upload this apk to google play store.
x86 done till now

At this point don't run flutter clean
I was doing this and getting errors when building x64 apk

Step 3: Now open pubspec.yaml and change the version from
version: 1.0.0+1 to version: 1.0.0+2

The number next to + is version code

Step 4: Now run the command
flutter build apk --release --target-platform=android-arm64

After this command completes, go to build/app/outputs/apk/release/. In there you will find an apk with name app-arm64-v8a-release.apk. This is your 64 bit apk file with different version code.

Now upload this x64 apk to play store....and here you go. You have uploaded both x86 and x64 apps to play store.

It is working to me also without step 1. Thanks to every one. I have used ndk filters ndk {
abiFilters "armeabi-v7a", "x86"
}
in build gradle file. I dont know it is required or not. Other than that, i had followed all steps from step 2 and uploaded two apk's, one for 32 bit and other for 64 bit.

Earlier i had uploaded appbundle, this time uploaded apk files. Working fine. I have to check with appbundle and also trying to fix without uploading two apk's.

Note :
Before doing this process, my app has crashed in following arm-64 bit devices
Redmi MI,
Redmi 3S Prime
Honor 8x

Worked in in following arm-64 bit devices
Samsung Galaxy J4
Samsung On8

Hi Flutter Team,

Pls. also consider other app markets such as those in China. In China, we are not allowed to use Google Play Store, instead, we have many app markets such as the XiaoMi's, the HuaWei's and the Ali's ...etc.

In those app markets, we are NOT allowed to provide apk releases in different architectures, we can only upload ONE AND ONLY ONE apk per release, and that release will override the previous release's apk. Which means that the current work around is to use "armeabi-v7a".

Correct me if I'm wrong, by using "armeabi-v7a", all 64-bits devices will be running 32-bits libflutter.so, and I guess it will be slower.

So I would suggest if the flutter team can provide a method to allow us to build an apk that includes both 32-bit and 64-bit libflutter.so, although the size of the apk will be bigger. (In China, we usually have very fast internet speed and we pay little to have infinite 4G usage plans, and people don't usually care about the size of the apk)

Hi Flutter Team,

Pls. also consider other app markets such as those in China. In China, we are not allowed to use Google Play Store, instead, we have many app markets such as the XiaoMi's, the HuaWei's and the Ali's ...etc.

In those app markets, we are NOT allowed to provide apk releases in different architectures, we can only upload ONE AND ONLY ONE apk per release, and that release will override the previous release's apk. Which means that the current work around is to use "armeabi-v7a".

Correct me if I'm wrong, by using "armeabi-v7a", all 64-bits devices will be running 32-bits libflutter.so, and I guess it will be slower.

So I would suggest if the flutter team can provide a method to allow us to build an apk that includes both 32-bit and 64-bit libflutter.so, although the size of the apk will be bigger. (In China, we usually have very fast internet speed and we pay little to have infinite 4G usage plans, and people don't usually care about the size of the apk)

In your case, you can provide the standard 32-bit and everything will be fine, right?
The 64 bit warning is only for Google Play. I believe this is not an issue for China.
(Please, correct me if I am wrong.)

@KunalT6569 I guess step 3 as stated by you:

Step 3: Now open pubspec.yaml and change the version from
version: 1.0.0+1 to version: 1.0.0+2

is required to allow uploading both apk files to google play console, isn't it?

I have one more question - once both apk files are ready, you simply upload them via App releases\New Release\Browse Files section, don't you?

@angel1st Yes, Step 3 is required as Google play will not allow uploading two apks with same version codes.

For uploading multiple apks to google play, I referred to this video.
https://www.youtube.com/watch?v=rMl_oLlf_g0

FYI:

Our current plan is to release a beta using one of the recent dev releases in the coming 10 or so days. Then, our plan is to wait until we have an updated documented process for how to ship on Android that does not trigger the warnings about 64bit builds from the Play store, to have a way to package an APK that supports 64 bit, and to prove we can release the gallery using that process, and as soon as we have done that, to follow the process to release a new beta which we will then push to stable a week or so later.

This means we will likely have a beta in early June, and a beta in late June or early July which will go to stable shortly thereafter.

@Hixie There is Another Problem Arose here
app bundle by latest flutter (master as of now) not generating x86 , x86_64 versions
Files produced by master branch

Files generated by Old Version with android studio

Expected Behaviour is to include x86 , x86_64 versions as well in file produced by new version

@canewsin independent of this issue, we don't provide x86 release binaries (https://github.com/flutter/flutter/issues/9253) - is the "old version" in https://github.com/flutter/flutter/issues/18494#issuecomment-497118805 referring to a debug build?

I have the same problem, building for 32-bit will exclude 64-bit devices, it runs on them though. Building for 64 by specifying --target-platform android-arm64 works on 64-bit devices, but crashes on 32-bit devices. Also Google will be restricting upload of apks to be 64-bit in 2019.

Flutter Team, please resolve this basic issue!

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

i compiled my app with latest flutter master branch and uploaded to play store as app bundle but app is crashing on device this log is taken from test lab

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

Flutter doctor -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 looks like this issue was fixed in https://github.com/flutter/engine/pull/9078. In your Flutter tree, update your local master branch, git fetch upstream && git merge upstream/master

After seeing repeated questions, which have already answered in previous comments, I wrote a short article documenting what options we have now https://medium.com/@truongsinh/flutter-android-64-bit-so-what-the-fuss-15da6f8e3a46. Here's the TLDR:

@truongsinh, we're also finalizing support for using flutter build appbundle to build an app bundle containing both 32 and 64 bit binaries for deployment to the Play Store. See https://github.com/flutter/flutter/issues/31922 for more info - please try it out and let us know if you encounter any problems.

@truongsinh, we're also finalizing support for using flutter build appbundle to build an app bundle containing both 32 and 64 bit binaries for deployment to the Play Store. See #31922 for more info - please try it out and let us know if you encounter any problems.

Yep I'm still waiting for flutter build appbundle to produce app the does not stuck or crash :D

Yep I'm still waiting for flutter build appbundle to produce app the does not stuck or crash :D

Acknowledged 🙂 . If you have a reproducible case of this happening that we can take a look at, that'd be great. If you were willing to build an unsigned .aab file from the 1.7.1 release and send it to me via email ([email protected]), I'd appreciate it!

FYI, the following announcement was sent to [email protected] regarding our 64-bit support.

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

I am having this issue too.

When I build app bundle in Android Studios i can load it fine on my simulator, but it crashes the app when I download it from the play store

Hi Guys people who are using flutter master branch and building app bundles
if you are debugging your app your app runs fine
some face crashes on downloading from play store if this happens you have check your app bundle whether it is working on your device because debug mode produces JIT binaries and release mode produces AOT binaries currently their placements are also different i think so to test your app correctly
produce apk from app bundle for only specific configuration based on your device and completely uninstall debug app from your device and install this new output app from app bundle if it crashes it will crash when downloaded from play store or otherwise, hope this will help others..

Ref for Output to APK from your app bundle from cmd line
https://developer.android.com/studio/command-line/bundletool

FYI, the crashes in the app bundles are better tracked in https://github.com/flutter/flutter/issues/31922. However, cross-posting here:

Hi all,

TLDR:

We've identified the problem with the crashes when downloaded from the Play Store and are working on a fix, to be delivered within the same timeframe as outlined above in https://github.com/flutter/flutter/issues/31922#issuecomment-498880614

High-level explanation

For those interested, the somewhat long explanation is that with devices running Android Marshmallow or later, the Play Store will detect apps that are packaged as App Bundles containing multiple ABIs -- and it will install those apps on the device in the form of "split APKs". When it does this, the .so files contained therein are not extracted from the APK zip archive, which is different than the behavior of non-split APKs. Since Flutter engine's current mechanism for finding the .so files assumes they've been extracted from the APK, it fails in the case of split APKs.

The solution is just to dlopen the libraries, and Android abstracts away where the libraries are located (i.e. within an archive or not). However, the necessary .so files were never true libraries to begin with - they were just binary blobs of data that we loaded into the Dart VM. So as part of this, we're making them ELF libraries (e.g. https://github.com/dart-lang/sdk/commit/6d608fb52bc1926a73d986d73ab228b77cfb7ca2 and https://github.com/flutter/flutter/pull/33696).

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

I get this error after adding the code snippet to build.gradle
Gradle build failed to produce an Android package.

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

I get this error after adding the code snippet to build.gradle
Gradle build failed to produce an Android package.

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

Could someone solve the problem? I have an app on flutter that only works its 32-bit apk but the 64's do not work or do not install. I'm testing on a 64-bit cell phone

@CgarciaTC please see https://github.com/flutter/flutter/issues/18494#issuecomment-500101807 for the most recent update

Hi all,

We believe the fixes have all landed on tip-of-tree on the master channel. If you'd like to try them out, here's how:

• flutter build appbundle

  By default, the App Bundle contains your Dart code and the Flutter runtime compiled for armeabi-v7a (32-bit) and arm64-v8a (64-bit)

• flutter build apk --split-per-abi

  This command will result in two APKs:

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

• flutter build apk

  This will result in a fat APK that contains your code compiled for all the target ABIs. Such APKs will be larger in size than their split counterparts, causing the user to download native binaries that are not applicable to their device’s architecture.

flutter build apk --split-per-abi
This command will result in two APKs:
build/app/outputs/apk/release/app-armeabi-v7a-release.apk
build/app/outputs/apk/release/app-arm64-v8a-release.apk

@tvolkert - in this particular scenario, what about each release version number? As long as I am aware, they have to differ, so we can upload both into Google Play. Is that part somehow managed, when the apks are built? If not, how is it supposed to be handled?

@angel1st it's managed automatically when the APKs are built, per the guidance in https://developer.android.com/studio/build/configure-apk-splits#configure-APK-versions

@tvolkert is there any information about when this will land in stable channel ?

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

Can confirm this is working (After switching to master) on multiple android devices. What a lifesaver, thank you.

@tvolkert Thanks heaps. Any timeline for getting this into Flutter stable?

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

@harsha973 you are seriously tagging and asking the exact same question that he answered 2 posts above yours. Not only ignorant but on the verge of disrespectful.

@PerLycke sorry about that.

I have checked out the master channel, upgraded flutter and now I can't really build the app, using the command:
flutter build apk --release --flavor production -t lib/main.dart
the result is:

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

Similar StackOverflow issues' answers do not really help.

@MichaelRFairhurst flutter build apk --release worked well for me, so maybe the new updates on master also requires an update to your flavor settings.

I know it's not an answer, sorry, but at least a point in the right direction.

When will the fix go beta?

@derolf please see https://github.com/flutter/flutter/issues/18494#issuecomment-498880287 as the most recent update with target timelines.

Hi all,

These fixes are now live in the dev channel, at the v1.7.4 release or later.

While trying to figure out this 64 bit stuff, I am having the same issue as @michalsuryntequiqo and I cannot build anything now via CLI. It builds and runs fine through Android Studio....
run flutter build apk --flavor=dev -t lib/main-dev.dart

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

doctor

Edit:
just tried with the commit right before 8627ff433b4658195e66b9c0034902116f53d580 and it produces the apk with the usual error Gradle build failed to produce an Android package. because of https://github.com/flutter/flutter/issues/24106

@blasten Any idea how to get this working again with your changes?

Edit 2:
Opened new issue for this: https://github.com/flutter/flutter/issues/34598

I read flutter documentation today and i found:

From the command line:

Enter cd
(Replace with your application’s directory.)
Run flutter build apk --split-per-abi
(The flutter build command defaults to --release.)
This command results in two APK files:

/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 which versioncodes are used, when using --split-per-abi?

I saw it in the documentation and i thought to publish it here. I didn't test it.
I'd run the command and didn't work. It says:

Could not find an option named "split-per-abi".

Run 'flutter -h' (or 'flutter -h') for available flutter commands and options.

flutter doctor:

Flutter 1.6.3 • channel beta • https://github.com/flutter/flutter.git
Framework • revision bc7bc94083 (4 weeks ago) • 2019-05-23 10:29:07 -0700
Engine • revision 8dc3a4cde2
Tools • Dart 2.3.2 (build 2.3.2-dev.0.0 e3edfd36b2)

Running "flutter pub upgrade" in consumos_app... 19,8s

Running flutter doctor...
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel beta, v1.6.3, on Microsoft Windows [Versión 10.0.17134.829], locale es-AR)
[√] Android toolchain - develop for Android devices (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)
[!] Connected device
! No devices available

I think this function will be available soon.

I saw it in the documentation and i thought to publish it here. I didn't test it.
I'd run the command and didn't work. It says:

Could not find an option named "split-per-abi".
Run 'flutter -h' (or 'flutter -h') for available flutter commands and options.

flutter doctor:

Flutter 1.6.3 • channel beta • https://github.com/flutter/flutter.git
Framework • revision bc7bc94 (4 weeks ago) • 2019-05-23 10:29:07 -0700
Engine • revision 8dc3a4cde2
Tools • Dart 2.3.2 (build 2.3.2-dev.0.0 e3edfd36b2)
Running "flutter pub upgrade" in consumos_app... 19,8s
Running flutter doctor...
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel beta, v1.6.3, on Microsoft Windows [Versión 10.0.17134.829], locale es-AR)
[√] Android toolchain - develop for Android devices (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)
[!] Connected device
! No devices available

I think this function will be available soon.

Please be reminded that this is on dev channel / version 1.7.4 onward only. You are running beta channel / version 1.6.3

I just tried it (building and publishing using Codemagic) and it worked really well. Thanks!

Google still complains that I’m not using appbundle though. Given this warning, publishing apks maybe doesn’t make too much sense?

I would use appbundle - but this stops Google’s automated testing (generating the pre-launch-report) from working. Should I open a new issue for this?

@nohli We updated the docs to reflect the latest about app bundles/APKs: https://flutter.dev/docs/deployment/android#building-the-app-for-release.

Feel free to file the issue about Google’s automated testing.

I build my the app from bundle but after running on 64bit devices says libflutter.so is missing by building app for both 32bit device and 64bit device. How to add libflutter.so for both architecture in single bundle file?

@nohli We updated the docs to reflect the latest about app bundles/APKs: https://flutter.dev/docs/deployment/android#building-the-app-for-release.

Feel free to file the issue about Google’s automated testing.

@blasten The procedure given on in the link didn't produce 64-bit APK in the bundle. When I uploaded the bundle, the Google Play store had the same error intact saying your APK is not 64-bit compliant.

@wal33d006 see the disclaimer at the top of the page - it only applies to v1.7.4 or later (currently dev or master channels).

@wal33d006 see the disclaimer at the top of the page - it only applies to v1.7.4 or later (currently dev or master channels).

@tvolkert I am unable to even build my application through dev or master channels.

This is my output when I build it on dev or master channels:

Compiler message:
file:///Users/waleed/.pub-cache/hosted/pub.dartlang.org/cached_network_image-0.5.1/lib/cached_network_image.dart:199:38: Error: The argument type 'void Function(ImageInfo, bool)' can't be assigned to the parameter type 'ImageStreamListener'.

• 'ImageInfo' is from 'package:flutter/src/painting/image_stream.dart' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart').
• 'ImageStreamListener' is from 'package:flutter/src/painting/image_stream.dart' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart').
  Try changing the type of the parameter, or casting the argument to 'ImageStreamListener'.
  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: Error: The argument type 'void Function(ImageInfo, bool)' can't be assigned to the parameter type 'ImageStreamListener'.
• 'ImageInfo' is from 'package:flutter/src/painting/image_stream.dart' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart').
• 'ImageStreamListener' is from 'package:flutter/src/painting/image_stream.dart' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart').
  Try changing the type of the parameter, or casting the argument to 'ImageStreamListener'.
  _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: Error: The argument type 'void Function(ImageInfo, bool)' can't be assigned to the parameter type 'ImageStreamListener'.
• 'ImageInfo' is from 'package:flutter/src/painting/image_stream.dart' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart').
• 'ImageStreamListener' is from 'package:flutter/src/painting/image_stream.dart' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/painting/image_stream.dart').
  Try changing the type of the parameter, or casting the argument to 'ImageStreamListener'.
  _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: Error: The argument type 'Null Function(StringBuffer)' can't be assigned to the parameter type 'Iterable Function()'.
• 'StringBuffer' is from 'dart:core'.
• 'Iterable' is from 'dart:core'.
• 'DiagnosticsNode' is from 'package:flutter/src/foundation/diagnostics.dart' ('file:///Users/waleed/Developer/flutter-sdk/flutter/packages/flutter/lib/src/foundation/diagnostics.dart').
  Try changing the type of the parameter, or casting the argument to 'Iterable Function()'.
  informationCollector: (StringBuffer information) {
  ^
  Compiler terminated unexpectedly.

FAILURE: Build failed with an exception.

• Where:
  Script '/Users/waleed/Developer/flutter-sdk/flutter/packages/flutter_tools/gradle/flutter.gradle' line: 638

• What went wrong:
  Execution failed for task ':app:compileflutterBuildReleaseArm'.

  Process 'command '/Users/waleed/Developer/flutter-sdk/flutter/bin/flutter'' finished with non-zero exit value 1

• 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 14s
Running Gradle task 'bundleRelease'...
Running Gradle task 'bundleRelease'... Done 15.0s
Gradle task bundleRelease failed with exit code 1

@wal33d006 package:cached_network_image is now version 0.8.0and you're using 0.5.1 -- it looks like when running against the newer version of Flutter, you need to update your version constraint in your pubspec.yaml and flutter packages upgrade

@tvolkert you are saying that in v1.7.4 the file libflutter.so is automatically added for 64bit device when we build the bundle using command flutter build appbundle?

@nimesh1997 yep, although the build that makes it to stable will likely be a newer version.

@tvolkert I changed my channel to ### master channel and also upgraded the ### package:cached_network_image version to 0.8.0 by changing inside the pubspec.yaml. But when running flutter packages upgrade. Error shows below like this:
**Because cached_network_image >=0.7.0 depends on flutter_cache_manager ^0.3.2 which depends on path_provider ^0.5.0+1, cached_network_image >=0.7.0 requires path_provider ^0.5.0+1.

@nimesh1997 can you file a separate issue and cc me? There are hundreds of people subscribed to this bug.

@tvolkert When will be flutter version 1.7.4 be available in stable channel and when the error mentioned below be resolved in flutter version 1.7.4 because of that error it does not run on 64bit devices (libflutter.so is missing)?

This is the output I am getting when I run on flutter v1.7.4 or later:-

Compiler message:
file:///home/zunroof-dev-4/package_flutter/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_image-1.0.0/lib/network.dart:75:31:
Error: The argument type 'Null Function(StringBuffer)' can't be assigned to the parameter type 'Iterable Function()'.

• 'StringBuffer' is from 'dart:core'.
• 'Iterable' is from 'dart:core'.
• 'DiagnosticsNode' is from 'package:flutter/src/foundation/diagnostics.dart' ('file:///home/zunroof-dev-4/package_flutter/flutter/packages/flutter/lib/src/foundation/diagnostics.dart').
  Try changing the type of the parameter, or casting the argument to 'Iterable Function()'.
  informationCollector: (StringBuffer information) {
  ^
  file:///home/zunroof-dev-4/package_flutter/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_image-1.0.0/lib/network.dart:168:65: Error: The argument type 'String' can't be assigned to the parameter type 'DiagnosticsNode'.
• 'DiagnosticsNode' is from 'package:flutter/src/foundation/diagnostics.dart' ('file:///home/zunroof-dev-4/package_flutter/flutter/packages/flutter/lib/src/foundation/diagnostics.dart').
  Try changing the type of the parameter, or casting the argument to 'DiagnosticsNode'.
  context: '$runtimeType failed to load ${instructions.uri}',
  ^
  Compiler terminated unexpectedly.

Error compiling, does not generate logs and flutter doctor -v does not point to errors. what should I do?

If you are deploying the app to the Play Store, it's recommended to use app
bundles or split the APK to reduce the APK size.
To generate an app bundle, run:
flutter build appbundle --target-platform android-arm,android-arm64
Learn more on: https://developer.android.com/guide/app-bundle
To split the APKs per ABI, run:
flutter build apk --target-platform android-arm,android-arm64
--split-per-abi
Learn more on:
https://developer.android.com/studio/build/configure-apk-splits#configur
e-abi-split
Initializing gradle... 7,4s
Resolving dependencies... 4,3s
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
Running Gradle task 'assembleRelease'...
Running Gradle task 'assembleRelease'... Done 9,0s

Gradle build failed to produce an Android package.

@leonardop21 try with

flutter run -v

@canewsin

OMG. I have no idea what to do now

Gradle build failed to produce an Android package.

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

1 _buildGradleProjectV2

(package: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 (package: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)

We have updated our docs to indicate how you can build APKs with 32-bit and 64-bit binaries. https://flutter.dev/docs/deployment/android#building-the-app-for-release .

Please use the dev channel: v1.7.9 or above. The team is working to promote the latest changes to beta by this Friday (06/28/2019).

Compiler message:
file:///Users/systemgnk/Desktop/flutter/.pub-cache/hosted/pub.dartlang.org/flare_flutter-1.5.2/lib/flare.dart:1033:18: Error: The argument type 'Int32List' can't be assigned to the parameter type 'Uint16List'.

• 'Int32List' is from 'dart:typed_data'.
• 'Uint16List' is from 'dart:typed_data'.
  Try changing the type of the parameter, or casting the argument to 'Uint16List'.
  indices: _indices, textureCoordinates: _uvBuffer);
  ^
  Compiler terminated unexpectedly.

FAILURE: Build failed with an exception.

• Where:
  Script '/Users/systemgnk/Desktop/flutter/packages/flutter_tools/gradle/flutter.gradle' line: 631

• What went wrong:
  Execution failed for task ':app:compileflutterBuildReleaseArm'.

  Process 'command '/Users/systemgnk/Desktop/flutter/bin/flutter'' finished with non-zero exit value 1

• 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 22s
Running Gradle task 'assembleRelease'...
Running Gradle task 'assembleRelease'... Done 23.3s
Gradle task assembleRelease failed with exit code 1

[✓] Flutter (Channel dev, v1.7.10, on Mac OS X 10.13.6 17G65, locale en-US)
• Flutter version 1.7.10 at /Users/systemgnk/Desktop/flutter
• Framework revision 9a3a7490c8 (2 days ago), 2019-06-25 15:59:15 +0200
• Engine revision ae8e6d9f46
• Dart version 2.4.0

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

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

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

[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 3.3)
• Android Studio at /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)

[✓] Connected device (4 available)
• Android SDK built for x86 • emulator-5554 • android-x86 • Android 7.0 (API 24) (emulator)
• System’s iPhone • 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

• No issues found!

I am still having issue with building apk.
I was only available to build 32bit apk in stable channel.

I think I need to wait until flutter team fix this bug rather than use dev or master channel sdk.

Thank you.

@JaeyoungChu Refer to 2d-inc/Flare-Flutter#79

@ctrysbita Thanks for the link. I changed the channel to master and change type of _indices from Int32List to Uint16List.
apk which is uploaded on play store does not have warning for 64bit and it is running after installing from play store test page.

I have other issues with dev channel flutter sdk such as not pop up permission dialog for location and google map does not show in ios and could not show big image file by http(cached network image). Those issues are not sure due to dev channel but when I got back to stable and build again all the issues are gone. I do not have much time for digging in this issues so it is not 100% sure. Sorry about that but perhaps someone get hint from this issues.

This was my solution:

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. run flutter build apk --release --target-platform=android-arm
2. upload app-armeabi-v7a-release.apk to the play store
3. increment versionCode
4. run flutter build apk --release --target-platform=android-arm64
5. upload app-arm64-v8a-release.apk to the play store

Google play store will serve App according to device architecture. 32bit devices are happy, 64bit devices are happy and I'm happy knowing that my APK size remains relatively small while still serving both architectures.

If we include support for both architectures in the same APK, expect the size of your app to be 10MB+

WHERE? WHERE do we add the splits section to the gradle file?? I added it between flutter {} and dependencies {} and it will not build the first APK as it says:

Please review your Gradle project setup in the android/ folder.

So clearly this is not right, as this is the only change I have made to the project since my last build.

@ArtfulDodgerB92 Thanks for the solution. which channel did you user for building apk and version?

WHERE? WHERE do we add the splits section to the gradle file?? I added it between flutter {} and dependencies {} and it will not build the first APK as it says:

Please review your Gradle project setup in the android/ folder.

So clearly this is not right, as this is the only change I have made to the project since my last build.

@ArtfulDodgerB92 it should be inside android{} section, as written here: https://developer.android.com/studio/build/configure-apk-splits.html

FYI, the following announcement was sent to [email protected] regarding our 64-bit support.

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

any news about an upcoming beta release?

@nohli we delayed the beta release by a few days to pick up a fix (revert commit) to https://github.com/flutter/flutter/issues/35291. We're working to get a release out to beta ASAP.

This is now live on the beta channel, in release v1.7.8+hotfix.2

This is now live on the beta channel, in release v1.7.8+hotfix.2

Сool how to generate release apk ?

This is now live on the beta channel, in release v1.7.8+hotfix.2

Сool how to generate release apk ?

Here's the instruction https://flutter.dev/docs/deployment/android

This is now live on the beta channel, in release v1.7.8+hotfix.2

Сool how to generate release apk ?

Here's the instruction https://flutter.dev/docs/deployment/android

i tried but not working at 32

i tried but not working at 32

What do you mean by 32? Like "I can generate a fat apk, and that apk is working on a 64-bit device, but crashing on 32-bit device"?

Can you post the result of flutter doctor, your step-by-step (e.g. this is the step 2 of progard https://flutter.dev/docs/deployment/android#step-2---enable-obfuscation-andor-minification), are you generating APK or AAB, and which device are you testing?

do we still need to put
ndk { abiFilters 'armeabi-v7a' , 'x86', 'armeabi' } in the gradle ot no longer needed after the fix on beta??

@ksamj that isn’t needed.

i tried but not working at 32

What do you mean by 32? Like "I can generate a fat apk, and that apk is working on a 64-bit device, but crashing on 32-bit device"?

Can you post the result of flutter doctor, your step-by-step (e.g. this is the step 2 of progard https://flutter.dev/docs/deployment/android#step-2---enable-obfuscation-andor-minification), are you generating APK or AAB, and which device are you testing?

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, v1.7.8+hotfix.2, on Mac OS X 10.14.5 18F132, locale ru-RU)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
[✓] iOS tools - develop for iOS devices
[✓] Android Studio (version 3.4)
[✓] Connected device (1 available)

• No issues found!

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, v1.7.8+hotfix.2, on Mac OS X 10.14.5 18F132, locale ru-RU)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
[✓] iOS tools - develop for iOS devices
[✓] Android Studio (version 3.4)
[✓] Connected device (1 available)

• No issues found!
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, v1.7.8+hotfix.2, on Mac OS X 10.14.5 18F132, locale ru-RU)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
[✓] iOS tools - develop for iOS devices
[✓] Android Studio (version 3.4)
[✓] Connected device (1 available)

• No issues found!
build apk
I did everything as in the instructions but it does not install on 32 bit

I did everything as in the instructions but it does not install on 32 bit

Any screenshot/log showing that the installation of 32-bit apk on the 32-bit device was not successful, and what device model is that?

Hi all,

v1.7.8+hotfix.2 has been released to the stable channel, so this fix is now available in all channels. Thanks everyone for your patience and help along the way!

I did everything as in the instructions but it does not install on 32 bit

Any screenshot/log showing that the installation of 32-bit apk on the 32-bit device was not successful, and what device model is that?

thanks for help, i tried to build appbundle and its worked.

@tvolkert Same issue please check it. https://github.com/flutter/flutter/issues/31962#issuecomment-509458960

@nimesh1997 that issue has nothing to do with this one. If you didn't find the answers provides in the linked issue helpful, perhaps you could look at posting a Stackoverflow question with your problem.

@tvolkert - just to clarify - the above hotfix can be used to build separate apks according to flutter docs instructions, correct?
Therefore, it won't be required to make any other changes in gradle file as described in earlier partial solutions
Thanks for you and the rest of the team excellent work and on time delivery!

I have just compiled one of my app with the most recent hot fix. As a result the compiled app-production-armeabi-v7a-release.apk is not able to run on Galaxy S3 mini (Android OS 4.1.2) - after the splash screen, the app closes without any notification.
I am able however to successfully run the very same apk on 64 phone e.g. Galaxy S8.
here is how I run the flutter from the command line:

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

and here is my flutter doctor -v

[√] Flutter (Channel stable, v1.7.8+hotfix.2, on Microsoft Windows [Version 10.0.17763.557], locale en-US)
• Flutter version 1.7.8+hotfix.2 at E:\DevToolsflutter
• Framework revision 2e540931f7 (7 days ago), 2019-07-02 09:31:07 -0700
• Engine revision b1cb0d9e9b
• Dart version 2.4.0

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
• Android SDK at E:\DevTools\Android\Sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-28, build-tools 28.0.3
• ANDROID_SDK_ROOT = E:\DevTools\Android\Sdk
• Java binary at: E:\DevTools\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 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)

[√] Connected device (1 available)
• Android SDK built for x86 • emulator-5554 • android-x86 • Android 8.1.0 (API 27) (emulator)

• No issues found!

Additionally - the fat apk also is not able to run - after the install (on the same arm-32 device) & run it just closes.
Please let me know how to proceed and resolve the issue, thanks!

@angel1st is it possible that you can share your AAB and/or APK file here so that we can help you troubleshooting?

@truongsinh - sure, here they are:

app-production-releases.zip

I have uploaded both APKs, although, the alleged issue is with arm-32 version as stated above.

Guys, in the meantime, would someone be so kind and tell (if they know), what would happen after August 1st in Google Play Store, in case you do not have arm-64 version of your app - would the apk will stop to be served to arm64 devices or you will not be able to upload arm32 only version or both?

@angel1st I was able to run the app (app-production-armeabi-v7a-release.apk) on Android 4.4.2 Galaxy S4. Nice app!

I suspect this is very specific to Galaxy S3 mini / Android OS 4.1.2. In the meanwhile, I requested this configuration to see if I can repro the issue.

@angel1st here's the most informative source: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

The requirement [64-bit stuff] does not apply to:

• APKs or app bundles explicitly targeting Wear OS or Android TV, which are form factors that do not currently support 64-bit code.
• APKs or app bundles that are not distributed to devices running Android 9 Pie or later.

Starting August 1, 2019:

• All new apps and app updates that include native code are required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play.

In other words, apps continue to be distributed, though you cannot upload a new version of exisiting app, or publish new app without compliance.

@angel1st I was able to repro this issue on a Galaxy S3 mini running Android OS 4.1.2.

The logcat is:

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

I filed https://github.com/flutter/flutter/issues/35838 in the meanwhile.

cc @jason-simmons

@truongsinh - thanks for the overview.

@blasten - thanks for the prompt feedback. As far as I understand, there is nothing I can do ATM but monitor #35838 with fingers crossed it will be resolved at some point this month? I believe the same issue will appear to any other apk for Android 4.1.2 compiled with the most recent hot fix?
FYI - the app apk compiled with previous flutter stable version does not have this issue (S3 mini with Android 4.1.2 is one of my test devices).

Anyone else got a mail from Google today, saying

"Action required: Update your apps to be 64-bit compliant by August 1, 2019"

although already publishing both 32bit and 64bit versions?

It says

By August 1, 2019, all apps that use native code must provide a 64-bit version in order to publish an update. As of the sending of this email, at least one of your apps* does not yet meet the requirement

*Note: This list of apps reflects Google’s best estimate as of the sending of this email. (...)

I guess, Google's "best estimate" is not correct?

Thanks for Flutter team. I upgrade Flutter and build on stable channel and the warning is gone.
hope to not have a bug with testers but so far I did not find any bugs yet with real device!

Thanks Team Flutter, upgrading Flutter with the hotfix fixes this issue when building .aab

Thanks to the flutter team for this achievement. Now to continue programmed!

@angel1st I am also having issues on some Samsung devices.

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

@abdullayev007 - thanks! I would suggest you to take a look at #35838, it might be somehow related.

I did everything as in the instructions but it does not install on 32 bit

Any screenshot/log showing that the installation of 32-bit apk on the 32-bit device was not successful, and what device model is that?

The device is Samsung M10

@tvolkert Please give me any solution for fixing following issue:
https://github.com/flutter/flutter/issues/36063

Thanks

I tried the latest version of flutter from dev channel - v1.8.4. I created a fresh project too - vanilla flutter project and tried building a release signed version out of it. It builds and app size is just 10.4 mb. But tried all above steps in this trail, nothing helping out. Can some one give a clear set of sequence of steps to take a build that we can push to playstore with aab or apk with emulator and local device from flutter. Its been more than a week, we have project built on flutter not moving to prod on android, but we are able to publish to appstore on ios. Some help will be great.

`[✓] Flutter (Channel dev, v1.8.4, on Mac OS X 10.14.5, locale en-US)
• Flutter version 1.8.4 at /Users/muthu/muthu/devapps/flutter
• Framework revision 954714c967 (7 days ago), 2019-08-02 10:10:39 -0700
• Engine revision 26368225b5
• Dart version 2.5.0 (build 2.5.0-dev.1.0 bd049f5b53)

[!] Android toolchain - develop for Android devices (Android SDK version 29.0.1)
• Android SDK at ../Library/Android/sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-29, build-tools 29.0.1
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
✗ Android license status unknown.
Try re-installing or updating your Android SDK Manager.
See https://developer.android.com/studio/#downloads or visit https://flutter.dev/setup/#android-setup
for detailed instructions.

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

[✓] Android Studio (version 3.4)
• Android Studio at /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 at /Applications/Visual Studio Code.app/Contents
• Flutter extension version 3.3.0

[✓] Connected device (3 available)
• Android SDK built for x86 • emulator-5554 • android-x86 • Android 9 (API 28)
(emulator)`

@muthufmass, please file a new issue with details of what's not working and how to reproduce the failure. Thanks!

Can some one give a clear set of sequence of steps to take a build that we can push to playstore

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

Can some one give a clear set of sequence of steps to take a build that we can push to playstore

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

These steps are already followed, its not working on the prod release build. debug build works! I clearly find a difference, in debug build, the .so files of flutter are present, but not with the release version. Those are ones, creating problem to install the apk to emulator or to devices with signed apk.

@muthufmass, please file a new issue with details of what's not working and how to reproduce the failure. Thanks!

I hope I have shared cleared steps above. Fresh app creation using flutter create - vanilla code with latest flutter sdk. Unable to build a release version, while debug versions runs smooth. Significant difference between prod and dev version of apk on size. Tried all the above steps, unable to build a release version that runs. Build happens super fast and file comes less than 11 mb with release, while with debug apk it comes around 40mb+. Debug apk works, while prod release signed apk doesnt install even.

@muthufmass when you file the new issue, please include the Android SDK version, device model, the doctor output, and steps starting from flutter create.

@muthufmass as well as adb logcat output.

This issue is closed - please file a new issue so we can track it properly.

raised a separate ticket now https://github.com/flutter/flutter/issues/37935

If u had flavors in your project, and want to support both x64 and x32, just add jniLibs folder to your flavor folder and it's work great, like this

how can I do this in adobe animate cc
need more info

Google play console recently has started disabling the rollout button because of various warnings. And one of those warnings is using apk instead of .aab file. There are solutions to make .aab file if the project has been created in Android Studio or Unity. But what if apk has been created by Animate CC or Haxe/Flash Develop? Is there any way to convert?

@newapproach it's not clear to me if your comment has anything to do with Flutter? Would you be willing to file a new issue with more details? Thanks!

Have the same problem - but flutter.so not included in "armeabi-v7a folder.
Has only third party libraries for x86 and armeabi-v7a - but no arm64.
Would like to build flutter only for "armeabi-v7a with
ndk{
abiFilters "armeabi-v7a" // also not work"armeabi", "x86",
}
and set as target-platform as @mravn-google suggest to android-arm.

APK without specify arch and not include libraries

APK with libraries and no arm spec

APK with specify arch and include libraries

Any suggestion how to debug further steps?

I has find this error too, it is fixed?? Could help me?

I recommend asking on Stack Overflow, or opening a new bug. I doubt this closed bug will be the right place for folks to help you resolve the above issue. Thanks!

This was my solution:

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. run flutter build apk --release --target-platform=android-arm
2. upload app-armeabi-v7a-release.apk to the play store
3. increment versionCode
4. run flutter build apk --release --target-platform=android-arm64
5. upload app-arm64-v8a-release.apk to the play store

Google play store will serve App according to device architecture. 32bit devices are happy, 64bit devices are happy and I'm happy knowing that my APK size remains relatively small while still serving both architectures.

If we include support for both architectures in the same APK, expect the size of your app to be 10MB+

doesn't work.. when I view it on playstore on pixel 2 it says not supported for this device

It does work, many well-known apps have been deploying multiple APKs this way and letting the Play Store serve the appropriate one to the appropriate device for a long time.

App bundles are the modern way to do this, though.

It does work, many well-known apps have been deploying multiple APKs this way and letting the Play Store serve the appropriate one to the appropriate device for a long time.

App bundles are the modern way to do this, though.

I don’t know why it’s not showing up on pixel 2 playstore for me then... I folllowr exactly , twice, just incase..
I used app bundle and my app is crashing hence I’m looking for alternatives

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.