Recently we've been made aware that the publisher ID computation is flawed in ways that make it quite likely that renewed certificates will not have identical publisher IDs. These range from the trivial to the unresolvable:
If you've run into this situation, you should use the migration signature feature, which was first added in AIR 1.1. It was originally designed to allow secured updates across unrelated certificates (i.e., not renewals). As a general purpose mechanism, however, it also works just as well with renewals, whether or not they run into this issue.
There are, however, two drawbacks to the migration signature mechanism:
This is an unfortunate turn of events for a feature that was designed to make things easier, and we apologize for the trouble all of this has caused. To address these issues, we will be making two significant changes in an otherwise minor release of AIR. This release is currently scheduled for December. The changes are:
Further details will be made available in conjunction with the upcoming release.
]]>Took some great questions from the audience during the talk. If you have further questions, please post a comment or drop me an email. (My email address is in the last slide of the presentation.)
When an XML document is loaded, it's stored in memory as a graph of individual objects representing elements, text, attributes, and so on. Each pair of related objects--for example, a parent/child element parent--are linked, in the underlying representation, with pointers going in both directions.
This is a convenient representation for traversal, but can be problematic for the garbage collector. As I mentioned in my earlier post about referencing counting and ActionScript objects, the garbage collector will eventually find and discard the entire set of objects after the last external reference is removed. However, it takes more work for the GC than less-connected data structures.
In practice, the amount of time it takes the garbage collector to do its job is related both to the number of allocated objects and the number of pointers between them. So while it is nice that the GC is capable of finding even these highly-connected graphs of objects, using them is also asking it do a lot of work. You can reduce this workload by explicitly disconnecting the pointers between objects.
For graphs of ActionScript objects, you can ease the GC workload by simply nulling out reference between the objects. Note that you don't have to find every last reference for this to be helpful. The GC will still do it's job in the end, and every bit of clearing references helps. For ActionScript objects this can be particularly helpful because, if their reference count then goes to zero, they can be cleaned up even before the GC sweep completes.
XML objects are a trickier case because the API doesn't allow developers to traverse the actual object graph. That's where System.disposeXML() comes in: It traverses the internal object graph backing the XML object, setting all of the internal points to null. Afterwords, the XML object is empty and, presumably, useless. But then, since you were done with it anyway, that shouldn't be a problem.
By default, all AIR application signatures are timestamped. Timestamps are created by a timestamp server, and are themselves signatures. When AIR validates the timestamp signature, it downloads the CRL associated with the timestamp signing certificate--just like it would when validating any other signature. And the Thawte timestamp server uses a certificate that--no surprise here--has a CRL hosted by Thawte.
This default is easy to override using the "-tsa" option to the AIR file packaging tool, adt. A value of "-tsa none" turns off timestamps entirely. To specify an alternate timestamp server, specify the URL of that server after the -tsa flag.
For more on AIR code signing, including why timestamping is used, take a look at Code Signing in Adobe AIR.
Substitute an actual version string in place of "<version>", i.e, "1.5" or "1.5.2".
]]>Starting with AIR 1.5.2, hitting escape causes fullScreenInteractive to exit by default but the behavior can be canceled by calling preventDefault() on the keydown event. Applications that use full screen to keep users (perhaps kids) from too easily leaving the application may find this change useful. As always, remember to update your namespace to take advantage of this new behavior.
]]>The problem arises because, by default, Flash Player renders content into a separate window that is positioned on top of the correct location relative to the underlying HTML. This is the original browser rendering for plug-ins. It's straightforward, but makes it impossible for the rendered plug-in content to participate in the blending of the transparent window's contents against whatever lies behind the window.
Flash Player has for some time offered alternate rendering models in which the contents are drawn as part of the HTML content instead of as a separate window. This allows the content to be covered by HTML elements--drop down menus, for example. These modes are accessed by setting the "wmode" parameter to "transparent" or "opaque". See this Tech Note for details.
Prior to AIR 1.5.2, the HTMLLoader refused to display any SWF when it was inside a transparent window in order to avoid the incorrect rendering that would otherwise result. Starting with 1.5.2, the wmode of the content is inspected. If the wmode is "window"--the default value--the content can still not be rendered correctly, and the old behavior still applies. However, if the wmode is "transparent" or "opaque", the SWF will be rendered and, because it is rendered into the HTML content, will correctly participate in the window transparency.
]]>LocalConnection operates via a shared memory segment that contains a list of endpoints listening for messages, plus a buffer in which messages can be queued up. All clients using LocalConnection periodically poll the segment, removing any messages for which they are the recipient and enqueueing any new messages they wish to send.
Clients that exit gracefully will remove themselves from the endpoint list during shutdown. However, to avoid a crashed client clogging up the segment with undeliverable messages, endpoints (and associated messages) are timed out by the other clients. Basically, any client that finds old messages queued up, thus indicating an unresponsive endpoint, removes that endpoint and associated messages from the segment. "Old" is defined as a few seconds.
This heuristic for detecting crashed clients can be tripped up by clients that merely become unresponsive--i.e. are in a tight loop in ActionScript--for too long. When this happens, the client's endpoint is closed even though the client itself is still running. After this, the client can no longer receive any messages destined for that endpoint. Note that there are two things that have to happen to get into this situation: the listener has (1) to be unresponsive for a "long" time while (2) simultaneously having LocalConnection messages sent to it.
Clearly, the implementation could be modified to avoid this issue, and you certainly shouldn't depend on this behavior. Still, I hope that knowing about this issue might help you avoid it by keeping your applications responsive. Keeping applications responsive is, of course, a good thing in any case.
LocalConnection provides local (i.e., on the same machine) communication between SWFs and AIR applications. It operates via a shared memory segment that's visible to all processes that use the mechanism.When LocalConnection was first implemented on Mac OS, it used a memory segment that is visible to all processes running on the machine. This was reasonable at the time, but problematic now that Mac OS is a multi-user operating system. The unfortunate result is that LocalConnection can be used to communicate across user accounts on Mac OS.
To address this a new, per-user implementation has been implemented on Mac OS. You should always use this mode; it's safer. To do that, set LocalConnection.isPerUser = true on every LocalConnection object you create.
Unfortunately, AIR can't do this for you transparently. The problem is that, if it did, you could get into a situation where version skew breaks use of LocalConnection. For example, this can occur if an application is running on AIR 1.5.2 and attempts to communicate with a SWF in the browser running on Flash Player 9. Until both sides are updated, there's no way to use the isPerUser = true option. By adding an API and making this an option, we've given you a chance to migrate to this option without breaking anything along the way.
This issue is specific to Mac OS. Windows and Linux use a user-scoped LocalConnection in all cases, regardless of the isPerUser setting. You can safely set LocalConnection.isPerUser = true everywhere and be confident that the Windows and Linux behavior won't change.
Final note: The default setting of this property is likely to change to true in a future release, in order to be consistent with our general philosophy of defaulting to safe behavior.
]]>As you are probably aware, AIR applications are protected during deployment by digital signatures. These signatures are checked at installation time in order to verify that the application has not been tampered with and, when possible, to reliably display the application's publisher.
The signatures are preserved by the installation process but are not normally checked when an application is running. However, there are two exceptions to this: the signature
When we designed this mechanism, we targeted applications in the 1 MB to 10 MB size range. This is important because checking the signature requires computing hashes over the entire application. For these sizes we determined that we could compute hashes over the entire application without significant delay, and so we went with the straightforward implementation that does just that. Larger applications, however--and I've seen examples of applications over 1 GB in size--will suffer painful delays during these signature validation pauses.
Our current recommendation is that you avoid making applications this big. That may sound trite, but every large application I've seen so far was that big because it included assets, such as videos, that consumed the majority of the space. Moving these kinds of non-code-containing assets out of the application itself--for example, downloading them separately into the application storage directory--is a straightforward way to reduce the application to a tractable size.
For completeness, I'll note that it is possible to design a validation mechanism that works incrementally. For example, Mac OS uses a clever scheme that hashes each page of the executable separately; the kernel can then amortize validation cost across each page as it is first referenced. (If the page is never referenced, it doesn't matter if it has been modified.) At this time, however, we have no plans to adopt such a scheme for AIR.
One final note: This signature validation usually occurs just once, the first time either the ELS or DRM capabilities are used. However, if you set "stronglyBound" to true when using the ELS API, signature validation will occur on every access. I don't recommend using this stronglyBound feature, for this and other reasons.
Perhaps most interesting of all is that we've revised the much-loved unrestricted system access warning that's displayed during application install. I think you'll be pleased with the new design:
Please note that this change applies only to applications signed with certificates that are trusted on the targeted machine. I hope you'll find some comfort in knowing that we do, indeed, listen to--and appreciate--your feedback.
]]>
Learn how to get your AIR applications to your users and how to keep them up to date. We will discuss important considerations for distribution on the Internet or an intranet, including impacts on your auto-update mechanism. We will cover existing deployment options such as badge installation and IBM Tivoli support. Finally, we will explore the new deployment options that will be available in Adobe AIR 2, including the native installer support required to use some of the advanced new AIR 2 APIs.
For example, suppose you were to monitor memory use as you stepped through the following lines of code:
var buffer:ByteArray = new ByteArray(); buffer.length = 100 * 1024 * 1024; buffer = null;
This code creates a 100 MB buffer, then discards the reference to it. After the second line executes, you'll see memory use grow by 100 MB. (Using such a large number is convenient because it makes the results really obvious in your monitoring tool.) After the third line, however, you'll see memory use drop back down immediately.
(Caveat: Monitoring memory use can be tricky in its own right, and you need to make sure you're monitoring the correct measurements to see this effect. See Performance Tuning AIR Applications for more about how to monitor memory use.)
Despite this quick-cleanup capability, it often seems like the memory use of a given application tends to creep up over time. There are two major reasons for this.
First, it's quite common in ActionScript programming that objects are connected—that is, have references to each other—in cycles. When a graph of objects contains a cycle it prevents the reference counts from going to zero even if the entire graph is itself unreferenced. The garbage collector will ultimately sort out the situation and free these objects, but it can take a while, and in the meantime the memory remains in use.
The second possibility is that there's a "leak", which is to say there's an unintended reference to an object that is, at least logically, no longer in use. These objects simply can't be freed: they have a non-zero reference count and, because they are referenced, won't be collected, either.
You can combat the first issue (cycles) and help uncover instances of the second (leaks) by eliminating cycles in object graphs when discarding references to them. More about this in upcoming posts.
]]>When an AIR application is installed on Windows, it's installed via Windows Installer. This is a good thing; it allows leveraging all the capabilities of Windows Installer. For example, silently uninstalling an AIR application on Windows can be accomplished directly via the "msiexec" utility that is part of Windows. All you need to provide to msiexec is the product code of the application.
AIR applications don't inherently contain product codes—they're specific to Windows Installer—and you won't, for example, find one in your application descriptor. Furthermore, Windows Installer requires that product codes change—even for the same application—under certain circumstances. In order to play it safe, AIR generates a unique product code for each version of your application. This, in turn, means you need to know the product code associated with the specific installed version of the application in order to uninstall it. This is a hassle.
Fortunately, Windows Installer also associates an upgrade code with each application. An upgrade code is basically an application identifier that never changes and, given an upgrade code, you can look up the corresponding product code. The mapping from upgrade code to product code is stored in the registry at application install time. Like product codes, AIR generates an upgrade code for your application. Unlike product codes, upgrade codes are the same across all versions of your application and are easily determined via the OSID application that comes with the redistribution support.
Unfortunately, the only way to look up that mapping is via the MsiEnumRelatedProducts() system call, and the msiexec utility won't do it for you. (Theoretically you can look this mapping up yourself in the registry, but that turns out to be fairly complicated, and I'm not sure it can be done reliably.)
How much of a problem this is depends on the uninstall technology you're using, whether or not it can perform this lookup for you, and whether or not you're in a position to write a few lines of C code to perform the lookup. For anyone out of luck on all counts—or just curious—I've written a small utility called "msiu2p". You can download msiu2p here. (The zip package includes the executable and the source.)
Here's an example:
c:\ msiu2p {8DA920D5-C41C-42E0-BF31-87BA49984EE4}
{A2BCA9F1-566C-4805-97D1-7FDC93386723}
c:\
Of course this isn't useful just for AIR applications, either: It's a handy complement to msiexec for any application using Windows Installer.
We plan to improve AIR's intrinsic support for this kind of thing in an upcoming release. In the meantime, I hope this utility will help fill the gap for those who need it.
]]>