21 September 2011
AIR 3 includes new options for deployment and installation of the AIR runtime and of AIR applications, both on mobile devices and on the desktop.
The new captive runtime option supports installation of AIR applications on Android devices without the need for a separate install of the AIR runtime.
On the desktop, the new custom installer capability enables development of AIR applications that run in place, install and update without admin privileges, and more.
Taken together, these two items represent a significant enhancement to the installation and deployment options available to AIR developers.
Prior to AIR 3, the AIR runtime was generally deployed as a separate install, distinct from any applications that depended on it. On the desktop, a unified installation UI could be used to make it appear as if a single installation was occurring, but under the hood, this was not the case. For example, after such an installation process, AIR can be separately uninstalled from the computer, leaving the application that depends on it in place but inoperable.
Starting with AIR 3, publishers have the option of including a captive copy of the runtime with their application installation package. This copy is used exclusively by the associated application, and always installs and uninstalls as part of the application itself.
Using a captive copy of the runtime has a number of advantages:
- Complete control over the version of AIR bound to the application. Unlike a shared installation, the captive runtime cannot be updated unless the application itself is updated. While Adobe strives for maximum compatibility when updating AIR, this approach nonetheless eliminates the risk that an update to AIR will break a deployed application.
- Simplified installation workflow. Although this can be largely addressed on desktop platforms via the unified installation UI, on Android no such unified UI was available. Using a captive runtime removes the need for users to download and install AIR as a separate application.
- Simplified distribution to multiple application stores. When an Android application is deployed to multiple marketplaces (for example, the Google Android Market and the Amazon App Store), it must send the user back to the same store to download AIR if required. In order to implement this, a different copy of the application, configured with the correct download URL, must be uploaded to each marketplace. By eliminating the need for the download, the need for a custom package is also removed.
- Creation of custom installers. The captive runtime option is required for applications that require custom installers for the desktop. This is covered in more detail, below.
Anyone using the captive runtime should be aware that it has two downsides:
- Increased application size. Since an entire copy of the runtime is included in your application, the size of the application package is necessarily increased.
- Increased security burden. When applications used the shared installation of AIR on a device, they can rely on the AIR auto-update mechanism to make sure the runtime is always up-to-date. The auto-update mechanisms do not apply to the captive runtime. If you use the captive runtime, you must repackage and update your application each time you need to pick up a new version of AIR. Because new releases always include security enhancements, application developers are encouraged to update their application every time AIR is updated.
To create Android applications with a captive runtime, simply change your target option in the adt packaging command from
adt -package -target apk-captive-runtime ...
Note that the captive runtime is the only option that is available when using AIR to target iOS. Since iOS does not support a shared runtime model, the captive model remains the only option on this platform.
To use a captive runtime with a desktop application, use the new custom installer option described in the next section.
Originally AIR applications were all deployed in AIR files, which are ZIP-based, cross-platform packages. In AIR 2, developers gained the option of deploying their applications using native installation packages: a self-extracting executable on Windows, and a DMG on Mac OS X. These two options cover many use cases, but not all of them.
In AIR 3, developers have the additional option of creating their own installers for their applications. These installers are similar to the native installation packages added in AIR 2, in that they result in an application that runs in the extended desktop profile and can leverage the NativeProcess API and native extensions. However, these installers are produced directly by the AIR packaging tool, adt.
adt supports this new option by creating the set of files that is the input to the installer creation process. Borrowing from Mac OS X terminology, we call this set of files a "bundle" and expose it as a new adt target:
adt -package -target bundle ...
The resulting set of files is a complete AIR application, including a captive copy of the AIR runtime. It can then be packaged as an installer using several different approaches.
The simplest approach requires no additional work at all. Since AIR application bundles require no additional setup, the application can be run in place. On Mac OS X, the bundle is an Application bundle; simply double-click it to execute the application. (In Finder, it will appear as a single file, as do all other Mac OS X applications.) It can also be installed by simply dragging-and-dropping it into the applications folder.
On Windows, the application can be run by launching the executable file in the root bundle directory. You can't move the executable relative to the other files, but you can mark the other files in the directory as hidden to simplify the view for anyone viewing the application in Explorer.
For both Mac OS X and Windows, this capability can be used to create applications that run directly off of CDs, flash drives, or other media. All you have to do is keep the directory structure and file permissions intact.
Note that the captive runtime is key to making all of this work: Because it's embedded with the application, it's always available. There's no need to be concerned with a separate install, downloading the runtime, or making sure it's up-to-date.
As useful as run-in-place can be, sometimes a bit of packaging or logic is appropriate for application deployment.
On Mac OS X, this often takes the form of a DMG that is used to distribute the application image. Note that, among other things, the DMG file format preserves the directory structure, symbolic links, and file permissions that constitute the application even when copied to non-Mac OS X systems. This is why DMG files are used for Mac OS X application distribution.
You can create a DMG manually via Disk Utility, or script the creation of one with the hdiutil command line utility. Either way, simply include the application bundle in your DMG image.
On Windows, applications are frequently distributed as MSI files, which can be installed and managed via Windows Installer. You can use a variety of commercial tools, such as InstallShield, to create MSI files. Also worth a look is the open-source Windows Installer XML toolset, WiX.
Note that you can modify the bundle contents before packaging. Of course, certain changes will break the application. For example, if you remove the main SWF, the application isn't going to run anymore. On the other hand, this can be quite useful if you want to modify an application's Info.plist entries on Mac OS X, or make other similar tweaks.
There are some situations in which more needs to be done at install time: Perhaps installing other pieces of software at the same time, modifying registry entries or installing services, and so on. Here again, AIR bundles can be integrated with platform installation technologies.
On Mac OS X, advanced installers can be created with the PackageMaker tool. It supports installing multiple pieces of software at once, running scripts during installs, and so on. AIR applications be incorporated directly into larger packages containing other files and software. Or, they can be placed in their own packages, and then those packages leveraged in a multipackage installation.
On Windows, other files and software can be incorporated into the application's MSI file. Alternatively, AIR applications can be placed in MSI merge modules (MSM). MSM files can then be distributed to other teams building product installers and merged into the final MSI package. Finally, installation of multiple MSI files, or even custom install logic, can be orchestrated via a "bootstrapper" program, which is a custom application that uses Windows Installer to install software.
When designing an installer, one has the option to choose from approaches that may or may not require administrative privilege. For example, a drag-and-drop install on Mac OS X requires no special privilege; users can always copy the application into their own application folders, for which they have the necessary permissions. On the other hand, if registry keys must be written to the machine-specific portion of the registry on Windows, installation of that application will require administrative privilege to do so.
The two installer formats directly supported by AIR, AIR files and native installers, have always required administrative privilege. This was a design decision made in part to simplify the implementation of the AIR installers: If administrative privilege is assumed to be available, implementation is possible if the registry can be written to, and so on. It was also selected because, in many enterprises, this is the desired behavior: administrators can use the privilege requirement to gate software installation.
All the same, there are scenarios where supporting installation without requiring administrative privileges is desirable, or even necessary. This can now be achieved using custom installers; you simply need to author an installer that operates correctly with only standard user privilege. In practice this can be easy to achieve; a simple install-by-copy to a writable location (that is, in the user's own folder) will suffice. Should you author a more complex installer, you should keep in mind that the addition of certain operations during the install process will in turn reintroduce the requirement for administrative privileges.
While AIR applications packaged as bundles don't require any additional install-time support, this can result in a couple of capabilities that require registry entries to be modified not to function: registering for file extensions and registering to launch at startup.
If your application needs these capabilities, equivalent functionality (although not the built-in API support) can be restored by adding the appropriate settings to your custom-built installer. Most installer creation tools will have specific support for these items, or at least an escape mechanism that allows the creating the registry entries required for these functions. Consult the Microsoft documentation for which entries to add.
You can also integrate your application with the system in ways that the installers created by AIR do not support. For example, your installer can register a custom URL scheme to your application, which is not otherwise possible with AIR. (When the application is invoked in this way, it will receive an
InvokeEvent, just as it does when started via other methods.)
As noted above, consider to which portion of the registry you write any such settings. If you write them to the machine-specific portion (HKLM) instead of current user (HKCU), then your installer will typically require administrator privileges.
When using bundles to deploy your application, you necessarily take on responsibility for updating your application and the captive copy of the AIR runtime that it contains. Since updates to AIR always include security enhancements, you are encouraged to repackage and update your application each time AIR itself is updated.
Note that this does not necessarily mean that you need to implement your own auto-update mechanism. If you use a commercial tool to create your installer, it may include auto-update mechanisms that you can leverage. On the other hand, if you do need to write your own update mechanism, you should find the URLStream, File, and NativeProcess APIs handy in implementation.
Note that AIR does still include auto-update functionality for applications deployed as AIR files. However, an update mechanism must have a priori knowledge of the installation mechanism in use in order to function. Since the option to use a custom installer necessarily implies that no such knowledge is available in AIR itself, these two approaches remain incompatible.
When considering whether or not to use the custom installer option, review the pros and cons of the captive runtime approach, as described earlier. Use of a custom installer requires use of a captive runtime, whereas both AIR files and native installers leverage the shared runtime install.
If you would like to take advantage of custom installers with an existing application, you will also need to consider how to switch between approaches. This is primarily an issue for applications currently distributed as AIR files: They can download a custom installer, but will not be able to launch it automatically. In most such cases, it is helpful to issue at least one more update as an AIR file containing the necessary logic and UI to guide customers through the transition. (For applications using native installers the issue is less severe, since those applications can directly launch a downloaded installer via the NativeProcess API.)
Finally, consider the initial install experience for your users. When using AIR files, you can use the AIR in-browser API ("badge install") to launch an installation directly from a web page. This capability is not available with either native installers or custom installers, both of which typically have to use the regular browser download mechanism. And, unlike with AIR files and native installers, the in-browser API cannot detect or launch an application installed via a custom installer.
AIR has always included built-in support for creating application installers. Over the last few releases, AIR has expanded its ability to create installers for mobile devices and new types of installers on the desktop.
Using the new captive runtime capability, applications can include their own copy of the AIR runtime. Among other benefits, this eliminates the need for a separate installation of AIR and, on the desktop, enables the creation of custom installers.
Using the new custom installer option, developers can author their own installers for desktop apps. These can range from simple options like running from a flash drive or install-by-copy to complex scenarios involving registry operations, custom installation scripts, and embedding in aggregate installation sequences.
Taken together, these options provide almost unlimited flexibility in installation and deployment options for AIR applications.