I had gradle
classpath 'com.android.tools.build:gradle:3.5.3'
distributionUrl=https\://services.gradle.org/distributions/gradle-5.4.1-all.zip
and my apk 160Mb
then I update it to
classpath 'com.android.tools.build:gradle:3.6.3'
distributionUrl=https\://services.gradle.org/distributions/gradle-5.6.4-all.zip
and my apk size is 270Mb
How is it possible? But acctually if I build .aab it is still has 160Mb, so size increasing if I build .apk
This is caused by a change in the Gradle plugin which used to zip deflate the native libraries, but now just stores them. According to Google this ends up being a benefit for end users:
Smaller app install size because the platform can access the native
libraries directly from the installed APK, without creating a copy of
the libraries.
Smaller download size because Play Store compression is
typically better when you include uncompressed native libraries in
your APK or Android App Bundle.
According to that same link, you can revert this change by setting extractNativeLibs to true
add this tag on you AndroidManifest.xml file
android:extractNativeLibs="true"
example:
<application
android:extractNativeLibs="true"
... >
</application>
i had the same problem the only thing that help me little is to add abiFilter in build.gradle inside defaultConfig
ndk{
abiFilters "mips","mips64","armeabi","armeabi-v7a","arm64-v8a"
}
I had the same problem, but the provided solution was not working. For those having multidex enabled on your APK your must add the following instead:
android {
packagingOptions {
dex {
useLegacyPackaging true
}
}
}
on your module build.gradle
Source : https://developer.android.com/studio/releases/gradle-plugin#dex_files_uncompressed_in_apks_when_minsdk_28_or_higher
Related
It appears that my libraries no longer exist in nativeLibraryDir after updating Gradle from 5.4.1 to 5.6.4 and Android Studio from 3.5.3 to 3.6.1. My current implementation for accessing my libraries is as follows:
File libDirectory = new File(context.getApplicationInfo().nativeLibraryDir);
String files[] = libDirectory.list();
Before the update, I can debug and see that the 'files' array contains a list of all my libraries as expected.
After the update, the 'files' array appears empty.
I have analyzed my APK and confirmed that the libraries do exist in the package.
Am I retrieving the path in a poor fashion? Is there required permissions that I am not aware of? I am using CMake to build my libraries:
externalNativeBuild {
cmake {
path '../../../common/CMakeLists.txt'
}
}
Using NDK version 21.0.6113669
Update:
Reverting to NDK r19c produces the same results
Update: libDirectory resolves to /data/app/com.example.application-1/lib/arm before and after the update
Update: setting android.useNewApkCreator=false in gradle.properties produces the same result
Update: Using the Device File Explorer, I am able to view the libraries within the lib/arm/ folder prior to the update. After the update, the lib/arm/ folder is still the same size (4KB), but I am no longer able to view the content within the folder. Folder permissions appear to be unchanged.
I also encountered this problem, and I finally solved it by :
// AndroidManifest.xml
<application
...
android:extractNativeLibs="true"
...
>
when extractNativeLibs set to true, so files copy to lib/xxx folder.
use this version
dependencies {
classpath 'com.android.tools.build:gradle:3.6.0'
}
with Gradle 5.6.4
Where do i report this error? or could anyone help me?
“Directory X specified for property ‘$2’ does not exist” error when executing crashlyticsGenerateSymbols task
with
android gradle plugin 3.6.0
gradle version 5.6.4
fabric gradle plugin 1.31.2
[Error logs]
Some problems were found with the configuration of task ':~~~~~:crashlyticsGenerateSymbolsRelease' (type 'DefaultTask').
Directory '~~~' specified for property '$1' does not exist.
Directory '~~~~' specified for property '$2' does not exist.
Fabric/Firebaser here. This error comes up when the Fabric Gradle plugin is trying to parse your project structure in order to find your stripped and unstripped binaries, and is unable to do so. When it asks for properties $1 and $2 it means it could not find the default paths to the "obj" and "libs" folders that contain your supported ABIs folders with your supported native libraries there.
Using the legacy Fabric Gradle plugin, you can specify these paths under your crashlytics block in the build.gradle, like so:
crashlytics {
enableNdk true
androidNdkOut 'obj'
androidNdkLibsOut 'libs'
}
In the case for builds that are on Android Studio 3.5 or later, you can usually find the paths for these somewhere in the outputted build folders under "merged_native_libs" and "stripped_native_libs."
If you're using the new Firebase Crashlytics SDKs and Gradle plugin, those paths are controlled by "strippedNativeLibsDir" and "unstrippedNativeLibsDir" flags in the firebaseCrashlytics block in your build.gradle.
If you continue running into problems feel free to file a case with Firebase support with more details about your project and what you've tried to configure so far, and you can also still reach out to support#fabric.io.
I got the same issue on my side, and I fixed it by removing ext.enableCrashlytics = false from my app-level build.gradle in
android {
buildTypes {
debug {
// ext.enableCrashlytics = false
}
}
}
We are having problems in building our multidex App. We keep receiving different java.lang.NoClassDefFoundError erros during the application boot.
We noticed that they are very likely related to the multidex issues. As the required classes for booting the App must be present in the primary DEX file and they are not being included in the classes.dex. We performed the steps described in https://developer.android.com/studio/build/multidex.html#keep
but the classes we specify in the multidex-config.txt, or even in the multidex-config.pro are not being placed in the primary dex file (classes.dex).
Do you guys have experience using the multiDexKeepFile or the multiDexKeepProguard? Does it really work? Is there any trick to make it work and place the files in the classes.dex?
Try updating your gradle plugin. I've seen that in 2.2.0 the configuration is ignored entirely. When I updated to 2.3.3 it started respecting the rules I set.
Example:
classpath com.android.tools.build:gradle:2.3.3
And in my default config I have this set:
multiDexEnabled true
multiDexKeepProguard file('proguard.multidex.config')
Also you may have to do a clean build before the changes are reflected.
I have the same problem.And i still don't know why.
But i found another solution,and it works.
In your app module's build.gradle add dexOptions:
android {
dexOptions {
additionalParameters = ['--multi-dex',
'--set-max-idx-number=60000',
'--main-dex-list='+projectDir+'/your_multidexconfig.txt',
'--minimal-main-dex'
]
}
}
You should check your minSdkVersion, if your minSdkVersion is >= 21, multiDexKeepProguard is not supported. Because the build tools has do the dex split by default.
More details:
https://developer.android.com/studio/build/multidex
two weeks ago I uploaded a new version of my Android app to the Developer Console to run an Alpha Test. However I was not able to download this test version on my test device, since the Play Store offered no such update to my test user.
After I was not able to solve this issue here I contacted the Google Developer Support directly.
I now received the following reply:
I’ve looked into your issue and found that your app's Version 15 is not compatible with the Nexus 5 due to a conflict in your app’s manifest with the following native platforms: armeabi, armeabi-v7a.
For more information about platforms, visit our developer site at https://developer.android.com/ndk/guides/abis.html
This is quite confusing. As far as I understand the information on the linked page, the ABI setting is only available/relevant when working with the NDK. However I am working with the latest SDK version in Android Studio 2.1
Is it even possible to set/define the ABI version when working with the SDK?
The App Manifest does not include any settings related the the ABI version.
When I copy the APK manually to my device (Nexus 5 running Android 4.4.4) and install it, it runs without any problem. So, is the APK really not compatible with my device?
EDIT:
Inspired by the the comment by user1056837 I found this page, that describes how to add an NDK block to the build.gradle file:
android {
...
ndk {
// All configurations that can be changed in android.ndk.
...
}
productFlavors {
create("arm") {
ndk {
// You can customize the NDK configurations for each
// productFlavors and buildTypes.
abiFilters.add("armeabi-v7a")
}
}
create("fat") {
// If ndk.abiFilters is not configured, the application
// compile and package all suppported ABI.
}
}
}
Currently my build.gradle file does NOT include any NDK configuration. I am not sure, how I could solve the problem with the Play Store by adding such config.
As far as I understand the information on the linked page, a fat binary will be created of no abiFilters are configured. Is that correct?
Then one of the following should be correct:
My project does contain some native code without my knowledge. In this case a fat binary is created since my build.gradle file does NOT include any NDK configuration.
My project does not contain any hidden native code. In this case the NDK config would not have any effect at all.
Did I miss something here? No matter which case is correct, in both scenarios I do not know what config would solve the problem...
Maybe it is to late, but nevertheless:
I had the same problem. It was in third-party libraries. When my application started to build, the library bitcoinj created a native script in the /lib/x86_64/darwin/libscrypt.dylib folder. I just excluded this folder in the build.gradle file.
packagingOptions {
exclude 'lib/x86_64/darwin/libscrypt.dylib'
}
After that all started work fine. My app support 5900 devices now.
How do I prevent the Android "build process" from optimizing .png images?
I have an Android project with the following res directories:
- /res/
- /res/drawable
- /res/drawable-hdpi
- /res/drawable-hdpi-v5
- /res/drawable-ldpi
- /res/drawable-ldpi-v5
- /res/drawable-mdpi
- /res/drawable-mdpi-v5
These directories contain many .png files. I optimize PNG sizes with PNGOUTWin, and the overall size is reduced by more than 20%. When I build the .apk file, the images are "optimized" by the build process and the overall size is now 10% above the initial size, or 30% above my/PNGOUTWin optimized size.
My goal is to reduce the .apk size, even if it will affect the final performance, memory requirements, etc. How do I prevent the "build process" from optimizing .png images?
I'm targeting Android 2.2 and above.
P.S.: I am currently building my Android project from Eclipse, but I will switch to the automated build later (Ant?).
Note about JPG images: JPG will not work, because they do not have transparency.
Finally there is an official way to disable the PNG cruncher with Gradle which hasn't been mentioned here yet:
Edit main build.gradle to require gradle version 1.1.3 (or newer):
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.1.3'
}
}
In the individual apps's build.gradle, section android {}, insert:
aaptOptions {
cruncherEnabled = false
}
Reference:
https://code.google.com/p/android/issues/detail?id=65335
Specifying PNG crunching is now a BuildType property and is disabled by default on debug builds:
android {
…
buildTypes {
release {
crunchPngs false // or true
}
}
}
Note: It's available from Android Studio 3.0 Canary 5 .
As mentioned in the Android documentation: http://developer.android.com/guide/topics/graphics/2d-graphics.html#drawables
Note: Image resources placed in res/drawable/ may be automatically optimized with lossless image compression by the aapt tool during the
build process. For example, a true-color PNG that does not require
more than 256 colors may be converted to an 8-bit PNG with a color
palette. This will result in an image of equal quality but which
requires less memory. So be aware that the image binaries placed in
this directory can change during the build.
So if you want to reduce the size of your application you should either reduce the color-depth of your PNG files (this helps a lot) or switch to .JPG files wherever possible.
Android Studio: Since Gradle Android plugin 1.0.0:
android {
...
aaptOptions {
useNewCruncher false
}
....
}
Eclipse: Override the crunch task writing this in your build.xml:
<target name="-crunch">
<echo message="This will skip PNG optimization"/>
</target>
buildTypes {
release {
crunchPngs false // or true
}
}
add above the line on android block in
in ionic/Cordova project : root_folder_Of_App/platforms/android/app/build.gradle
in Android project: app/build.gradle
For More Information Visit: https://androidstudio.googleblog.com/2017/06/android-studio-30-canary-5-is-now.html
Google recently introduced a new PNG processor in aapt 0.9.1 in the Android SDK Build Tools that fixes this issue of increased PNG sizes after aapt optimization.
With this update, it is now possible for Android Studio & Gradle to switch between the PNG processors with the following change in your build.gradle configuration file:
android {
..
..
aaptOptions.useAaptPngCruncher = false
}
By adding this line, aapt uses the new PNG processor in which it checks to see if the "optimized" PNG files are smaller than the original PNG files. I was able to reduce 4.8 MB in my compiled APK and have not encountered any bugs/issues with the new build configuration.
UPDATE: This has been deprecated in later versions of Android Studio. Please refer to the answer provided by ChrisG.