What is the difference between the different .apk outputs when building a signed apk from IntelliJ IDEA?
When I do a signed apk build from IntelliJ Idea (13.1.2) I get three different apk files.
../myApp.apk (921 KB)
../out/production/myApp/myApp.apk (914 KB)
../out/production/myApp/myApp.unaligned.apk (1412 KB)
My guess is unaligned is non compressed and shouldn't be used in the play store. Which one should be used in the playstore?
Note: I am using proguard but not using Ant or Maven.
Use the one you find at .../out/production/Your App name/yourapp.apk
Yet again, in properties of the project you can set the custom location for your APK. But I suggest you get used to the default ones since it will be a pain to set up your path each time.
Related
My android release apk size built using Flutter is around 150MB. I would like to upload this apk to the google play store but play store has a apk size limit of 100MB. In Android app development we create APK expansion files for such limit in steps shown in this link. Would like to know the steps in Flutter code to create and use similar expansion files and reduce the app size to below 100MB.
Update
This question is not related to large size of apk due to Flutter. The apk is huge because of the assets used in the app. Want to know the process of uploading such apps in Flutter. In native android development we have the option of expansion files as shown in the link. IS there a similar option for Flutter if not what is the process to upload such apps to google play store.
When building a release version of your app, consider using the --split-debug-info tag. This tag can dramatically reduce code size. For an example of using this tag, see Obfuscating Dart code.
Some of the other things you can do to make your app smaller are:
Remove unused resources
Minimize resource imported from libraries
Support a limited number of screen densities
Compress PNG and JPEG files
or
One way that i use to reduce my app size is to use;
flutter clean
before i run the build command;
flutter build appbundle --target-platform android-arm,android-arm64
Use an appbundle and you get 150mb
https://developer.android.com/guide/app-bundle
use Firebase Storage to download the content (12 cents per gig)
https://firebase.google.com/pricing
or follow the Expansion files inclusion in Flutter (it is very quiet at the moment)
https://github.com/flutter/website/issues/2215
use this command to create multiple small size apk then upload multiple apk in play store
flutter build apk --split-per-abi
Use Deferred components for app-bundle generation if you have larger apk in flutter.
This feature is currently only available on Android, taking advantage
of Android and Google Play Stores’ dynamic feature modules to deliver
the deferred components packaged as Android modules. Deferred code
does not impact other platforms, which continue to build as normal
with all deferred components and assets included at initial install
time
I agree with #RĂ©miRousselet maybe you can check your assets and tell us if that's the case. But if it's not, then maybe it's a package issue.
But as an FYI, Flutter team has an answer for big size APK. Check this. Also check this to know the minimum size of Flutter that they came up with. It was stated that,
we measured the size of a minimal Flutter app (no Material Components, just a single Center widget, built with flutter build apk), bundled and compressed as a release APK, to be approximately 4.48MB.
Judging from that statement, the Flutter APK is really large and it has a fixed overhead size.
Here are some reference you can check regarding how to reduce APK size.
Reduce --release apk and ipa sizes
Would like an article which explains how to reduce APK size
Also check this StackOverflow question related to yours.
I have a third-party apk that I'm trying to optimize, as the developer couldn't be bothered with such petty things.
The application is built with Xamarin and contains AOT assemblies. Is there a way to strip them from the apk without completely reverse-engineering the project and building it anew?
Removing AOT assemblies from an .apk is as easy as deleting them and correctly re-signing the package.
Here are the steps:
Open the .apk as zip file, delete lib\<architecture>\libaot-*.so files.
Xamarin apps include libmonodroid.so and libmonosgen-2.0.so even without AOT compilation, don't touch those.
Delete META-INF from root of the .apk.
Sign the resulting .apk using jarsigner from the JDK. If you don't have the original key, any will do, you will just lose the ability to update the app automatically.
Don't forget to align the .apk with zipalign from Android build tools.
Resulting thinner app installs and runs perfectly, but will, of course take a couple of seconds longer to launch.
I need to produce 2 apks, one for x86 and one for ARM. I do this with different versions of crosswalk, which internally uses cordova. All I need to do one the two projects are created is ./cordova/build --release and then sign the APK. The Google Play store docs mention a way of uploading both into a single app listing, but they assume I'm using the Android NDK, which I'm not. Will I need to start using it or is there another way to simply upload both apks?
Google does support posting of architechture-specific APKs: http://developer.android.com/google/play/publishing/multiple-apks.html. Note however that the documentation states, in bold:
we encourage you to develop and publish a single APK
So, if you take the single APK approach:
Just compile your native code into libraries (i.e. .so files) and place them in the following locations
<Project_Root>/app/src/main/jniLibs/armeabi/
and
<Project_Root>/app/src/main/jniLibs/x86/
The build process will package these in the appropriate manner so that your APK contains libs for both architectures. Then at runtime, Android will ensure that the architecture-appropriate library is loaded.
Note that the above assumes that you are using Gradle to build your APKs. If you are using the old ant-based build process, the locations are slightly different:
<Project_Root>/libs/armeabi/
and
<Project_Root>/libs/x86/
I have a native library that my project uses(for four architectures). (Note, that I did not compile them , I just got them from a third-party). Exporting a signed apk right now is a pain. I do the following:
Delete 3 of the 4 architectures from the libs folder
Export a signed package
Replace the libs folder with history
Go back to step one
Now, these steps are fairly tiresome and there is a chance of making mistakes while uploading.
Is there any simple way I can just Export 4 apks for the for 4 different architectures (in an automated way)?
I am using Eclipse
Well done for considering the user, and producing architecture specific apks, rather than bundling all architectures in a single apk with the resultant waste of filespace on already constrained devices.
Eclipse (or rather the ADT) does not have the ability to do what you want.
One answer to your problem (unfortunately adopted by many developers) is to simply give up, and just produce one apk with all architectures included. (I've even seen this happen for system apps - that by definition must know exactly what architecture they are going to run on).
An approach I've taken is to export the app from Eclipse with all architectures in it, and then to manipulate that apk using a zip tool to produce further copies with the unwanted libs deleted. You then have to resign the apk since you have changed the constituent contents.
I was very happy when I found ability to create release signed and proguarded apk
in my IntelliJ IDEA 11.
But created apk is very small ( 6 MB) against 33 MB of
all files in "production\out\mygame"
I guess images from /assets were not included to this final apk.
Or should I upload somehow classes.dex, mygame.apk.res to GooglePlay?
Thanks.
I was able to export the signed apk from the provided project and run it on my device. Try to disable Proguard option, it didn't work for me, probably because your project needs different configuration for obfuscation.
The signed APK contains all the images from /assets.
Finally I am not right. IntelliJ works okay. It is just impossible to install unsigned apk on device (what I tryed to do). Thanks