Xamarin.Android "Generate one package(.apk) per selected ABI" option does not work

[JeroenBer]

What App Center service does this affect?
Xamarin.Android

Describe the bug
In Xamarin.Android there is a project option called "Generate one package(.apk) per selected ABI". When enabled it should generate 4 extra apk's: (arm64, armeabi, x86, x86_64). However after the app center build it is only 1 APK as output.

To Reproduce
Run the build. Download output.

Expected behavior
I expect an APK per ABI as output.

[patniko]

Hi @JeroenBer, we don't actually support this today, but have been looking at adding in support for it in the future. Switching this to a feature request for now.

[booker-dragon]

Supporting per ABI apk will be great but need to find out a way to handle the auto increment build version issue

[aeirola]

This would also be useful for React Native builds. React Native supports splitting the build into multiple APKs https://facebook.github.io/react-native/docs/signed-apk-android#split-apks-by-abi-to-reduce-file-size

[softlion]

In fact it's no more useful. All devices are arm64 nowdays. No more x86/x86_64 or armv7a.

[danieljgmaclean]

Actually this is a much higher priority feature than is initially obvious. Google made it clear in January that all Apps submitted from August 1st 2019 must contain a 64bit ABI as well as the regular 32bit ABI. I expect that many Apps will be able to fit both ABI's under the 100 MB APK size limit Google impose on uploads to the Play Store i.e. as a universal APK. But, some of us have apps already very close to the 100 MB limit with only a single ABI. This problem is easily fixed i.e. just upload an APK per ABI, however App Center does not support specific APK's per ABI. Come August 2019, you may find this issue gets way more attention. If this feature isn't implemented before August 2019, I'll have to avoid using App Center for supporting Xamarin Android apps which exceed 100 MB with the 64bit and 32bit ABI's.

[toomasz]

This feature is necessary for deploying any professional android app.

[nilofer]

Thanks for opening this request and the further detail. This greatly helps us when prioritizing future work! Will keep this open to track further interest.

[brodymerritt]

I would also like to be an advocate for this. I believe this is a crucial step for contributing to the full DevOps process using AppCenter for Xamarin Forms app, especially on the part of fulfilling an optimized Google Store production deployment without manual steps.

[scastria]

But even without the multiple apk's per ABI, what about universal apk's? When I build on my desktop, my apk is universal as it contains multiple lib/XXX for each ABI. However, the build that App Center produces, only contains 32-bit. How do I get App Center to generate a universal apk like my desktop?

[scastria]

I may have found the problem. My csproj file does NOT EXPLICITLY list the AndroidSupportedAbis. VS for Mac was showing 64 bit checked so maybe I am suffering from a problem with defaults. With no AndroidSupportedAbis listed, VS for mac defaults 64-bit as ON, but maybe App Center defaults it to OFF. I will explicitly add AndroidSupportedAbis in my csproj and see what happens with App Center.

[scastria]

Yes, that worked. Sorry to bother everybody, but maybe my experience will help someone else.

[dennispan]

Trying to understand this more. If we add support to build AAB for Xamarin.Android, is this still a critical issue to resolve?

[softlion]

If you manage to support AAB, it won't be necessary anymore.

[brodymerritt]

The primary issue to resolve here is AppCenter releases for both testing and the Google play store. If you manually upload any APK to the Google play store, it automatically shrinks the file size (even if it's over 100mb). To automate releases to the store, we need the files to be less than 100mb - apps with many features using xamarin, this isnt likely. For AppCenter, itd be nice to build both types of apks on my build config - bundled or individual. and when I want to release to the store, if it also took the MultiAAB apk or the individual apks for each CPU type and uploaded them all into Google play for a single release shrunk (like it does if you upload manually). Currently it would overwrite each release with an individual apk and not shrink them apk - thus only making 1 apk available.

[dennispan]

The spec and updates for the AAB work is shared in #194 . The gist is that we are working on building AAB and distribute to Store. Would love to learn additional thoughts if those aren't enough.

[MisterJimson]

One reason is distributing outside of the Play Store, like in China. No AAB support there, but we should have the option of doing both fat APKs and split APKs.

[jdepypere]

I appreciate the work that is done for AAB support in #194, but for me personally multiple apk support would still be preferred. A concern of AAB is that you need to give your signing keys to Google, since they create and sign the apk's for you. For this reason we are attempting to steer clear of AAB and split our own apk's for smaller filesizes & support for different abi's.

For us this is a deal breaker in using AppCenter for distribution for now.

[EmilAlipiev]

One reason is distributing outside of the Play Store, like in China. No AAB support there, but we should have the option of doing both fat APKs and split APKs.

same for Amazon Store. no aab is supported there.

[othorin]

It would also be good for App Center Beta distribution of apps. Currently our universal APK is ~140MB while the ABI specific ones are ~30MB.

[jonathanantoine]

Any update on this one 😁?

[nilofer]

@jonathanantoine no update to share at the moment, but we will continue to monitor this feature request!

[sim1986]

Is there any update on this item. As stated in the above comments it is extremely important to be able to upload multiple apks for different CPU architectures for a single release.

[ackava]

Xamarin.Forms apps are now failing due to size constraints, it is impossible to split apps using Bundles without reengineering entire app. As we are using many third party native libraries and it is a huge blocker now !!

[softlion]

Xamarin.Forms apps are now failing due to size constraints, it is impossible to split apps using Bundles without reengineering entire app. As we are using many third party native libraries and it is a huge blocker now !!

Activate "link user and sdk libraries", add some preserve attributes and it will fix your issue forever

[ackava]

@softlion What makes you think we are not doing it? Does that automatically link native libraries which are compiled in c/c++ ?

[user1701]

(React Native) I'm building APK per CPU architecture, but how I can download it with universal APK from the app center. I found out that after the build process runs android-postprocess.sh that removes all ABI dependent APKs. It is a crucial feature for our project because APK size is more than 100Mb and we have to use splits. Is the feature adding arranged?

[user1701]

@patniko Do you have updates about the feature?

[ttodorov-maf]

@patniko, that's a huge blocker, please update if it's in scope at all.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[ghost]

This issue will now be closed because it hasn't had any activity for 15 days after stale. Please feel free to open a new issue if you still have a question/issue or suggestion.

[EmilAlipiev]

this needs to be reopened? !

[m-sadegh-sh]

Any update on this?