I have recently migrated to new Android Studio 2.2 among many other features I also came across android.enableBuildCache=true to decrease build time.
My question is that how is this helping my builds go faster and what exactly is being cached ? Because I have actually noticed an increase in initial build time which has made me question whether I should use it or not. If somebody could explain me the inner functionality and what exactly is cached and in what conditions then maybe I will be able to fine tune this caching and speed up my builds.
this link shows all the details: http://tools.android.com/tech-docs/build-cache
here are some relevant parts:
... build cache feature that can speed up build times (including full
builds, incremental builds, and instant run) by storing and reusing
files/directories that were created in previous builds of the same or
different Android project.
Currently, the build cache contains only pre-dexed libraries; in the
future, we will use it for caching other types of files as well.
when your build time increased, then maybe
I guess this could be normal for the first build after activating the cache
it's a bug of this experimental feature: in this case, please file a bug
the cache was not used at all:
Step 0
Ensure that android.dexOptions.preDexLibraries is either not
set or set to true; otherwise the libraries will not be pre-dexed and
therefore the build cache will not be used.
Step 1
android.enableBuildCache=true
Step 2
Build your Android project and check the following locations to see whether the build cache took
effect. By default the cache-dir is
/.android/build-cache. The final pre-dexed files
are stored in
/build/intermediates/pre-dexed/debug and
/build/intermediates/pre-dexed/release. You
need to run the command line to see the “pre-dexed” directory; if you
click the “Run” button from the Android Studio menu, you will not see
this directory as it will be deleted.
Note: If you are using Multi-dex with minSdk >= 21, the dexed files
will be stored directly into the
/build/intermediates/transforms/dex directory
without being stored in /build/intermediates/pre-dexed.
Related
I have a big Android Studio project that has a separate module which contains native code.
The native build is defined with CMake and includes a bunch of source files of C++ code.
I noticed that since a very recent update (might be Android Studio 3.5), NDK rebuilds everything ALL THE TIME.
It can happen with a small change in Java code, switching flavor in an unrelated module in the project, incrementing version code, etc.
This is a major problem, since it can waste 10 minutes at a time for no reason.
I could not find a reasonable way to profile NDK builds in Android Studio and check what's causing the rebuild or what's taking so long.
Unfortunately the project's build files are too big to attach here. Any pointers for things to look after?
For the C/C++ code that you build with cmake, make sure you point cmake to a directory where it can keep its object files and binary outputs.
Let's say you have a dependency on Game in your top level CMakeLists.txt like so:
# dependency: Game
set ( game_src_DIR ../Game )
add_subdirectory( ${game_src_DIR} ${CMAKE_CURRENT_BINARY_DIR}/game )
Then the second parameter to add_subdirectory specified the place where AndroidStudio will keep the object files.
The debug and release object files will live in different subdirs, as will each dependency, so switching debug/release will not clash.
This appears to have been a regression in behavior from Android Studio 3.4 and has been fixed in Android Studio 4.1 Canary 4. Release notes are here.
Often, it helps to split the AS project such that the C++ part, possibly with its Java wrappers become a separate (library) module. This module will hopefully be more stable, not sensitive to increments of app version code.
Such module should not define many flavors, but have careful matching to the flavors of other modules. Sometimes, it makes sense even to disable "debug" variants for such library. There was an effort of the NDK team to better handle debug vs. release build switching, but this is still tricky.
But if after these improvements, insignificant changes to the project still cause massive rebuild, I would suggest to consider ccache.
Android studio is getting slow in grade building process.I noticed this problem after updating to new version 3.5.Is there any ways to
speed up the building process?
1- Make sure you’re using the latest version of Gradle. Generally with every new update there is a significant improvement in performance.
Note: Java 1.8 is faster than 1.6. Make sure it’s updated too.
2- Try to minimize the use of modules. There are many cases where we need to fork the library to modify it to fit according to our needs. A module takes 4x greater time than a jar or aar dependency. This happens due to the fact that the module needs to be built from the scratch every time.
3- Enable gradle Offline Work from Preferences-> Build, Execution, Deployment-> Build Tools-> Gradle. This will not allow the gradle to access the network during build and force it to resolve the dependencies from the cache itself.
Note: This only works if all the dependencies are downloaded and
stored in the cache once. If you need to modify or add a new
dependency you’ll have to disable this option else the build would
fail.
4-Open up the gradle.properties file from the root of your project. Add the following lines of code in it.
org.gradle.daemon=true
Gradle daemon is a background process. Adding this would consume some extra memory while building.
org.gradle.parallel=true
The above line of code enables compilation of multiple modules at the same time. Besides that it also gives us other benefits such as;
Re-using the configuration for unchanged projects
Project-level is up-to-date checks
Using pre-built artifacts in the place of building dependent projects
Adding the following line of code also aids us in speeding up the build.
org.gradle.configureondemand=true
Another important property is;
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
The above line is used to allow Java compilers to have available memory up to 2 GB (2048 MB). It should only be used if you have available memory more than 2 GB.
This is how the gradle.properties file should look like:
5- Avoid dynamic dependencies such as
compile 'com.google.maps.android:android-maps-utils:0.4+'.
Dynamic Dependencies slow down your build since they keep searching for the latest builds every time. To improve the performance we need to fix the version in place.
6- Use only those dependencies that you need. For example google maps dependency, instead of importing , like :
implementation 'com.google.android.gms:play-services:17.0.0'
implementation 'com.google.android.gms:play-services-maps:17.0.0'
Gradle build speed depends on a lot of factors including the specification of your machine as well as your build type and android studio settings. You can check out this article on how to reduce your build time or go through the steps in the Android developer website.
Personal experience:
When I faced this issue, enabling offline mode drastically reduced my build time. The only problem is that I have to toggle this setting (on and off) every time I want to add a new dependency and this almost made me go berserk on several occasions. However, if properly handled, this helps a great deal.
I hope this helps. Merry coding!
you can set file->setting->search 'Gradle'-> check 'use local gradle distribution' and check 'offline work'.. in android studio. it will improve gradel building time.
Note: In newer version of Android studio, View->Tool Windows->Gradle->Toggle button of online/offline
I'm trying out cocos2d-js (version 3.0) and even the simplest 'Hello World' project is over 1 gigabyte in size when it is created.
Is this normal? (I have a habit of creating dozens of demo-projects when trying out a new platform, but it looks like I need to get myself a bigger SSD, just for this!)
Also, the size of the apk, when compiled for Android, is about 9 MB. Any ways to reduce this size?
Sadly, yes. I've mentioned this in the community a couple of times to no avail. I believe this files should be referenced/cached in a common location for all projects, but the dev team seems to have other priorities at present.
If you wish to keep your projects you'll be better off heading to their frameworks directory and deleting all folders except cocos2d-html5 (this one should be 5MB only) in there. -
An alternative would be to also delete the cocos2d-html5 folder, place it in a common dir (or use the copy in your install folder) and reference the path properly in your projetc's config file. Keep in mind this option may break code suggesstion/autocomplete in some editors, and throw errors in your webserver when you try to run the project.-
This way, you'll be able to run any of those projects in the browser, and then only add the files neccessary for native compilation in projects you wish to test in the emulator or your device (or compile for publishing). This will sadly take a lot of time to copy and re-generate the files, of course.
As for reducing the size of the .apks... I don't know a way. I know efforts are being made to optimize the binder, and there may be a way to explicitly avoid packaging unused stuff, but I don't know about it.
You can reduce the app size in Cocos2d-js v3.2 released in January. It allows you to exclude the unused modules. Refer to the upgrade guide for more details on how to do this. The minimum apk size for Android is 4.4mb .
When I right click on a project on Eclipse and click on "Run as Android App", does it have a different build process then Ant builds?
Currently I am working on an app that uses another project as a library dependence. Everything compiles fine and the app loads, but when I try to use the functionality the library provides, problems come up. The library has a checksum file to verify that the library resources are loaded correctly. When I build to my phone from Eclipse, this check passes. But when I use my ant build, the resource check fails.
I have compared both apk results (diff -rq ant/ eclipse/) and my differences are as follows:
Files ant/AndroidManifest.xml and eclipse/AndroidManifest.xml differ (this is expected)
Files ant/META-INF/CERT.RSA and eclipse/META-INF/CERT.RSA differ
Files ant/META-INF/CERT.SF and eclipse/META-INF/CERT.SF differ
Files ant/META-INF/MANIFEST.MF and eclipse/META-INF/MANIFEST.MF differ
Files ant/classes.dex and eclipse/classes.dex differ
Files ant/resources.arsc and eclipse/resources.arsc differ
I suspect resources.arsc may be causing the problem. The size of these files are only 8 bytes different.
I'm lost on this, anyone have an idea of why this is happening. I've tried deleting the checksum file, but the library won't work without it.
I have been working on one project which is too complex and contain very much space with so many images and Java files as well.
Somewhere I have read about the proguard which optimizes the code.
I have used it, but it's still does not have an effect on my final APK file.
It might be I have made a mistake somewhere. I have the following this like http://developer.android.com/guide/developing/tools/proguard.html.
How can I optimize my code?
You can add it to the default.properties. I've been adding manually without having a problem so far.
If you add the line:
proguard.config=proguard.cfg
As said it will only use ProGuard when exporting signed application (Android Tools => Export Signed Application)
If you start the project with the SDK before Android 2.3 the proguard.cfg file will not be created (next to default.properties as in 2.3>).
To enable automatic creation of it, just simply update to the SDK of Android 2.3 and create a new project with existing sources (which are the sources of the project you currently have).
Automagically the proguard.cfg fill will be created.
Without optimizations the compiler produces very dumb code - each command is compiled in a very straightforward manner, so that it does the intended thing.
The Debug builds have optimizations disabled by default, because without the optimizations the produced executable matches the source code in a straightforward manner.
Please refer this one
From documentation:
ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode.