The New Android SDK Build System
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.xmlfile and the XML files for your Activities, and compiles them. An
R.javais also produced so you can reference your resources from your Java code.
- The aidl tool converts any
.aidlinterfaces that you have into Java interfaces.
- All of your Java code, including the
.aidlfiles, 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
.dexfiles so that they can be packaged into the final
- All non-compiled resources (such as images), compiled resources, and the .dex files are
sent to the apkbuilder tool to be packaged into an
- Once the
.apkis 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
.apkwith the zipalign tool. Aligning the final
.apkdecreases 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.To avoid this error, see Building Apps with Over 65K Methods.
The build generates an APK for each build variant in the
app/build/outputs/apk/ directory contains packages named
app-<flavor>-<buildtype>.apk; for example,