I’ve been asked a couple of times if it’s possible to parameterize the application identifier, etc. for an AIR-based application during the installation process. The scenario is usually something like this: A developer has created an application that they publish through different vendors. Each vendor stamps some unique branding, etc. on the application but the underlying code is the same. The developer doesn’t want to produce a different AIR file for each vendor. Instead, they’d like to parameterize things like the application identifier, application name, logo, etc. during the installation process.
The problem with this is that it’s directly at odds with secure delivery of the applications. Secure delivery is designed to establish the trusted identity of the publisher of each application via digital signatures. If any part of the application can be changed at install time then it’s (by definition) not covered by that signature, and we can no longer establish the authenticity of the application. Maybe you got assigned a correct parameter, or maybe you got a malicious one that will open you to an attack. How do you know?
In these scenarios it’s the vendor, not the developer, who is actually publishing the application. They’re the ones who should be signing the application; this will insure that it’s their name that appears during application install. And of course they should only be signing it after any re-branding, etc. has been applied.
Too much work for the developer? It shouldn’t be. Packaging can be fully automated via the adt tool provided for free in the SDK. Create a script that uses it to produce all of your unsigned, parameterized, intermediate AIR (.airi) files. Hand this file off to your vendor and have them sign it, again using adt, to produce the final AIR file for distribution. Voila.