The APK file is actually a compressed zipped package of a bunch of different files, including the compiled Java code and non-compiled resources, such as images.

An APK file is built for a specific target version of Android, but it also indicates a minimum version. An app built for an older version of Android, in general, will run on newer Android versions but not vice versa. To build for an older version of Android, however, means that newer features will not be available to the app. You want to choose the minimum version of Android that supports the features you need in order to target as many devices as possible. Or, if you want to support a smaller subset of devices for, say, performance reasons, you might choose an artificially high minimum API version.

To build your project and create an APK file in Android Studio, you need to click on the Build menu option and select Make Project, (or click on the green arrow icon to build, deploy, and run the app on a device or within an Android Virtual Device (AVD)), which kicks off a Gradle build process. You can build a version to develop and debug or build a more optimized release version of the application for distribution. You can choose to do this by clicking on the Build menu and selecting Select Build Variant....

Android Studio uses a tool named Gradle to build the APK file from your project files. The following is a flow diagram of the Gradle build process taken from the Android documentation (http://developer.android.com/sdk/installing/studio-build.html). Actually, most of the illustrated details aren't so important for us. What is important is to see the many pieces and how they fit together.

In the bottom-most box in the preceding diagram, you can see that the result of the build is a signed and aligned .apk file, which is the final version of our app that has been compiled (converted from the source code), zipped (compressed), and signed (for authentication) from the earlier build process. The final step, zipalign, aligns the compressed resources along 4-byte boundaries in order to quickly access them at runtime. Basically, this last step makes the app load faster.

In the middle of the diagram, you'll see that the .apk (unsigned, uncompressed) file is assembled from .dex files, compiled Java classes, and other resources (such as images and media files).

A .dex file is the Java code, which has been compiled into a format (Dalvik bytecode) that runs on the Dalvik virtual machine (DVM) on your device. This is an executable file of your program. Any third-party libraries and compiled Java source code files (.class) that you have included in your module build are converted to .dex files in order to be packaged into the final .apk file.

Again, don't sweat the details if this is new to you. The important thing is that we're going to be working with a lot of different files in our Google Cardboard projects. It will be helpful for us to have a context of where they're used in the build process.

For example, the common.aar file (binary Android Library Archive) with the Cardboard SDK is one of the third-party libraries which we will use. The contents of your project's res/ directory, such as layout/activity_main.xml, are passed through the Android Asset Packaging Tool (aapt).

What feeds into the .dex file? A Java compiler takes the Java language source code and generates an .dex file containing bytecode. By referring to the preceding Gradle build flow diagram, at the top of the diagram, you will see that the inputs to the Java compiler include the following:

In the rest of this book, we're going to talk a lot about these source code files. That's the stuff you write! That's the place where you do your magic! That's the world where we programmers live.

Let's now take a look at the directory structure of your Android project source code.