Versioning of multiple APKs for Android

Recently, with AIR 14, we announced x86 support for AIR applications. In this article, we explain how should developers manage the binary upload on Google Play Store for ARM and x86 binaries. Android devices are available with three kind of architectures – ARM, x86 and devices which support both x86 and ARM architectures (Eg: Samsung Galaxy Tab 3 10.1). AIR SDK (14.0.0.125 beta onwards) allows developers to create separate APK files for ARM and x86 architectures. And Google Play Developer console provides CPU architecture (ABI) as a filter criteria to support multiple APKs for the same application. The way Adobe AIR developers should make use of this filter criteria would depend on the packaging mode - captive or shared.

 

For Apps packaged with Captive mode

Please take a look at the following documentation. AIR developers should follow the same guidelines, as are mentioned for native applications.

http://developer.android.com/google/play/publishing/multiple-apks.html

Assigning a higher versionNumber  (in application descriptor) for the x86 version of apk would ensure that the Google Play serves x86 binary to devices with both x86 and ARM support,  thereby resulting in better performance.

 

For Apps packaged with Shared mode

After the recent release of x86 support in AIR, Play Store will have two different binaries for AIR Runtime app– one for ARM devices, and another for x86 devices. For devices which can run both, ARM binary version would be preferred because that used to get downloaded even before we introduced x86 support. And we plan to continue with the same preference to ensure that shared apps dependent on AIR runtime aren’t affected. To align with AIR Runtime app, applications packaged in shared mode should also keep their x86 based binary with lower versionNumber. With this approach, if you face any performance related issues on devices which support both the processors, then you can opt for captive mode of packaging.

The table below summarizes what version gets downloaded on device with different processors type.

  ARM Device x86 Device Device supporting both x86 and ARM
Runtime.apk ARM version x86 version ARM version
Captive App ARM version x86 version x86 version
Shared App ARM version x86 version ARM version

-Thanks

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! :)

Playpanel 1.4 is here!!

After introducing a revamped home screen and an alert capability in the previous version, Playpanel 1.4 was released few days back. So what exactly does the new Playpanel version hold in its kitty? Lets take a closer look.

Play Better

First and foremost, Playpanel is now available in 15 international languages which makes it accessible, globally. A major effort has also been put in to improve the performance of the application and the results have been amazing. Navigation through different parts of the application is super fast. Now you can also open Playpanel in windowed mode just like any other normal windows application. This makes it very useful for the users who want to drag it across multiple screens, minimize it to taskbar as per their wish.

Playpanel 1.4

Playpanel 1.4

Starting with 1.4 release, users can also view the games pinned by their Facebook friends within the Friends tab. This keeps them updated about what their friends like and a chance to try them out. Likewise, you can share your favourite games and also view them in the newly introduced Pinned games tab on the top. Additionally, you can invite any of your Facebook friend who is not on Playpanel, right at the click of a button.

All in all, Playpanel 1.4 offers an array of exciting features to take the users’ game playing experience to a whole new level.

If you are a game publisher, and are interested in making your game reach out to more users, please let us know by dropping a mail to PlaypanelMarketing@adobe.com.

Play more, Play better!

Adobe Playpanel : Play Better, Play More

Today, it’s all about games! The online gaming industry is growing by leaps & bounds. And with this growth comes the challenge for game developers and publishers like you to market their games.

Making your game discoverable amongst the million others is the biggest hurdle. Not just that, after users visit your game for the first time, the next challenge is to get them back to your game.

Playpanel's Home Screen

Playpanel’s Home Screen

Adobe Playpanel aims to help you in this regard by providing a platform to showcase your games to a large number of users, retain them more, thereby eventually increasing your revenues. Playpanel is a desktop application, which shows high quality games, which are either hand picked by our editors or are the ones which get played most by the users around the world. Users need to login into Playpanel using their Facebook account, and that helps Playpanel in suggesting games to them which are played by their friends.

Game Details Panel

Game Details Panel

Playpanel is capable of showing games built using any technology (Flash, HTML5, Unity, etc.), but works slightly better for Flash based games. That’s because it is integrated with Flash Player, thereby providing the users with the added convenience of managing all their games automatically, without any manual intervention.

If you are a game publisher, and are interested in making your game reach out to more users, please let us know by dropping a mail to PlaypanelMarketing@adobe.com.

Play better, Play more!

External hosting of secondary SWFs for AIR apps on iOS

Starting with AIR 3.7, application developers will be able to host their secondary SWFs on an external server and load them on demand as per their application logic.

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 :

 AIR 3.5 Workflow

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:

Continue reading…