Understanding the Android Sourcecode Compliation and Build Process

• The Android Sourcecode Compilation or  build process involves many tools and processes that generate intermediate files on the way to producing an .apk.
•  If you are developing in Eclipse, the complete build process is automatically done periodically as you develop and save your code changes.
•  If you are using other IDEs, this build process is done every time you run the generated Ant build script for your project. 
• It is useful, however, to understand what is happening under the hood since much of the tools and processes are masked from you.    

I am going to provide  a detail insight view  of this compilation and build  process. Here is  the flow chart of Build process in android

 Step 1: - 
Build process start  in android from the generation of Java source files from your Android resources. The resources, stored in the res sub-directory  include such things as icons, layouts and strings. These are compiled using the aapt tool into a file named R.java, stored in the gen/ sub-directory. if you look on that R.java file you find there a bunch of constant.
Step 2:- 

Service Interface Pre-compilation
The second build step also involves generation of Java source. If your project uses any service interfaces, you need to include the service interface definition files (which have an .aidl extension) in your project. These files superficially resemble normal Java interfaces:

1 2 3 4 5 6

package com.sks.android.myapp; interface implementedService {     String echo(in String s); }

The aidl tool is used to generate actual Java interfaces for these services. The Java source files will have the same name as the input files (with the .aidl extension replaced by .java) and are created in the gen/ subdirectory. These generated sources serve as a basis for us to implement or call the service interfaces in our own code.
Step 3:- 

Java Compilation
After the two pre-compilation steps, our project’s Java code is complete and ready to be compiled itself. This step is a standard Java compilation from .java source files (both hand-crafted and generated) to .class byte-code files. The binary byte-code files are stored in the bin/classes sub-directory.

One thing to be aware of is the classpath used to compile your source. This includes:

• The android.jar file for your target Android platform. This jar includes class and method stubs for all of the Android APIs.
• External library jars you have added to your project (all .jar files in the libs/ subdirectory).
• For test projects only: the class files and external libraries for the tested project.

Step 4:-
This the main step where something happen new. The dance of Dex tool !!!  Yes ...

After compilation, We have standard Java bytecode, which would run on a standard Java VM. However, Android uses its own Dalvik VM, which requires a different bytecode format. Thus, after compilation, the dx tool is used to translate/convert your class files into a Dalvik executable or .dex file. This includes the class files stored in any external library jars you have added to your project. All classes are package up in a single output file, named as .dex, which is produced in the bin/subdirectory.
Step 5:-
Next, the resources are compiled into a partial Android package file. This is done by the same aapt tool that generates Java source corresponding to the resources. The resource package is created, named after our application with an ap_ suffix in the bin directory. We can use unzip to take a peek inside the package:

1 2 3 4 5 6 7 8 9

saurabh@caligula:~/work/my-app/build$ unzip -t MyApp.ap_ Archive:  MyApp.ap_     testing: res/layout/main.xml      OK     testing: AndroidManifest.xml      OK     testing: resources.arsc           OK     testing: res/drawable-hdpi/icon.png   OK     testing: res/drawable-ldpi/icon.png   OK     testing: res/drawable-mdpi/icon.png   OK No errors detected in compressed data of MyApp.ap_.

Note that although icon and layout files are included at their original location, they have been processed during packaging (presumably for more efficient storage and/or processing). The icons appear to be optimized but still valid images, whereas layout XML files are converted to a binary format. Strings are compiled into the binary resources.arsc file.
Step 6:-
Now all of the components required for the final Android package are ready to be bundled up into an apk file named after our application. In the default debug mode, this build step also includes signing of the package with a debug key. Note that for release, signing is a separate step that requires access to our own key (and may prompt for a password). Android packages are assembled with the apkbuidler tool, which takes input from several sources:

• The Dalvik executable file bin/classes.dex.
• All non-Java resources from your source directory (src/).
• All non-Java resources from your external libraries (found by searching all .jar files in the libs/ subdirectory).
• Any native code shared-libraries included by your project.
• The resource package built in the previous step.

The produced package will be placed in the bin/ subdirectory, named something like MyApp-debug-unaligned.apk.
Step 7:-

Alignment
As a final optimisation step, the package file is aligned using the zipalign tool. This step ensures that resources in the package file are aligned on 4-byte word boundaries. This allows the Dalvik VM to memory-map those parts of the file for more efficient access. You can read more about alignment on the Android Developers Blog. This step takes the -unaligned package as input, and produces an output something like bin/MyApp-debug.apk. This is the final, signed, aligned Android package — ready to be installed on an Android device!
For More Detail You can visit following link:-

http://developer.android.com/guide/components/aidl.html