As you’ve likely discovered by now, applications that run on Adobe AIR are distributed via AIR files. While the AIR file format is unique to Adobe AIR, it’s mostly made up of familiar parts. Here’s a quick tour of some of its salient features.
- AIR files are ZIP files. Note that the converse is not true; not every ZIP file is an AIR file. In general, any tool that can read ZIP files can be used to inspect, unpackage, etc. an AIR file. Making an AIR file, however, generally requires a purpose-built tool to handle the AIR-specific requirements.
- AIR files do not protect against discovery. That is, anyone with access to an AIR file can easily read its contents; there is no encryption of any kind. Individual files within the AIR file may be compressed, and typically are if they’re a text-based format to begin with. As noted in the previous point, that’s hardly a barrier to inspecting their contents. If you want further protection against discovery, you need to run your source through on obfuscater, etc., before packaging.
- AIR files do protect against tampering. An AIR file must contain a valid signature covering the entire contents of the file. If the signature isn’t valid then the file isn’t either. Signatures are stored in the W3C-recommended XML Signature format.
- AIR uses a naming convention to keep user-provided files separate from those required by the format itself. Format-specific files, such as the application descriptor and signature, are stored under the prefix META-INF/. (This convention is borrowed from the JAR file format.)
Most of the time you don’t need to know any of this, as your tools (adt, FlexBuilder, etc.) will do the heavy lifting for you. All the same, sometimes it’s fun to know what’s going on under the covers.