Developing Android Applications with Adobe AIR [13]
Repackage your application with the emulator as a target. In Flash Professional, select File→AIR Android settings→Deployment→Emulator release. When using Flash Builder, enter the following command:
androidSDK/bin/adt -package -target apk-emulator -storetype pkcs12
-keystore yourCertificate.p12 hello.apk Main-app.xml Main.swf
In Flash Professional, the emulator launches the application automatically. In Flash Builder, install it on the emulator using the Android SDK:
androidSDK/platform-tools/adb install hello.apk
If you have the device attached and the emulator running, use either -d or -e before the install:
androidSDK/platform-tools/adb -e install Main.apk
You can read about the emulator in detail on the Android developer website, at http://developer.android.com/guide/developing/tools/emulator.html or http://developer.android.com/guide/developing/tools/othertools.html#android.
How Does AIR Run on Android?
The packaging of an AIR application includes the compiled .swf file, any necessary assets, and bootstrapping code. A bootstrapper is a simple program that activates a more complicated one.
An AIR application starts as any native application. This mechanism is similar to that for AIR desktop applications. The bootstrapper, which is a small piece of Dalvik (.dex), checks to see that the AIR runtime is installed. If it is not, it directs the user to get it.
The bootstrapper loads the Runtime library and invokes it, passing it to the application’s main .swf file. If more than one AIR application is running, the mechanism manages a shared copy of the runtime for all of them.
In some cases, code from the Runtime library also invokes OS functions in Dalvik, the Android virtual machine, and makes Java Native Interface (JNI) calls. It becomes a broadcast subscriber for the specific events related to the application’s permissions. It also interfaces with the system for screen display and input events such as gesture and keyboard inputs.
Starting AIR with intent
In the Android environment, applications or the browser can launch other applications and pass arguments to them. I demonstrated this in the example in Chapter 2. An application can receive arguments even if it is already running.
At the time of this writing, AIR applications cannot launch other applications, but they can be launched by others and capture arguments. To test this, install the Android Advanced Task Killer, a free application for listing running applications and then killing them, or making them active.
If your AIR application is launched by a native application, you can listen to the InvokeEvent.INVOKE event:
import flash.desktop.NativeApplication;
import flash.events.InvokeEvent;
NativeApplication.nativeApplication.addEventListener
(InvokeEvent.INVOKE, onInvoke);
function onInvoke(event:InvokeEvent):void {
trace(event);
trace(event.arguments);
}
Android development using Java is beyond the scope of this book, but this is what launching an application using intent would look like:
Intent myIntent = new Intent();
myIntent.addCategory(Intent.CATEGORY_LAUNCHER);
myIntent.setAction(Intent.ACTION_MAIN);
myIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
myIntent.setClassName("air.NAME_APP", "air.NAME_APP.AppEntry");
startActivity(myIntent);
AIR Access to Android APIs
The biggest limitation with AIR for Android at the time of this writing is that it cannot issue Android system notifications (such as notification bar updates), or communicate with other applications. There is also no widget support.
Some experiments have been done to try to overcome this and create a hybrid AIR–Java application for Android. Create two APK files, one with the Android SDK and one with the AIR SDK, then merge them together.
Set up a mechanism such as a network socket for the two processes to communicate at runtime. The ip and port must be the same. AIR sends messages over sockets to Java to show notifications.
This is not public, nor is it official (at the time of this writing). Expect to read about some developments regarding this,