"This app isn't compatible with the latest version of Android." - Android 14.

[phitrti]

I'm kinda lost on this one. I've searched the web, this community, and I just don't know where to start.

We have an app targeting Android SDK 33. We are using the latest AIR 51.1.3.8. It runs great on Android 13. The exact same .apk, when running on Android 14 displays the "This app isn't compatible with the latest version of android." message. Changing the target sdk to 34 makes no difference. We use Distriqt ANEs but I downloaded the latest when I downloaded 51.1.3.8. The app works on Android 14 but it sure would be nice to figure out what is causing that popup message.

I've looked at screen sizes, build architectures, etc and I'm just not finding what I need to change. I have
<buildArchitectures>armv7,armv8,x86,x64</buildArchitectures>

and the adt.cfg has:
DefaultArch=armv8
OverrideArch=armv8

I tried commenting the arch keys in adt.cfg out as well as it is unclear which takes precedence (buildArchitectures xml vs. adt.cfg) much less if the architecture is even the issue. I haven't found a solution yet.

Any ideas?

[FliplineStudios]

I believe by default, APKs built with AIR are going to only contain one architecture, and that warning will pop up if you're installing an APK from a different architecture than the device expects -- for example, installing an armv7-only APK onto a device that supports armv8. (Android re-uses that same warning pop-up message for all sorts of errors, not just when it's related to the version of Android).

Have you checked whether your APK is an armv7 or an armv8 one? A quick method to check is to rename your .apk as .zip, then open that and look in the lib folder, and you should see what platform it's built for in there (armeabi-v7a, arm64-v8a, etc.)

I believe there's a loosely-documented way to build an APK that contains all architectures, though I've never tried it myself since Google requires AAB instead of APK for new apps now.

[phitrti]

Thanks for the pointer about looking at the lib folder. Yes, only armv7 was being generated. When I added -arch all to my adt command, I got all 4 outputs.

But I'm a little confused. The documentation https://airsdk.dev/docs/building/application-descriptor-files/elements/android#buildarchitectures which says: "The default is armv7,armv8,x86,x64 which means an Android App Bundle would include all of the supported platforms." I assumed ADT looked in the manifest to determine what to build since this overrode the command line adt -arch. With the default being those 4, does ADT not produce all 4 outputs since that is the default. Even when I specify that element in the XML and have no specific -arch argument to adt, I still only get armv7. Also note in this scenario that the 2 arch variables in adt.cfg are commented out.

Is there some other element that also comes in to play? Right now, buildarchitectures seems to be ignored and the only way I can get an architecture is adt -arch all.

[FliplineStudios]

I think that's the default for an Android App Bundle (AAB file), but not for an APK file. APK likely still uses armv7 as the default if you don't specify an -arch flag when you call ADT, since in the past APKs were always one architecture only and you had to build multiple APKs to upload to the Play Store (back when Google still allowed APK). AABs will normally have all of the architectures, unless you specify you want to drop some of them with that buildArchitectures option.

I believe DefaultArch and OverrideArch were the original elements that would force Animate or Flash Builder to build an APK with armv8 if you set it there (since you can't use -arch with those tools), but if you were able to edit the adt call yourself that was a more straightforward way to specify the -arch you wanted... I'm guessing if you do supply an -arch flag it ignores those settings in adt.cfg, though I'm not sure what takes priority for that.

Is there a reason why you're trying to build an APK (or multiple APKs) rather than an AAB?

[phitrti]

That makes sense, thanks for that explanation. For scientific research mobile apps, sometimes we provision the hardware (phones, tablets) to give to the study participants after they consented to the study. In this case, we bypass the app store and just provision the hardware directly with the .apk. And other studies, we go through the app store (aab). It really depends on the study protocol what we need. As a software dev, I try to keep things flexible for them so the technology doesn’t get in the way of the science.

…

-Randy From: FliplineStudios ***@***.***> Date: Tuesday, March 25, 2025 at 9:17 AM To: airsdk/Adobe-Runtime-Support ***@***.***> Cc: [Technology] PHIT ***@***.***>, Author ***@***.***> Subject: Re: [airsdk/Adobe-Runtime-Support] "This app isn't compatible with the latest version of Android." - Android 14. (Discussion #3722) EXTERNAL: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I think that's the default for an Android App Bundle (AAB file), but not for an APK file. APK likely still uses armv7 as the default if you don't specify an -arch flag when you call ADT, since in the past APKs were always one architecture only and you had to build multiple APKs to upload to the Play Store (back when Google still allowed APK). AABs will normally have all of the architectures, unless you specify you want to drop some of them with that buildArchitectures option. I believe DefaultArch and OverrideArch were the original elements that would force Animate or Flash Builder to build an APK with armv8 if you set it there (since you can't use -arch with those tools), but if you were able to edit the adt call yourself that was a more straightforward way to specify the -arch you wanted... I'm guessing if you do supply an -arch flag it ignores those settings in adt.cfg, though I'm not sure what takes priority for that. Is there a reason why you're trying to build an APK (or multiple APKs) rather than an AAB? — Reply to this email directly, view it on GitHub<#3722 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFCUWSHAGLBDOQHUJGOOBRD2WFJOJAVCNFSM6AAAAABZV4XEHGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRRGUYTSMA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ajwfrost]

Thanks @FliplineStudios for clarifying this :-)

One thing to add - if you're using ADT, you can use the "-installApp" command with an AAB file to install the app onto any phone. Internally, it uses the Android bundletool to create an APK that's compatible with the connected device.

Alternatively - you can create a universal APK file from an AAB via ADT "-package", e.g.

AIRSDK/bin/adt -package -target apk -storetype pkcs12 -keystore your_store.p12 -storepass xxxxxx universal.apk input.aab