Introduction of Android

Many network-based or network-capable appliances run a flavor of the Linux kernel. It's a solid platform: cost-effective to deploy and support and readily accepted as a good design approach for deployment. The UI for such devices is often HTML-based and viewable with a PC or Mac browser. But not every appliance needs to be controlled by a general computing device. Consider a conventional appliance, such as a stove, microwave or bread maker. What if your household appliances were controlled by Android and boasted a color touch screen? With an Android UI on the stove-top, the author might even be able to cook something. In this case study, we see about the Android platform and how it can be used for mobile and nonmobile applications. History The Android platform is the product of the Open Handset Alliance, a group of organizations collaborating to build a better mobile phone. The group, led by Google, includes mobile operators, device handset manufacturers, component manufacturers, software solution and platform providers, and marketing companies. From a software development standpoint, Android sits smack in the middle of the open source world. The first Android-capable handset on the market was the G1 device manufactured by HTC and provisioned on T-Mobile. The device became available after almost a year of speculation, where the only software development tools available were some incrementally improving SDK releases. As the G1 release date neared, the Android team released SDK V1.0 and applications began surfacing for the new platform. To spur innovation, Google sponsored two rounds of "Android Developer Challenges," where millions of dollars were given to top contest submissions. A few months after the G1, the Android Market was released, allowing users to browse and download applications directly to their phones. Over about 18 months, a new mobile platform entered the public arena.

Features

1. Application framework enabling reuse and replacement of components 2. Dalvik virtual machine optimized for mobile devices 3. Integrated browser based on the open source Web Kit engine 4. Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional) 5. SQLite for structured data storage 6. Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF) 7. GSM Telephony (hardware dependent) 8. Bluetooth, EDGE, 3G, and WiFi (hardware dependent) 9. Camera, GPS, compass, and accelerometer (hardware dependent) 10. Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plug-in for the Eclipse IDE

The Android platform

With Android's breadth of capabilities, it would be easy to confuse it with a desktop operating system. Android is a layered environment built upon a foundation of the Linux kernel, and it includes rich functions. The UI subsystem includes: 1. Windows 2. Views 3. Widgets for displaying common elements such as edit boxes, lists, and drop-down lists Android includes an embeddable browser built upon Web Kit, the same open source browser engine powering the iPhone's Mobile Safari browser. Android boasts a healthy array of connectivity options, including WiFi, Bluetooth, and wireless data over a cellular connection (for example, GPRS, EDGE, and 3G). A popular technique in Android applications is to link to Google Maps to display an address directly within an application. Support for location-based services (such as GPS) and accelerometers is also available in the Android software stack, though not all Android devices are equipped with the required hardware. There is also camera support. Historically, two areas where mobile applications have struggled to keep pace with their desktop counterparts are graphics/media, and data storage methods. Android addresses the graphics challenge with built-in support for 2-D and 3-D graphics, including the OpenGL library. The data-storage burden is eased because the Android platform includes the popular open source SQLite database. Figure 1 shows a simplified view of the Android software layers. Figure 1. Android software layers

Application architecture
As mentioned, Android runs atop a Linux kernel. Android applications are written in the Java programming language, and they run within a virtual machine (VM). It's important to note that the VM is not a JVM as you might expect, but is the Dalvik Virtual Machine, an open source technology. Each Android application runs within an instance of the Dalvik VM, which in turn resides within a Linux-kernel managed process, as shown below. Figure 2. Dalvik VM

The following diagram shows the major components of the Android operating system. Each section is described in more detail below.

An Android application consists of one or more of the following classifications: Activities An application that has a visible UI is implemented with an activity. When a user selects an application from the home screen or application launcher, an activity is started. Services A service should be used for any application that needs to persist for a long time, such as a network monitor or update-checking application. Content providers One can think of content providers as a database server. A content provider's job is to manage access to persisted data, such as a SQLite database. If your application is very simple, you might not necessarily create a content provider. If you're building a larger application, or one that makes data available to multiple activities or applications, a content provider is the means of accessing your data.

Broadcast receivers An Android application may be launched to process a element of data or respond to an event, such as the receipt of a text message. An Android application, along with a file called Android Manifest.xml, is deployed to a device. AndroidManifest.xml contains the necessary configuration information to properly install it to the device. It includes the required class names and types of events the application is able to process, and the required permissions the application needs to run. For example, if an application requires access to the network to download a file, for example this permission must be explicitly stated in the manifest file. Many applications may have this specific permission enabled. Such declarative security helps reduce the likelihood that a rogue application can cause damage on your device.

Installation of Android
Process for how to install Android OS on Vega:

1. Build or download a console image for the Vega from the Angstrom Distribution.
2.

Build a patched kernel for Android. It is used the android .diff from Benno to patch the linux-rp-2.6.23 kernel of the Angstrom distribution. It had to do some minor tweaks in the patch to apply cleanly: I removed some Goldfish device specific parts. In the kernel configuration enable all Android specific options except the USB gadget and the QEMU / debug options.
3. Flash the console image and the patched kernel onto the device.

4. Extract the contents of the /data and the /system drives from the emulator using Busybox tar. Benno provides a busybox compiled for the emulator here. Make sure you get the device files as well. 5. Extract the ramdisk image of the emulator using gzip and cpio. 6. Build a directory tree of the Andoid software which mimics the emulator layout. Make sure to preserve the file ownerships and permissions from the tar archives. 7. 8. 9. Share this directory over NFS Connect your Vega to your host PC either with usbnet or wlan. Mount the NFS share on your Vega to /android

10. Copy the /dev/binder to /android/dev/binder. This was necessary because in the emulator the binder device had major number 252 while in the Vega it had 253. Make sure that the binder device has the mode 666. 11. Create a small script on your Vega as /android/a.sh with the following contents: #!/system/bin/sh

export PATH=/sbin:/system/sbin:/system/bin:$PATH export LD_LIBRARY_PATH=/system/lib export ANDROID_ROOT=/system export ANDROID_ASSETS=/system/app export ANDROID_DATA=/data export EXTERNAL_STORAGE=/sdcard export DRM_CONTENT=/data/drm/content mount -t proc proc /proc mount -t sysfs sysfs /sys
/system/bin/app_process

-Xzygote /system/bin --zygote & /system/bin/dbus-daemon --system & runtime 12. Create a small script on your Vega as /bin/a.sh with the following contents: #!/bin/sh umask 000 chroot /android /a.sh 1. 2. 3. 4. 5. 6. 7. Next steps: 1. 2. Execute /bin/a.sh as root on your Vega and hope for the best Current status: The system boots and the applications seem to work. Runs from an NFS share over a network connection. Keyboard input is working. Touchscreen is not working. No network connection yet for Android applications. Get the touchscreen to work. Set up networking.

3. Make it work from the flash file system as well. (JFFS2 does not support read-write memory mapped files, so we will need to use Yaffs, just like Google does.)

Security and Permissions

Android is a multi-process system, in which each application (and parts of the system) runs in its own process. Most security between applications and the system is enforced at the process level through standard Linux facilities, such as user and group IDs that are assigned to applications. Additional finergrained security features are provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad-hoc access to specific pieces of data.

Data Storage
1. Content Providers and Content Resolvers

A typical desktop operating system provides a common file system that any application can use to store files that can be read by other applications (perhaps with some access control settings). Android uses a different system: On Android, all application data (including files) are private to that application. However, Android also provides a standard way for an application to expose its private data to other applications through content providers. A content provider is an optional component of an application that exposes read/write access to the application's data, subject to whatever restrictions it might impose. Content providers implement a standard syntax for requesting and modifying data, and a standard mechanism for reading the returned data. Android supplies a number of content providers for standard data types, such as image, audio, and video files and personal contact information. For more information on using content providers, see a separate document, Content Providers. Whether or not you want to export your application's data to others, you need a way to store it. Android provides the following four mechanisms for storing and retrieving data: Preferences, Files, Databases, and Network.

Files
You can store files directly on the mobile device or on a removable storage medium. By default, other applications cannot access these files. To read data from a file, call Context.openFileInput() and pass it the local name and path of the file. It returns a standard Java FileInputStream object. To write to a file, call Context.openFileOutput() with the name and path. It returns aFileOutputStream object. Calling these methods with name and path strings from another application will not work; you can only access local files. If you have a static file to package with your application at compile time, you can save the file in your project inres/raw/myDataFile, and then open it with Resources.openRawResource (R.raw.myDataFile). It returns anInputStream object that you can use to read from the file.

Databases
The Android API contains support for creating and using SQLite databases. Each database is private to the application that creates it. The SQLiteDatabase object represents a database and has methods for interacting with it making queries and managing the data. To create the database, call SQLiteDatabase.create() and also subclass SQLiteOpenHelper. As part of its support for the SQLite database system, Android exposes database management functions that let you store complex collections of data wrapped into useful objects. For example, Android defines a data type for contact information; it consists of many fields including a first and last name (strings), an address and phone numbers (also strings), a photo (bitmap image), and much other information describing a person. Android ships with the sqlite3 database tool, which enables you to browse table contents, run SQL commands, and perform other useful functions on SQLite databases. See Examine databases (sqlite3) to learn how to run this program. All databases, SQLite and others, are stored on the device in

/data/data/package_name/databases.

Discussion of how many tables to create, what fields they contain, and how they are linked, is beyond the scope of this note, but Android does not impose any limitations beyond the standard SQLite concepts. We do recommend including an autoincrement value key field that can be used as a unique ID to quickly find a record. This is not required for private data, but if you implement a content provider, you must

include such a unique ID field. See the Content Providers document for more information on this field and the NotePadProvider class in the NotePad sample code for an example of creating and populating a new database. Any databases you create will be accessible by name to any other class in the application, but not outside the application.

Implementation of Antroid 1. Graphics

Android graphics are powered by a custom 2D graphics library and OpenGL ES 1.0 for high performance 3D graphics. The most common 2D graphics APIs can be found in the drawable package. OpenGL APIs are available from the Khronos OpenGL ES package, plus some Android OpenGL utilities. When starting a project, it's important to consider exactly what your graphical demands will be. Varying graphical tasks are best accomplished with varying techniques. For example, graphics and animations for a rather static application should be implemented much differently than graphics and animations for an interactive game or 3D rendering.

2. Audio and Video

The Android platform offers built-in encoding/decoding for a variety of common media types, so that you can easily integrate audio, video, and images into your applications. Accessing the platform's media capabilities is fairly straightforward you do so using the same intents and activities mechanism that the rest of Android uses. Android lets you play audio and video from several types of data sources. You can play audio or video from media files stored in the application's resources (raw resources), from standalone files in the filesystem, or from a data stream arriving over a network connection. To play audio or video from your application, use the MediaPlayerclass. The platform also lets you record audio and video, where supported by the mobile device hardware. To record audio or video, use theMediaRecorder class. Note that the emulator doesn't have hardware to capture audio or video, but actual mobile devices are likely to provide these capabilities, accessible through the MediaRecorder class.

3.Location and Maps

Location- and maps-based applications and services are compelling for mobile device users. You can build these capabilities into your applications using the classes of the android.location package and the Google Maps external library.

4. App Widgets
App Widgets are miniature application views that can be embedded in other applications (such as the Home screen) and receive periodic updates. These views are referred to as Widgets in the user interface, and you can publish one with an App Widget provider. An application component that is able to hold other App Widgets is called an App Widget host. The screenshot below shows the Music App Widget.

5. Bluetooth
The Android platform includes support for the Bluetooth network stack, which allows a device to wirelessly exchange data with other Bluetooth devices. The application framework provides access to the Bluetooth functionality through the Android Bluetooth APIs. These APIs let applications wirelessly connect to other Bluetooth devices, enabling point-to-point and multipoint wireless features. Using the Bluetooth APIs, an Android application can perform the following: 1. 2. 3. 4. 5. 6. Scan for other Bluetooth devices Query the local Bluetooth adapter for paired Bluetooth devices Establish RFCOMM channels Connect to other devices through service discovery Transfer data to and from other devices Manage multiple connections