Build System Overview

The Android build system is the toolkit you use to build, test, run and package your apps. The build system can run as an integrated tool from the Android Studio menu and independently from the command line. You can use the features of the build system to:

• Customize, configure, and extend the build process.
• Create multiple APKs for your app with different features using the same project and modules.
• Reuse code and resources across source sets.

The flexibility of the Android build system enables you to achieve all of this without modifying your app's core source files. To build an Android Studio project, see Building and Running from Android Studio. To configure custom build settings in an Android Studio project, see Configuring Gradle Builds.

A Detailed Look at the Build Process

The build process involves many tools and processes that generate intermediate files on the way to producing an .apk. If you are developing in Android Studio, the complete build process is done every time you run the Gradle build task for your project or modules. The build process is very flexible so it's useful, however, to understand what is happening under the hood since much of the build process is configurable and extensible. The following diagram depicts the different tools and processes that are involved in a build:

The general process for a typical build is outlined below. The build system merges all the resources from the configured product flavors, build types, and dependencies. If different folders contain resources with the same name or setting, the following override priority order is: dependencies override build types, which override product flavors, which override the main source directory.

• The Android Asset Packaging Tool (aapt) takes your application resource files, such as the AndroidManifest.xml file and the XML files for your Activities, and compiles them. An R.java is also produced so you can reference your resources from your Java code.
• The aidl tool converts any .aidl interfaces that you have into Java interfaces.
• All of your Java code, including the R.java and .aidl files, are compiled by the Java compiler and .class files are output.
• The dex tool converts the .class files to Dalvik byte code. Any 3rd party libraries and .class files that you have included in your module build are also converted into .dex files so that they can be packaged into the final .apk file.
• All non-compiled resources (such as images), compiled resources, and the .dex files are sent to the apkbuilder tool to be packaged into an .apk file.
• Once the .apk is built, it must be signed with either a debug or release key before it can be installed to a device.
• Finally, if the application is being signed in release mode, you must align the .apk with the zipalign tool. Aligning the final .apk decreases memory usage when the application is -running on a device.

Note: Apps are limited to a 64K method reference limit. If your app reaches this limit, the build process outputs the following error message:

Unable to execute dex: method ID not in [0, 0xffff]: 65536.

Build output

The build generates an APK for each build variant in the app/build folder: the app/build/outputs/apk/ directory contains packages named app-<flavor>-<buildtype>.apk; for example, app-full-release.apk and app-demo-debug.apk.