Posts in Category "AIR"


As part of this week’s restructuring at Adobe, I’m moving to a new role on the Creative Cloud team. Thank you to everyone who has followed my ramblings here on various things AIR-related. While I don’t plan to continue to post further on AIR, I do plan to write about various things Creative Cloud-related as the project moves forward. I hope you’ll consider continuing to read.

Oliver Goldman

AIR Native Extensions, ByteArray, and BitmapData

[Note: Updated on October 11, 2011 to note that multiple ByteArrays or BitmapDatas can be acquired at the same time in the AIR 3 implementation. —Oliver]

The new-to-AIR 3 native extensions capability includes not only a general-purpose API for manipulating ActionScript objects from native code, but also fast-path APIs that allow direct access to ByteArray and BitmapData objects.

Using these APIs, native code can get direct access to the memory that sits behind a ByteArray or BitmapData—no copies, no translations. In order to achieve that, native applications have to declare when they want access via an acquire call, and when they’re done via a release. In between the two, we restrict access to the rest of the API in order to guarantee the pointer that’s returned remains valid.

Furthermore, it’s possible to acquire two or more byte arrays or bitmaps at the same time so long as there no intervening calls to the rest of the API. This can be used, for example, to take image as an input for a filter and write directly to a second as the output.

As always, if you have ideas for enhancements to this and other features, you can vote for them at

See the Native Extensions documentation for more on working with ByteArray and working with BitmapData.

MAX 2011 Follow-up

Thanks to all of you who attended my MAX talks earlier this week! I had a great time presenting, and always enjoy the chance to meet people in person.

Slides and video of my Adobe MAX 2011 presentations are now available online. The two talks are largely the same, with some mobile- versus desktop-specific details appearing in the last 15 minutes or so of each.

How to Extend Your Mobile AIR Applications Using Native Extensions: video on Adobe TV, and slides on

How to Extend Your Desktop AIR Applications Using Native Extensions: video on Adobe TV, and slides on


New Installation and Deployment Options in AIR 3

It is with great pleasure (and a little bit of relief) that I report that AIR 3 will deliver new and much improved installation and deployment options for the desktop. These options enable installation without administrative rights, GPO-based deployment of AIR applications, XCOPY deployment, run-in-place from flash drives, tight binding to specific versions of AIR, and more.

These advantages arise from two new key capabilities:

  1. Captive runtimes. Already used on iOS, this capability allows a copy of the AIR runtime to be embedded with each AIR application. This capability is now supported across Mac OS, Windows, and Android, too.
  2. Custom installers. The application packaging tool, adt, can now be used to generate an application’s file set instead of a complete installer. The file set is a complete copy of the application, capable of being run in place. Or, you can package it up in your own custom installer, whether that’s an MSI for GPO, a PKG for Mac OS, or something else.
For a more comprehensive overview, please see Installation and Deployment Options in AIR 3 on the Adobe Developer Connection.

AIR Native Extensions Samples Available

In conjunction with today’s announcement of AIR 3, we have now posted a Native Extensions for Adobe AIR page on the Adobe Developer Connection. It currently lists four extensions available for download from both Adobe and our developer community. We’ll post more here as they become available.

And, a reminder that there’s still time to register for Adobe MAX 2011. It’s a great place to find out about all of the new AIR 3 and Flash Player 11 features, including native extensions.


Disabling AIR Certificate Revocation Checks During Silent Install

Here’s a quick tip that doesn’t seem to be covered in the administrator’s guide for AIR, although it likely should be: You can control how revocation checks are performed during silent installs via the -revocationCheck flag.

When digital signatures are validated, one step in the process involves checking to see if the certificate used to sign has been revoked. This is how certification authorities defend against stolen certificates: they revoke stolen certificates by publishing them in a revocation list; software that validates signatures then checks those lists.

Revocation lists are published to web servers at URLs embedded in the certificates themselves. In order to check the lists, they need to be downloaded. This gives rise to a number of potential questions, like what to do when you are offline and can’t download the latest version. One needs to make a policy decision to answer such questions.

The -revocationCheck flag accepts four values, one for each supported policy:

  • never Don’t check the list, period. No network requests will be issued. (More on this below.)
  • bestEffort Look for a revocation list, but if something goes wrong other than the certificate being revoked, proceed on the assumption that everything is ok.
  • requiredIfInfoAvailable Assuming you can fetch the revocation list, then fail if any later errors occur. But if you can’t download the list at all, proceed as for bestEffort.
  • alwaysRequired If the revocation list can’t be checked without error, don’t proceed.

AIR defaults to “bestEffort”. That’s typically a reasonable choice, and it has the advantage of working both online and offline. But it does mean that for most installations, the AIR installer will at least attempt to issue a network request to download the list. (Lists are also cached, so you won’t always see the request, however.)

Now, there’s one particular case where “never” is a handy setting: Silent installation behind an HTTP proxy that requires authentication. In this situation, so long as AIR issues a network request, the OS will typically pop up a proxy authentication dialog, which of course halts the installation flow and requires manual intervention. To work around it, simply add “-revocationCheck never” to your command line arguments.

Using a Cross-Platform Runtime to Build Better Apps

The inherent advantage of using a cross-platform runtime, such as AIR, to develop applications is typically understood to be the boost in productivity that’s achieved by reducing the amount of per-platform work that’s required. While it’s true this is a potential advantage, it’s generally discussed with an implicit assumption that the developer is interested in reducing the development cost.

Suppose, for moment, that this is not the case. If you spend just as much on development as you did before and use a cross-platform runtime, then what happens? You build better apps.

The key is to take all the time you saving writing code once and apply the savings elsewhere in your application. That could be to additional features. Or it could be a better experience: improved responsiveness, more intuitive UI, lower memory use. No matter how you spend this savings, you build a better app.

Perspective on the AIR 2.7 Release

Yesterday we shipped the AIR 2.7 release. Although a relatively minor release in the grand scheme of things, this one is an important milestone for the Flash Runtime. It marks the culmination of an enormous effort over the past two years to bring AIR to mobile devices.

It has not been a straightforward path. Our first work targeted the first generation iPhone, which included a couple of major challenges. First we had to craft an alternate compilation strategy for ActionScript, since using just-in-time compilation, our usual strategy, was not permitted. Then we had to try to achieve reasonable performance on what was a slow device.

Further bumps along the way included scrambling to support the iPad, being forced off of iOS entirely, and switching our focus to the quickly-evolving Android platform. For all their similarities, Android and iOS often taken different approaches under the covers which made, and continues to make, the creation of cross-platform APIs a real challenge.

Of course, bringing AIR to iOS and Android wasn’t simply a matter of porting the code, either. We also added a variety of new APIs to accommodate the different features found in mobile devices. That list includes major additions like Geolocation, Accelerometer, CameraUI, CameraRoll, and StageWebView. Smaller enhancements supported screen orientation, soft keyboards, and other mobile-specific capabilities.

For me, the 2.7 release brings us to an important milestone. AIR is now clearly a viable platform for building applications across the PlayBook, Android, and iOS, with thousands of AIR-based applications available in various marketplaces. We’ve rounded out a basic set of mobile-specific APIs, and, with the iOS performance enhancements in this release, eliminated performance as a barrier to adoption. Moving to mobile was a mad scramble; now we’re there.

With 2.7 out the door, we’re shifting our attention from merely moving to mobile to pushing the envelope. That AIR is a cross-platform runtime is no reason for us to compromise on capabilities, performance, or tools, and you’ll see that in our upcoming releases. The technologies that will drive the next generation of AIR are already in the works, running here behind closed doors. We look forward to sharing these with you in the months to come.

Platform Parity and Scalability

Confession: We’ve made a bit of a mess for ourselves in the application descriptor.

(For those not familiar with the application descriptor, it’s a short XML document that’s a required part of any AIR application. It provides essential information like the application’s unique ID and version, plus a variety of optional settings covering everything from screen orientation behavior to application marketplace filtering. It’s roughly analogous to Info.plist on Mac OS and iOS, and AndroidManifest.xml on Android.)

In AIR 1.0, we strived to keep this descriptor purely cross-platform. We almost achieved that goal, but compromised a bit with the <programMenuFolder> setting. That setting allows an AIR app to control, on Windows, where it appears in the Start Menu. Customers told us it was essential.

When we added iOS support in AIR 2.0, we realized that there was a host of options, accessible via the iOS Info.plist file, that we wanted developers to have access to and yet didn’t have any cross-platform analogue. That was hardly surprising at the time, since iOS was the first mobile platform we supported.

So, we decided to add an escape hatch: the <iPhone> element. (Why not <iOS>? Because this was before iPhone OS became iOS.) It contains iOS-specific settings, including arbitrary additions to the Info.plist file.

When we added Android support, we extended this in the obvious way, adding an <android> element with similar capabilities.

Now, about this time was when we realized we had a problem. Our list of supported platforms is continuing to grow, but adding new elements to the descriptor for each one isn’t a scalable approach. In particular, it requires that Adobe modify the descriptor schema each time a new platform comes online, rather than enabling our platform partners to make these additions on their own. Our partners don’t want to have to wait for us for such a change, and we don’t want to have to make them wait, either.

As we worked with RIM to bring AIR to the PlayBook, we asked RIM to help us fix this and store PlayBook-specific settings in a separate file, outside the application descriptor. This approach is easily scalable, as it’s trivial for each platform to add its own file. And it’s easier to use then open-ended extensions in the application descriptor itself, which can get tricky when storing XML in one schema inside XML in another schema.

At the moment, the unfortunate result of this mess is that PlayBook might appear to be a second-class citizen, in that it doesn’t get its own element in the descriptor. This is not at all the case. On the contrary, PlayBook is the first platform to move to our preferred mechanism. It’s iOS and Android that are stuck with the older, more awkward mechanism.

Although I can’t speak to the timing, as it’s not yet determined, we will be moving platform-specific settings for all platforms, including iOS and Android, to external files in the future. Then we’ll finally be where we should have been heading from the beginning: Parity between platforms, in a scalable fashion.

Unique Device Identifiers on AIR Mobile

Application developers frequently want a mechanism by which they can track a device’s identity. Such a value is frequently used in conjunction with copy protection schemes to, for example, limit the total number of devices on which a user can view purchased content.

AIR ostensibly does not include an API for obtaining such an identifier. Such an API would be straightforward to implement on iOS, since iOS itself provides an identifier that can be used for this purpose. However, on Android, no such facility is provided. Seems surprising to some, but even the Android team agrees.

How to work around it? I recommend using Math.random() to generate an ID on first launch and save it locally. It’s portable, and does a better job of protecting user privacy than the iOS device identifier does. Of course it can be reset, but then users also sometimes lose or dispose of devices, so any scheme needs a mechanism to flush old device IDs from the system as “no longer in use.”