AIR SDK release

Last Updated: July 10, 2020

see the release notes

Purpose of the release

This version builds upon which was withdrawn due to problems – primarily on MacOS – caused by incorrect signing of executable files. A number of other fixes have been brought into this release, in particular:

  • Ensuring applications can create a new Encrypted Local Store on Windows platforms

  • Preventing an iOS application running in the background due to proximity sensing from being spuriously hung following an unexpected OS message

  • Refining the splash screen detection mechanism on Android

The issues that had been caused by incorrectly code-signing the MacOS binaries included the inability to use the device-specific functionality (such as listing devices and installing applications onto devices), as well as the ahead-of-time compilation of ActionScript when creating an IPA file.

There are a number of key issues still outstanding that are now being worked on, see section 3.2.


3.1.5 Bug Fixes

Gamua-371: IPA won’t compile with when Fast Packaging is off
Gamua-374: iOS Device not found AIR
Gamua-375: java.lang.NullPointerException - AppEntry.dispatchKeyEvent
Gamua-377: WARNING: Unlicensed version of AIR SDK
Gamua 378: Unable to build iOS ipa File with
AIR-282: Proximity on IOS blocks event processing when enabled
AIR-568: Encrypted local store - can’t create new ELS on Windows (Gamua-205)


3.2 Known Problems

One key area where there are currently major issues is around multimedia, particularly the support (or lack of support) for H.264 and AAC formats on desktop platforms. We intend to address these with a goal to release a version supporting these prior to the end of the year.

We are also aware of a problem with Android SDK level 29 on 32-bit Android builds where the security changes mean that one of the Neon detection optimisations is no longer permitted. This will be addressed shortly along with a number of other updates that are already in progress.

Some Android resource packaging problems have been found to be caused by the code within ADT that generates the R.class files from resources embedded in ANEs. Normally the generation would be done via the JDK, but if this isn’t present on a computer (i.e. if JAVA_HOME isn’t set to a JDK folder) then ADT attempts to generate the Java bytecode instead. See Gamua-274.



Just checked: the bug, which I reported to @ajwfrost was fixed, too :slight_smile: Thank you!