Anyone working on android development should know about Android architecture. The android application architecture is explained in detail in this section and it covers the android application framework and the resources that form the architecture for android applications.To develop android applications with eclipse Google provides the android development tools (ADT). ADT is set of plug- INS components and these components are extending the Eclipse IDE with android development capabilities. ADT provides all required functionality to create, compile, debug and deploy android applications from the Eclipse IDE and from the command line and it also provide an android device emulator because the android applications can be tested without a real android phone.
The major components of android architecture are
Android applications are written in the Java programming language. The Java source files are converted to Java class files by using the Java compiler. Android uses a “dx” tool and this tool helps to converts Java files into dex (Dalvik Executable) file. For each application the corresponding class files are compressed .dex file and redundant information in the class files are optimized in the .dex file. The dex files are smaller in size than the corresponding class files.
Eg: – The same string is found in different class files the .dex file consists of one reference of this string.
The dex file and the resources like images named XML files are packed into an android package called .apk file. This packaging operations are handled by a program called aapt (Android asset packaging tool). The .apk file includes all the necessary data for running the android applications and also it can be deployed to an android device through “adb” tool.
Applications are defined to Android via the android manifest file, located in the root of the Eclipse project definition (AndroidManifest.xml). An Android application is a collection of activities; an activity correlates to a screen or form that is presented to the user.
The components and settings of an android application are showed in the file AndroidManifest.xml.
Eg: – Activities and services of the application should be declared in this file.
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.temperature" android:versionCode="1" android:versionName="1.0"> <application android:icon="@drawable/icon" android:label="@string/app_name"> <activity android:name=".Convert" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> <uses-sdk android:minSdkVersion="9" /> </manifest>
For referring Java objects we are using the package attribute and the Java object lies within different package, it should be declared with the fully qualified package name. We can avoid collisions with other android applications by using reverse domain name as package name.
android:versionName: – It defines what the user sees and can be any string.
android:versionCode: – The version code should be an integer and this helps to show the version of your application. The versionCode perform an update of the applications for the existing installation. Normally the values start with ‘1’ and increase this value by one if we roll out a new version of our application.
<activity> tag: – This tag defines an Activity. In this example that points to the class com.j2eebrain.android.temperature Convert the package. An intent filter is registered for this class that defines this activity starts once the application starts (action android: name = “android.intent.action.MAIN”). The category definition of category android: name = “android.intent.category.LAUNCHER” defines that this application is added to the directory of the application in the Android device.
@string/app_name:- This value point to the resource file which includes the actual value of the application name. The resource file usage helps easy to provide different resources.
Eg: – Strings, colors, icons for different devices and makes it easy to translate applications.
R.java and Resources
The generated values are includes in the ‘gen’ directory in an android project. The generated class R.java includes the references to particular resources of the project and these resources should be defined in the ‘res’ directory and can be XML files, icons or pictures.
Eg: – define values, menus, layouts or animations through XML files.
We try to make a new resource the corresponding reference is automatically created in R.java through the Eclipse ADT tools and these references are static values and define ID’s for the resources. These ID’s are used to the android system and provides methods to access the corresponding resources.
Eg: – getString (R.string.yourString)) method helps to access a string with the R.string.yourString ID
The assets directory helps to store any kind of data and in Java we access this data through AssetsManager and the getAssets() method.
Activities and Layouts
The user interface for Activities is defined through layouts and this layout includes Views or widgets and their properties. Mainly the layout is defined as an XML file. We can also define through Java code.
The XML supported layouts are defined through resource file in the /res/layout folder and these file specifies the ViewGroups, Views their relationship and their attributes for this specific layout.
Reference to resources in the XML file
We can refer the resources through the ‘@’ sign.
Eg: – we want to refer to a color defined in the XML resource we refer through @ color/your_id or we defined a ‘hello’ string in an XML resource we access it through @string/hello.
Activities and Lifecycle
The android system defines a lifecycle for Activities through predefined methods. Mainly used predefined methods are,
We can restart Activity through the configuration change mechanism. The configuration change happens when an event is triggered which may be relevant for the application. In the emulator we can simulate the change of the orientation via CNTR+F11. The following Activity will not be restarted in case of orientation changes or position of the physical keyboard (hidden / visible).
<activity android:name=".ProgressTestActivity" android:label="@string/app_name" android:configChanges="orientation|keyboardHidden|keyboard"> </activity>
The android.content.Context class makes connections to the android system and it is the interface to global information about the application environment. It also provides access to android Services like Location Service. Activities and Services expand the Context class and can be used as Context.
The developers can access all framework APIs an manage phone’s basic functions like resource allocation, switching between processes or programs, telephone applications, and keeping track of the phone’s physical location.
This layer includes android libraries written in C, C++ and used by different system and these libraries show how to handle variety of data and are exposed to android developers through android application framework. The Android runtime layer which includes set of core java libraries and DVM (Dalvik Virtual Machine) is also located in same layer.
This layer contains the set of base libraries that are required for java libraries. Every Android application gets its own instance of Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently and it executes files in executable (.Dex) optimized for minimum memory. The Android system uses a special virtual machine, i.e. the Dalvik Virtual Machine to run Java based applications. Dalvik uses its own bytecode format which is different from Java bytecode. Therefore you cannot directly run Java class files on Android, they need to get converted in the Dalvik bytecode format.
This layer contains android memory management programs, security settings, power management software and several drivers for hardware, file system access, networking and inter-process-communication. The kernel also acts as an abstraction layer between hardware and the rest of the software stack.