Last Updated: Nov 11, 2019
see the release notes
some highlight points
This release fixes a number of bugs reported by end users, and reverts a problem with iOS IPA packaging that was introduced with the 220.127.116.118 build where only ARMv8 code was stored rather than the IPA packages supporting both ARMv7 and ARMv8.
There are two additional updates in this release which are experimental, there are some known limitations and we recommend that significant testing should be done by developers prior to releasing applications that use these:
Support for the x86_64 target for Android. There may not be much demand for this but it is required as part of Google’s Play Store requirements for companies who are supporting x86 based devices.
There is a current outstanding issue related to device font rendering but embedded fonts should appear correctly.
Support for the Android App Bundle format. This is a newer format than having to include multiple binaries into a single APK (resulting in huge downloads for end users), and can be used rather than providing multiple APKs each for a different processor architecture (the current mechanism used by AIR SDK). The Android App Bundle contains all of the different binaries for the four supported processor architectures, but once uploaded, the Play Store then generates a slimmer APK file for a user’s device based upon its supported processor and resolution. More details can be found in section 7.
AIR-169: Android App Bundle support – see section 7 for details and limitations.
AIR-278: AIR support for Android x86_64 targets
3.1.4 Bug Fixes
AIR-137: Crash in AIR runtime during requestPermission call
AIR-265: Crash with null function pointer when trying to pause audio stream
AIR-266: Ensuring output progress messages aren’t blocked and async large file writing completes (Gamua-134)
AIR-267: Ensuring local URLs are correctly converted on Windows for Trusted Folder settings
AIR-268: Preventing URLLoader from reading bytes from a URLStream that has been closed already (Gamua-127)
AIR-274: ADT does not recognise new Apple certificates as being production ones (Gamua-137)
AIR-275: Reverting IPA generation to ensure we package both ARMv7 and ARMv8 versions (Gamua-142)
AIR-277: Italic textField cuts off by autoSize property (Gamua-78)
AIR-284: Fixing crash in attachNetStream when the video plane is not on a view (Gamua-146)
3.2 Known Problems
AIR-168: AIR content goes all white/blank after AR camera closes (Gamua-67)
AIR-183: ANRs caused by inputs not finishing processing in time (Gamua-29)
AIR-263: IPA process cannot uninstall an application from iOS13
7 Android App Bundle
Google introduced a new format for packaging up the necessary files and resources for an application intended for uploading to the Play Store, called the Android App Bundle. Information on this can be found at https://developer.android.com/guide/app-bundle
AIR now supports this on an experimental basis, with the packaging of the libraries for each of the four supported ABIs into the single AAB file. This uses a different resource packaging tool, “aapt2” as well as the “bundletool2 utility which are now added to the AIR SDK (see license information for these under the “lib/android/licenses” folder).
To generate an Android App Bundle file, the ADT syntax is similar to the “apk” usage:
adt -package -target aab <signing options> output.aab <app descriptor and files> [-extdir <folder>]
No “-arch” option can be provided, as the tool will automatically include all of the architecture types.
Note that the creation of an Android App Bundle involves a few steps and can take significantly longer than creating an APK file. We recommend that APK generation is still used during development and testing, and the AAB output can be used when packaging up an application for upload to the Play Store.
AAB files cannot be installed onto a handset: instead, an appropriate APK needs to be generated and installed, which can be done via the “bundletool” utility. Instructions for this are available at
https://developer.android.com/studio/command-line/bundletool#deploy_with_bundletool, essentially the below lines can be used:
java -jar bundletool.jar build-apks --bundle output.aab --output output.apks --connected-device
java -jar bundletool.jar install-apks --apks=output.apks
The first step generates an “apks” file which is a collection of different APK files that are appropriate for the connected device; the second step then installs this onto a handset.
Note that the APK generation here will use a default/debug keystore; additional command-line parameters can be used if the output APK needs to be signed with a particular certificate.
HARMAN is intending to add support for installation of an AAB file using a single ADT comment, to simplify this process.
There are some limitations to the current implementation of the Android App Bundle within AIR SDK:
The outputs used are solely the release build and do not contain debugging support: essentially it is the equivalent of “apk-captive-runtime” rather than “apk-debug”. For debugging, please continue to use “apk-debug”.
AIR Native Extensions have a restriction regarding the use of Android resources that are packaged along with them. ANEs that are purely native libraries (JAR/SO files) should work, however if one of these attempts to load a resource e.g. a layout, this will fail. This issue is under investigation.
This final restriction means that the usefulness of Android App Bundles may be limited at present, however we welcome any feedback from developers who are able to use the format.