4 Replies Latest reply on Nov 8, 2009 9:52 AM by Tarindel

    Adobe AIR runtime update dialog breaks application


      I'm working on a large project that utilizes a C++ application to house the core logic and an AIR application to display a UI. The C++ program launches the AIR UI and passes it several command line parameters, including locale and port number to call back to the C++ application with.  Under normal circumstances, this works great.


      However, when there's an Adobe AIR runtime update, things go bad.  The runtime intercepts the UI invocation, kills it, and displays the generic AIR "do you want to update?" dialog.  Whether the user presses update or cancel, the UI application eventually gets relaunched -- but without the command line parameters originally passed to it!  I presume this is a bug in the Adobe AIR runtime updater code.


      The end result of this is that the UI gets relaunched, but doesn't know how to localize itself or what port to call back to the C++ application with!  If the user relaunches, it works fine (because the update dialog won't intercept again), but by then the user experience has already been mangled.  We can't even display a localized error message to tell them to relaunch because we don't know what locale they're using any more, and we can't call back to the C++ application to ask.


      I'm trying to find solutions/workarounds to this issue.  Because AIR won't let us turn off the update check on a per-application basis, it seems like the only viable solution would be to turn off the runtime update check for the whole machine.  But altering machines settings for the benefit of one application is definitely bad form, and I'd prefer not to do that if any other viable workaround exist.


      Any ideas?

        • 1. Re: Adobe AIR runtime update dialog breaks application
          tzeng Adobe Employee

          If users press Cancel, the app should not shut down.


          But back to your problem, have you tried to record the parameters to a pref file, say stored in storage directory?

          Every time when the app get launched and doesn't receive a port, it can use the one in pref file written in last launch by command line.


          When Runtime Update dialog comes up, it should ask users to quit all the running AIR applications before it updates.

          I don't see how the app. get shut down and launched automatically. It should be done by users.

          • 2. Re: Adobe AIR runtime update dialog breaks application
            Tarindel Level 1

            When the Adobe runtime update launches, it terminates the app that was just launched -- task manager confirms this.  This happens as soon as the runtime update dialog appears, before the user even can make a choice whether to update or cancel.  This appears to be part of the runtime update process and is totally out of the hands of my application.  (Note: the runtime update mechanism is different than the application update mechanism)


            We thought about using the disk as a transfer mechanism, but the problem is that the parameters can vary from session to session.  We could probably preserve the last known good locale this way, which would at least let us throw up a localized error message, but the port number varies with every launch (depending on how many instances of our C++ app are running), so we'd still have a non-workign application and the user would have to relaunch.


            Right now, we're investigating the idea of launching an "update pre-check" application to "consume" the runtime update check, and then launch our real application behind it.  That way the update check won't get in the way of our real application launch.  How robust this solution would be, I dunno, but it's the best we've come up with so far.

            • 3. Re: Adobe AIR runtime update dialog breaks application
              tzeng Adobe Employee

              This is not the correct behavior. Runtime Update should ask users to quit all running AIR apps first before it updates the Runtime.

              Could you file a bug at




              We have not seen this behavior. I think you have filed a bug asking the Runtime Update remember the parameters. But this is not how the Runtime Update works. It should not shut down your app. automatically. If you can include the situation this behavior can be duplicated, that would be a great help.


              When you say "vary from session to session", I assume you mean each launch is a session. If that is the case, couldn't your app check the EvokeEvent at launch, if there is a port number, write it to a file and continue. If there is no port number, read the port number from the record file?


              This would be the same behavior as Runtime remembering the parameters during relaunch.





              • 4. Re: Adobe AIR runtime update dialog breaks application
                Tarindel Level 1

                I filed a bug report last night using that same form.


                The duplication steps are straightforward.  I can duplicate the following with 100% success on a freshly imaged Win 7 32-bit box, admin user account:


                1) Install older version of Adobe AIR framework (I tried both 1.1 and 1.5.1).  It will ask you to update.  Click "Update later".

                2) Pull up task manager and watch the process list

                3) Run ANY Adobe AIR app with some parameters (I used Adobe's Settings Manager as a sample because it's small)

                4) Note that your application appears in the task manager briefly

                5) Your app is terminated and "Adobe Air Installer.exe" appears in the task manager.  A dialog pops up asking you to update.

                6) Click cancel

                7) Your app is reinvoked without any parameters


                As for my specific case, by "session" I do mean a single launch.


                I'm not aware of an evoke event -- perhaps you meant invoke event?  The invoke event is not executing before the app terminates (in step 5 above).  I think the AIR app is just running long enough to load the runtime and then the runtime takes over from there.