Android SDK Features

The true appeal of Android as a development environment lies in the APIs it provides.

As an application-neutral platform, Android gives you the opportunity to create applications that are as much a part of the phone as anything provided out of the box. The following list highlights some of the most noteworthy Android features:

Android includes API libraries to simplify development involving the device hardware. These ensure that you don’t need to create specific implementations of your software for different devices, so you can create Android applications that work as expected on any device that supports the Android software stack.

The Android SDK includes APIs for location-based hardware (such as GPS), camera, network connections, Wi-Fi, Bluetooth, accelerometers, touch screen, and power management. You can explore the possibilities of some of Android’s hardware APIs in more detail later in this blog.

Native map support lets you create a range of map-based applications that leverage the mobility of Android devices. Android lets you create activities that include interactive Google Maps as part of your user interface with full access to maps that you can control programmatically and annotate using Android’s rich graphics library.

Android’s location-based services manage technologies like GPS and Google’s GSM cell-based location technology to determine the device’s current position. These services enforce an abstraction from specific location-detecting technology and let you specify minimum requirements (e.g., accuracy or cost) rather than choosing a particular technology. It also means that your location-based applications will work no matter what technology the host handset supports.

To combine maps with locations, Android includes an API for forward and reverse geocoding that lets you fi nd map coordinates for an address, and the address of a map position.

You’ll learn the details of using maps, the geocoder, and location-based services later in this blog.

Modern mobiles are by nature multifunction devices; however, their limited screen size means that generally only one interactive application can be visible at any time. Platforms that don’t support background execution limit the viability of applications that don’t need your constant attention.

Background services make it possible to create invisible application components that perform automatic processing without direct user action. Background execution allows your applications to become eventdriven and to support regular updates, which is perfect for monitoring game scores or market prices, generating location-based alerts, or prioritizing and pre-screening incoming calls and SMS messages.

Android provides a lightweight relational database for each application using SQLite. Your applications can take advantage of the managed relational database engine to store data securely and efficiently.

By default, each application database is sandboxed — its content is available only to the application that created it — but Content Providers supply a mechanism for the managed sharing of these application databases.

Android includes three techniques for transmitting information from your applications for use elsewhere: Notifications, Intents, and Content Providers.

Notifications are the standard ways in which a mobile device traditionally alerts users. Using the API, you can trigger audible alerts, cause vibration, and flash the device’s LED, as well as control status bar notification icons.

Intents provide a mechanism for message passing within and between applications. Using Intents, you can broadcast a desired action (such as dialing the phone or editing a contact) system-wide for other applications to handle. Intents are an important core component of Android.

Finally, Content Providers are a way to give managed access to your application’s private database. The data stores for native applications, such as the Contact Manager, are exposed as Content Providers so you can create your own applications that read or modify these data stores.

Based on earlier SDK versions, it’s expected that in later releases you will once again be able to send structured messages from your application to any other Android mobile using Android’s peer-to-peer (P2P) communications service.

The Android P2P service uses a specialized version of XMPP (Extensible Messaging and Presence Protocol). Based on Google’s Google Talk instant messaging service, it creates a persistent socket connection between your device and any other online Android handset that ensures communication with low latency and rapid response times.

When made available, you’ll be able to use the Google Talk service for conventional instant messaging, or an interface to send data between application instances on separate devices. This is strong sauce for creating interactive applications that involve multiple users, such as real-time multiplayer games or social applications.

The P2P service also offers presence notification, which is used to see if a contact is online. While the P2P service is very attractive in itself, it also plays very well with other Android features. Imagine a background service that transmits locations between friends and a corresponding mapping application that displays these locations or alerts you when friends are nearby.

Owing to security concerns, sending data messages with Google Talk isn’t possible in Android 1.0. An instant messaging client is available, and it’s expected that XMPP-compatible IM and data messaging will be made available to developers in a future SDK release.

Bigger screens and brighter, higher-resolution displays have helped make mobiles multimedia devices. To make the most of the hardware available, Android provides graphics libraries for 2D canvas drawing and 3D graphics with OpenGL.

Android also offers comprehensive libraries for handling still images, video, and audio fi les including the MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, and GIF formats.

Android’s process and memory management is a little unusual. Like Java and .NET, Android uses its own run time and virtual machine to manage application memory. Unlike either of these frameworks, the Android run time also manages the process lifetimes. Android ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications.

In this context, priority is determined depending on the application with which the user is interacting. Ensuring that your applications are prepared for a swift death but are still able to remain responsive and update or restart in the background if necessary, is an important consideration in an environment that does not allow applications to control their own lifetimes.