I have a very simple react native app it doesn't use any heavy resources, just 2 images (146kb combined). Upon generating the .aab file using this https://reactnative.dev/docs/signed-apk-android the size of the .aab file is 27 Mb. Once I publish the release on the playstore and test it on my device there is no change in the size of the app it is still 27 Mb. I have tried the following in an effort to reduce the size of the app but to no avail.
How to reduce Android APK size in react-native?
How to decrease React-Native android App Size
https://medium.com/#aswinmohanme/how-i-reduced-the-size-of-my-react-native-app-by-86-27be72bba640
The below code is what I'm currently using as part of the build.gradle file. I'm not sure on where I'm going wrong or why the size of the .aab file is 27 Mb even after installing on my device (I understand the .aab files are bundled with multiple apk configs and the size is supposed to reduce anywhere between 7-10 Mb on installation).
Any help would be greatly appreciated thanks in advance!
def enableSeparateBuildPerCPUArchitecture = true
def enableProguardInReleaseBuilds = true
splits {
abi {
reset()
enable enableSeparateBuildPerCPUArchitecture
universalApk false // If true, also generate a universal APK
include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
}
}
buildTypes {
debug {
signingConfig signingConfigs.debug
}
release {
// Caution! In production, you need to generate your own keystore file.
// see https://reactnative.dev/docs/signed-apk-android.
debuggable false
shrinkResources true
zipAlignEnabled true
minifyEnabled enableProguardInReleaseBuilds
proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
signingConfig signingConfigs.release
}
}
It works only after you upload it on the app store so the .aab file on local installs is generally heavier from those that are directly donwloaded from the play store.
Related
I would like to publish a a library with debuggable true on release build types. This would help me debug that library. What are the potential problems if this library goes into production? Is it secure ? What difference does it make when released with debuggable as false?
buildTypes {
release {
minifyEnabled true
debuggable true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
}
First of all, you can not publish an apk with debuggable set to true.
Google play console will give you an error just after you upload the apk.
Secondly, it is not secure at all. Your apk will be very slow.
There are differences in a debug build and a release build. Release builds are much faster. Release builds do not print logs (it is a good practice to not print logs in release builds) which makes execution slower as it takes time to print the characters in the console and all print commands are usually in sync.
Moreover, a release build may also trigger code obfuscation and splits.
when I'm trying to build the application, Both release and debug are creating huge data(in MB).[this is my gradle file. I have created a new project and nothing is been created in it but still producing 2-3 MB..]
can anyone please help me out?
This is because of the dependencies libraries especially the support libraries. If you create your application without the support libraries, your application will not weight about 1 MB. Which means you need to use Activity instead of AppCompatActivity and use ListView instead of RecyclerView and etc.
Your basic application with support libraries will be weight about > 2 MB this is the trade-off of all the features support libraries gives you.
Update:
Also delete one or more of these to save some space if you don't use them: glide,circle image view, cardview, constraint layout
end Update
This is basic support library size, maybe you are using some drawable which has some size of around 1MB.
Anyways, you can reduct apk size by shrinking resources and enabling minify.
app/build.gradle
android{
.
.
buildTypes {
debug {
shrinkResources true
minifyEnabled true
useProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
release {
shrinkResources true
minifyEnabled true
useProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
For my react native android app, size of codes I have written is only 12KB
But package generated is of size 7.9MB. How can i decrease that.
As per Documentation for react native, I have already enbabled proguard on file app_root/android/app/proguard-rules.pro but size of didn't decrease
...
android {
...
buildTypes {
release {
...
minifyEnabled true
}
}
}
...
Is there a solution available for this?
React Native app APKs include JSCore binaries for x86 and ARM. If you don't need x86 you could reduce the size to 3-4 MB.
1)In your app/build.gradle set
def enableSeparateBuildPerCPUArchitecture = true
2)remove x86 from abiFilters
this helped me in reducing size from 7.8 mb to 4.5MB
Android devices support two major device artitectures armebi and x86. By default RN builds the native librariers for both these artitectures into the same apk.
Open up android/app/build.gradle :
Set def enableProguardInReleaseBuilds = true,
this would enable Progaurd to compress the Java Bytecode. This reduces the app size by a lil bit
And,
Set def enableSeparateBuildPerCPUArchitecture = true .
And check in android/app/build/outputs/apk/ - you will receive two apk files for armebi and x86 with approx half size of original apk.
There are a couple of techniques in order to reduce your APK size:
Split your app by architecture, you can split your APK by a list of well-known architectures: armeabi-v7a, x86, arm64-v8a, x86_64
if you're distributing your application, using the play store it's a good idea to do it with the Android app bundle.
Enabling prodguard will result in a lower size of the APK.
Optimize your image assets, and if there's a chance try using SVG assets as much a possible.
There have been a change in the size of the resulted APK in React-Native 0.62 by enabling the new JavaScript engine which reduce the size of the native libs almost 40% Hermes Engine
These stats below are from Hermes engine and also mention the APK size reduction.
release {
signingConfig signingConfigs.debug
minifyEnabled enableProguardInReleaseBuilds
proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
shrinkResources true
ndk {
abiFilters "x86", "armeabi-v7a" //this will help you to shrink your app size in release build
}
}
I am using Android Studio 1.0.2.
When I click assembleRelease in gradle tasks, two files are generated, app-release-unaligned.apk and app-release.apk. I know app-release-unaligned.apk is unaligned but what is app-release.apk? Is it aligned apk? My build.gradle is like below.
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt'
signingConfig signingConfigs.config
zipAlignEnabled true // Is this necessary or not in Android Studio 1.0.2?
}
}
Even if I didn't put zipAlignEnabled true, app-release.apk is generated.
Is it still necessary in Android Studio 1.0.2?
All information I get about zipalign is before Android Studio 1.0 comes out.
You don't need to set that flag.
From official guide
The possible properties and their default values are:
It is both aligned and signed.
Ready for publication.
AFAIK zipAlignEnabled is true by default for release builds.
I tried uploading my apk to Googleplay because of this.
You uploaded an APK that is not zip aligned. You will need to run a
zip align tool on your APK and upload it again.
So I added buildtypes for using zipalign with proguard in build.gradle
buildTypes {
release {
runProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
zipAlign true
}
}
but I got this error code during making signed apk file.
Generate signed APK: Errors while building apk, see messages tool
window for list of errors.
so I tried building signed apk with setting runProguard false, actually it worked.
but I really wondering why I couldn't make signed apk with Proguard.
Check the location and path to the key signature.