Flutter: Support app bundles with 32-bit and 64-bit binaries within them

no

I had the same warning. Could someone from the Flutter team care to comment on, or explain the same, and what can we do to ensure that the appbundle generated with flutter build appbundle --release also have the 64-bit code. @zoechi Can you tell us something about it?

I'm also seeing this. Here's a screenshot:

And the "learn more" documentation is here: https://developer.android.com/distribute/best-practices/develop/64-bit

I'm looking forward to a reply from the Flutter team.

I got this warning message today too.

Same issue here.

me too

me too

Is there a solution for this yet?

Look at this: https://github.com/flutter/flutter/issues/18494#issuecomment-477502287

It worked for me.

the [start rollout to internal test] button is disabled in app releases page of Google Play Console (the screen where the above 64bit warning message appears)

the 64bit bundle requirement is now a show stopper for flutter projects.

/cc @mklim @cbracken

It appears the play store has started issuing a warning which is triggered if using the default release instructions from Flutter.
https://flutter.dev/docs/deployment/android

It is possible to submit APKs for both 32 and 64-bit ARM with Flutter, it just currently requires a couple extra steps. Various approaches to solving such are discussed in:
https://github.com/flutter/flutter/issues/18494#issuecomment-477502287

We're also looking right now to see how best we should update the default template/tools/release steps to avoid this warning.

Thanks for your patience.

@eseidelGoogle Correct me if I am wrong, however, I thought that the whole point of an app bundle was to pack everything into a single file and let the Play Store only ship the necessary apk to each user.

As I pointed out in my original question, I am using flutter build appbundle. In this case, the solution you proposed would not apply, right?

We tried flutter build appbundle yesterday and were getting error messages from the play store that it was a debug build ...

of course it also needs to work in add2app scenarios where instructions from flutter.dev are not used but instead android studio build->Generate Signed APK is used

Thank you for labeling it critical

We just discussed this in person. @tvolkert is going to find someone to help drive this to closure.

I am also getting this warning, is there a way to default to 64bit ?

Small modification to build.gradle can force inclusion of 64bit native libs in release apk and aab - take a look here for workaround

For googles sake, please give us visibility in how many phones out there still use 32bit.
If you add 64bit and 32bit libs you increase the final apk size.

I have a non-flutter project, where I split the APK by ABI, so I have separate apks for 32bit and 64bit to reduce the size. Now this step seems to force me to increase the apk size moving forward.
But why ?

I don't have stats on how many 32bit only phones are out there in India/Africa ... I am certain it's next to nothing in Europe, the US, and parts of Asia.
What about x86 / x86_64 vs armeabi / arm64-v8a ? Do we need to add libflutter.so for all 4 ABIs into the final production apk ?
.. also mips ... are there any phones out there still using mips ? Only google knows.

@VarolOkan Use AAB and let google generate APK's for all ABI & screen dpi combinations it needs.

the [start rollout to internal test] button is disabled in app releases page of Google Play Console (the screen where the above 64bit warning message appears)

the 64bit bundle requirement is now a show stopper for flutter projects.

@eseidelGoogle or anyone - can anyone confirm if this is
a) a show stopper
or b) a warning until August
see: https://forums.expo.io/t/warning-with-the-google-play-64-bit-requirement/22305
He indicates there are some boxes on the left to check to get it to work, and if the warning says August it seems like a big problem if it is actually early May.

Also - very useful to know if in fact there are approximately no 32bit machines and using a single line abiFilter for 64bit arm is a viable option to support 99.5% of users or something; I saw somebody cleaning a full year ago "all phones on market" were 64bit... perhaps that means there are lots of old phones?

My understanding is this is not a show stopper, but rather a common warning. We've asked @blasten to take a look at what we can do here to make the default Flutter setup avoid this warning. I expect we'll have some updates in the next few days.

As @eseidelGoogle said, I will be taking care of this issue. In the meanwhile, have you tried to follow these steps https://github.com/flutter/flutter/issues/18494#issuecomment-489807239?

Is this not a problem anymore? https://github.com/flutter/flutter/issues/18494#issuecomment-482795450

It's not a showstopper. I got the warning but was able to release my app to
the playstore.

Kr Morten

On Tue, 7 May 2019 at 17.46, Audrius Karosevicius notifications@github.com
wrote:

Is this not a problem anymore? #18494 (comment)
https://github.com/flutter/flutter/issues/18494#issuecomment-482795450

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/31922#issuecomment-490135779,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4B4J5BY3BJVIELNEPC4N3PUGP7BANCNFSM4HJU7TZA
.

>

;-)
/Morten

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

To summarize:

1) Earlier this year Play communicated to developers that it will require apps uploaded to the store to provide 64-bit versions from August (https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html). This week, the Play Store has started to display an informational message for apps uploaded to provide a warning of the upcoming requirement. However, the Play Store requirements have not changed at this time.

2) The 64-bit APK requirement the warning references are possible to comply with now with a little manual effort to modify the gradle files in ones Flutter project: https://github.com/flutter/flutter/issues/18494#issuecomment-489807239 for one example as to how.

3) We're working on making the default behavior of Flutter comply with the coming updates to the Play guidelines around 64-bit support without any additional effort from users. I expect that work will be completed in the next few days/weeks, long before the August deadlines.

If I've missed something above, please don't hesitate to comment or reach out. Apologies that we didn't have this updated prior to Play turning on the warning. Thanks all for your help and feedback!

@eseidelGoogle

1. I can't publish the app created by flutter build apk. Play Store doesn't accept 32bit-only builds on my profile.
2. The solution from #18494 (comment) fails on 32bit devices like OnePlus One.

In my opinion, it is a showstopper.

@eseidelGoogle

1. Resolved. Google Play doesn't accept any builds if Rating and Countries are not configured. Just the message is misleading.

The 64-bit APK requirement the warning references are possible to comply with now with a little manual effort to modify the gradle files in ones Flutter project: #18494 (comment) for one example as to how.

after a good few hours of trial & error I was __not__ able to produce a signed apk nor appbundle containing a 64-bit libflutter.so

the only libflutter.so included in the bundle is the
armeabi-v7a (32-bit)
, when using
Android Studio 3.4
Build #AI-183.5429.30.34.5452501, built on April 10, 2019

menu: Build > Generate Signed Bundle / APK

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

both fail @ > Task :app:validateSigningRelease FAILED

@ciez This produced 64bit only apk for me:

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

@adriank
yes, it works.
figured out what the problem was: "~" in the path to the keystore.jks needed to be replaced with /home/user

sorry about the false alarm.

it appears that each bundle built like this can target only 1 arch at most?

Waiting for the Flutter update as the workaround just broke my builds.

@mulderpf which workaround did you apply, and how did your build break?

See this comment for the latest update from the Flutter team.

I got an update: I have this working in my branch!
The suggestion is to use flutter build appbundle --release --target-platform=android-arm-all (recommended to get APK split out of box) or flutter build apk --release --target-platform=android-arm-all in a future release.

Is anyone in the PST time zone willing to try it? If so, please reach out on Gitter or Slack :)

@blasten Sadly I wasn't able to produce appbundle with your branch. Gradle fails on app:properties somehow, but looking at the code it looks promising.
Have you managed to verify that flutter/engine will load AOT snapshots from ./lib/ directory? Looking at engine code it uses assets everywhere... If this works it will solve the overall App Bundles problem, as for now they lack the support of assets directory targeting by ABI.

@SPodjasek correct, it would also need a local build of the engine, so the classes in the APK look for the new snapshots.

@blasten I've managed to fix my build tree and now I can successfully build App Bundle that contains AOT snapshots in base/lib/${abi}/

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

And I'm wondering would it be enough to modify this...

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

to something like:

getContext().getApplicationInfo().nativeLibraryDir;

Of course, it wouldn't be that simple, but to get the general idea...

Here's how to try flutter build appbundle with 32 and 64 bits support:

1. Download flutter.jar from https://drive.google.com/open?id=1yAkfhPKfhdd8MwW39qfkZDePc66SMA_z and place it under {flutterInstallationPath}/bin/cache/artifacts/engine/android-arm-release. To check the Flutter installation path, use which flutter

If you want to see the changes to FlutterMain.java see: https://github.com/blasten/engine/commit/b3ab9def28a414ffa53bf10ad6a3249f31ed00e3

1. Check out the patch from this branch:

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

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

Let me know what you find.

+1

@danysz Instead of writing +1, if you had upvoted this issue, that would have made more sense (no harsh feelings for you). To others, if they read this message, kindly don't write "me too", "same here", "+1", instead upvote this issue.

Thank you!

@blasten Apps are failing to start:

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

This goes to my physical device and 9/10 Test Lab device - we have an inconsistent result for Pixel-Q-beta.

@danysz Instead of writing +1, if you had upvoted this issue, that would have made more sense (no harsh feelings for you). To others, if they read this message, kindly don't write "me too", "same here", "+1", instead upvote this issue.

Thank you!

done

@blasten Looking through your changes I've found that for existing apps one needs to modify AndroidManifest.xml

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

Nevertheless, it still fails...

@blasten

git build

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

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

Sadly I wasn't able to produce appbundle with your instructions. Gradle fails on app:properties somehow (after a "Building flutter tool..." and some downloads of android-arm-*....).

It seems that download process overwrote flutter.jar

@MoacirSchmidt I've had similar issues but cleaning build dirs (flutter clean) and gradle caches (~/.gradle/caches & ${projectRoot}/android/.gradle) helped

For people having an issue building 64-bit apk.
This setting worked for me.

build.gradle

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

increment versionCode

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

more discussion on https://github.com/flutter/flutter/issues/18494

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

For people, like me, who scared to change gradle files – if you want only 64 bit version, flutter build apk --release --target-platform=android-arm64 works even without modifying build.gradle.

@blasten I tried flutter build appbundle in the beta channel. When I try to upload to the play store, I still get the 32 / 64 errror.

I know you said master but I have some errors I am working through on that branch still. Just wanted to give you that info!

I am also getting this warning!

Is there any way to build an app bundle for all architectures?

Any update on how to fix it?

I'm closing this bug since it refers to app bundles. If you switch to the master branch, you can use flutter build appbundle to generate app bundles that support 32 and 64-bit CPU architectures. If you prefer or cannot use app bundles, then follow this thread for additional support via fat APKs.

@blasten - could you please provide a kind of instructions how to use it from within Android Studio?
Here is my current flutter config:

Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, v1.2.1, on Microsoft Windows [Version 10.0.17763.503], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[√] Android Studio (version 3.4)

When this change will go to the stable branch?

@blasten does it work with Add2App?

@blasten how to sign the app bundle created by flutter build appbundle?

@blasten is it a good way to use master branch for production apps?

@dblokhin you can use flutter channel master to switch to the master channel. Note that this is now available on the dev channel as well.

@tvolkert - any timeframe when this will be merged to the stable branch?

@angel1st I would guest about 3 months from now.

@truongsinh - considering August, 1st is about two months from now, I would expect much faster adoption, actually...

@angel1st it’s in stable already! I will find out more...

@angel1st it’s in stable already!

Are you sure about that? The current stable is 1.5.4-hotfix 2 ant it is not generating bundles with both 32 and 64. Or am I missing something ?

@shinayser it isn't yet, sorry. I will find out more and update the thread. As Todd mentioned, the master channel is the only option at this point.

I tried the appbundle. I had 1.6.1-pre version of Flutter in the master
channel.

The output of the bundle was around 12 MB which didn't generate the warning
and the individual APK sizes were around 7. So far everything is good.

But when I opened the app after updating through Play Store my app got
stuck in the Splash Screen.

I had no choice to revert to flutter build apk which worked fine, idk how
and why.

So I don't think this issue is closed yet, because even though the warning
is gone with the appbundle, so is the app itself. The appbundle is
rendering the app useless as it's stuck in the splash screen.

In that case, feel free to reach out to me directly on Gitter: https://gitter.im/flutter/flutter. If possible, it will be helpful if you can send the .aab file that the tool generated.

I believe we need the usage documented one way or another. Also I believe having this merged to stable prior the end of June is vital if Flutter team wants to keep developers around.

@angel1st we're working hard to get this work promoted to stable by the end of June.

Some updates:

We were able to reproduce apps getting stuck in the splash screen after deploying an APK from an app bundle (generated using flutter build appbundle from the master channel).

This seems to be caused by our placement of the AOT snapshots (vm-snapshot-data, vm-snapshot-instr, isolate-snapshot-data, isolate-snapshot-instr) as libraries within /lib/{abi}/lib_{snapshot}.so to get ABI split for app bundles. After all, the snapshots aren't real libraries and our hack to get this behavior didn't work.

EDIT: The root cause turned out to be that code in the Android embedder expects a directory named flutter_assets in this line, but my recent change to support app bundles disabled creating such directory, which caused the app to never start. This commit by @jason-simmons https://github.com/flutter/engine/compare/7f4f52f95294...e8db5dfd52ee fixes the issue.

Conclusion

The current plan is to allow the flutter tool to generate ELF shared libraries instead of AOT snapshots. This feature was just added to the Dart SDK in https://github.com/dart-lang/sdk/commit/af93ebcf4cb55ae5f0f39a183ad2d42ca13ae51f.

What this means is that we will get ABI split for app bundles and fat APKs using real libraries.

I will update this bug and https://github.com/flutter/flutter/issues/18494 once the issue is fixed. In the meanwhile, passing a --target-platform to build appbundle will let you build app bundles without moving the AOT snapshots to lib/.

Some updates:

We were able to reproduce apps getting stuck in the splash screen after deploying an APK from an app bundle (generated using flutter build appbundle from the master channel).

This seems to be caused by our placement of the AOT snapshots (vm-snapshot-data, vm-snapshot-instr, isolate-snapshot-data, isolate-snapshot-instr) as libraries within /lib/{abi}/lib_{snapshot}.so to get ABI split for app bundles. After all, the snapshots aren't real libraries and our hack to get this behavior didn't work.

The current plan is to allow the flutter tool to generate ELF shared libraries instead of AOT snapshots. This feature was just added to the Dart SDK in dart-lang/sdk@af93ebc.

What this means is that we will get ABI split for app bundles and fat APKs using real libraries.

I will update this bug and #18494 once the issue is fixed. In the meanwhile, passing a --target-platform to build appbundle will let you build app bundles without moving the AOT snapshots to lib/.

@blasten will this work properly when you have another libraries that uses native code as well? For example: VLC. It produces some .so when we are building the APK.

Yes - you can use other native code libraries within your APK.

In the new packaging format a Flutter app will include the libflutter.so engine library along with another .so containing the AOT snapshot data compiled from your app's Dart code. The app can add other .so libraries unrelated to Flutter if needed.

FYI, the fix to the issue of getting stuck on the splash screen should be in the (forthcoming) 1.7.0 dev channel release (https://github.com/flutter/flutter/wiki/Bad-Builds#v161---v167)

Hi all. The fix to the issue of getting stuck on the splash screen has landed on the dev channel - you should see it if you flutter upgrade to v1.7.0. Please try it out and let us know if you encounter problems with flutter build appbundle.

@tvolkert Did not work for me before and does not work for me now. Neither on channel dev (1.7.0) nor on channel master (1.7.1). App build with flutter build appbundle crashes after publishing it via Play Store and running it on a real device.
Edit: It works now on channel dev (1.7.0) after deleting the app from the device and reinstalling it from the Play Store.
Edit2: It does NOT work. Play Store was a little bit slower than normal while distribution the correct version. What can I do to help reproducing?

@masewo can you collect the tombstone from the device, along with what version of Flutter was running on it at the time?

@jason-simmons @blasten anything else you'd like to help track this down?

@tvolkert

tombstone:

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

flutter:

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

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

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

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

@jason-simmons @blasten it's this assertion that's causing the crash in @masewo's case

@masewo we're unable to reproduce the crashing on our side with out apps -- would you be willing to build an unsigned .aab file from the 1.7.1 release that demonstrates this behavior and send it to me via email ([email protected])? If so, that'd be hugely helpful!

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

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

@tvolkert is the team also working on making https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps compatible with all the points you were listing?

1. Provide a way (by default) to build an app bundle that supports both 32-bit and 64-bit. (already available to test on the dev channel)

2. Provide a way (by default) to build an APK that supports both 32-bit and 64-bit. (in progress)

@truongsinh Yes, see this comment in the pending PR: https://github.com/flutter/flutter/pull/33696#issuecomment-498934359

@masewo and everyone else: we've been able to replicate the crash described in https://github.com/flutter/flutter/issues/31922#issuecomment-498541765 and are tracking it down.

tldr: hang tight - we're on it 🙂

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

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 appbundle is now working for me. Thanks @tvolkert !

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

Great! Thanks go to @blasten, @jason-simmons, and @rmacnak-google - I'm just the messenger 🙂

Thank you to all of the Flutter team and contributors for such a rapid response. Hopefully, this one get's to the beta channel within 1.5 months :)

@tomaszpolanski the plan is to get it to beta by the end of June and to stable by early July 🙂

@tvolkert is there a flutter build appbundle command flag we can pass to also include x86?

@athornz not in release mode atm. See: https://github.com/flutter/flutter/issues/9253. It will be possible to add AOT snapshots for x86_64 in the near future though.

Switching to the master branch gives me the following error. Stable builds but fails to include 64bit in the release bundle.

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

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

@xinoxapps, can you send the full output of flutter build appbundle -v (as a gist.github.com link please, for readability of this thread 🙂)?

@xinoxapps, I was unable to repro this issue locally. Now, looking at the warnings you are getting, it seems there's some custom build.gradle config logic, which may or may not be causing the problem. Would it be possible to get to a minimal repro case? e.g. try removing some of that custom Gradle config until it works, then share what exactly caused the problem. This is how I defined the flavor:

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

Hi all,

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

I switched to app bundles and pushed to the Play Store, and most users seem happy. However, I have two reports of the app not starting at all on an x86 device which supports ARM emulation, the Asus ZenFone 2 ZE551ML: https://www.gsmarena.com/asus_zenfone_2_ze551ml-6917.php. Unfortunately the users haven't been able to provide adb logcat output. Is the new ELF format intended to work on such devices?

Switching to both master and dev channels gives me this error with flutter build appbundle:

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

@darioielardi can you include gist.google.com links with the output of flutter build appbundle -v, as well as the contents of your android/build.gradle and android/app/build.gradle files?

@tvolkert sure, https://gist.github.com/darioielardi/f7497398a39b2c12d4ea1767ca6b6e69

I switched to app bundles and pushed to the Play Store, and most users seem happy. However, I have two reports of the app not starting at all on an x86 device which supports ARM emulation, the Asus ZenFone 2 ZE551ML: https://www.gsmarena.com/asus_zenfone_2_ze551ml-6917.php. Unfortunately the users haven't been able to provide adb logcat output. Is the new ELF format intended to work on such devices?

yeah, i have the same problem. it works with flutter build appbundle and most of devices run my apps well. but not for this asus

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

@blasten Yes I understand that native x86 is not supported, but I think the issue here is that the ARM/ARM64 app bundles are getting installed by Google Play onto x86 devices that advertise support for ARM via translation, but the new appbundles somehow do not work correctly on such devices (perhaps because the new ELF formats confuse the ARM translator). The original ARM (non-ARM64) APKs do seem to work on them, however, as confirmed by reverting to a two-week old master branch (e1a784ae to be specific) and noting that the two users who were seeing issues now have my app running again on their ZenFone 2 devices. This is going to prevent me from upgrading to v1.7.4.

@xinoxapps, can you send the full output of flutter build appbundle -v (as a gist.github.com link please, for readability of this thread 🙂)?

It works for me now on the dev channel. Do you still need some info?

@xinoxapps nope - glad to hear it's working for you.

@darioielardi the issue is fixed in master now. Please run flutter upgrade in the master channel.

@darioielardi the issue is fixed in master now. Please run flutter upgrade in the master channel.

@blasten I've switch to master and got this error when executing flutter build appbundle
Execution failed for task ':app:transformClassesAndResourcesWithProguardForRelease'.

this is my gradle and full output https://gist.github.com/julindra/80cd2e588cf11bdd0df3f34239b07409

Hi all,

We're aiming to get a few more bug fixes in for add-to-app and flavors - and cut a v1.7.5 dev release. As such, we're holding off on promoting to beta to pick up those fixes. We still expect this in stable in early July.

flutter build appbundle worked for me. Thanks alot @tvolkert .

@julindra adding -ignorewarnings to 'proguard-rules.pro fixes that issue. We currently don't include the package android.arch.*. Another option is to edit your android/app/build.gradle and add the following:

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

cc @matthew-carroll

I uploaded the bundle app.aab to play store. The warning for missing 64 bit was gone but the app just crashed on launch after installing from play store. Any suggestions?

Also is it safe to use flutter build appbundle to release on production?

@sulaysumaria can you post the result of running flutter doctor?

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

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

! Doctor found issues in 2 categories.

@truongsinh

I also tried generating apk from app bundle and installing it. It also crashes on launch.

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

Try switching to dev channel and check.

I tried to build in dev channel but it broke one of my dependencies. I will try commenting it out and building to see if app works.

Also is it safe to use dev channel for production release?

Oops sorry. I would be more careful if it was for production.

I am going with building APKs for now. Although Google suggests to upload bundles instead of apks so it will be good if this is fixed in next release on stable branch.

I found this using adb logcat:

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

I am on stable channel.

Solution from https://github.com/flutter/flutter/issues/19865 worked.

I also had to remove splits section from build.gradle.

App works fine now when installed via bundletool. I will try uploading to playstore and check if everything goes well.

@sulaysumaria the fix is only available on the master branch yet. If you are on stable – as indicated on your flutter doctor output

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

the fix is not applied. You need to wait until the fix is on stable if you want to build with stable. Looks like its somewhere around 1.7.x until then you need to upload the apk's separately.

Ohh... Thanks @pythoneer . Do you know when will it be available on stable channel?

@sulaysumaria no problem. It is mentioned multiple times in this thread

We still expect this in stable in early July.

It worked on dev channel. I used flutter build appbundle --target-platform android-arm,android-arm64 and uploaded bundle to play store and it worked perfectly.

@sulaysumaria - you should use already prepared instructions with either master or dev channel.

@julindra adding -ignorewarnings to 'proguard-rules.pro fixes that issue. We currently don't include the package android.arch.*. Another option is to edit your android/app/build.gradle and add the following:

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

cc @matthew-carroll

Thanks. I just use dev channel and add -ignorewarnings, it works perfect.

worked for me with flutter build appbundle
https://github.com/flutter/flutter/issues/18494#issuecomment-489807239

@blasten is this closeable at this point, or is there work remaining?

@cbracken, I think this can be closed now or after the next stable release.

Are you still planning to address the incompatibility issue with ZenFone 2 device and similar x86 devices that allow installation of ARM apps from the Play Store and use libhoudini to run them?

I tried to build in dev channel but it broke one of my dependencies. I will try commenting it out and building to see if app works.

Also is it safe to use dev channel for production release?

I've never used any branch rather than dev and my apps are working seamlessly. So trust the branch it never disappoints. @sulaysumaria

@matthewlloyd we heard from the Play Store team that it's better to add an explicit x86 binary than trying to make the our existing binaries work well with the arm->x86 translator. - However, the team recently improved the code that the Dart compiler generates, and I wonder if that perhaps made the translation work. Give it a try and let me know. Otherwise, depending on the situation, you might need to build the JIT version for x86, which is typically used for debugging/profiling in emulators.

@blasten Thanks for the info. It puts me in a bit of a bind because I don't have one of these devices myself - just two anonymous Play Store reviews from disgruntled ZenFone 2 users - so I have no way to test. The risk of breaking things is too great to push out another appbundle build until somebody confirms the improved code actually works on those devices. Unless there's a way to tell the Play Store to exclude such devices, I will continue releasing builds created with an old version of Flutter (and 32-bit APKs), until it is either tested and confirmed fixed by Google, or confirmed no longer an issue. I guess that won't be until more apps are pushed to the store using the new appbundle/.so format. I will wait...

for those still looking, here was the solution that worked for me :

flutter build apk --split-per-abi
didn't work,, even after editing build gradle
from https://flutter.dev/docs/deployment/android#build-an-apk

instead, use :

1. flutter build appbundle
2. and then upload app.aab

issue fixed for both 32 and 64 bits, and the alert 'release is not compliant with the Play 64-bit requirement." has gone.

Thanks @juliengit2, flutter build appbundle does work.

It's worth mentioning the flutter version as well, because I had v1.5.0 until now and it didn't work.
I had to update (currently to v1.7.9) in order to make it work.

@PerechicK, by latest you meant stable channel or dev channel?

DEV channel, as it appears today here: https://flutter.dev/docs/development/tools/sdk/releases?tab=windows

I still don’t know since which version this issue is fixed.

When using anything other than the stable branch, I'm running into one of my plugins throwing the error "Methods marked with @UiThread must be executed on the main thread", which was introduced with this flutter sdk commit https://github.com/flutter/engine/commit/2c9e37c34e79475bbde7c8163eb5e56cdb9662a1.

Is there a way to build the 64-bit appbundle while using the 1.5.4-hotfix.2 stable branch?

@uj this issue https://github.com/flutter/flutter/issues/33562 might be related to your error if using firebase_database.

and no 64bit introduced in 1.7.4+ according to Flutter Docs

No, it's not firebase_database, it's actually OneSignal, but their only solution is to "use the stable branch of Flutter"

Is there a way to build the 64-bit appbundle while using the 1.5.4-hotfix.2 stable branch?

@uj even though you cannot build 64-bit appbundle with 1.5.4-hotfix.2, you can build 2 apks, one with 32-bit, one with 64-bit, upload both apks to Google Store to resolve the warning.

Flutter 1.5.4-hotfix.2 appbundle currently targets android-arm which builds only 32bit native code (flutter build appbundle -h). To change this run flutter build appbundle --target-platform=android-arm64 to change the default target.

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

@tvolkert - excellent news, thanks. Would you be more specific when we might expect the fix live in stable, e.g. a date when this will happen?

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

(we're working to make it happen as soon as possible)

@tvolkert - considering the fact we are about three weeks from the Google deadline re 64 bit apks, I would expect a deadline from your side as well. Also we as developers will need some time buffer between your release and the above mentioned deadline so we can build, test and release our apps without disturbing our clients.
Other than that, I really appreciate the efforts and deliverable for the last couple of months, but I hope you would be able to put yourself in our shoes and see how the things look like from that perspective. Thanks for the understanding and all you efforts so far!

@angel1st absolutely. Per the earlier announcement, we're aiming to have this to stable by early July (so very soon) - I just can't predict the exact date.

I have this problem in unity 2017.4.20 or 2019.1.2 , How can I resolve it? this
is in blow link : https://stackoverflow.com/questions/56687339/what-is-this-error-in-build-adroid-and-build-app-bundle-in-unity-2017-4-17 please Help me Because I am in this problem for 2 month thanks

Hope to see this one solved as soon as possible. The deadline is tight

@DoubleHub you can change to beta channel to solve it.
Or wait to release stable version in 8 July.

@abc873693 I read about it, I think I will wait for stable version. I'm happy that this problem is finally solved officially!

@abc873693 I experienced issues when attempting to publish android apps to the play store using the _beta_ channel. Pre launch reports showed Warnings for Accessibility. It appears that the app did not go past the Splash Screen. All screen shots for all the devices stayed at the splash screen.

The solution for me was to simply switch to the STABLE channel and build the app-bundle using the --target-platform flag.

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!

@tvolkert Thank you! I just confirmed that the observation that I mentioned here is no longer there with the stable channel!

@tvolkert how to apply this v1.7.8+hotfix.2 on existing project? Do i need to recreate all over again?

@jaasaria this issue is around building your app for release. if you're on stable, you'd need to upgrade your flutter installation. the issue reported here is around building an app bundle as per this link

@jaasaria just execute: $ flutter channel stable && flutter upgrade

@MaikuB I created my src file a month ago and everytime i build my project i need to execute flutter build appbundle --target-platform=android-arm64 command instead of flutter build appbundle to avoid playstore x64 error.

@dblokhin Just got upgraded and luckily my project didn't break. :) thanks you

Thanks @juliengit2, flutter build appbundle does work.

It's worth mentioning the flutter version as well, because I had v1.5.0 until now and it didn't work.
I had to update (currently to v1.7.9) in order to make it work.

Thanks for the warning!

I've flutter version 1.7.8+hotfix.3 will "flutter build appbundle" will result with app.aab with 32 & 64 bit both?

strange I tried with 1.7.8+hotfix.3 with channel stable and I get again the playstore warning:

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

when uploading a bundle after : _flutter build appbundle_

I tried also to upgrade flutter but same result.
and with a new Flutter install : same result

Here is my conf:

Any idea??

@juliengit2 Open .aab file as a normal zip, go into base/lib folder and check if there are armeabi-v7a and arm64-v8a folders

Tried doing it with my app "flutter build appbundle" lib folder contains v8a & v7a both. Can I push the update now, I don't want another warning coming to my head's email.

Another similar case of a far APK receiving warning https://github.com/flutter/flutter/issues/18494#issuecomment-509937209

for those with the same issue, I removed in build.gradle :

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

and the warning disappeared.

(if you keep the abifilters, you will still get "release is not compliant" even with _flutter build appbundle_

Hi i built my appbundle with success, but when i try to upload it to the play store i received this error...
To upload an Android App Bundle you must be enrolled in App Signing by Google Play.
Export your key from Android Studio. From the Build menu, select Generate Signed Bundle/APK. Select the Bundle option and press Next. Select Export the encrypted key and press Next.

i try to export the encrypted key like that, directly from the android module but i coudn't finish the process because i get this error

Process 'command '/Users/oaacelasu/Documents/flutter/bin/flutter'' finished with non-zero exit value 1

bref i supposed that is not the correct way... Is there another workaround to get the encrypted key for enrolling the app directly from the flutter build appbundle command?

I tried to use appbundle in playstore,
but in android 6.0 arm 64, it was crashed on startup because of libflutter.so could not be found, and after i checked the libflutter.so was included in aab arm 64

@matthewlloyd , I've reproduced this with a local chromebook (although that chromebook might be leaving on a trip for three weeks on Monday. I have to check). I think that it _should_ reproduce against most x86 chromebooks -- I think there are likely more of these than there are x86 phones.

the team recently improved the code that the Dart compiler generates, and I wonder if that perhaps made the translation work. Give it a try and let me know. Otherwise, depending on the situation, you might need to build the JIT version for x86, which is typically used for debugging/profiling in emulators.

@blasten , is there a particular version of Dart you were thinking of? I reproduced with 2.3.1 (with flutter 1.7.8+hotfix.2) Shall I test with 2.4.0?

Also, I reproduced when we released an alpha build. I still need to look into how to test an appbundle without going through the play store.

@wreppun Thanks for the heads up, I will hold off releasing a new-style AAB to my users for now since it seems the issue is not yet fixed (or even acknowledged by Google!). Can you share more information about the specific Chromebook, and is there a way to capture a crash log?

@matthewlloyd This is what showed up in the Play Store crash log:

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

That might show up in some of your (old) crash logs if any of your users opted in to sharing stats.

The device was an HP Chromebook x360.

I'm sorry this isn't working on 100% of the configurations. We are working to get better test coverage on a variety of SDKs and devices. In the meanwhile, I'm going to set up some tests on Firebase test lab.

At this point I think the most effective way for us to get all these fixed is probably to file new issues and link back to this one. @tvolkert and I will make sure each gets looked at, but it would help us if we could sort these into separate buckets and track their fixes individually.

It's very possible we need to make small adjustments to the Dart compiler, we have in the past for CPUs or emulators which have have specific processor quirks. Without testing on an x86 Chromebook myself (which I haven't yet) I can't say for sure.

Would those experiencing issues please help us sort out the remaining troubles by filing new issues for each? That would be of great help to making sure we address each one. Thank you!

@wreppun Thanks - I checked my app's crash reports and neither of the affected Asus ZenFone 2 users sent anything.

@blasten No worries, that's great. If someone can show the new appbundles work on an Asus ZenFone 2 device that would be enough to get me moving forward. Unfortunately I don't have access to one, but I'm hoping Google's mobile testing labs do.

@matthewlloyd no "Asus ZenFone" on Firebase test lab. What SDK version? Most of the time, the issue can be reproduced by just running a specific version of the Android SDK.

What SDK version? Most of the time, the issue can be reproduced by just running a specific version of the Android SDK.

😂

Hello Flutter team,
I would like to stress on this topic status. From my standing point, there are two severe issues:

• Current stable flutter version 1.7.8+hotfix.3 does not build stable apks - at least split-per-abi does not work as it should - arm32 has a regression issue and cannot run on some arm32 devices. It is not clear yet when this will be fixed;
• August 1st deadline - in about a week we as developers won't be able to neither update nor release new flutter apps to Google Play Store - as simple as that. Considering the current flutter version issue (as mentioned above) and the remaining time, I don't think it is feasible to expect having the fix in stable channel prior the end of the month (unless someone of you guys has a magic wand :-))

Considering the above two issues, I would like to suggest following contingency plan, which IMO would best serve us as developers:

• Rollback flutter stable channel to its version prior the hotfix.2
• Postpone August 1st deadline for couple of months - I understand this will require some escalation on the issue, but I hope you guys would understand how serious impact might have if the developers cannot release reliable flutter app after August 1st because of flutter framework issues.

I can speak on my behalf only, but I have clients with contracts and I decided to move from React Native to Flutter, since I believed, Google would provide better support for their own products. I have projects in progress and applications to support.
Now I find myself in an absurd case, when Google forces me to release 64 bit apk version and at the same time Google does not provide me with the tool to do that (and yes, I know Flutter team is not the same as Google Play team but where I stand from - you are the same business entity).
If Google fails to deliver on time, this will lead to strong push back from Flutter, since each day after August 1st will shrink framework's credibility.
I apologize if my words sound a bit stronger, I only hope you can put yourself in my shoes for the moment.

Anyone - please vote on this, and hopefully we will have our voice heard!

I also agree to this... But as a contingency plan I would suggest not to rollback to previous release, but rather switch to dev channel....

From my personal experience, I was also not comfortable using dev channel i initially. I thought of sticking to stable channel, because you know, its stable!... But now I have been using dev channel and releasing apps using app bundles on play store without any issue....

The situation is something which shouldn't occur as both are Google product...

What I presented is just a simpler workaround, because you can start pushing updates using aabs and not apks, which is suggested by Google...

@angel1st same issue, same problems, same shoes
@sulaysumaria if we switch to dev channel, will the libapp.so problem be solved?
Because neither the master channel seems to work

What I presented is just a simpler workaround, because you can start pushing updates using aabs and not apks, which is suggested by Google...

@sulaysumaria - it is not as simple as it looks, believe me... Also re switching to dev channel seems to lead to some complications with third party packages and plugins which will lead to different set of issues.

@campioncino I think yes because I have never faced that issue.... I simply build the release appbundle and upload it to play store... It never shows any warnings.... and app works fine when installed from play store (at least what my client is using so far...)

@angel1st, I can understand.. in that case rolling back is the only option... But that dependencies need to be upgraded or else you can never upgrade to a newer version... I also faced that kind of issue with one plugin I was using, fortunately they released a newer version in beta to support newer version of flutter... Maybe if the plugin is not maintained, we should not use it..

@sulaysumaria I have never faced this problem too ... up to the last build.
I'll try but it's not so simple to test, because it only happens on some devices.

For example on Samsung Galaxy Tab 2 7.0 P3110, Android 4.2.2, and on some other old tablet with android 4.1.2

Ohhh... My app is not for tablets thats for sure... It would be better if you test it once...

Hi all,

Here's the current status:

1. Indications are that https://github.com/flutter/flutter/issues/35838 affects Android 4.2 and earlier, meaning that it affects ~3% of Android phones. We're working with affected people on that bug to identify the scope of the fix and track down possible ancillary issues that likely only affect some apps (such as a possible unrelated bug in the Dart VM that doesn't manifest on all apps). Based on that investigation and its conclusion, we'll decide whether it's better to patch the current stable release or to push a new release through the channels to stable.

2. If anyone would prefer to build from an earlier Flutter version and manually build 32 and 64-bit APKs, they can do so by downloading an earlier version of Flutter here. Reverting our stable release is not an option -- doing so would cause far more problems than it would solve.

3. If anyone is experiencing problems building for Android _other_ than https://github.com/flutter/flutter/issues/35838, please file a separate issue and cc me, as we very much want to track any such problems down.

4. Separately, we're actively working on increasing our test matrix to better detect issues on a wider variety of devices / Android versions earlier in the process (so that bug reports aren't our first line of defense).

@tvolkert - thanks for the feedback. Just to make sure we are on the same page - rolling back to previous Flutter version does not make sense until August 1st deadline is postponed, since Google Play won't allow me to upload 32 app version only after August 1st.

@angel1st would this option be suitable for your case?

1. Revert flutter SDK to v1.5.4-hotfix.2 (flutter version v1.5.4-hotfix.2)
2. Build 2 separate APKs (one on 32-bit flutter build apk --target-platform android-arm and one on 64-bit flutter build apk --target-platform android-arm64)
3. Upload both of these APKs on Google Play Store

I know it's a workaround, but at least it solves both the stability problem and "warning" one.

@truongsinh - thanks for the suggestion - it is worth to consider. Would you be so kind to confirm step 2 from your suggestion above will not require changes as in previous suggestion e.g. app gradle amendments?

@angel1st as long as you have the whole app in flutter (i.e. not https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps), and you haven't modify any thing in Gradle files (i.e. vanilla files from flutter create), I believe we don't have to do anything.

You can do the quick check yourself (assuming version "3.4.5", following https://github.com/flutter/flutter/issues/31922#issuecomment-512292798, my personal choice of format for "build number" is bbxxyyzz, in which bb is just the to identify 32- or 64-bit, xx is major, yy is minor, zz is patch , but there are other recommended format as well, see https://developer.android.com/google/play/publishing/multiple-apks#using-a-version-code-scheme):

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

I include the 2 APKs here. They work with my Pixel 2. Also looking at the APK analysis, we can clearly see that each APK has different libflutter.so and 4 snapshot/aot files

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

Just a note for when uploading two apks... Google does not allow to upload multiple files having same build number, so you might want to change the build number before creating apk for 64 bit.

Just a note for when uploading two apks... Google does not allow to upload multiple files having same build number, so you might want to change the build number before creating apk for 64 bit.

Ah, true that (ref https://developer.android.com/google/play/publishing/multiple-apks#Rules) . Just make sure for every version, build number of 64-bit is higher than 32-bit (I updated my previous example https://github.com/flutter/flutter/issues/31922#issuecomment-512223030).

Hey, I get an error message when I try to build with appbundle. flutter build apk works fine but I want to publish a new version to play store. Can someone help me what the reason could be?

The output of running flutter build appbundle --target-platform android-arm,android-arm64 --flavor my_flavor --release -t "bin/main.dart is the following:

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

Sadly the error message is not really helpful. Also the output of flutter doctor:

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

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

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

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

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

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

• No issues found!

Edit
If I try to use --split-per abi the building fails with flutter build apk as well.

@wreppun Thanks - I checked my app's crash reports and neither of the affected Asus ZenFone 2 users sent anything.

@blasten No worries, that's great. If someone can show the new appbundles work on an Asus ZenFone 2 device that would be enough to get me moving forward. Unfortunately I don't have access to one, but I'm hoping Google's mobile testing labs do.

Even I am facing issue wit Asus Zenfone. When I am running using flutter build apk the app runs on the phone. But when I upload it to the App Store using appbundle, it doesn't move ahead of splash screen.

Any solution ??

I tryed to compile and release one new version of one of my application (app) in "Play Store", but i had some troublems.

1-) When i upload 32 and 64 bits, the site recuses, becouse of 32 bits version.

2-) When i upload just 32 bits, the site recuses, becouse i need the 64 bits.

3-) When i upload just 64 bits, the site works, but my customers maybe don't have the 64 bits Android. In my cellphone by example, i use this same app, but in my cellphone just works when i use the apk 32 bits. When i intall the apk 64 bits in my cellphone it stop in splash screen.

How i must to do now to release??

Tigerclaw1980 use flutter appbundle option

Tigerclaw1980 use flutter appbundle option @MoacirSchmidt

I used Delphi Beta to make apk files for 32 and 64 bits. I don't know if this option is available

I tryed to compile and release one new version of one of my application (app) in "Play Store", but i had some troublems.

1-) When i upload 32 and 64 bits, the site recuses, becouse of 32 bits version.

2-) When i upload just 32 bits, the site recuses, becouse i need the 64 bits.

3-) When i upload just 64 bits, the site works, but my customers maybe don't have the 64 bits Android. In my cellphone by example, i use this same app, but in my cellphone just works when i use the apk 32 bits. When i intall the apk 64 bits in my cellphone it stop in splash screen.

How i must to do now to release??

@Tigerclaw1980 did you fix this error?