AIR SDK 33.1.1.190 release

Last Updated: July 10, 2020
https://airsdk.harman.com/

see the release notes


Purpose of the release

This version builds upon 33.1.1.176 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.

and

3.1.5 Bug Fixes

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

and

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.

See https://github.com/Gamua/Adobe-Runtime-Support/issues

4 Likes

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