UPDATE 2019–07–09: Flutter stable just get updated to 1.7.8+hotfix.2 , and now universal AAB and “fat” APK can be built with ease. Kudos to Flutter team.

UPDATE 2019–06–26: universal AAB and “fat” APK can be built using Flutter 1.7.9 or above. This version is already on dev channel, and expected to be on beta channel by 2019–06–28 and stable by July end.

UPDATE 2019–06–04: Flutter team is working as hard as they can to achieve universal AAB (and then “fat” APK). See the progress at PR#33696, and try out and giving feedback if you can. Meanwhile, don’t worry about the warning from Google Play Store.

Since the beginning of May 2019, there have been concerns over Google play warning about not compliant with the Play 64-bit requirement . Following Flutter’s Github issues, I see there are multiple duplicated issues regarding this (example #18494 and #31922), each with repeated questions, which have already answered in previous comments. In this post, I will sum the whole thing up in a simple flow chart, and will explain each node in the flow chart in detail below.

Embedded Flutter in existing Android App

If you follow simple official wiki Add Flutter to existing apps or more advanced instruction How to Add Flutter to your production Android app (disclaimer: I am the author), there is nothing you can do that I know of besides building only 32-bit apk/aab by using ABI filter.

This change may not be significant at first, but as soon as you app is using some 3rd-party library with pre-compiled binary (.so files, such as Mapbox’s), without this change, your app will crash on 64-bit device.

By there is nothing you can do that I know of , I really mean it. I did try manually copy libflutter.so from arm64-v8a , but it did not work, because besides libflutter.so , Flutter requires Dart AOT snapshot as well, and 32-bit AOT snapshot is not compatible with 64-bit runtime.

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’

Users in Mainland China or NOT using Google Play to distribute

Mainland China blocks all Google-related infrastructure, including Google Play (and http://flutter.dev), thus if you are to serve users here, there is no point using Google Play, which in turns no point worrying about Google Play warning. Similarly, if you are distributing your apps using alternative distributions, again, no point worrying about Google Play warning.

What you have to consider is whether to support only 64-bit devices. What it means to support only 64-bit devices is that any 32-bit device running your app will crash immediately. My 2-cent is that 32-bit app running and 64-bit-capable device might or might not be optimal, but you should not pay so much attention to this for now. Just stick to 32-bit apk/aab until Flutter team makes changes.

Ignoring Google Play warning

Google Play warning is like a deprecated warning, sometimes helpful, sometimes annoying. If you are willing to ignore the warning, by all means do so. This warning is an advanced notice, and shit will hit the fan only from August 2019. Flutter team has 3 months to react, let’s see, pray and wait.

Build separate apks/aabs for 32-bit and 64-bit

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

and

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

will produce 2 different apks (and the same applies to flutter build appbundle ). Upload these apks/aabs to the version of your app on Google Play, it will figure out and distribute the correct architecture to each device.

Conclusion

Well, the conclusion is the flow chart you saw at the beginning of this post. My personal recommendation for now is to stick with 32-bit only, don’t worry about the warning from Google Play Store. Flutter team is working as hard as they can to achieve universal AAB (and then “fat” APK). See the progress at PR#33696, and try out and giving feedback if you can.