Developing Android Applications with Adobe AIR

Chapter 1. AIR

Intelligence is the faculty of making artificial objects, especially tools to make tools.

—Henri Bergson

Adobe Integrated Runtime (AIR), initially code-named Apollo, was created in 2007 as an environment for building Rich Internet Applications (RIAs) running outside the browser while benefiting from desktop features. With AIR, developers can write desktop software using ActionScript, HTML, or JavaScript for the Windows, Macintosh, and Linux platforms. Each application is installed as a standalone client application; its proper execution requires that the AIR runtime be installed in the environment. Figure 1-1 shows the Apollo and AIR logos.

Figure 1-1. Apollo and AIR logos

AIR version 2.5 focused on mobile development and introduced new features such as geolocation capability, accelerometer capability, and multitouch inputs. AIR is targeted at smartphones as well as tablet computers and netbooks.

AIR 2.5 and later supports the Android platform. Android is an operating system based on the open source Linux platform. It was initially developed by Google, and was further expanded by the Open Handset Alliance for use with mobile devices. Android runs applications developed using the Java programming language and packaged as an Android Package (APK) file.

Adobe adapted AIR as a tool for ActionScript programmers to make Android applications. HTML/Ajax mobile development is not available for AIR for Android.

The purpose of this book is to teach you everything you need to know—and more—to develop AIR applications for the Android platform.

Beyond Android, the Adobe Open Screen Project has brought AIR to RIM for BlackBerry, and is committed to bringing it to other partners in the future. For more information on the Open Screen Project, go to http://www.openscreenproject.org/.

The premise of this effort is to offer a uniform tool for a fragmented mobile world. One could hope that AIR will be to mobile development what Flash Player is to the Internet. It enables ease of development and distribution of applications across platforms and browsers.

Installing the Adobe Development Tools

The Adobe development tools come in several forms: Flash Professional CS5.5 and Flash Builder 4.5. They support Android OS 2.2 (named Froyo) and later, as well as devices with an ARMv7 or higher processor. AIR for Android does not work with earlier versions of the Android system.

Flash Professional CS5.5

The latest version of Flash Professional comes with the AIR for Android extension bundled. No separate download or additional installation is needed. When you launch CS5.5 and select File→New, you will see an AIR for Android option under the General tab or an AIR for Android category under Templates.

Flash Builder 4.5

Burrito is the code name for the new version of Flash Builder, in public beta at the time of this writing. You can download Burrito from the Adobe Labs website at http://labs.adobe.com/technologies/flashbuilder_burrito/.

Burrito has templates for Flex Mobile and ActionScript Mobile projects.

Both products, Flash Professional and Flash Builder, include the AIR SDK and tools to automate deployment to devices. We will build our first AIR for Android application in Chapter 2.

Installing the AIR Runtime on an Android Device

The AIR runtime stores the native AS classes which an Android application can reference. It is invoked by your application when it launches. It only needs to be installed on the device once and is shared by all AIR applications.

Note

The AIR runtime is the C/C++ implementation of the Flash engine, rendering engine, and virtual machine.

The AIR runtime comes installed on some new Android devices, but not all. As with all applications installed on an Android device, the AIR runtime is packaged as an APK file. If you do not have Adobe AIR yet, search for it in the Android Market application on your device, download it, and install it. You will need it in the next chapter.

Future AIR updates will also be deployed via the Android Market to adapt to Android evolution. For instance, the AIR 2.6 runtime became available in February 2011 to run on Android 2.2 (Froyo), Android 2.3 (Gingerbread), and Android 3.0 (Honeycomb). It provides new features and performance improvements.

Using AIR on Android creates an additional layer on top of the platform, and communicates with it. You do not need to know the inner workings of this process, but being familiar with the Android system may be helpful. Chapter 3 will go over some of that.

What Is in the AIR SDK

The AIR SDK is the set of tools used to package and deploy your AIR application. It comes bundled in the tools, so no additional installation is needed. The tools take care of accessing these files without any development on your part.

The AIR SDK consists of the following:

AIR Developer Tool (ADT)

ADT is a multipurpose tool written in Java. It requires Java 1.5 or later, and is used to package the AIR application for Android devices. It creates a different package based on the target defined: apk for distribution, apk-emulator for the emulator, or apk-debug to debug locally or on the device. ADT creates the self-signed digital code certificate used to sign the application with an option to expand the validity period to conform to Android specifications. It installs, uninstalls, and launches the application on the Android device.

The ADT tool is called adt or adt.bat and is located in the bin folder. adt.jar is the executable file called by adt or adt.bat and is located in the lib folder.

AIR Debug Launcher (ADL)

ADL is used to test your AIR application during development without packaging it. It uses the runtime included in the SDK, and prints trace statements and runtime errors. It is also used to start a Flash Debugger (FDB) session.

The ADL tool is called adl or adl.exe and is located in the bin folder.

AIR runtime

The AIR runtime is used to launch and test your application during the development and debugging process, before you install the application on the device. It contains the emulator and device versions for both desktop and Android devices.

The AIR runtime is called Runtime.apk and is located in the runtimes folder.

Frameworks

The Frameworks directory includes all the AIR core libraries.

Adobe recently made available some documentation on using the command-line tool for ADT. We will cover these commands in Chapter 3. If you need an explanation or a refresher on using the command-line tool, please refer to Using the Command-Line Tool in Chapter 3.

New ActionScript Libraries

Many libraries were added to AIR 2.5 with a specific focus on mobile development. We will cover all of them in detail in the chapters to come. Here is a list of the new functionality and APIs, and the chapters in which they are discussed:

Chapter 2, Call Me, Text Me

• AIR application debugging on Android

• Simulation on the desktop

• URI schemes to invoke native Android applications

Chapter 4, Permissions, Certificates, and Installation

• Application icons

• Certificate validity

• Application permissions

• Application versioning

Chapter 5, Evaluating Device Capabilities and Handling Multiple Devices

• Screen orientation API

• System idle detection and overwrite

• New soft keys to register for keyboard events on the Android device

• Virtual keyboard

Chapter 7, Multitouch Technology

• Gestures

• Multitouch capability

Chapter 8, Accelerometer

• Accelerometer

Chapter 9, Camera

• Access to the device’s camera application

• Access to the device’s media library

Chapter 10, Geolocation

• Geolocation

Chapter 11, Microphone and Audio

• Access to the device’s microphone

Chapter 12, Video

• Camera video capture

Chapter 13, StageWebView

• StageWebView, used to render HTML content inside mobile AIR applications

• NetworkInfo

Chapter 14, Hardware Acceleration

• OpenGL ES 2 and hardware acceleration

Functionalities Not Yet Supported

Some features are not yet supported in AIR at the time of this writing, while others may not be planned as part of future releases. For instance, some APIs and features that are missing from AIR include those for activating the phone’s vibrate function via AIR, accessing the native Android contact list, creating Android intents, messaging to the status/notification bar, enabling one AIR application to open another, and creating widgets.

If you would like a specific feature added to AIR, send a request to Adobe at https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform.

AIR on the Desktop Versus AIR on Android

If you want to convert an existing AIR desktop application to Android, you must make a few changes:

• If you are using Flash Builder, the WindowedApplication application MXML tag needs to be changed to ViewNavigatorApplication. WindowedApplication assumes there is a NativeWindow, which is not the case on Android.

• In the Application descriptor, the namespace must be 2.6 or later and the visible tag must be set to true.

• The AIR SDK packaging command must use apk as the target.

The following desktop functionalities are not supported on Android:

ActionScript 2, ContextMenu, DatagramSocket, Dockicon, EncryptedLocalStore, HTMLoader, LocalConnection, NativeMenu, NativeWindow, PrintJob, SecureSocket, ServerSocket, StorageVolumeInfo, SystemTrayIcon, Updater, XMLSignatureValidator

Mobile Flash Player 10.1 Versus AIR 2.6 on Android

The Flash Player, version 10.1, first became available in Android 2.2 in June 2010. It runs within the device’s native browser. Developing applications for the mobile browser is beyond the scope of this book. However, understanding the similarities and differences between the two environments is important, especially if mobile development is new to you.

• Both types of applications are cross-platform rich media applications. They both use the ActionScript language, but AIR for Android only supports ActionScript 3.

• Both benefit from recent performance and optimization improvements, such as hardware acceleration for graphics and video, bitmap manipulation, battery and CPU optimization, better memory utilization, and scripting optimization.

• Applications running in the Flash Player browser plug-in are typically located on a website and do not require installation. They rely on the Flash plug-in. AIR applications require packaging, certificates, and installation on the device. They rely on the AIR runtime.

• Flash Player is subject to the browser sandbox and its restricted environment. The browser security is high because applications may come from many unknown websites. Persistent data is stored in the Flash Local Shared Object, but there is no access to the filesystem. AIR applications function as native applications and have access to local storage and system files. Persistent data may be stored in a local database. The user is informed upon installation of what data the application has access to via a list of permissions.

• AIR has additional functionality unique to mobile devices, such as geolocation, accelerometer capability, and access to the camera.

We will build our first application in the next chapter.