• 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.

Till AIR 3.5, loading of only assets such as images, videos and SWFs without actionscript code, commonly referred as Actionscript Byte Code(ABC Code), from external server was supported. The workflow for the application developer for loading such assets from server resembles the diagram below :

With AIR 3.6, the feature for loading of locally packaged secondary SWFs containing ABC code was introduced. The detailed description about this feature and its usage can be found at this blog – “Packaging and loading of multiple SWFs for AIR apps on iOS“. The workflow for the application developer using this feature is described in the diagram below:

With AIR 3.7, the feature for external hosting of secondary SWFs has been introduced. The workflow for the application developers who want this feature would change slightly from AIR 3.6 and is shown below :

The developer needs to provide the url of the secondary stripped SWF in the URLRequest. The stripped SWF is obtained after the ADT packaging as described later in the blog post. A sample URL request for using this feature is :

private var externalSwfUrl:String= "http://www.xyz.com/ExternalSwf.swf";
private var urlRequest:URLRequest = new URLRequest(externalSwfUrl);

To use this feature, developer needs to specify a text file containing details of the SWF files to be stripped & externally hosted. This text file contains line separated paths of SWFs, which are to be externally hosted. A sample text file describing 3 SWFs to be externally hosted  would look like :

assets/Level1.swf
assets/Level2.swf
assets/Level3/asset/Level3.swf

The name of the text file needs to be mentioned in the <externalSwfs> tag within the <iPhone> tag in the application descriptor as shown below :

<iPhone>
       .
       .
       <externalSwfs>assets/SampleSWFInfoFile.txt</externalSwfs>
       .
       .
</iPhone>

During command line packaging using AIR Developer Tool(ADT), the developer needs to specify the text file  just like an asset along with the set of SWF’s mentioned in the text file. A sample ADT  command for using this feature is:

~/bin/adt -package -target ipa-app-store -provisioning-profile <Provisioning Profile> -storetype pkcs12 -keystore <Certificate> -storepass <Password> ResultantIPA.ipa SampleMainSwf-app.xml SampleMainSwf.swf assets/SampleSWFInfoFile.txt assets/Level1.swf assets/Level2.swf assets/Level3/asset/Level3.swf

Or another variation of the above command is where all the SWFs to be externally hosted and the text file are present in the assets folder is as follows :

~/bin/adt -package -target ipa-app-store -provisioning-profile <Provisioning Profile> -storetype pkcs12 -keystore <Certificate> -storepass <Password> ResultantIPA.ipa SampleMainSwf-app.xml SampleMainSwf.swf assets

During IPA packaging,  ADT extracts the ABC code from all child SWFs, adds it to the final executable and generates stripped SWFs in the “externalStrippedSwfs” folder created in the current working directory. The directory structure within the “externalStrippedSwfs” folder remains the same as specified within the text file. The generated stripped SWF’s should then be externally hosted on a web server of developer’s choice.

NOTE: The externalStrippedSwfs folder is not generated in the currently available release of Flash Builder 4.7/ Flash CS6. To enable generation of Stripped SWFs for external hosting, command line ADT packaging should be used.

A sample actionscript code which loads a secondary SWF  from an external server is described below :

package
{
	import flash.display.Loader;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.IOErrorEvent;
	import flash.net.URLRequest;
	import flash.system.ApplicationDomain;
	import flash.system.LoaderContext;

	public class SampleMainSwf extends Sprite
	{	
		private var externalLoader:Loader;
		private var url:String= "http://www.xyz.com/Level1.swf";
		private var urlRequest:URLRequest = new URLRequest(url);
		private var ldrContext:LoaderContext;

		public function SampleMainSwf()
		{	
			externalLoader = new Loader();
			externalLoader.contentLoaderInfo.addEventListener(Event.COMPLETE,completeHandler);
			externalLoader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR,errorHandler);
			ldrContext=new LoaderContext(false,ApplicationDomain.currentDomain,null);

			try
			{
				externalLoader.load(urlRequest, ldrContext);	
			}
			catch(e:Error)
			{
				trace("Error ID : "+e.errorID+"\nError Message : "+e.message);
			}
		}

		private function completeHandler(e:Event):void
		{	
			addChild(externalLoader);	
		}

		private function errorHandler(e:IOErrorEvent):void
		{
			trace("In IO ErrorEvent Handler");
		}

	}
}

POINTS TO NOTE :

1. The stripped SWFs generated using this feature are different from pure asset SWFs. It must be noted that while pure asset SWFs are valid SWFs the stripped SWFs are invalid SWFs.

2. The SWF version of the ROOT.SWF must be >= 20 to use this feature. If the SWF version is set to <20, the stripped SWFs won’t be generated in the ‘externalStrippedSwfs’ folder even if the SWF files have been specified in the text file.

3. It is recommended that this feature should not be used as a means for updating and displaying content in a dynamic manner. The externally hosted SWFs should not be replaced by any other stripped SWFs except the ones generated during IPA packaging. Any change in the secondary SWF requires a corresponding updation of stripped SWFs on external server.

4. All the SWFs specified in the text file should be passed during the ADT packaging as well.

KNOWN ISSUES :

1. External hosting of Flex SWF does not work and might cause the application to crash.

var myCacheFile: File = File.cacheDirectory.resolvePath("cacheFile.txt");


There can be cases when a file or directory is required to be stored in a directory other than <APPLICATION_HOME>/Library/Caches directory, but still not required to be backed up on the iCloud, eg. files stored in the application storage directory. To address this issue, another property, preventBackup has been added to the File API. The default value of this property is false on all platforms and can be set to true only on iOS. When the property is set to true for a File object on iOS, the file/directory corresponding to that File object is not backed up on the iCloud. If the File object points to a directory on iOS, all files in that directory are not backed up (irrespective of the values of preventBackup for individual files/sub-directories of that directory). This property works on iOS 5.1 devices and later and does not work on the iOS Simulator. Files stored in APP_HOME/tmp/ or APP_HOME/Library/Caches directory are not backed up, irrespective of the value set for this property. On querying the value of preventBackup for a particular File object, the last set value of preventBackup or false (the default value) will be returned on iOS and all other platforms will continue to return false, even if explicitly set to true.

var file: File = File.applicationStorageDirectory.resolvePath("abc.txt");
file.preventBackup = true;


The above properties will only work for application descriptor namespace 3.6 (or greater) and SWF version greater than 19.

In AIR 3.5:
AppName/Library/Application Support/com.namecompany.name/Local Store/ #SharedObjects/Content.swf
where Content.swf comes from the <Content> tag of app-xml which contains
the name of root SWF of app.

This issue is fixed in 3.6(labs), so when user will update his/her app from AIR 3.4 to 3.6, then application will not lose any data which is stored with shared object. While any new App which will be published with next release of AIR will have shared object path:
AppName/Library/Application Support/com.namecompany.name/Local Store/ #SharedObjects/Content.swf

Workaround for AIR 3.5:

For those app-developers who are going to publish their app with AIR 3.5 there is a workaround for them.Since now shared object path is taken from tag <Content> rather than tag <Filename> so you can rename your root SWF to Filename.swf and also provide the same to tag. For example:
In AIR 3.4 :
<Filename>MysharedObject</Filename>
<Content>Root.swf</Content>

Now in AIR 3.5, rename it like following:
<Filename>MysharedObject</Filename>
<Content>MysharedObject.swf</Content>

and also rename Root.swf to MysharedObject.swf.
By this way the data of the app will be saved when it will be updated from AIR 3.4 to AIR 3.5.

We would like to hear your feedback, please let us know if you face any issues.

A new attribute ‘excludeDevices’ has been added in AIR 3.6  in the requestedDisplayResolution tag in the application descriptor. Developers will now be able to explicitly disable the specified display resolution on one or more iOS devices using this attribute.

<requestedDisplayResolution excludeDevices="iPhone4,1">high</requestedDisplayResolution>

The value specified to this attribute is a space separated list of device model identifiers. The complete list of device model identifiers is given at the end of page. Developers can choose to either specify the complete list of devices model identifiers or provide a common prefix of a model identifier to be exlcluded from the specified resolution mode. An exact match of the specified device model identifier is done with the current device when complete device model identifier is specified as the value to excludeDevices attribute. Prefix matching is done when complete device model identifier is not provided. Thus, developers will have the choice to exclude

• a particular device like only iPhone 5th Generation
• multiple devices like iPhone 5thGeneration and iPod 5th Generation
• a particular device model like iPad, iPhone or iPod.

Examples

1. The following example disables retina mode only on iPhone 5th Generation.

  <requestedDisplayResolution excludeDevices="iPhone5,1">high</requestedDisplayResolution>

2. The following examples disable the retina mode only on iPhone and iPod 5th Generation.

  <requestedDisplayResolution excludeDevices="iPhone4,1 iPod5,1">high</requestedDisplayResolution>

3. The following example disables retina mode on all iPads.

  <requestedDisplayResolution excludeDevices="iPad">high</requestedDisplayResolution>

4. The following example disables the retina mode only on iPad 3rd Generation and iPad 4th Generation.

  <requestedDisplayResolution excludeDevices="iPad3">high</requestedDisplayResolution>

5. The following example enables retina mode only on iPhone and iPods.

  <requestedDisplayResolution excludeDevices="iPod iPhone">standard</requestedDisplayResolution>

Device Model Identifiers List

Please Note that

• This attribute will be allowed only with the application descriptor namespace 3.6 and higher. AIR 3.6 is currently available only in the labs release. This labs release can be downloaded from here.
• This attribute wont have any effect while running apps on AIR simulator. Simulator will only imitate the value mentioned in the application descriptor.
• The device model identifiers can also be verified using System.Capabilities.os property.