Before we talk about this feature, let me give an overview of Shared and Captive runtimes.
- Shared Runtime – A runtime that is installed as a separate application and can be used by multiple applications.
- Captive or Embedded Runtime – A runtime that is embedded within the application and is only used by that one application.
With shared runtime when an AIR Android application is launched a dialog is shown to install/update the runtime if AIR runtime is not installed or not updated, and this being an extra step is not a great experience for the application users.
Starting AIR 3.7, packaging AIR applications for Android in any target will embed the AIR runtime in the application itself. So, this dialog will now not be seen for applications packaged from AIR 3.7 and onwards. This will allow applications to get a better installation experience, however the application size would increase by around 9MB. This is now parallel to iOS applications where also AIR runtime is embedded.
Advantages of moving to applications with captive AIR runtime:
- AIR Android applications can now be installed seamlessly, without a separate runtime download.
- Users will not be concerned with updating the runtime.
- Developers can now control their applications to use a specific runtime version.
The existing workflows for packaging Android applications from tools such as Flash Builder and Flash Professional remains unchanged. Internally however these tools would create applications with AIR runtime embedded for all the targets.
Comments
Great! good to know! Thanks for listening programmers’ needs and push out the boundary together.
Oh, yeah, good news.
err. why is this news?….This option was there since at least AIR 3.5 or (even 3.4 I think).
Hi Anon,
Earlier only apk-captive-runtime target would embed runtime within the application.
Starting AIR 3.7, packaging Android applications in all targets would embed AIR runtime with the application.
So, all Android AIR applications will be captive by default.
This is very much helpful information i learnt a new thing by reading this today. This is really useful information
And what about the size will reduce ?
Was this actually an issue? have users complained a lot about having to download air once in phone’s their lifetime?
I installed air once.. and never had to do it again. and I didn’t perceive this as a bad user experience, since the app nicely asked me to to install air..
I never understood why this was an issue. I much rather have 1 shared runtime and lots of smaller apps, than having lots of apps that are 9mb larger..
it’s too bad we’re now going to be forced to include the air runtime in every air app.
I agree 100% with you. I have an app which is 250 kb… and now that I am testing the same app with the 3.7 SDK, well, it increases the size almost to 9.4 Mb.
So if I have 20 good apps under 250 kb, that means that all of them will be up to 5 Mb… but if I switch them to the new SDK, they will increase the size up to 180 Mb. :S
250kb per app? Well, you must be talking about some very basic stuff coded with native languages.
If you want the joy of crossplatform development then you gotta face the slight drawback of having a captive. Really, what kind of expectations do you have?
I really feel you don’t realise what’s going on with captive runtime, why its 9mb, and so on and forth.
It’s actually much more user friendly (at least not for power users) not to care about “what’s that thing Adobe Air that app is asking me to download”.
Really , guys. And +9mb is nothing these days. You have plenty of space (40 mb) to write app that wouldn’t require extra packages as per Android requirements.
It would actually be nicer if only the parts of AIR that are used are packaged, and not the ENTIRE air shared library… since nothing is going to share it, why include the useless bits?
Thumbs up… It could be a solution, but not sure if that would be possible so far.