How to build an APK that supports multiple architectures

[yutfa]

trafficstars

I want to build an APK that contains two ABI directories, arm64-v8a and armeabi-v7a, how can I do that, thanks@ajwfrost

[ajwfrost]

You'd need to do this via Android Studio ..

If you are using the latest AIR SDK, there's an option to just output the Android Studio project (-target android-studio) or else if you uncomment the KeepAndroidStudioOutput=true line in the SDK's "lib\adt.cfg" file, you will end up with an Android Studio project folder under 'AndroidStudioProject'.

Then if you open up that folder in Android Studio, in the 'Android' view you should be able to open the Gradle Scripts section and find one something like:

build.gradle (Module: application-name.app)

(which is actually just in the project folder, subfolder "app", filename "build.gradle").

It will have a section 'android', i.e. something like:

android {
    some stuff...
    defaultConfig {
      other stuff...
    }
    compileOptions {
        more stuff...
    }
}
dependencies {
...

and you just need to add a 'splits' section to it:

android {
    some stuff...
    defaultConfig {
      other stuff...
    }
    compileOptions {
        more stuff...
    }
    splits {
        abi {
            enable true
            reset()
            include "armeabi-v7a", "arm64-v8a"
            universalApk false
        }
    }
}
dependencies {
...

I believe this then will generate individual APKs for both of the ABI types, but also a 'universal' APK that contains both of them together..

See https://developer.android.com/studio/build/configure-apk-splits.html#configure-abi-split

thanks

[Policy56]

@ajwfrost, do you believe that it would be feasible to construct an APK with multiple architectures in a future version of AIR SDK ? I've got an CI/CD to build APK or AAB and automatically deploy it. And I can't manually change build.gradle file to do your workaround ...

Thanks

[ajwfrost]

Hi

Can I check what you're trying to achieve with this? It's possible to create an AAB, which has the multiple architectures, and this is then what you'd need in order to upload anything to the Play Store. I'm not actually sure what usage there might be for an APK that contains multiple architectures; if you're just using this internally then would it be equally viable to just run the build multiple times i.e. once for each of the required architectures?

From the actual required steps that we'd need to do here: a) currently (for APK generation rather than AAB) we already add the 'splits' section and then just write whichever of the architectures that's been requested b) so we'd need to have a way to recognise that multiple architectures should be included, and adjust the gradle file generation slightly (this adjustment is the easy bit!) c) we'd also need to check the output here, grabbing just the 'universal' APK and ensuring that's the one that then gets signed and renamed to be the desired output file

In terms of knowing that multiple architectures are required, we have a setting in the application descriptor file under the path "application.android.buildArchitectures" where multiple architectures can be set .. but this is used for overriding things (as well as for limiting what goes into an AAB file) so e.g. if you wanted an armv8 APK but your IDE was always calling ADT with 'armv7' on the command-line, you can use this to override it.

Ultimately then, it would be possible to switch the behaviour so that the 'buildArchitectures' list, used in combination with a request for an APK file (and perhaps only where the '-arch' command is excluded?), is used to create a multi-architecture APK?

I'd have a slight concern that we'd start outputting multi-architecture APKs when people may not actually want that.. but potentially we can enable this capability only with a different -arch argument..

And actually, given we had introduced (but then never really used) an 'all' option when we were putting the original Android App Bundle support in there, I just tried that with the APK argument. When building with the gradle mechanism, this does actually then package up the runtime library in all of the available architectures, although it doesn't add this 'split' option into the gradle script .. which may actually help, because it then doesn't create individual ones as well as a universal one?

So there may need to be some refinement, but could you please try updating your set-up so that you call ADT with the command line that has -target apk -arch all?

Assuming that does work, we could then look at refining it (limiting what architectures go into it, in case you're not interested in x86/x64) via that buildArchitectures setting in the app descriptor..

thanks

[Policy56]

Hi, Thank you for your answer.

The customer, who I work for, need to deploy an app on the PlayStore with an APK only... (Because the application was created before 2021, it is possible to deploy APK, else it is only AAB yet.)

The security of customer's information system are forcing us to manage APK only, and block all requests with AAB.

He want to get the app on Chromebook, with armv7 architecture, and play store need 64bits app.. And he got an error on play store when he try to publish : Release is not compliant with the Play 64-bit requirement. The followings APKS are available to 64-bit devices, but they only have 32-bit native code. That's why i can't have multi APK for each architecture..

I tried to make and APK with -target apk -arch all and with <buildArchitectures> armv7,armv8 </buildArchitectures> , but it didn't work.. they have only armv7 arch inside the APK..

[ajwfrost]

So, either you could create two different individual APKs, with the armv8 one having a slightly increase version code in it, and then if you upload both of these I think it should be acceptable to the Play Store.

Otherwise, yes we'd need to have a way to create a single APK that has both 32-bit and 64-bit ARM code in it. For the above, are you able to share the ADT log to see what's happening here? it may be that something is overriding this.. (to get the log, you can update your configuration file adt.cfg to add 'DebugOut=true' and then check the file '~/adt.log' - or simpler is to just have AIR SDK Manager installed and running with the Troubleshooting tab...)

thanks

[FliplineStudios]

So, either you could create two different individual APKs, with the armv8 one having a slightly increase version code in it, and then if you upload both of these I think it should be acceptable to the Play Store.

This is how we still update all of our older Android apps from before AAB was used (and how they were released to begin with). You just have to upload both APKs (armv7 and armv8) in the same release, and Google will accept it as meeting the requirements. We just updated a ton of apps within the last month and they were still accepted with this method, so it's still supported just fine.

[Policy56]

Thanks for all your reply.

I found a solution to build the APK with multi architecture -> Firstly, I build AAB with <buildArchitectures> armv7,armv8 </buildArchitectures> -> Then, I convert the AAB to APK using this python tool : https://github.com/idzresearch/aab-to-apk-converter

That's a workaround to make it, thanks

[Policy56]

Fixed in AIR SDK 50.2.3.7 release

[Alxx9]

Thanks for all your reply.

I found a solution to build the APK with multi architecture -> Firstly, I build AAB with <buildArchitectures> armv7,armv8 </buildArchitectures> -> Then, I convert the AAB to APK using this python tool : https://github.com/idzresearch/aab-to-apk-converter

That's a workaround to make it, thanks

Can you help me at something please