Develop Reference

Android Studio build/sync time in multi module project

I have a project with 30+ modules and sub modules(feature base modules).
I've read that build time of a multi module project is less than a single module project, as it was when it had less than 10 modules(Layer base modules). But when module count grows it affects Android Studio index/build/sync time. Moreover, during development of a multi module project Android Studio takes high CPU and Memory usage.
What should I do to optimize build speed and Android Studio performance?
Note 1: There is a complex relation between module dependencies.
Note 2: Gradle parallel has been enabled and I've checked Google Optimize your build speed

I was having the same issue as yours. I solved my problem by using custom gradle dependency resolution.
The idea is pretty simple, I publish all my modules to a repository (artifactory in my case) and then in my build.gradle file for modules I depend on the published modules. To switch the dependency from published to local during development I use gradle dependency resolution to resolve to local versions.
def loadedModules = [:]
getSubprojects().forEach {
loadedModules.put(it.name, it.path)
}
def group = 'np.com.susanthapa.efficientmultimodule'
allprojects {
repositories {
mavenLocal()
google()
jcenter()
// replace configurations for all modules
configurations.all {
// get our own dependencies
resolutionStrategy.dependencySubstitution.all { dependency ->
if (dependency.requested instanceof ModuleComponentSelector && dependency.requested.group == group && loadedModules.containsKey(dependency.requested.module)) {
def targetProject = findProject(loadedModules.get(dependency.requested.module))
if (targetProject != null) {
dependency.useTarget targetProject
}
}
}
}
}
}
Then what you can do is unload all the modules from your project except app module and also comment out all the modules from settings.gradle file.
Now to work on a particular module just uncomment that specific module in settings.gradle and also load that module in android studio. The above code will make sure that the local version of the loaded module will be used through out your project. This should reduce the build time as well as android studio indexing.
For more info here is the link to the blog post.

Follow the profiling steps in the link you posted.
In addition or for quicker/less formal profiling you can use the --scan option with a ./gradlew build and check the stats that are published online.
Memory usage can be tuned based on those results and that can give you great benefits. Personally, I've seen builds take literally minutes in garbage collection due to low memory.
You can also increase the memory available to Android Studio based on these results. Help->Edit custom VM options. But I would get to the point you are seeing improvements on the command line (./gradlew) builds first.

Android Studio and Kotlin code inspection is unusable when there are multiple errors in file

In Kotlin files when I have multiple errors, Android Studio becomes unusable.
When I make any change everything freezes for a few seconds, when I disable code inspection then it works normally.
This does not happen with java
Is this an issue with my pc or Kotlin or android studio, and is there any kind of a solution

Did you update your kotlin version?
I passed over a similar problem because of updating some implements or kotlin,google-services version etc. in the middle of a project!
After i returned the previous version; it is fixed...
So try using previous version for example kotlin_version = '1.3.40' in the project's build.gradle.
buildscript {
ext.kotlin_version = '1.3.40'
...
...
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
...

It might not be an issue with Kotlin.
Ensure that both the Kotlin plugin and Android Studio plugins are up to date.
The IDE can hang if it does not have enough memory allocated.
To change the memory allocation, go to Edit -> Edit Custom VM option and update the memory allocation as shown in the image below. This might help.
If you need additional assistance finding this setting, please refer to the official Android Studio Configuration guide.

Why not adding mavenLocal() in all Android apps?

When creating an Android project from scratch, Android Studio doesn't add mavenLocal() to the list of Gradle repositories. But we added it, and builds are now faster than ever.
Is there any reason to avoid adding mavenLocal() at every Android project we have? I mean, are there any cons in doing it?

What if you didn't have .m2 local repository?
mavenLocal() actually adds your .m2 to your Gradle repositories.
Gradle has its own ivy cache, and probably when you migrated the project or had a different project that used some common dependencies, its actually faster as all the dependencies been downloaded already before, therefore adding maven local repo to Gradle repositories makes the fresh project faster as it doesn't need to download them again to its local cache.
I would personally have it there as I have some maven and some Gradle projects, and yes it speeds up the build, and it doesn't use as much space to store duplicated dependencies for multiple projects. But I also think that if you are not using maven, you should let Gradle manage its dependencies.

I think #LazerBanana has pointed out the issue.
But besides that, I also want to mention the continuous integration practices everyone has nowadays for the builds. That is another thing we should not have mavenLocal(), because it makes builds depending on machines.

Is there a way to easily start and manage an android project and it's dependancies?

I am looking for an easy and somewhat automated way of starting and managing an Android project. I have been working on a few projects here and there and have found that a good amount of the time dependencies are a pain point. I am currently using Eclipse and looking into Maven. Which from what I understand is a dependency manager. I would greatly appreciate if anyone could provide suggestions on good process or tools to make setup and initialization less of a hassle. Thank you!

If you're starting to learn Android, don't waste your time with learning Maven / the Android Maven plugin, but go for Gradle / the Gradle plugin for Android and Android Studio as the IDE. Both Maven and Gradle are dependency managers (and build systems).
Google's docs on the new Gradle build system contain a section about why Gradle was chosen, and examples about how to manage dependencies. Basically, all you need to do is to add repositories and an compile dependencies like
repositories {
mavenCentral()
}
dependencies {
compile 'com.google.guava:guava:11.0.2'
}
android {
...
}

Studio failed to download library from gradle repository

I already saw this question, but it is not helping me. First of all, I tried to add google play services in my project using:
dependencies{
compile 'com.google.android.gms:play-services:6.5.87'
}
It was showing me error:
Then I updated my studio to 1.0.1 and gradle to 1.0.0. And then I again synced the project with gradle. And it worked! It showed me another option despite of two options shown in above screenshot. It was "Install the library"(something like that). I clicked it and it popped up a dialog, and I installed the library(it was like downloadind using SDK manager and not like gradle downloads).
Now, I tried to download this library using:
compile('com.fortysevendeg.swipelistview:swipelistview:1.0-SNAPSHOT#aar') {
transitive = true
}
And it gives me error:
My android repository is updated:
Also, my internet connection is working fine. I tried to sync project many times, but same error all the time. I am not running gradle in offline mode:
How to fix this? And what is the permanent solution? And why is all this happening?

I found this question: Studio failed to download library from gradle repository which describes the exact same error, and that question had this bit of build script that you need to add to the build file that has the dependency statement in question:
repositories {
maven { url 'http://clinker.47deg.com/nexus/content/groups/public' }
}
When I do this, it works for me.
As to the general question of why this happens (and the better question of why the solution is different for different libraries):
Gradle, the build system that Android Studio uses, has the ability to automatically download library dependencies from the Internet. By and large this is a big boon for developers, because instead of having to manually download archive files, put them in the right place in your project, check them into source control, and repeat the process for new versions, now you just have to add a line of build script and the build system takes care of the housekeeping for you. The major downsides are Internet connectivity woes, which affect different developers to different degrees, and some added confusion about what it means when you get an error.
How does Gradle know where to download dependencies? Most Gradle build scripts contain a block that looks like this:
repositories {
jcenter()
}
or it may be mavenCentral() instead of jcenter(). This tells the build system to look in the JCenter or Maven Central global repositories (and JCenter is in a simplistic way of thinking about it a value-added mirror of MavenCentral); these contain archives of many versions of many, many, many libraries and are very convenient to use.
You can specify other repositories as well. This swipelistview library hasn't been uploaded to Maven Central, so the developer has made a repository for it available via a URL: if you add that URL to your repositories block, it will look for it there.
I was worried about the fact that you're accessing a SNAPSHOT version of the library -- these are supposed to be unpublished by definition. But adding a dependency on the snapshot version of the library in my test project worked for me, and looking around that URL in a web browser reveals that there's only a "1.0-" (trailing dash included) version of the library, so there's some subtletly there I'm missing; if you know more, please edit my answer or comment.
In any event, there are a couple caveats to this explanation. Some libraries aren't on Maven Central or on any Internet-accessible archive (at least they're not officially published by Android), but are instead published as part of the Android SDK download and maintained via the SDK manager. The Android support libraries and Google libraries fall under this category. If you get errors about those not being found, you have to fix it via the SDK manager.
How does the build system know to look in the SDK for those, since you didn't tell it via the repositories block? This behavior is hardcoded into the Android Gradle plugin.
The other caveat is that there's a detail that trips up a lot of people, which is that you actually have two repositories blocks, though with the usual Android Studio setup they're often in different files. One is in a buildscript block, which usually lives in the top-level build.gradle file and looks like this:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
The other often also lives in the top-level build.gradle, but you can augment it with another block in your module's build.gradle file. The top-level one looks like this:
allprojects {
repositories {
jcenter()
}
}
and a module-level one would look like one of the previous examples in this answer. What do all of these mean?
The buildscript block tells Gradle where to find build system plugins. These are plugins that enhance the functionality of the build system itself but don't say anything about your actual project. In Android projects, the Android Gradle plugin is in this category, and unlike the Android/Google libraries, this one does live on Maven Central. The repositories block (in coordination with the dependencies block, which is not the same as the dependencies block for your project, keep reading) in buildscript tells the build system where to go look for these plugins.
The allprojects block in the top-level build file tells the build system to apply the bit of contained script to all build files in the project. In this example, it's telling it to add a repositories block pointing to JCenter to all subprojects. This is a convenience so you don't have to copy/paste it into multiple build files in your modules.
In your modules, you also have a repositories block, which in conjunction with the allprojects thingy, tells the build system where to go to get library dependencies for your project, as was previously discussed.