AIR SDK 33.1.1.259 release

Last Updated: September 19, 2020
https://airsdk.harman.com/

see the release notes


Purpose of the release

This update brings some fixes and new features on Windows, Android and iPhone platforms, and is provided so that Android users can continue with the appropriate SDK 29 capabilities. Work is ongoing regarding MacOS codesigning and notarization, and there are a number of other smaller bugs that will be fixed over the coming weeks.

The team is now focused on iOS14 to ensure that the SDK is updated with the appropriate frameworks and toolchain updates, and to fix the multimedia issues that have been found with this.

Please also see section 3.2. Multimedia in general remains an area that we will be focusing on prior to the end of this year to ensure that desktop platforms are able to play back H.264/AAC media again.

and

3.1.4 Features

AIR-662: Packaging any content in a ‘res’ folder as if it’s a resource (Gamua-163).
This update means that any files/folders provided to the ADT packaging command for Android, that are under a ‘res’ folder, will be treated as if they’re resources.
AIR-938: Updating AIR on Windows to handle up to 6 concurrent HTTP connections per server
Gamua-113 Adding libclang_rt.ios.a to SDK (for convenience…)

and

3.1.5 Bug Fixes

Gamua-330: RTMP video streams stuttering/hanging
Gamua-452: Ensuring Android splash screen check uses correct AppID
AIR-446: Audio doesn’t restart after phone interruption (Gamua-161)
AIR-931 Ensuring .air files can be generated into installation packages

and

3.2 Known Problems

iOS14: we will be updating the SDK shortly to build this against iPhoneOS SDK 14.0; we are also aware of problems with multimedia playback on this version which are under investigation currently.

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.

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

For a list of open issues, see https://github.com/Gamua/Adobe-Runtime-Support/issues

3 Likes

I find the following a bit ridiculous

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

kudos to Harman to go the the length of finding out the details of such problem
but if dev can not setup Java on their computer, then they are the bug

  1. learn the damn command-line
  2. learn what are environment variables
  3. learn how/why you need to configure
    JAVA_HOME, JAVA_OPTS, and PATH
  4. if you can’t figure that out, stop programming and go back to 1.

Annex.
it is not just Java, you will need to know those for most programming languages and dev environment

4 Likes