AIR applications, when accessing content via HTTP or HTTPS, always do so via the system proxy settings. On Windows that means they use the same settings as Internet Explorer. On Mac OS, those are the same settings as used by Safari. It’s hard to use a machine if the system proxy settings aren’t correct, so users typically have this set up early on and then don’t have to think twice about it—it just works.
The folks over at Sun who had to implement Java for Windows had other ideas, and gave Java its own proxy settings. If you have to explicitly enter your proxy settings for your operating system, you most likely will have to separately enter those settings to any JRE you’ve installed. In current versions of Java, these settings are accessed via the Java Control Panel.
ADT is, as explained earlier, written in Java. It also generally has to access the network when signing in order to obtain a secure timestamp; that server is accessed via an HTTP request. The end result? Developers often find that AIR applications can access the network just fine during development, but when it comes time to create an AIR file, packaging fails because a timestamp can’t be created.
If you run into this situation, be sure to check your Java proxy settings—and make sure you’re checking for the same JRE that ADT is using. (If you have more than one JRE, they may not be sharing proxy settings.) I do not recommend disabling timestamping, for reasons I’ll explain later.