How can I include both ARMv7 and ARMv8?

[Boycraft123]

Hello,

I am updating an existing HARMAN AIR / Adobe Animate based Android app, and I would like to support both 32-bit and 64-bit Android devices.

As far as I understand, HARMAN AIR / Adobe Animate only allows one processor target when publishing an Android APK:

• ARMv7
• Intel x86
• ARMv8

So I cannot find a way to include both armeabi-v7a and arm64-v8a in the same APK.

My questions are:

1. Is there any official way to create a single AIR Android APK that includes both ARMv7 and ARMv8 native libraries?
2. If not, is the correct approach to create separate APKs for ARMv7 and ARMv8 with the same application ID and different versionCodes?
3. Is there any recommended workflow for HARMAN AIR apps that need to support both existing ARMv7 Android devices and newer ARMv8 / Android 16 devices?

Any advice would be greatly appreciated.

Best regards,
Yuki

[krotname]

There are two different cases here: APK and AAB.

For a single APK, ADT does have an all architecture value. The AIR docs for adt -package -arch list:

armv7
armv8
x86
x64
all

and describe all as a universal APK containing all architectures. So if you package outside the Animate UI, the single-APK route is:

adt -package -target apk-captive-runtime -arch all ...

For Google Play, though, the better current workflow is usually an Android App Bundle. The AIR docs say AAB is the Google Play publishing format, and the Android descriptor docs now have buildArchitectures:

<android>
    <buildArchitectures>armv7,armv8</buildArchitectures>
</android>

That setting was added to override IDEs that do not expose the newer packaging options. The docs say the default is armv7,armv8,x86,x64; setting armv7,armv8 keeps both ARM ABIs and drops Intel ABIs.

So I would use one of these:

• For side-loading / non-Play distribution: package with ADT and -arch all, or set buildArchitectures if using a current AIR SDK that supports it.
• For Google Play: build an AAB and set <buildArchitectures>armv7,armv8</buildArchitectures> if you only want the ARM targets.
• Separate ARMv7 and ARMv8 APKs with the same application id and different version codes is the fallback if you are stuck on an older toolchain/UI path, but it is not the nicest current Play workflow.

Docs:

• adt -package -arch: https://airsdk.dev/docs/building/air-developer-tool/commands/package#-arch
• Android descriptor buildArchitectures: https://airsdk.dev/docs/building/application-descriptor-files/elements/android#buildarchitectures
• Packaging Android App Bundles: https://airsdk.dev/docs/tutorials/platform/android/packaging-android-app-bundles

[Boycraft123]

Hello,

Thank you for the information about -arch all and buildArchitectures.

I did some further testing, and I have now been able to create a universal APK containing both ARMv7 and ARMv8 libraries by using a newly created .p12 certificate.

The successful setup was:

• A newly created .p12 certificate
• Java 21 from Android Studio
• adt.bat executed directly from the command line
• -arch all

The generated APK was confirmed in Android Studio to contain both:

• armeabi-v7a
• arm64-v8a

So the -arch all workflow itself appears to work correctly.

However, the issue remains with my old .p12 certificate.

The same old .p12 certificate works correctly when I publish from Adobe Animate. I manually cleared and re-entered the password in Animate, and Animate was able to publish the APK successfully.

However, when I use the same old .p12 file and the same password from the command line, adt fails to open the keystore.

I tested the certificate in an English-only folder path:

F:\sample\adt_build\zetsumetsu.p12

I also tried passing the password directly with -storepass, but I still get the same error.

Example:

adt -checkstore -storetype pkcs12 -keystore "zetsumetsu.p12" -storepass "****"

Result:

could not load keystore file (password may be incorrect - keystore password was incorrect)

I also tried Java keytool with the same .p12, and it reports:

java.io.IOException: keystore password was incorrect

So the current situation is:

• Adobe Animate can publish successfully with the old .p12 and password.
• adt -checkstore fails with the same old .p12 and password.
• Java keytool also fails with the same old .p12 and password.
• A newly created .p12 works with direct ADT packaging.
• With the new .p12, adt -package -target apk-captive-runtime -arch all successfully creates an APK containing both ARMv7 and ARMv8 libraries.

The old .p12 certificate may be quite old. It was probably created around 10 years ago or more, possibly with an older Adobe AIR / Animate workflow.

Could this be related to an old PKCS#12 format, encryption method, RSA key size, or compatibility issue with newer Java / keytool / direct ADT usage?

Is Adobe Animate using a different signing process or compatibility handling compared to calling adt.bat directly?

Most importantly, is there any recommended way to use, convert, or re-save an older AIR signing certificate so that it can be used from direct ADT packaging, while keeping the same signing identity for app updates?

Any advice would be greatly appreciated.

Best regards,
Yuki

[krotname]

@Boycraft123 Yes, I would treat this as a keystore compatibility issue, not an -arch all issue.

ADT uses Java/JCA for code signing, and AIR's signing docs say the ADT keystore options are the Java keystore path (-storepass, -keypass, -storetype, -alias). So if Java 21 keytool and command-line ADT both fail on the old .p12, the current Java keystore provider probably cannot read that PKCS#12 file as-is.

Animate can still work if it is using a different bundled signing path/JRE, stored key password, or compatibility path. I would not assume that means the file is readable by Java 21 ADT.

I would try this order:

1. If the old certificate has an alias or a separate private-key password, pass them explicitly:
   adt -checkstore -storetype pkcs12 -keystore zetsumetsu.p12 -storepass ... -keypass ... -alias ...

2. Try reading it with an older JDK, especially JDK 8:
   keytool -list -v -storetype pkcs12 -keystore zetsumetsu.p12

3. Try OpenSSL's legacy PKCS#12 reader:
   openssl pkcs12 -legacy -info -in zetsumetsu.p12 -noout

If OpenSSL can read it, re-export the same private key and certificate into a modern .p12:

openssl pkcs12 -legacy -in zetsumetsu.p12 -nodes -out zetsumetsu.pem
openssl pkcs12 -export -in zetsumetsu.pem -out zetsumetsu-converted.p12 -name zetsumetsu

Then verify the converted keystore:

keytool -list -v -storetype pkcs12 -keystore zetsumetsu-converted.p12
adt -checkstore -storetype pkcs12 -keystore zetsumetsu-converted.p12

zetsumetsu.pem contains the private key, so keep it offline and delete it after the converted keystore is verified.

For app updates, the important part is that the private key/certificate stays the same. Re-exporting the same key into a new .p12 keeps the signing identity. Generating a new .p12 with a new key does not, unless this is only a Play App Signing upload-key situation where Google lets you reset the upload key.

Before uploading anything, compare the certificate fingerprints from the old/recovered key, the converted .p12, and the currently published APK/AAB or Play Console entry.

Docs:

• AIR ADT signing options: https://airsdk.dev/docs/building/air-developer-tool/option-sets/code-signing-options
• OpenSSL PKCS#12 legacy option: https://docs.openssl.org/4.0/man1/openssl-pkcs12/
• Android app signing keys: https://developer.android.com/studio/publish/app-signing