If you want users to be able to move your AIR for Android application to the SD card, all you have to do is modify the android manifest section of your application descriptor. If you want your application to be installed on internal storage by default, but allow users to move it to the SD card, set
android:installLocation to "
auto" like this:
If you want your application to be installed on external storage by default (which the user can override), set the
android:installLocation to "
preferExternal" like this:
And finally, if you don’t want to give users an option of where to install your application (not sure why you’d do this, but you can), just leave the
android:installLocation attribute out entirely.
For more details, see the App Install Location section of the Android docs.
I recently uploaded an application called AIRBench to the Android Market which is designed to compare Adobe AIR performance across devices. We test AIR across as many different devices with as many different configurations as we can, of course, but there are so many different permutations out there now that we decided to release an app to help us understand how different devices compare to each other.
AIRBench performs two types of tests: capability and performance. Capability tests just ensure that a particular API works, and performance tests determine how well your device performs a particular task. Below is a breakdown of all the tests included in the first version of AIRBench:
- Camera: calls
Camera.getCamera() and displays the video feed.
- CameraUIImageTest: Makes sure you can take a picture using the
- CameraUIVideoTest: Makes sure you can record video with the
- CameraRollAddTest: Adds an image to the camera roll.
- CameraRollBrowseTest: Tests the ability for the user to browse the camera roll and choose an image.
- GeolocationTest: Makes sure geolocation data can discovered.
- AccelerometerTest: Makes sure the
Accelerometer APIs work.
- MultitouchTest: Has the user place as many fingers on the screen as
Multitouch.maxTouchPoints reports, and makes sure those two numbers are equal.
- MicrophoneTest: Makes sure sound can be detected from the microphone. (Watch out for interference on this one.)
- StageWebViewTest: Loads an HTML page into a
- XMLTest: Parses a pretty big XML file (74K) and reports the time. (It’s my Google Reader feed copied several times.)
- MemoryAllocationTest: Creates a
ByteArray and sets it length to 8MB, then reports the amount of time it took.
- FileAccessTest: Creates a file, writes 1MB of data, reads the file, then deletes the file. Reports the total time.
- SQLTest: Creates a new database, creates a table with 5 columns, inserts 500 rows of data, runs a select statement, deletes all the data, and closes the connection. Reports the total time.
- StringTest: Runs 9 different string operations on a very big string and reports the total time.
- ComputationTest: Hashes a 49K image using SHA256 (to test bitwise operations), then calculates sunrise and sunset times for 10 different locations (Adobe offices) 100 times (to test math operations).
- RenderingTest: Animates a square, changing the rotation, scale, and alpha at 60 frames per second. Measures the FPS after a few seconds and reports the number of frames dropped. (Note that this version of the test does not use hardware acceleration — that will be tested in a future test.)
Tests are versioned, so I’ll release new and better tests as we add new capabilities to the runtime, and as I have time to make improvements. Results can be submitted to Adobe (completely anonymously), and once I get back from MAX, I’ll write a series of reports for everyone to check out at airbenchmark.com.
If you want to help contribute data to the AIRBench database, just search for AIRBench in the Android Market, run through the series of tests, and submit the results. AIRBench serves a second purpose by providing a simple demonstration of how all the device-specific APIs work, so if you’re interested in doing some AIR mobile development, check out the code.
I recently started playing around with GPU rendering in AIR for Android, and I decided to do a quick video demonstrating the differences between CPU and GPU rendering modes.
The code for this example is available here on GitHub.
As you can see from the example application, the key to offloading rendering to the GPU is to do three things:
1. Set rendering mode to GPU in your application descriptor like this:
2. Make sure
cacheAsBitmap is set to true on your
DisplayObject like this:
square.cacheAsBitmap = true;
3. Make sure to assign a
Matrix to the
cacheAsBitmapMatrix property on your
DisplayObject like this:
square.cacheAsBitmapMatrix = new Matrix();
That’s all you have to do to offload your rending to the GPU and to free your CPU up for more important tasks.
In my recent Packager for iPhone Refresher, I left something out which several people have been asking for: how to deploy your iOS application to an iPad rather than an iPhone or iPod touch. We stopped development on PFI before we could really dig into the iPad, but now that we’re back to developing AIR for iOS, I figured I should go ahead and post instructions.
There are two things you need to do:
1. Add metadata to your application descriptor.
Just add the following to your application descriptor at the top level (as a child of <application>):
2. Include a 72×72 icon.
Rather than the 57×57 pixel icon you would use with a pre-retina display iPhone or iPod touch, use a 72×72 pixel icon like this:
That’s it. Your app is now ready for the iPad.