Mac Desktop captive runtime app "Adobe AIR cannot be found" error

[MMPGreg]

Problem Description

I am packaging a Mac Desktop application package from IntelliJ, using the captive runtime bundle (*.app). My issue is with the app when prepared for distribution outside of the Mac App Store.

We are encountering an issue when our app is launched on a Mac that produced the error message: “This application requires a version of Adobe AIR which cannot be found. Please download the latest version of the runtime...”

As the app is packaged for captive runtime, one would expect that this issue should not be encountered.

I can confirm that the framework is in the app package, and is located at: Contents/Frameworks/Adobe AIR.framework/...

Prior to distributing the app, it is signed with an Apple Developer ID Application certificate, notarized, and stapled. It passes all of Apple's validations in this regard and is cleared to go.

This condition has apparently existed from at least SDK version 33.1.1.xxx to 50.2.2.6.

I have not experienced this condition myself, as the developer, but a coworker has reported this on a Mac laptop and iMac. And apparently installing Adobe AIR explicitly and running the app still produced the same error for him.

Steps to Reproduce

Creating a new blank Mac Desktop app Flex/AIR project from IntelliJ with nothing else done to the default code, packaging it as stated above, still created the runtime error.

[ajwfrost]

Hi

The error message implies that the runtime framework can't be loaded (hence it tries looking for another one).. can you please confirm:

1) is this happening on an Apple Silicon device? if so, can you right-click on the application, choose "Get Info", and then select the option to run this in Rosetta? Sometimes this lowers the security requirement around the code-signing

2) can you run ls -la on that "Adobe AIR.framework" folder (from a terminal window) and check that there are symbolic links there? Sometimes there are processes in the SDK unpackaging or in the creation of the bundle where links are turned into normal files and this may pass signing/notarisation, but get caught by gatekeeper when you try to run it..

3) and just checking, it's not an app that's based on an HTML file as the initial content? For this, you'd need to use AIR SDK 33.1.1.743, anything later would cause a problem (but you would have already hit that when testing it..)

Feel free to send us the .app bundle and we can also run it here to analyse it and see what may be wrong..

thanks

[MMPGreg]

Thank you, @ajwfrost.

1. I can confirm that no Apple Silicon devices are at play.
2. I have a feeling the symlinks may be the issue, though I don't know what they are expected to be.
3. No HTML content is present at launch.

I can confirm that there are 2 in the framework root: "Adobe AIR" and "Resources". Within Versions there is 1 for "Current".

[ajwfrost]

Hi

Thanks for those -> that all looks fine though. Not sure why this would then not start, there's no xattr markings on that file listing.. Is it possible for you to zip up and send us the .app bundle? We can try to reproduce here.. Upload link: https://transfer.harman.com/requests/RFMdNBqnz2ypx4mA7NN1ZZ

thanks

[MMPGreg]

Thank you, @ajwfrost. File sent.

[ajwfrost]

Okay so oddly, the issue is in the "Adobe AIR_64" file that's within the "Adobe\ AIR.framework/Versions/1.0" path. In a normal build, this is just a symbolic link back to "Adobe AIR" (it's there for historical reasons I believe), but in your version it's actually a different/old file:

% ls -la
33140928 12 Jun 09:58 Adobe AIR
27780752 12 Jun 09:58 Adobe AIR_64

% file Adobe\ AIR
Adobe AIR: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
Adobe AIR (for architecture x86_64):    Mach-O 64-bit dynamically linked shared library x86_64
Adobe AIR (for architecture arm64): Mach-O 64-bit dynamically linked shared library arm64
% file Adobe\ AIR_64 
Adobe AIR_64: Mach-O 64-bit dynamically linked shared library x86_64

So can you check your AIR SDK installation and see whether there's a file like this in there somehow? if so, delete that and replace it with a symbolic link to the main binary e.g. ln -s "Adobe AIR" "Adobe AIR_64"

thanks

[MMPGreg]

Thank you @ajwfrost.

I did realize that I may not have created my combined Flex/AIR SDK correctly for version 50.2.2.6, so I rebuilt that. I did get errors initially from the copy process indicating files in the Adobe AIR framework runtime for Mac (captive and not) could not be replaced. I manually deleted the existing files in my base Flex directory so the overlaid AIR contents could be copied correctly.

I added to my code sign script the line to create the symlink explicitly to generate the Adobe AIR_64 file from the existing Adobe AIR file. That all appears to work correctly.

However, now when I run my code sign script - just with the addition of that line - I get the below error from the Terminal (if I comment out the new symlink line, my code sign completes as expected):

Code signing verification failed! --prepared:/.../XXX.app/Contents/Frameworks/Adobe AIR.framework/Versions/Current/. XXX.app: unsealed contents present in the root directory of an embedded framework In subcomponent: /.../XXX.app/Contents/Frameworks/Adobe AIR.framework

From my eyes, there does not seem to be any additional "unsealed contents" in the framework - only the new symlink was added. I also noticed that in the runtime directory of the AIR SDK, for the Mac version, the "air" and "air-captive" versions of the Framework differ, particularly in regards to symlinks and the "_64" file. Could that be a factor here?

[ajwfrost]

Hi

the "air" and "air-captive" versions of the Framework differ

I believe only one of them needs the "Adobe AIR_64" entry, but it should be a symbolic link. The links should be pretty much the same for both of them - under the .framework folder, just "Versions" is a real folder, then "1.0", and then you're into the place where the files actually sit. I think "Captive" omits the _64 binary and the Headers folder.

Does your code signing script re-sign the framework itself? as you'd need to do that, if you're changing it.. but it would be better to fix the AIR/Flex SDK so that this file is already a symbolic link when you package it up. (I'm assuming that if it's a symbolic link in the SDK folder, it will also be a symbolic link in your generated app ... if not, something else has gone very wrong!)

You can always use ADT instead of your signing script?

adt -sign -storetype KeychainStore -alias "Developer ID Application" -target bundle InputBundle.app OutputBundle.app

This should dive into the frameworks and sign each one first..

thanks

[MMPGreg]

Thank you @ajwfrost.

I seem to have overcome the symlinks/signing issue as it relates specifically to the Adobe AIR.framework by leaving its directory structure intact, not adding/removing any symlinks and leaving its existing _CodeSignature intact. Just to be sure, I rebuild my Flex/AIR SDK again.

I was able to get my app to a place where the only complaint that the notarization process had was with "The executable does not have the hardened runtime enabled."

When I changed my script to use the ADT 'sign' command on the app itself, instead of the 'codesign' one, I was finally able to create an app that both ran without the Air framework error, and pass Apple's notarization.

Thanks for all your help!