I need to understand the Android device architecture and, Why there is three different types of APKs are generated when I use:
flutter build apk --split-per-abi.
And when I use
flutter build apk
I get a large APK file called fat APK contains the 3 versions of the app.
The command flutter build apk --split-per-abi typically generates two APK files.
arm64 or x86_64 is the apk file for devices having 64-bit processors.
x86 is the apk file for 32-bit processors.
You can upload both of them on the PlayStore and based on the user's device architecture the corresponding apk will be installed.
The fat apk that you are getting while using the flutter build apk contains the necessary compiled code to target all the Application Binary Interfaces or ABIs. Once a user downloads this fat apk, then only the code applicable to the device will be used.
flutter build apk gives you large apk because,
flutter build apk results in a fat APK that contains your code compiled for all the target ABIs. Such APKs are larger in size than their split counterparts, causing the user to download native binaries that are not applicable to their device’s architecture.
--split-per-abi results in two APK files:
(The flutter build command defaults to --release.)
<app dir>/build/app/outputs/apk/release/app-armeabi-v7a-release.apk
<app dir>/build/app/outputs/apk/release/app-arm64-v8a-release.apk
Where armeabi-v7a for is 32-bit devices and arm64-v8a for 64-bit devices.
Read More on
https://flutter.dev/docs/deployment/android#build-an-apk
https://flutter.dev/docs/deployment/android#build-an-app-bundle
https://developer.android.com/studio/build/configure-apk-splits#configure-split
Run flutter build apk --split-per-abi
This command results in three APK files:
<app dir>/build/app/outputs/apk/release/app-armeabi-v7a-release.apk
<app dir>/build/app/outputs/apk/release/app-arm64-v8a-release.apk
<app dir>/build/app/outputs/apk/release/app-x86_64-release.apk
Removing the --split-per-abi flag results in a fat APK that contains your code compiled for all the target ABIs . Such APKs are larger in size than their split counterparts, causing the user to download native binaries that are not applicable to their device’s architecture.
ABI means : Application Binary Interface
APK means : Android Package
app dir is your application’s directory
NOTE : If you can build an app bundle instead of apk , do it .With this, the application will be signed more easily .
By default, the app bundle contains your Dart code and the Flutter runtime compiled for armeabi-v7a (ARM 32-bit), arm64-v8a (ARM 64-bit), and x86-64 (x86 64-bit).
Remember that creating an App Bundle (an .aab file) is preferred over creating a fat APK or multiple APKs per abi. To assemble an App Bundle, run flutter build appbundle. The bundle will be created at build/app/outputs/bundle/release/app.aab
Related
Why the size of flutter build apk --release is larger than the size of flutter run --release which reduces the size by half. I need to get the leaner app size.
We should know that flutter run --release compiles only for a target ABI (because you run the generated APK directly to your device). while, flutter build apk --release results in a fat APK (Universal apk) that contains your code compiled for all the target ABIs, as a result, you could install this apk on any device.
Flutter app can be compiled for
Armeabi-v7a (ARM 32-bit)
Arm64-v8a (ARM 64-bit)
x86-64 (x86 64-bit)
In Flutter, a build refers to the process of taking your source code and turning it into a deployable app. There are two types of builds in Flutter: debug builds and release builds.
Debug builds are used for development and testing. They are built with debugging symbols enabled, which makes it easier to debug your code. Debug builds also include a debugger that allows you to pause the execution of your code and inspect variables and the call stack.
Release builds are used for deploying your app to app stores or distributing it to users. They are built with debugging symbols stripped, which makes the app smaller and faster. Release builds also have optimizations enabled, which makes the app even faster.
To create a release build in Flutter, you can use the flutter build command with the --release flag. For example:
flutter build apk --release
This will create a release build of your app in the build/app/outputs/apk directory.
Running into an issue around a native-Android Unity integration release into the Play Store. I extract it as a project out of Unity and migrate it as a Library in our native app.
When attempting to upload an .AAB into the Play Store, the following error occurs:
This release is not compliant with the Google Play 64-bit requirement.
The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: [10406]
I've already checked the following:
First, I followed the steps in the official guide: https://developer.android.com/distribute/best-practices/develop/64-bit
Unity version: 2019.4.9f1, Android player settings I've selected both ARMv7 and ARM64. No x86 option in this version of Unity. Scripting backend listed as IL2CPP
In the build.gradle file, I have listed: ndk { abiFilters 'armeabi-v7a', 'arm64-v8a' } as we want to support both 32-bit and 64-bit
I've used the APK Analyzer tool inside of Android Studio to analyze both the APK and AAB versions of the app. There are the same 10 '.so' files listed in both the lib/armeabi-v7a and lib/arm64-v8a folders.
Next I used the apktool in combination with the 'file' command to extract the contents of both an APK and AAB version of the app, and double check that the '.so' files inside the arm64-v8a folder are, in fact, 64 bit architecture
I tested that if I directly install the APK version using the following command on a 64bit device, it was successful:
% adb install --abi arm64-v8a app.apk
Performing Streamed Install
Success
I am officially out of ideas and I did contact the Play Store for assistance but they haven't responded in 2 days so I'm getting antsy.
Does anyone have ideas as to what I may have missed?
EDIT:
Forgot to mention, this is also inside the app and unityLibrary build.gradle files:
packagingOptions {
doNotStrip '*/armeabi-v7a/*.so'
doNotStrip '*/arm64-v8a/*.so'
}
Here's a repo containing my simplified gradle files, if it helps:
https://github.com/azdragon2/unityandroid-stackoverflow-question
Thank you!
The problem stemmed from the usage of '.bc' files contained within a Unity library I was using. These bc files are always interpreted as 32-bit. You'll have to upgrade whichever library you're using that contains these files.
You can determine if you have the same issue by running the following command on your APK or AAB file:
zipinfo -1 app.apk | grep \.bc$
I just finished an application with flutter and while I run it in debug mode everything is fine, but when I switch to --profile or --release mode it changes all the icons that I use and puts others, even the navigation arrows of the application.
I've had this error before while locally testing on a device with an .apk file directly generated from flutter build.
It fixed itself once I tested from the play store.
I found that when directly testing flutter build .apk files, there are issues as there are different processor types armeabi-v7a (ARM 32-bit), arm64-v8a (ARM 64-bit), and x86-64 (x86 64-bit).
If you are testing locally I would recommend:
Building an app bundle using flutter build appbundle in
terminal.
Using the bundletool from the GitHub repository.
Generate a set of APKs from your app bundle.
Deploy the APKs to connected devices.
Source
I was getting this warning in google play. This release is not compliant with the Google Play 64-bit requirement. The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code
I noticed that my apk had only x86, x86_64, armeabi_v7a folders. So I updated the gradle build script and now I have arm64-v8a folder as well. I see all the .so in armeabi-v7a generated in arm64 too.
How can I validate that this will support 64 bit devices
You can create an emulator with 64 bit image, to see that the app works on it.
Also, in your build variants, you can choose which active abi to use:
In 3d party APK files I notice there are folders for different architectures - armv7, arm64, x86, mips - so a single APK works for multiple architectures, supported by Android.
However, I don't seem to find a way to do that with Qt projects. I have a project that targets multiple architectures, but I can only produce an APK for an architecture at a time, only for the currently active project kit.
Is it possible to produce such a muti-arch APK for a Qt projects?
I have found a work-around for this problem. I came across this problem when my Qt application had to comply to Google's requirement of providing 64 binaries for 64 bit architecture. Although this process is not totally automated but it works.
1- Build your APKs for different architectures(in my case armeabi-v7a and arm64-v8a)
2- Open all APKs for editing with any compression/decompression software(I used the default provided by Ubuntu. On windows you can use WinRaR)
3- Go to "lib" folder and copy the folder named with the architecture (arm64-v8a, armeabi-v7a, etc.)
4- Consolidate all the copied folders from step#3 into the lib folder of any one APK. Now we will use this APK to move forward
5- Go to the folder named "META-INF" on APK root and delete files *.RSA and *.SF
6- Now close the APK file.
7- Go to https://github.com/patrickfav/uber-apk-signer and download the Jar file. You can use this tool to zipalign and sign your package again. Use the jar as follows.
java -jar uber-apk-signer-1.0.0.jar --apks ./android-build-release-signed.apk --ks android_release.keystore --ksAlias your_certificate_alias
Now you can publish the final APK to Google Play. Cheers!