There are a few ways to make it easier to deal with multimodule projects, and there are a few things to keep in mind when working with several modules. Being aware of these can save you time and frustration.
As we saw in Chapter 2, Basic Build Customization, it is possible to run Gradle tasks straight from Android Studio. When you have multiple modules, Android Studio recognizes them, and shows a grouped overview of all available tasks.
The Gradle tool window makes it easier to run module-specific tasks. There is no option to run a task for all modules at the same time, so if you wish to do that, the command-line interface is still faster.
When you build a multimodule project, Gradle processes all modules sequentially. With more and more cores available in computers, we can make the build process a lot faster by building the modules in parallel. This feature already exists in Gradle, but is not enabled by default.
If you want to apply parallel build execution to your project, you need to configure the parallel property in the gradle.properties file on the root of the project:
org.gradle.parallel=true
Gradle attempts to choose the right number of threads, based on available CPU cores. To prevent issues that may arise from executing two tasks from the same module in parallel, each thread owns an entire module.
Note
Parallel build execution is an incubating feature. This means that it is under active development and the implementation may change at any time. This feature has been a part of Gradle for a while now, though, and is already widely used. It is, therefore, safe to assume that the implementation will not disappear or change drastically.
Your mileage may vary, but you might be able to shave off a significant amount of time from your builds by simply enabling parallel build execution. There is one caveat, however. For this to work efficiently, you will need to make sure your modules are decoupled.
As we saw in Chapter 2, Basic Build Customization, it is possible to define properties for all modules in a project, using allprojects in the build.gradle file. When you have a project with multiple modules, you can use allprojects in any module to apply properties to all the modules in the project. Gradle even makes it possible for one module to reference properties from another module. These powerful features can make maintenance for multimodule builds a lot easier. The downside, though, is that your modules become coupled.
Two modules are considered to be coupled as soon as they access each other's tasks or properties. This has several consequences. For example, you give up portability. If you ever decide to extract a library out of the project, you will not be able to build the library before copying all project-wide settings first. Module coupling also has an effect on parallel builds. Using the allprojects block in any of the modules will render parallel build execution useless. Be aware of this when you add project-wide properties to any of the modules.
You can avoid coupling by not directly accessing tasks or properties from other modules. If you need this behavior, you can use the root module as an intermediary so that modules are coupled only to the root module and not to each other.