Mac M1 can't use idea package to publish IPA.

[ydkgame]

Exception in thread "main" java.lang.IllegalAccessError: class com.adobe.air.ipa.MachoSigner (in unnamed module @0x3571b748) cannot access class sun.security.x509.X500Name (in module java.base) because module java.base does not export sun.security.x509 to unnamed module @0x3571b748
at com.adobe.air.ipa.MachoSigner.isDistributionCert(MachoSigner.java)
at com.adobe.air.ipa.IPASigner.isDistributionCert(IPASigner.java)
at com.adobe.air.ipa.IPAOutputStream.createNewEntitlementPlist(IPAOutputStream.java)
at com.adobe.air.ipa.IPAOutputStream.finalizeFrameworkSig(IPAOutputStream.java)
at com.adobe.air.ApplicationPackager.createPackage(ApplicationPackager.java)
at com.adobe.air.ipa.IPAPackager.createPackage(IPAPackager.java)
at com.adobe.air.ADT.parseArgsAndGo(ADT.java)
at com.adobe.air.ADT.run(ADT.java)
at com.adobe.air.ADT.main(ADT.java)

I use it

AIR SDK33.1.1.444

AIR SDK33.1.1.217

AIR SDK33.1.1.476 JDK 1.8

JDK 11

AZUL-16 JDK 16

Multiple versions cannot package IPA normally

Is there an example of successful packaging on M1 chip? What version do you use?

[ajwfrost]

On our M1 devices we have the below. You'll need to make sure whatever tool you're using for packaging is using OpenJDK or similar..

openjdk version "1.8.0_275"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.275-b01, mixed mode)

thanks

[ydkgame]

在我们的M1设备上，我们具有以下内容。您需要确定用于打包的任何工具都在使用OpenJDK或类似工具。

openjdk version "1.8.0_275"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.275-b01, mixed mode)

谢谢

It is already available for release. It turns out that JDK has a high version, so it is necessary to delete the high version

[ventr1x]

I'm currently hitting this again with M1 Mac and this JDK installed:

openjdk version "1.8.0_292"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.292-b10, mixed mode)

New M1, only this one installed and set up in intellij.

[ajwfrost]

@ventr1x we can't easily do anything to get ADT to work on a version of Java that doesn't have the security classes available to us.. but it should still be possible to do (particularly if you're using OpenJDK 1.8). Below is a link to a version that gives us a bit of diagnostics, as I suspect that it's a JRE issue related to IntellJ.

This will try outputting to the stderr output so I don't know whether IntelliJ will report it properly.. but if you're able to replicate what IntelliJ is doing - but using ADT from a terminal window - then we should see it. Or we could look at debugging the details to a file...

https://transfer.harman.com/message/pqxfC3C60bsNo3grSeNINd

thanks

[ventr1x]

Well, the only explanation is that intellij is using its bundled jdk, and this cannot be overwritten. The boot jre can also not be replaced very easily as it will crash on most versions (haven't found a compatible one yet). That means intellij is suddenly unusable with Adobe Air.

[marchbold]

You should be able to change the JDK that intellij uses. We have done this successfully in the past:

https://docs.airnativeextensions.com/docs/tutorials/getting-started-intellij#changing-jdk

[ventr1x]

Have you done this with a M1 and the available JDKs? IntelliJ errors out with all I tested - like I mentioned. I even tried multiple Oracle versions, no success.

[marchbold]

No I don't have an M1 mac, but if there's an issue with IntelliJ running on an M1 then I'd suggest you let jetbrains know about it.

https://youtrack.jetbrains.com/issues/IDEA

[ventr1x]

I love how you turn this around. There is an issue with AIR and it using classes that are not widely available, especially in dev environments. It is not acceptable in the first place to force environment changes to adhere some SDK usages/sudden changes. I am using intellij not only for AIR. That issue does not exist for RN, Flutter, Java, Android native, Ionic, Unity... why is AIR going this route?

But you feel free to contact e.g. Oracle and force them to release Intellij compatible versions. The thing is: we pay over 1000€/year to AIR, NOT to Oracle or Intellij.

[marchbold]

I'm not a developer of AIR, just suggesting a way to get your issue resolved.

[ajwfrost]

The background here, as far as I know it, is that Adobe implemented the code-signing for IPA files themselves using the sun.security classes that were available in the Java runtime at that time. They did this so that AIR could be used to create IPA files on Windows as well as on Macs; the other frameworks/tools I believe require you to have a Mac and would use the native codesign tool available from Apple.

So then they had a dependency on the Java runtime, and it sounds like Oracle are now removing the access to those classes in new JRE releases.

The simplest thing for us to do would be to drop Windows support and do the same i.e. remove all this code and just call the codesign tool.. but maybe we can look at a compromise situation first to see whether we can adapt the behaviour based on what JRE you're using..

[ventr1x]

There were so many issue with compilation on Windows that I've stopped using Windows years ago. There were past releases where Windows wasn't supported for some time at all. Especially if any dynamic lib is used, Windows can't be used anyhow as far as I remember.

Wouldn't the simplest solution be to add a new flag in the adt.cfg?

[FliplineStudios]

I'd really hate to lose Windows support for AIR compiling IPAs in order to accommodate a M1+IntelliJ issue, we've been using Windows for AIR iOS apps for nearly a decade without any problems. Hopefully there's a solution that doesn't involve cutting out Windows users altogether, like being able to toggle whether you want the native codesign on a Mac or the classic Java-based version.

[raresn]

For us windows users, using VMWare with a MAC image to always compile, would kinda suck :)

[ajwfrost]

Yes I think we can go with a flag in adt.cfg, so if this flag is set we should avoid all use of the internal Java classes and signing processing, and instead use a new mechanism that just calls the macOS codesign tool. There may be some complexities, or new flags perhaps, since e.g. the actual error shown at the origin of this issue is where AIR is trying to work out if it's a distribution cert so that it can adjust the entitlements that are built into the IPA (get-task-allow and beta-reports-active field). Possibly this means that you'd need to manually switch between different XML descriptor files, with different Entitlements sections in them, when doing a build with a distribution certificate..

We'll look at getting something out shortly to try this out. This way then, we should be able to switch to just using codesign directly on a mac, but continue using the internal Java classes on Windows; we can also look a little more at whether it would be feasible to switch to a third-party solution there that doesn't rely on these internal classes..

thanks

[ajwfrost]

@ventr1x are you able to try with the below version of ADT please? https://transfer.harman.com/message/ghqv7zUIEZAGOPxjMh90k4

If you're on a mac and it detects that you don't have the sun.security classes available from Java, or if you have set up the configuration file, then it should just try to use the native codesign app. The configuration file entry is UseNativeCodesign=true

Note you have to have the signing certificate available in your keychain for codesign to work. We tested with the .p12 file we've been using for ages and got a "Code signing error" result -> imported this into the Keychain app and then it worked. If you're using a Keychain+alias mechanism it may be simplest although internally it all gets turned into the same thing before it then calls codesign with the certificate...

[ventr1x]

It does not seem to work.

Tried building it with .p12 not in keychain: builds, can't be installed Resignd it with Distriqts script: can't be installed.

Added p12 to keychain: same results. Beides it asking to access the keychain this time around.

Never got an error while building, only trying to open the app (integrity error).

They're basic generated certs, exported with private key from my other Mac.

[ajwfrost]

Hi @ventr1x - have you tried the 33.1.1.554 release to try to bypass this issue now?

There's a similar problem that you'll presumably see when trying to build an APK file though, and signed AAB, as these use the same sort of mechanism - we'll work on removing that dependency too...

[ventr1x]

I did and same issue as explained. Building works without issues, but it can't installed as ios complains about the signing.

I can upload an ipa if you like.

[ajwfrost]

Okay that's frustrating - yes please - and if you can confirm whether you are using macOS or Windows for it, it may help. Then also you mentioned earlier that it still failed with the resigning script? any chance you could run that on it, and provide a resigned version? https://transfer.harman.com/requests/GEKdEYojlh9lxv5GvpdUrH

Finally: to install it onto the device, can you please connect it and then code into the lib/aot/bin/iOSBin folder of the SDK, and attempt to install the ipa file via the command ideviceinstaller -i myapp.ipa?

thanks

[ventr1x]

I just uploaded two .ipa.

I also tested ideviceinstaller and it seems the issue is with dynamic libs, in my case distriqts Fb SDK ANE.

iOSBin % ./ideviceinstaller -i *.ipa
WARNING: could not locate iTunesMetadata.plist in archive!
WARNING: could not locate Payload/*.app/SC_Info/*.sinf in archive!
Copying '*.ipa' to device... DONE.
Installing '*'
Install: CreatingStagingDirectory (5%)
Install: ExtractingPackage (15%)
Install: InspectingPackage (20%)
Install: TakingInstallLock (20%)
Install: PreflightingApplication (30%)
Install: InstallingEmbeddedProfile (30%)
Install: VerifyingApplication (40%)ERROR: Install failed. Got error "ApplicationVerificationFailed" with code 0xe800801c: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.DFwxyR/extracted/Payload/*.app/Frameworks/FBAudienceNetwork.framework : 0xe800801c (No code signature found.)

[ajwfrost]

Hi @ventr1x

Thanks, so that's interesting:

• with the initial IPA, none of the frameworks are codesigned
• with the resigned IPA, two of the frameworks are now signed but one of them still isn't

Looking in more detail: the executable here is a non-fat arm64 binary. The frameworks are fat/universal binaries with arm64 and armv7

It doesn't look like either parts of the universal binaries were signed ..

But this gives us some clues, we can see if we're able to reproduce this then.

thanks

[ajwfrost]

... although having said that ... we can't reproduce this: even if we try on an M1 and have the same outcome in terms of the universal/thin binary types (which looks like it is by design: each library is treated individually).

The only thing I wonder is that the universal libraries are not allowing much space, between regions so it may be that the code signature doesn't fit: but I'd expect to see some sort of error output if that was the case. But when I sign the binary, I end up with a universal library where the sections have been more spaced out...

Looking at the code:

• if there's no error happening then it would suggest we think it's a simulator build, but that should only be the case if the framework has x86/x86_64 blocks and no armv7/arm64 ... which shouldn't be the case
• if there's not enough space in the file then we may be failing for some reason but this should be reported...

OR alternatively, of course, you're not actually using the built-in code-signing within ADT because of the Java version, instead the new native macOS-based "use codesign" feature is being used, and this is only signing the .app file and not any Frameworks that are inside it...

That's frustrating. But should be easy to fix......

thanks

[ventr1x]

Of course it should be using the "new" codesign as everything else was failing and we can't overwrite the Java-Version intellij is using (or rather I haven't found a working runtime on M1 that doesn't kill intellij on startup).

I wonder though what "easy to fix" means. It's not fun having to work with two Macs just for building stuff.

[ajwfrost]

To clarify "easy to fix" .. it's fixed, July 28th looking at our repo history, which is also when the 33.1.1.575 release was cut... And looking at the release notes for that, it should be in there. Apologies, I hadn't gone through to update the issues that are in the release. Are you able to try with the latest (33.1.1.575) release and let us know whether there's still a problem?

thanks

[ventr1x]

I did a few days ago with the same result.

[ventr1x]

I really do not get what was fixed? It is still using the codesign instead of Java, it can compile but never install. With and without distriqts resign script. I am also still unable to install any app on any AIR version from my intel Mac without applying the resign script first. So that is also NOT fixed yet.

Further you added a new JAVA_HOME option but it is not used at all, at least not in intellij/ios for compilation.

[ajwfrost]

Hi @ventr1x

The recent changes have been twofold:

1. where we detect that the Java runtime isn't giving us access to the internal sun classes, or where the user has configured the 'UseNativeCodesign' option, we don't do the 'internal' code-signing; instead we call the codesign command on the macOS machine with what we believe to be the correct arguments.. earlier, with your IPA, we found that the 'deep' command for codesign doesn't actually mean that it signs any frameworks that are included, so we made a fix to search for and separately sign all frameworks.
2. for other cases (and the only option on Windows) we have updated the internal code-signing capabilities - just now, this included adding a new 'blob' to the signature that is a DER-encoded entitlements section, which is required for iOS15.

So if it's not working for you, we obviously aren't quite there yet with some of the edge cases... Can you please confirm:

1. you mention above that it compiles but never installs - even if you re-sign with the Distriqt script. What are you installing onto please - just checking in case that's using iOS 15. Do you know whether this is using the native code-signing or not? (are you able to configure the DebugOut=true setting and look in ~/adt.log?)
2. from your Intel Mac, you're saying it does actually install if you apply the resign script? but that doesn't work on the M1?

If possible, would you be able to set up the DebugOut value and then build again on both of the Macs, and send us the resulting IPA files and adt.log files? And also the resigned one from the Intel Mac which works?

To clarify the use of JAVA_HOME: that's when we are spawning a new Java task, which I believe only happens in Android APK/AAB builds. When generating an IPA file, the third party tools are things like the ABC compiler, the Apple linker, and now the codesign tool, so that setting will not be relevant.

thanks

Editing to add upload link: https://transfer.harman.com/requests/Esr9Aj12pek6pt4uZjpUdA thanks

[ventr1x]

I am still unable to distribute any ipa without using extra resign. With resign installing seems to work; on M1 and Intel.

As my 2018 Macbook burned through its battery with only 180 cycles in 2 years (gotta love the I9 and its heat...) and has extreme keyboard issues I am now only using a M1 Macbook pro.

I am using UseNativeCodesign and *.674.

If you give me another upload link, I can upload an IPA and debug output for you.

[aimozg]

(Sorry for necroposting; I had a similar issue with packaging an AIR app from IDEA with its built-in Java runtime and wantd to share a solution)

There is a JVM options to allow access to sun.* classes, in IntelliJ IDEA it can be configured under Settings > Build > AS & Flex Compiler VM options: --add-exports java.base/sun.security.x509=ALL-UNNAMED --add-exports java.base/sun.security.pkcs=ALL-UNNAMED

This should make packaging from IDEA work without downgrading the JDK.