1. What is Android?

1.1. Android Operation System

Android is an operating system based on Linux with a Java programming interface. The Android Software Development Kit (Android SDK) provides all necessary tools to develop Android applications. This includes a compiler, debugger and a device emulator, as well as its own virtual machine to run Android programs. Android is officially guided by the Open Handset Alliance. In reality Google leads the project. Android allows background processing, provides a rich user interface library, supports 2-D and 3-D graphics using the OpenGL libraries, access to the file system and provides an embedded SQLite database.

1.2. Important Android components

An Android application consists out of the following parts:
Activity

represents the presentation layer of an Android application. A simplified (and slightly incorrect) description is that an Activity is a a screen which the user sees. This is slightly incorrect as Activities can be displayed as dialogs or transparent. An Android application can have several activities and it can be switched between them during runtime of the application. Views are user interface widgets, e.g. buttons or text fields. The base class for all Views is android.view.View. The layout of the Views is managed by subclasses of type android.view.ViewGroups. Views often have attributes which can be used to change their appearance and behavior. Services perform background tasks without providing an UI. They can notify the user via the notification framework in Android. ContentProvider provides an structured interface to data. Via a ContentProvider your application can share data with other applications. Android contains an SQLite database which is frequently used in conjunction with a ContentProvider to persists the data of the ContentProvider. Intents are asynchronous messages which allow the application to request functionality from other components of the Android systen, e.g. from Services or Activities. An application can call a component directly (explicit intent) or ask the Android system to evaluate registered components for a certain Intents (implicit intents). For example the application could implement sharing of data via an Intent and all components which allow sharing of data would be available for the user to select. Applications register themselves to an intent via an IntentFilter. Intents allow to combine loosely coupled components to perform certain tasks. BroadcastReceiver can be registered to receives system messages and Intents. BroadcastReceiver will get notified by the Android system if the specified situation

happens. For example a BroadcastReceiver could get called once the system completed its boot process or if a phone call is received. Widgets are interactive components which are primary used on the Android homescreen. They typically display some kind of data and allow the user to perform actions via them. For example a Widget could display a short summary of new emails and if the user select a email it could start the email application with the selected email.

Android provide much more components but the list above describes the most important ones. Other Android components are "Live Folders" and "Live Wallpapers". Live Folders display data on the homescreen without launching the corresponding application.

1.3. Security and permissions

During deployment on an Android device, the Android system will create a unique user and group ID for every Android application. Each application file is private to this generated user, e.g. other applications cannot access these files. In addition each Android application will be started in its own process. Therefore by means of the underlying Linux operating system, every Android application is isolated from other running applications. A misbehaving application cannot easily harm other Android applications. If data should be shared the application must do this explicitly, e.g. via a Service or a ContentProvider. Android also contains a permission system. Android predefines permissions for certain tasks but every application can also define its own permissions. An application must declare in its configuration file (AndroidManifest.xml) that it requires certain permissions. Depending on the details of the defined permission, the Android system will during installation either automatically grant the permission, reject it or ask the user if he grants these permissions to the application. If for example the application declares that is requires Internet access then the user need to confirm this during installation. This is called "user driven security". The user decides to grant a permission or to deny it. If the user does not want to give all permissions required by the application, this application cannot be installed. The check of the permission is only performed during installation, permissions cannot be denied or granted after the installation. Typically not all users check the permissions in detail but some users do and if there is something strange with them, they will write bad reviews on the corresponding Android markets.

2. Android Development Tools

2.1. What are the Android Development Tools?
Google provides the Android Development Tools (ADT) to develop Android applications with Eclipse. ADT is a set of plug-in which extended the Eclipse IDE with Android development capabilities. ADT contains all required functionality to create, compile, debug and deploy Android applications from the Eclipse IDE and from the command line. Other IDE's, e.g. IntellJ, are also reusing components of ADT. ADT also provides an Android device emulator, so that Android applications can be tested without a real Android phone.

2.2. Dalvik Virtual Machine

The Android system uses a special virtual machine, e.g. the Dalvik Virtual Machine to run Java based applications. Dalvik uses special bytecode which is different from Java bytecode. Therefore you cannot run standard Java bytecode on Android.

2.3. How to develop Android Applications

Android applications are primary written in the Java programming language. The Java source files are converted to Java class files by the Java compiler. Android provides a tool dx which converts Java class files into a dex (Dalvik Executable) file. All class files of one application are placed in one compressed .dex file. During this conversion process redundant information in the class files are optimized in the .dex file. For example if the same String in different class file is found, the .dex file is stored only once and reference this String in the corresponding classes. .dex files are therefore much smaller in size then the corresponding class files. The .dex file and the resources of an Android project, e.g. the images and XML files are packed into an .apk (Android Package) file. The program aapt (Android Asset Packaging Tool) perform this packaging. The resulting .apk file contains all necessary data to run the Android application and can be deployed to an Android device via the "adb" tool. The Android Development Tools (ADT) allows that all these steps are performed transparent to the user; either within Eclipse or via the command line.

If you use the ADT tooling you press a button or run a script and the whole Android application (.apk file) will be created and deployed.

3. Android Application Architecture

3.1. AndroidManifest.xml
An Android application is described in the file AndroidManifest.xml. This file must declare all Activities, Services, BroadcastReceivers and ContentProvider of the application. It must also contain the required permissions for the application. For example if the application requires network access it must be specified here. AndroidManifest.xml can be thought as the deployment descriptor for an Android application.
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="de.vogella.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>

The package attribute defines the base package for the following Java elements. It also must be unique as the Android Marketplace only allows application for a specific package once. Therefore a good habit is to use your reverse domain name as a package to avoid collisions with other developers.
android:versionName and android:versionCode specify the version of your application. versionName is what the user sees and can be any string. versionCode must be an integer and

the Android Market uses this to determine if you provided a newer version to trigger the update on devices which have your application installed. You typically start with "1" and increase this value by one if you roll-out a new version of your application. The tag <activity> defines an Activity, in this example pointing to the class "de.vogella.android.temperature.Convert". An intent filter is registered for this class which defines that this Activity is started once the application starts (action

android:name="android.intent.action.MAIN" ). The category definition category android:name="android.intent.category.LAUNCHER" defines that this application is added to the application directory on the Android device. The @string/app_name value refer to

resource files which contain the actual values. This makes it easy to provide different resources, e.g. strings, colors, icons, for different devices and makes it easy to translate applications. The "uses-sdk" part of the "AndroidManifest.xml" defines the minimal SDK version for which your application is valid. This will prevent your application being installed on devices with older SDK versions. defines the minimal SDK version your application is valid for

3.2. R.java, Resources and Assets

The directory gen in an Android project contains generated values. R.java is a generated class which contains references to resources of the res folder in the project. These resources are defined in the res directory and can be values, menus, layouts, icons or pictures or animations. For example a resource can be an image or an XML file which defines strings. If you create a new resource, the corresponding reference is automatically created in R.java. The references are static int values, the Android system provides methods to access the corresponding resource. For example to access a String with the reference id R.string.yourString use the method getString(R.string.yourString));. R.java is automatically maintained by the Eclipse development environment, manual changes are not necessary. While the directory res contains structured values which are known to the Android platform the directory assets can be used to store any kind of data. In Java you can access this data via the AssetsManager and the method getAssets().

3.3. Reference to resources in XML files

In your XML files, e.g. your layout files you can refer to other resources via the @ sign. For example if you want to refer to a color you defined as resources you can refer to it via @color/your_id or if you have defined a "hello" string as resource you can access it via @string/hello .

3.4. Activities and Layouts

The user interface for Activities is defined via layouts. At runtime, layouts are instances of android.view.ViewGroups . The layout defines the UI elements, their properties and their arrangement.

UI elements are based on the class android.view.View . ViewGroup is a subclass of the class View and a layout can contain UI components ( Views ) or other layouts ( ViewGroups ). You should not nestle ViewGroups too deeply as this has a negative impact on performance. A layout can be defined via Java code or via XML. You typically uses Java code to generate the layout if you don't know the content until runtime; for example if your layout depends on content which you read from the Internet. XML based layouts are defined via a resource file in the folder /res/layout . This file specifies the ViewGroups , Views , their relationship and their attributes for a specific layout. If a UI element needs to be accessed via Java code you have to give the UI element an unique id via the android:id attribute. To assign a new id to an UI element use @+id/yourvalue . By conversion this will create and assign a new id yourvalue to the corresponding UI element. In your Java code you can later access these UI elements via the method findViewById(R.id.yourvalue) . Defining layouts via XML is usually the preferred way as this separates the programming logic from the layout definition. It also allows the definition of different layouts for different devices. You can also mix both approaches.

3.5. Activities and Lifecycle

The operating system controls the life cycle of your application. At any time the Android system may stop or destroy your application, e.g. because of an incoming call. The Android system defines a life cycle for activities via pre-defined methods. The most important methods are:
onSaveInstanceState()

- called if the activity is stopped. Used to save data so that the activity can restore its states if re-started onPause() - always called if the Activity ends, can be used to release resource or save data onResume() - called if the Activity is re-started, can be used to initialize fields

The activity will also be restarted if a so called "configuration change" happens. A configuration change for example happens if the user changes the orientation of the device (vertical or horizontal). The activity is in this case restarted to enable the Android platform to load different resources for these configuration, e.g. layouts for vertical or horizontal mode. In the emulator you can simulate the change of the orientation via CNTR+F11. You can avoid a restart of your application for certain configuration changes via the configChanges attribute on your activity definition in your AndroidManifest.xml. 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>

3.6. Context
The class android.content.Context provides the connections to the Android system. It is the interface to global information about the application environment. Context also provides access to Android Services, e.g. theLocation Service. As Activities and Services extend the class Context you can directly access the context via this.

4. Installation
The following assume that you have already Eclip