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

[creativecreatorormaybenot]

Warning

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

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

From August 1, 2019 all releases must be compliant with the Play 64-bit requirement.

Include 64-bit native code in addition to 32-bit native code in your app. Use the Android App Bundle publishing format to automatically ensure that each device architecture receives just the native code it needs. Learn More

This warning appears when trying to publish an aab created by flutter build appbundle to the Play Store since today.

Is this something that I need to worry about or will Flutter automatically resolve this, i.e. is this already planned to be resolved in time?

[Ahmad-Rayyan]

no

[ayush221b]

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?

[danwulff]

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.

[AmitJoki]

I got this warning message today too.

[overgaardmorten]

Same issue here.

[perez-danilo]

me too

[melvinm99]

me too

[Rafi993]

Is there a solution for this yet?

[dayofr]

Look at this: #18494 (comment)

It worked for me.

[ciez]

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.

[tvolkert]

/cc @mklim @cbracken

[eseidelGoogle]

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:
#18494 (comment)

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.

[creativecreatorormaybenot]

@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?

[neiljaywarner]

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

[eseidelGoogle]

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

[apravint]

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

[SPodjasek]

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

[VarolOkan]

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.

[SPodjasek]

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

[neiljaywarner]

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?

[eseidelGoogle]

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.

[blasten]

As @eseidelGoogle said, I will be taking care of this issue. In the meanwhile, have you tried to follow these steps #18494 (comment)?

[audkar]

Is this not a problem anymore? #18494 (comment)

[wreppun]

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

[blasten]

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.

[eseidelGoogle]

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!

[matthewlloyd]

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

[blasten]

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

[truongsinh]

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

😂

[angel1st]

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!

[ghost]

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

[campioncino]

@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

[angel1st]

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.

[ghost]

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

[campioncino]

@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

[ghost]

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

[tvolkert]

Hi all,

Here's the current status:

1. Indications are that libapp.so not found on Android 4.1.2  #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 libapp.so not found on Android 4.1.2  #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).

[angel1st]

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

[truongsinh]

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

[angel1st]

@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?

[truongsinh]

@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 #31922 (comment), 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

[ghost]

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.

[truongsinh]

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 #31922 (comment)).

[tomkastek]

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.

[lab-nit-s]

@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 ??

[Tigerclaw1980]

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

[MoacirSchmidt]

Tigerclaw1980 use flutter appbundle option

[Tigerclaw1980]

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

[sicnet]

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?

[github-actions]

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.