I am maintaining a legacy Android project which uses Android.mk build file instead of CMake. Previously the native compilation was done from command line batch files. I changed the build system to use build.gradle.
For some strange reason when I build the app the native file compilation is invoked every time I build the app. This happens even if I haven't done any modifications to native files.
I just tested building a project which I had built before and I hadn't done any changes to it. I build with 4 ABIs (armeabi-v7a, arm64-v8a, x86 and x86_64) and the build process spends about 8 minutes per ABI doing the Ndk build tasks:
Task :app:buildNdkBuildRelease[<ABI>]
Which means every time I make a build I have to wait for over 30 minutes! With my other projects that use CMake the native stuff isn't compiled again if there are no changes.
The Android.mk is invoked from build.gradle like this:
externalNativeBuild {
ndkBuild {
path '../jni/Android.mk'
}
}
Is there any way in (Android.mk or build.gradle) to fix this so that native is compiled only if there are actual changes in the native files?
I'm using Windows 11 and Android Studio Electric Eel | 2022.1.1.
The task runs every time because Gradle has no way of knowing if ndk-build needs to do any work (the same happens with the CMake task). If ndk-build is doing work every time, that means there's something in your build that believes something needs to be recompiled. This isn't generally a problem, so it's most likely something in your build scripts (there's always the potential that this is just a bug, be there have been no other reports and ndk-build rarely changes). Those weren't included in the question, so it's impossible to say what that might be.
Since the last update (Build from june 25) any changes in the Android studio Gradle is painfully slow. And it also seems to autotrack changes when you edit the file and recompile on keyup.
Each change takes several minutes on my i5.
Any idea how I can speed up my Gradle changes?
Definitely makes a difference: How To… Speed up Gradle build time
Just create a file named gradle.properties in the following directory:
/home/<username>/.gradle/ (Linux)
/Users/<username>/.gradle/ (Mac)
C:\Users\<username>\.gradle (Windows)
Add this line to the file:
org.gradle.daemon=true
After change this settings my compile time 10 mins reduced to 10 secs.
Step 1:
Settings(ctrl+Alt+S) ->
Build,Execution,Deployment ->
Compiler ->
type "--offline" in command-line Options box.
Step 2:
check the “Compile independent modules in parallel” checkbox.
& click Apply -> OK
Step 3: In your gradle.properties file -> Add following lines
org.gradle.jvmargs=-Xmx2048M -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
org.gradle.parallel=true
org.gradle.configureondemand=true
org.gradle.daemon=true
Update:
If you are using Android studio 2.0 or above try the Instant Run
Settings → Build, Execution, Deployment → Instant Run → Enable Instant
Run.
More info about Instant Run - https://developer.android.com/studio/run/index.html#instant-run
I was able to reduce my gradle build from 43 seconds down to 25 seconds on my old core2duo laptop (running linux mint) by adding the following to the gradle.properties file in android studio
org.gradle.parallel=true
org.gradle.daemon=true
source on why the daemon setting makes builds faster:
https://www.timroes.de/2013/09/12/speed-up-gradle/
The dev are working on it. Like I posted in this answer the fastest solution right now is to use gradle from the command line and you should switch to binary libs for all modules you do not develop. On g+ there is a discussion with the developers about it.
Following the steps will make it 10 times faster and reduce build time 90%
First create a file named gradle.properties in the following directory:
/home/<username>/.gradle/ (Linux)
/Users/<username>/.gradle/ (Mac)
C:\Users\<username>\.gradle (Windows)
Add this line to the file:
org.gradle.daemon=true
org.gradle.parallel=true
And check this options in Android Studio
There is a newer version of gradle (ver 2.4).
You can set this for your project(s) by opening up 'Project Structure' dialog from File menu,
Project Structure -> Project -> Gradle version
and set it to '2.4'.
You can read more about boosting performance at this link.
This is what I did and my gradle build speed improved dramatically! from 1 min to 20sec for the first build and succeeding builds became from 40 sec to 5 sec.
In the gradle.properties file
Add this:
org.gradle.jvmargs=-Xmx8192M -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
In the Command Line Arguments via Go to File > Other Settings> default Settings >Build, Execution, Deploy> Complier and add the following arguments to Command Line Arguments
Add this:
--debug --stacktrace -a, --no-rebuild -q, --quiet --offline
With Android Studio 2.1 you can enable "Dex In Process" for faster app builds.
You can get more info about it here: https://medium.com/google-developers/faster-android-studio-builds-with-dex-in-process-5988ed8aa37e#.vijksflyn
Try to avoid using a Mac/PC that has only 8 GB of RAM when doing Android development. As soon as you launch even 1 emulator (Genymotion or otherwise), your build times become extremely slow in Android Studio with gradle builds. This happens even if you make a simple one-line change to 1 source file.
Closing the emulator and using a real device helps a lot, but of course this is very limiting and less flexible. Reducing the RAM usage setting of the emulator can help, but the best way is to ensure your laptop has at least 12-16 GB of RAM.
Update (June 2017): There are now several good medium.com articles that explain how to speed up Android Studio gradle builds in detail, and it even works on 8 GB machines:
How to decrease your Gradle build time by 65%:
https://medium.com/#kevalpatel2106/how-to-decrease-your-gradle-build-time-by-65-310b572b0c43
Make your Gradle builds fast again!: https://medium.com/#wasyl/make-your-gradle-builds-fast-again-ea323ce6a435
The summarised consensus is:
Create a gradle.properties file (either global at ~/.gradle/gradle.properties or local to project), and add the following lines:
org.gradle.daemon=true
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
org.gradle.parallel=true
org.gradle.configureondemand=true
dexOptions {
incremental true
javaMaxHeapSize "4g"
}
Enable Offline Work
Improve Gradle Performance by adding following code in gradle.properties
org.gradle.daemon=true
org.gradle.parallel=true
Step by step guide:http://www.viralandroid.com/2015/08/how-to-make-android-studio-fast.html
Acording to this page of the Android Team of Wikimedia Apps, a good way of optimize Gradle builds is adding this lines to your ~/.gradle/gradle.properties
org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.configureondemand=true
org.gradle.jvmargs=-Xmx2048M
For those who do not have the file there are two ways to do it:
Add the file locally in your project by creating a file called gradle.properties in the project root or,
You can set them globally for all your projects by creating the same file in your home directory (%UserProfile%.gradle on Windows, ~/.gradle on Linux and Mac OS X)
It is a good practice to set the properties in your home directory, rather than on a project level.
You can also use command line for better performance.You can use the command ./gradlew <task name> from inside the root folder of your project from linux or use gradlew.bat file like gradlew <task name>.when you first run one of the commands above for a given Gradle version, it will download the corresponding Gradle distribution and use it to execute the build.
When importing a Gradle project via its wrapper, your IDE may ask to use the Gradle 'all' distribution. This is perfectly fine and helps the IDE provide code completion for the build files.
Not only does this mean that you don’t have to manually install Gradle yourself, but you are also sure to use the version of Gradle that the build is designed for. This makes your historical builds more reliable.
for more info refer Executing a build with the Wrapper
For faster builds, increase the maximum heap size for the Gradle daemon to more than 2048 MB.
To do this set org.gradle.jvmargs=-Xmx2048M in the project gradle.properties.
Add this to your gradle.properties file
org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.configureondemand=true
org.gradle.jvmargs=-Xmx2048M
Add a build.gradle file:
android {
...
dexOptions {
javaMaxHeapSize "4g" //specify the heap size for the dex process
}
...
}
I hope it helps.
I’m running a 5th gen i7 with Windows 10 and a 1TB Solid State.
I compressed the Android Studio Projects folder and got about an 80% boost.
Hope this helps.
I then combined it with the above solutions ie (org.gradle.parallel=true, org.gradle.daemon=true). The performance boost was quite impressive.
Additionally:
All of the above answers are totally correct but I must state as an experience Android developer (of 4 and a half years) that: No Android/Gradle developer should be working on a machine with a spinner drive, you need to fork out for a Solid State. We all hit that play button in the IDE 100s of times per day. When I went from a spinner to SSD (post Gradle), my speed and efficiency was literally 2 – 4 times faster and I promise you I’m NOT exaggerating here.
Now I’m not talking about having a machine with a small SSD and a big spinner, I’m talking about 1 big SSD. If you already have a machine with a small SSD and a big spinner you can upgrade the small spinner to say a 500GB SSD and set the SSD as your main OS drive with your developer tools installed on it.
So if you’re working in a fast paced environment please show this post to your boss. A decent 1TB SSD will set you back about £300 (including VAT), or about £160 for a 500GB SSD. Depending on if you are a junior or senior Android developer the drive will pay for itself (in wages expenses) in 1 – 2 working weeks, or about 2 and a half to 5 working days if you invest in a smaller; say 500GB SSD.
A lot of developers may argue that this is not the case, but it is the case for Gradle, as the Gradle system is very hard on the direct disk access. If you work with .NET/C#/VB Net or other development tools you won’t notice much difference but the difference in Gradle is HUGE. If you act on this post I promise you, you won’t be disappointed. Personally I’m using fifth gen i7 with 8GB RAM which originally came with a 1TB Spinner and I upgraded it to a Samsung SSD 840 EVO 1TB and I’ve never looked back since. I bought mine from: https://www.aria.co.uk.
Hope this helps. Also I must state that this is NOT a commercially motivated post, I’m just recommending Aria as I’ve used them many times before and they’ve always been reliable.
few commands we can add to the gradle.properties file:
org.gradle.configureondemand=true - This command will tell gradle to only build the projects that it really needs to build.
Use Daemon — org.gradle.daemon=true - Daemon keeps the instance of the gradle up and running in the background even after your build finishes. This will remove the time required to initialize the gradle and decrease your build timing significantly.
org.gradle.parallel=true - Allow gradle to build your project in parallel. If you have multiple modules in you project, then by enabling this, gradle can run build operations for independent modules parallelly.
Increase Heap Size — org.gradle.jvmargs=-Xmx3072m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 - Since android studio 2.0, gradle uses dex in the process to decrease the build timings for the project. Generally, while building the applications, multiple dx processes runs on different VM instances. But starting from the Android Studio 2.0, all these dx processes runs in the single VM and that VM is also shared with the gradle. This decreases the build time significantly as all the dex process runs on the same VM instances. But this requires larger memory to accommodate all the dex processes and gradle. That means you need to increase the heap size required by the gradle daemon. By default, the heap size for the daemon is about 1GB.
Ensure that dynamic dependency is not used. i.e. do not use
implementation 'com.android.support:appcompat-v7:27.0.+'.
This command means gradle will go online and check for the latest version every time it builds the app.
Instead use fixed versions i.e. 'com.android.support:appcompat-v7:27.0.2'
Open gradle.properties from android folder and uncomment highlighted lines and provide memory values as per your machine configuration.
I have 8gb ram on my machine so I gave maximum 4096mb and 1024mb respectively.
# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
# Default value: -Xmx10248m -XX:MaxPermSize=256m
//Uncomment below line for providing your system specific configuration
#org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=1024m -XX:+HeapDumpOnOutOfMemoryError - Dfile.encoding=UTF-8
# When configured, Gradle will run in incubating parallel mode.
# This option should only be used with decoupled projects. More details, visit
#http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects
//Uncomment below line to allow parallel process execution.
#org.gradle.parallel=true
My build time was reduced to half after this.
Happy building!!
It often happens when you enabled multidex in you project. This can potentially slow your development process!!
According doc:
multidex configuration requires significantly increased build processing time because the build system must make complex decisions about which classes must be included in the primary DEX file and which classes can be included in secondary DEX files. This means that incremental builds using multidex typically take longer and can potentially slow your development process.
but you can optimize this:
To mitigate longer incremental build times, you should use pre-dexing to reuse multidex output between builds.
If you're using Android Studio 2.3 and higher, the IDE automatically uses this feature when deploying your app to a device running Android 5.0 (API level 21) or higher.
So you need to set the minSdkVersion to 21 or higher!
But if you production version need to support minSdkVersion lower than 21, for example 19
you can use productFlavors to set minSdkVersion 21 for you dev version:
android {
defaultConfig {
...
multiDexEnabled true
// The default minimum API level you want to support.
minSdkVersion 15
}
productFlavors {
// Includes settings you want to keep only while developing your app.
dev{
//the IDE automatically uses pre-dexing feature to mitigate longer incremental when deploying your app to a device running Android 5.0 !
minSdkVersion 21
}
prod {
}
}
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
}
}
}
dependencies {
compile 'com.android.support:multidex:1.0.3'
}
I do prefer building from command line for better build times. If your app code base is large and you have multiple modules then you can try Local AAR approach as described here, it will give you a big boost in Android Studio performance & gradle build times. Its compatible with command line builds as well
https://blog.gojekengineering.com/how-we-improved-performance-and-build-times-in-android-studio-306028166b79
Demo project with integration instructions can be found here: https://github.com/akhgupta/AndroidLocalMavenRepoAARDemo
Right click on Drawable folder and convert png/jpg images to webp format it improved the gradle significantly
From the android developer doc:
Configure JVM garbage collector. It reduced the build time to 2 to 4 seconds
gradle.properties file
org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC
Refer to this Developer doc
Follow Android Studio and Gradle performance guidelines
Optimize your build speed
Improving the Performance of Gradle Builds
Configuration cache
Build Cache
Overall
Always keep Gradle version up-to-date to receive new performance improvements
Modularize your project as much as possible to benefit from Gradle parallel work
Know Gradle properties and understand what they do
My java project for Android has several configurations. Previously I switched them and build apk from eclipse manually, but recently I've developed several ant tasks to make my life much easier: I launch cmd file and it builds all the configurations (changing config vars each time, moving resources, modifying manifest, etc.).
But today I've found that code compiled by ant (it uses javac) with android workflow (my build.xml includes ${sdk.dir}/tools/ant/build.xml) is different from code generated by ADT tool in Eclipse. And difference is fatal.
On compile stage javac claimed that some files include BOM, and one class is too big (to many static arrays). I've converted all files to utf8 w/o bom, splitted big class into two and javac had no more issues. It was easy.
However if I launch ant-made apk on 4.0.x device or emulator (while works on 1.6, 2.2, 4.1, 4.2) it force closes in runtime and says:
03-01 09:15:16.247: W/dalvikvm(1993): VFY: register1 v3 type 17, wanted 18
03-01 09:15:16.247: W/dalvikvm(1993): VFY: rejecting opcode 0xc8 at 0x0023
03-01 09:15:16.247: W/dalvikvm(1993): VFY: rejected Lcom/myproj/MySomeClass;.doThing (I)V
03-01 09:15:16.247: W/dalvikvm(1993): Verifier rejected class Lcom/myproj/MySomeClass;
03-01 09:15:16.247: W/System.err(1993): java.lang.VerifyError: com/myproj/MySomeClass
...
<stack here>
...
But eclipse-adt-made apk works on 4.0.x pretty well! Moreover - I never saw adt claims about utf bom or class size on compile.
So I assume we should use something else raither than javac in ant build. But Google uses exactly javac in its build.xml. How can we use ADT compiler instead of javac when building with ant?
Of course I still can make builds in eclipse, but ant scripts spends 1 minute when I spend 20 minutes, and it never make silly mistakes while changing cfg vars (there some dependencies between them).
Thanks in advance!
UPDT:
I suspect it is somehow connected with java version I use. Ant executes with 1.7 x86 jdk, while eclipse uses jdk1.6.0_26 x64. Someone says that Dalvik dex doesn't understand some java 1.7 bytecodes, but I should check.
UPDT1: No, I've removed all jdks, then installed both jdk 1.6.0_41 x86 and x64, set eclipse work with 1.6.0_41 x64 and set JAVA_PATH to jdk 1.6.0_41 x86. The same thing - apk compiled in eclipse (Android tools->Export signed apk) works, ant-compiled apk says VerifyError.
Think I've solved this issue.
I spent hours switching java versions, re-defining default google ant tasks, trying to launch different javac from several jdk as standalone to compile my classes. During last five years I never compiled java with console tools, so it was hard and confusing. I had no luck with any javac, the same verify error.
Then I read Eclipse and Android docs and found that when we build apk in eclipse, ADT uses Eclipse's JDT (Eclipse Compiler for Java) instead of javac to compile java code into classes, and then dx tool to make dalvik code.
So we need to launch JDT instead of normal -compile ant task, right? No, actually everything is easier. As it often happens I started from the end but once I understood that I need this compile tool I was on the right way.
Eclipse Compiler for Java (JDT ECJ) is much smarter tool than actual javac. It's a new tool for me with bunch of parameters, but JDT provides pretty cool ant javac adapter, and we can use it in javac ant task - set "build.compiler" property and then launch normal android ant -compile task:
<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter" />
<javac encoding="${java.encoding}" source="1.6" target="1.6" debug="true" extdirs=""
includeantruntime="false" destdir="${out.classes.absolute.dir}"
bootclasspathref="project.target.class.path"
verbose="${verbose}" classpathref="project.javac.classpath"
fork="${need.javac.fork}" >
<src path="${source.absolute.dir}" />
<src path="${gen.absolute.dir}" />
<compilerarg line="${java.compilerargs}" />
</javac>
But this will not work unless you have ecj.jar. And there is no such a file in eclipse! Continuing investigation I've found out that Eclipse Compiler for Java can be downloaded as standalone. To make this work you need to copy this jar to ant/lib folder. But strange thing - ecj 4.2.2 compiled code with the same verify problem. Luckily I've tried ecj 3.5.1 - and it worked! However I'm not satisfied - I still can't say why ecj 4.2.2 doesn't help while 3.5.1 does. What if I upgrade eclipse and it will compile bad classes? I've compared byte code - it differs very slightly (decompiled by jd-gui), so I assume problem is in something inside resulting class files. I'd like to know what's the heck but I even can't imagine what to look for.
Anyway, there is more. When you look to eclipse/plugins folder you'll see a file with name like "org.eclipse.jdt.core_3.6.2.v_A76_R36x.jar". It holds jdtCompilerAdapter.jar file inside (as jar is a zip archive). If you copy it to ant/lib and then copy org.eclipse.jdt.core_xxxxxx.jar file itself you get exactly the same compiler that your current eclipse version has! Voila! This way you can be sure that if eclipse makes a "good" code - ant will do also.
So finally everything resulted in two simple steps:
copy org.eclipse.jdt.core_xxxxxx.jar and jdtCompilerAdapter.jar from inside of it to your ant/lib folder.
add following to you project.properties file:
java.target=1.6
java.source=1.6
build.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
That's all!
But if you have ideas why ecj from eclipse juno package (4.2.2) fails to compile right code I'd like to listen!
I am working on the contacts app from android open source project. My android version is 2.3.5_r1. And using mm to make the module, but the making speed is quite slow, so i doubt if there is a method to speed up the making.
PS:Actually if i compile this module in eclipse, i will speed up a litter because the auto build feature of eclipse. But i don't like work with eclipse so give it up.
For instance, I use the following command from the root folder of your Android project:
mmm frameworks/base snod -j4
And I think that this is the best choice. Try it but substitute frameworks/base with your project name (relative path where Android.mk is stored).
In order of least cost to you:
Don't make clean so much. Allow the makefile to determine what to rebuild.
Use CCACHE export USE_CCACHE=1. You're only likely to see the effects of CCACHE upon having rebuilt multiple times. If your project is large set a higher CCACHE size e.g. 10GB ${ANDROID_DIR}/prebuilt/linux-x86/ccache/ccache -M 10G
Get a better processor and run with higher -j parameter
1. Build module + dependencies
mmma is slower than mmm, as the former make sure all dependencies are met for the module, and if they are not it compiles them as well. So, initially instead of a full make command, build the dependencies concerning the module you are interested in using the following:
mmma -j4 adir/yourmoduledir
2. Build module
Now that dependencies have met, keep recompiling just the module you are interested in. Skipping check for dependencies saves precious time. The directory you are using though, might contain more than one compilation target. To compile a single target, use something like:
mmm -j4 adir/yourmoduledir:moduletargetname
Example
Build libart
Build library and all of its dependencies once:
mmma -j4 art/runtime
Modify libart's code and quickly build it:
mmm -j4 art/runtime:libart
You will get half compilation time in comparison to Yury's approach as for example the debugging flavor of libart (libartd) will be omitted altogether.
Further speedup?
You should of course enable caching as suggested by aultbot.
Also, depending on the modules you are interested, there might be compilation targets you might want to disable by digging up in the makefiles. For example libart is compiled for both the host and the target. If you modify a variable in the makefiles can force compilation just for one of the 2, saving you half of the time.
Additional info:
Checkout out the outdated build guide in aosp:
build/core/build-system.html.
N-Preview google is switching to a new build system that aims to speed up incremental builds. I hope the documentation gets updated as well.
I found that when I use my laptop ssh to my desktop computer and build module, I can build it very very fast. I don't know why.
I have created a demo application with the sbt android-plugin.
The app is very simple.
I have placed a MainActivity.java file under /src/main/java/my/package/ and when a button is pressed it takes you to a second Activity but done in Scala.
Everything is working fine but the build times are killing me.
When I modify something I run in my device using:
> android:package-debug
> android:start-device
My issue is that it takes almost a complete minute to build a two activities project.
Is there another way to compile and run?
This is my output of android:package-debug
> android:package-debug [info] Wrote
/Users/macarse/Documents/demo/target/src_managed/main/scala/my/package/TR.scala
[info] Compiling 1 Scala source to
/Users/macarse/Documents/demo/target/scala-2.9.0-1/classes...
ProGuard, version 4.6 ProGuard is released under the GNU General
Public License. You therefore must ensure that programs that link to
it (scala, ...) carry the GNU General Public License as well.
Alternatively, you can apply for an exception with the author of
ProGuard. Reading program directory
[/Users/macarse/Documents/demo/target/scala-2.9.0-1/classes] Reading
program jar
[/Users/macarse/.sbt/boot/scala-2.9.0-1/lib/scala-library.jar]
(filtered) Reading library jar
[/Users/macarse/Documents/android-sdk-mac_86/platforms/android-4/android.jar]
Note: You're ignoring all warnings! Preparing output jar
[/Users/macarse/Documents/demo/target/classes.min.jar] Copying
resources from program directory
[/Users/macarse/Documents/demo/target/scala-2.9.0-1/classes] Copying
resources from program jar
[/Users/macarse/.sbt/boot/scala-2.9.0-1/lib/scala-library.jar]
(filtered) [info] Dexing
/Users/macarse/Documents/demo/target/classes.dex [info] Packaging
/Users/macarse/Documents/demo/target/demo-0.1.apk [success] Total
time: 56 s, completed Oct 29, 2011 4:22:54 PM
There are a couple of options:
preinstall scala on the phone/emulator
Include predexed scala as a library
There is also a project called treeshaker for Eclipse which is a lot faster than proguard, but it is not integrated w/ the sbt plugin yet.
It takes long time because proguard need to process Scala standard library to minimize the .apk file you get, and Scala standard library is huge.
I will suggest you switch to Scala 2.8 if you didn't use features of Scala 2.9, because 2.8 has a smaller standard library.
In the other hand, don't use android:package-debug when not necessary. compile will compile your source code, it is sufficient if you only want to make sure your program could be compiled.
Only use android:package-debug when you are about to test it on the Android device, this will save your time.