Well, it depends on what you mean by "install". The Apache Flex Installer 3.3.2 that we hope to release soon is doing something similar. When you install Apache Flex Installer 3.3.2 for Windows, you are installing a 32-bit app. When that 32-bit app runs, it automatically downloads a 64-bit app into the Application Storage folder. Once the 64-bit app is there, the 32-bit app launches the 64-bit app. So you only installed one thing once, but it brought down other things.
It might also be possible to package the second app as part of the captive runtime bundle.
> I need the AIR application I'm working on to be able to restart itself
> an update process.
> The way to achieve this seems to be :
> /var productManager:ProductManager = new ProductManager("airappinstaller");
> productManager.launch("-launch " +
> But this code doesn't works. I think that it is because the
> <allowBrowserInvocation></allowBrowserInvocation> tag of the application
> descriptor must bet set to true.
> But my application is package as a captive runtime bundle and in that case
> the <allowBrowserInvocation> tag cannot be used.
> Does someone has a solution to solve this problem ?
> Sent from: http://apache-flex-users.2333346.n4.nabble.com/ >
Yes, I was a bit reluctant about the idea of doubling the bundle size only
to be able to restart the application.
But finally, Om's suggestion turned out to work perfectly (I wasn't setting
a valid path to my executable file).
Thank you Hugo, your link is very interesting. The restart method used here
is based on the NativeProcess object too and the way the executable file is
constructed allowed me to understand my mistake.
Updating an Air dekstop application with captive runtime is perfectly
viable. The only remaining issue I encounter is the fact that, on Windows,
it is not allowed to write files into the ProgramFiles directory. I don't
know if there is a way to circumvent this restriction programmatically ? My
workaround is to set the .msi installer to copy the application files at the
root of the system hard drive instead of the programFiles directory.
I spent a lot of time on this issue and a working solution for me for almost
- 0 external runtime dependencies: AIR captive runtime on both Windows and
- Optimal processor architecture: I provide 3 options: macOS, Win-32 and
more recently Win-64
- 0 Windows security issues about folders (on C:\ you may have security
issues): I install on Main Drive:\User Documents\AppData\roaming\My App Id
(ex: C:\Users\hugo\AppData\roaming\pt.mygreatecompany.greatapp) - This is
the same strategy and Spotify Windows App for years (User Documents folder
change from Windows Version and language)
- 0 dependencies of external dlls: For example, I have an ANE for Toast that
depend on C++ .NET runtime, so I isulated the needed files and bring with
the App folders (it turns out that was only 2 small dlls and the license for
this 2 dlls allows to do that)
- And last but not least an auto updater mechanism tested on about 10
combinations of Windows versions + macOS
I already implement a restart method that works based on Alex, Om and Hugo
For those who can be interested :
public function restartApplication():void
var applicationDescriptor:XML =
var xmlns:Namespace = new Namespace(applicationDescriptor.namespace());
var applicationName:String = applicationDescriptor.xmlns::filename;
var nativeProcessStartupInfo:NativeProcessStartupInfo = new
var nativeProcess:NativeProcess = new NativeProcess();
if (Capabilities.os.indexOf("Win") > -1)
applicationExecutable = new
File(File.applicationDirectory.nativePath + "/" + applicationName + ".exe");
applicationExecutable = new
File(File.applicationDirectory.nativePath.replace("Resources", "MacOS/" +