How Does Android App Work?
Developing an android application involves several processes that happen in a sequential manner. After writing the source code files, when developers click the Run button on the Android studio, plenty of operations and process starts at the backend. Every operation happening in the background is a crucial step and are interdependent. The IDE builds all the application files, make them device compatible in order to deploy, and assure that the application runs successfully on the device. This article broadly explains each and every critical step involved in the journey of an android app, from the IDE files to a working device application.
Step 1: Building the APK File
1. Code Compilation
The android application source files are written in either Java(*.java files) or Kotlin(*.kt files) programming languages. Syntax of writing the code in these 2 languages are different but their compilation process is almost the same. Both programming languages generate code that can be compiled to Java byte-code which is executable on JVM(Java Virtual Machine). In an android environment, the process begins with the compilation of Java/Kotlin source code into the Java class file. The class files have the extension *.class and it contains the java byte-code(represents Java assembly). This compilation task is carried out by the javac and kotlinc compilers for the Java and Kotlin language code respectively.
2. Conversion into Dalvik bytecodes
The generated Java class(*.class) file in the previous step is executable on Java Virtual Machine(JVM) as it contains the standard Oracle JVM Java byte-codes. However, this code format is not suitable for Android devices and thus Android has its own unique byte-code format known as Dalvik byte-code. Dex compiler translates the Java byte-code into the Dalvik byte-code that are machine-code instructions for a theoretical processor. During the compilation process, dx command ties up all the .class files as well as .jar files together and creates a single classes.dex file that is written in Dalvik byte-code format. This file is now executable on the virtual machine in the Android operating system known as Android Runtime(or Dalvik Virtual Machine(DVM) for android version older than Kitkat(4.4)).
Java regular code:
public int addTwoNumbers(int a, int b) {
return a+ b;
}
Equivalent Java byte-code:
public int addTwoNumbers(int, int);
Code:
0: iload_1
1: iload_2
2: iadd
3: ireturn
Equivalent Dalvik byte-code:
.method public addTwoNumbers(II)I
.registers 4
.param p1, “a” # I
.param p2, “b” # I
.line 6
add-int v0, p1, p2
return v0
.end method
3. Generating .apk file
Resource files of the android application like images, fonts, XML layouts, etc. are transformed into a single compiled resource unit by the Android Asset Packaging Tool(aapt). The aapt tool is also responsible for creating the R.java file of an android application. Further, the compiled resource unit along with the classes.dex file is compressed by the apkbuilder tool and a zip-like file is created that is termed as Android Package(.apk file). The generated .apk file contains all necessary data to run the Android application.
4. App Distribution
The .apk file generated in the previous step is a ready-to-use application package and developers can use this file for the purpose of app distribution. However, to distribute and publish the application through Google Play Store, developers need to sign it. Android applications are required to be digitally signed with a certificate so that they can be installed by the users. The certificate is self-signed, and the Android uses it to identify the author of the application. The app developer/author holds the private key of the certificate and these all details are stored as an additional file in the android package(.apk file).
Oracle Java Development Kit(JDK) provides the jarsigner tool to sign the .jar files and .apk files. Further, the compressed parts of the signed .apk file are required to line up on byte-boundaries in such a manner so that Android OS can read them without uncompressing the file. The byte alignment of files is assured by running the signed .apk file through the zipalign tool.
Step 2: Deploy the Application
1. Establish the ADB Server
Android Debug Bridge(ADB) deploys an application to Android devices. It is a command-line tool that acts as an interface and facilitates developers to communicate with an android device. To start the deployment, the ADB client will first check whether the ADB server process is already running on the device. If there isn’t, the server process starts with the ADB command. The ADB server starts and binds with local TCP port 5037. All communication and commands are transferred from the ADB server to ADB clients using port 5037. Further, the server sets up a connection with all running devices. It scans all the ports and when the server detects an ADB daemon(adbd: a background process on emulator or device instance), it set up a connection to that port. The adbd process that matches on the android device can communicate with applications, debug them, and collect their log output.
2. Transfer .apk file to the Device
The ADB command transfers the .apk file into the local file system of the target Android device. The app location in the device file system is defined by its package name. For example, if the application package is com.example.sampleapp, then its .apk file will be located in the path /data/app/com.example.sampleapp.
Step 3: Run the Application
1. App launch request
Zygote process is the parent to all Android apps and it launches an application when a user makes the request to do so. The zygote is a special kind of Android OS process which enables code sharing between different instances that run across Android virtual devices(Dalvik/Android Runtime). Those resources, classes, and code libraries which possibly required by any application at runtime are preloaded in the memory space of the zygote process. Whenever the process gets a request to launch a new application, it forks itself(creates a copy) using the fork system call(android is a Linux system) and starts the new app. The preloaded libraries and resources are the reason for efficient and fast app launch in android.
2. Conversion of the .dex code to native OAT format
When a new application is installed, the Android optimize the app data and generates a corresponding OAT file. This file is created by the Android OS to accelerate the application loading time. The process to generate the OAT file starts with the extraction of classes.dex file present inside the .apk file of the application. The classes.dex file is placed in a separate directory and Android compiles the Dalvik byte-code with ahead-of-time(AOT, also abbreviated as OAT) compilation into native machine code. Android system uses this native OAT file to enhance the user experience by loading the application quickly and smoothly.
Before AOT came into the picture, dexopt tool is used to convert the .dex files into .odex file(optimized DEX) that holds the optimized byte-code. With the introduction of AOT in Android, dex2oat tool converts and optimize the .dex file into an OAT file format that holds machine code written in ELF format(Executable and Linkable Format). This native library is then mapped into the memory of the application process. OAT files are generally saved in the Android device in the directory: /data/dalvik-cache/
After following all these steps and procedures, the application will finally start and the initial activity of the app will appear on the device screen.
Contact Us