search

airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
200 stars 11 forks source link

[macOS][AIR SDK 33.1.1.758] Some iOS applications cause ApplicationVerificationFailed error #1623

Closed itlancer closed 2 years ago

itlancer commented 2 years ago

Problem Description

Some iOS applications cause ApplicationVerificationFailed error on installation when AIR app built with latest AIR SDK 33.1.1.758 using macOS. I don't know where is problem exactly. It happens with different complex AIR apps with native extensions. There is no such problem with "empty" or simple AIR apps.

It has been tested with latest AIR SDK 33.1.1.758 with MacBook Pro A2141 16" 2019 macOS 11.3, different AIR apps (with different certificates) and Xcode 13.2.1.

There is no such issue with AIR SDK 33.1.1.758 for Windows. Also there is no such issue with AIR SDK 33.1.1.743 and earlier.

With adt.cfg we have UseNativeCodesign=true. We didn't make any extra "codesign" for native extensions. Just AIR adt -package -storetype pkcs12 -keystore cert.p12 -storepass password -keypass password -target ane MyANE.ane extension.xml ...

May be related issues: https://github.com/airsdk/Adobe-Runtime-Support/issues/1602 https://github.com/airsdk/Adobe-Runtime-Support/issues/1276 https://github.com/airsdk/Adobe-Runtime-Support/issues/1272 https://github.com/airsdk/Adobe-Runtime-Support/issues/1074 https://github.com/airsdk/Adobe-Runtime-Support/issues/768 https://github.com/airsdk/Adobe-Runtime-Support/issues/521

Steps to Reproduce

Build and package AIR app for iOS using macOS and AIR SDK 33.1.1.758. We use commands like that:

/Users/username/Documents/SDK/33/bin/amxmlc [
  '-define+=CONFIG::CONSTANT1,true',
  "-define+=CONFIG::CONSTANT2,'test'",
   '-source-path+=/Users/username/Documents/app/src',
  '-library-path+=/Users/username/Documents/app/libs/MyANE.ane',
  '-output=bin/MyApp.swf',
  '--',
  '/Users/username/Documents/app/src/MyApp.as'
]

/Users/itlancer/Documents/SDK/33/bin/adt [
  '-package',
  '-target',
  'ipa-ad-hoc',
  '-storetype',
  'pkcs12',
  '-keystore',
  '/Users/username/Documents/cert/certificate.p12',
  '-storepass',
  'password',
  '-keypass',
  'password',
  '-provisioning-profile',
  '/Users/username/Documents/cert/AdHoc_profile.mobileprovision',
  'bin/MyApp.ipa',
  'descriptor.xml',
  '-extdir',
  '/Users/username/Documents/app/libs',
  'MyApp.swf',
  'icons',
  'Assets.car',
  'LaunchScreen.storyboardc',
  'purposeStrings.xml'
]

And try to install app using:

/Users/username/Documents/SDK/33/bin/adt [
  '-installApp',
  '-platform',
  'ios',
  '-package',
  'bin/MyApp.ipa'
]

Actual Result: Application cannot be installed with errors:

WARNING: could not locate iTunesMetadata.plist in archive!
WARNING: could not locate Payload/MyApp.app/SC_Info/MyApp.sinf in archive!
ERROR: Install failed. Got error "ApplicationVerificationFailed" with code 0xe8008015: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.UEdBMt/extracted/Payload/MyApp.app : 0xe8008015 (A valid provisioning profile for this executable was not found.)

Expected Result: Application should be correctly installed and works.

Known Workarounds

Build iOS app using Windows device or use AIR SDK 33.1.1.743.

ajwfrost commented 2 years ago

Hmmm.... so if it was working with 33.1.1.743 but not with 33.1.1.758 then it's most likely the change for #1602 that is causing this, which is an update for when we are using the native 'codesign' process (seems to have been mis-identified in our release notes...!)

Are you able to send us one of the IPA files that is failing? or if it's not possible to get the whole thing, if you can send us the executable file and the provisioning profile, we can check what the difference is there.

The logic is currently set such that if the certificate "subject" starts with "iPhone/iPad/Apple Distribution" then we treat it as a distribution certificate (vs a development certificate) and we put the get-task-allow = false value into the entitlements. There's also a 'beta-reports-active' addition but that should only happen for app store deployments rather than ad-hoc.. but, somewhere we are likely to have a mismatch between the entitlements and the signed executable flags..

thanks

ajwfrost commented 2 years ago

Found an issue with the detection of distribution certificates vs development certificates, this was being mis-identified hence the problem... will be fixed in our next release (which won't be too far away...)

itlancer commented 2 years ago

Fixed with latest AIR versions. Checked with latest AIR 33.1.1.821.