Author Archive: nimisha

Multiple ANEs and conflicting resources

AIR 4.0 and later supports packaging of multiple JAR files in an ANE. That allows packaging of third party libraries and their corresponding resources an ANE.

The resources bundled in an ANE or any other library in the ANE can be accessed by R* method, and this document provides all the details.

This post talks about a scenario where multiple ANEs are used in an app and if two or more of the ANEs use same JAR file as a dependency (packagedDependency).  It is not possible to create such an app, and the packager fails with following error –

unexpected failure: duplicate entry: /R.class

This is expected because when the packager picks up resources of all the ANEs, and finds that two or more ANEs are using a same resource, the step to convert *.java to *.class file fails with a duplicate entry error. This is something which the packager cannot resolve by itself, and the developer has to step in.

If you face this packaging error, you need to remove the common JAR from all of the ANEs but one, to ensure that the packager finds a single copy of every JAR file as input.

Here is an example –

Suppose there are two ANEs used in an app i.e. example1.ane and example2.ane. Both of them use a common library, say commonlibrary.jar, and its resources, say, common-lib-res. If you try to package the app with these ANEs, ADT throws an error –

unexpected failure: duplicate entry: com.common.example.lib/R.class

To resolve the issue, you need to follow these steps (eg. is for a Mac) –

1. Copy example1.ane in a temp folder.

2. Unzip example.ane (run command ‘unzip example1.ane‘)

3. Remove the commonlibrary.jar from the package (i.e. from unzipped content of the ANE).

4. Remove the corresponding resources of commonlibrary.jar (i.e. “common-lib-res“) from the package.

5. In platform.xml, delete the entry for commonlibrary.jar from the tag and delete the entry of the common-lib-res from the tag.

6. Zip back contents of package to ANE –

  • zip –r –D example1.zip META-INF catalog.xml library.swf mimetype
  • rm –rf example1.ane META-INF catalog.xml library.swf mimetype
  • mv example1.zip example1.ane

Use this new temp/example1.ane and existing example2.ane to package the APK file. You should not see any packaging or runtime error now.

Hope that helps! :)

Changed behavior of Shared Object on iOS in AIR 3.5

With AIR 3.5 the path of shared objects changed than it used to be in AIR 3.4, following illustrates the difference between paths:
In AIR 3.4:
AppName/Library/Application Support/com.namecompany.name/Local Store/ #SharedObjects/Filename.swf
where Filename.swf comes from the <Filename> tag of app-xml.

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.