Android App Bundle (.aab) Support

[quinnbot2]

Issue:
Currently, AppCenter is only able to upload traditional .apk files to the Play Store. This is problematic for a number of reasons - foremost for my team because we are very sensitive to the download size/time of our app.

Request:
The Android App Bundle (.aab) is a much preferred way of uploading to the Play Store as it reduces the final app download size for the end user. It does so by deferring .apk generation to the Play Store itself, meaning the that end user only ever has the slimmest possible download for their specific platform, screensize, and language.

Feature has been available in Android Studio as of version 3.2 (Sept last year) so it seems within reason to ask for support on AppCenter. Additionally I believe it can be run via CLI so there is no dependence on the IDE.

https://developer.android.com/guide/app-bundle

[patniko]

We are constantly evaluating when the right time is to work on this and are very interested to know whether or not other users looking at this issue want it too.

[Eric-Dunaway]

React Native started supporting Android App Bundles (.aab) in React Native 0.58.

It would be nice to have this supported in App Center now that Google is mandating 64bit builds. And universal apk builds are ballooning in size.

[TheChrisGlass]

We definitely want this supported, too. As there are higher (150MB) file size limits on the Google Play Store for aab files, and there's an upcoming deadline to support 64-bit executables, we want to bundle both the 32-bit and 64-bit executables in the same file for ease of building, testing, and distribution.

By August 1st, all Google Play Store apps will need to have a 64-bit executable
https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

[xtal0]

We would like AAB support as well. Right now we are building both the AAB and APK so we can distribute for testing via HockeyApp. It would be nice to build just one artifact and know that the artifact that is being tested is the same artifact that is going to the Play Store.

[yuewah]

Unity also support AAB too. APK with 64 bit add ~20MB

[bed42]

We would very much like AAB support

[yamov]

🙏

[Sammekl]

We would definitely want this as well. It would save us about 15MB on a 35MB app

[heheok]

We also would like AAB support.

[davichaves]

We are also looking to get AAB Support

[msioen]

Adding my voice here as well in support for this feature request. Seems to be a must have with the 64bit requirements for the play store.

[terijyu]

+1

[efeyc]

+1

[zmugraby]

We are also looking to get AAB Support

[ghost]

This is a feature we would also love to see added ASAP.

[ianduke]

Google is strongly pushing app bundles. I'm very interested in this feature.

[softh]

🙏
We are also looking to get AAB Support

[rodineijf]

We are also looking to get AAB Support

[romsrini]

We would also love to get AAB support

[quinnbot2]

There is only 2 months left till Google's deadline for 64-bit apps... Can we get a progress update on this issue?

[Johan-dutoit]

Got this email today, would be great to get this in

By August 1, 2019, all apps that use native code must provide a 64-bit version in addition to the 32-bit version in order to publish an update. This past January, we reiterated that this is required in order to make way for innovation and in anticipation of future Android devices that only support 64-bit code.

As the deadline approaches, we wanted to remind you that at least one of your apps* uses native code but does not currently offer a 64-bit variant:

[c-lamont]

Android wouldn't know what a .resx file is, so I don't see how bundletool/Google Play would be stripping it from a .NET assembly..

Indeed, so the language support from Android is not appropriate in this case.

I must also point out I can't be certain the .resx file is being removed, only that it appears to have been removed as only English text is shown.

I'll try create an issue. However I have removed the .aab file from the Play Store so I can not download it again to inspect it. If you would like the .aab file or .apk file then let me know where to send it.

[matthiaswenz]

Good point @jonathanpeppers.
@c-lamont if you don't find a convenient way to share these details within the issue over on https://github.com/xamarin/xamarin-android/issues -
feel free to create a conversation in the App Center portal support chat and reference this conversation so it can be triaged correctly.
Ideally, provide the URL to the build in question and optionally the AAB/APKs

[dansiegel]

@c-lamont since resx files are embedded resources as a debug in production sort of thing you might add something for yourself to see what resources are embedded in the assembly...

foreach(var name in GetType().Assembly.GetManifestResourceNames())
{
    Console.WriteLine($"Found embedded resource: {name}");
}

[c-lamont]

feel free to create a conversation in the App Center portal support chat and reference this conversation so it can be triaged correctly.

Good idea, I'll start a conversation there.

[losmacko]

We've just shipped .aab support for Xamarin.Android apps! Give it a try and reach out with any questions or feedback.

Worked great!

However it has removed my Dutch .resx language file and everything is in English now. The .apk file has no issues.

Any fixes for this?

I have the same issue

[jonathanpeppers]

Everyone can follow the issue with resx here: xamarin/xamarin-android#3596

The issue is that the localization assemblies are compressed, and .NET assemblies must be uncompressed in Xamarin.Android:

14848        14848  assemblies\UsingResxLocalization.dll
 3584         1279  assemblies\de-CH\UsingResxLocalization.resources.dll
 3584         1275  assemblies\de\UsingResxLocalization.resources.dll
 3584         1306  assemblies\es\UsingResxLocalization.resources.dll
 3584         1273  assemblies\fr\UsingResxLocalization.resources.dll
 3584         1286  assemblies\id\UsingResxLocalization.resources.dll
 3584         1348  assemblies\ja\UsingResxLocalization.resources.dll
 3584         1280  assemblies\ms\UsingResxLocalization.resources.dll
 3584         1302  assemblies\pt-BR\UsingResxLocalization.resources.dll
 3584         1301  assemblies\pt\UsingResxLocalization.resources.dll
 3584         1288  assemblies\zh-Hans\UsingResxLocalization.resources.dll
 3584         1288  assemblies\zh-Hant\UsingResxLocalization.resources.dll

I should have a fix shortly.

[gcastaldi]

@msioen Manual upload of AAB is supported in App Center only for distribution to the Play Store at this time. Our goal with this feature was to enable the typical scenarios for developers which involve AAB at this stage, which we identified earlier as being able to build an app with an AAB and distribute said AAB to the Play Store.

App Center itself currently does not support distributing AABs directly to users of App Center, as AAB is not an installable format itself and a lot of the process that goes into building the respective APKs from the AABs for individual devices is internal to Play Store.

You will be able to push AABs to Store destinations through App Center's portal and the API (as well as the Azure Pipelines task) but not to App Center distribution groups or individual testers. If that is what you're looking for, I would recommend opening a new feature request for this specifically, although based on the discussion here above, there would be a lot of effort connected to getting full support of AABs in App Center Distribution.

For me this feature is enough. I want to upload aab in AppCenter only to be sent to playstore, but I don't find a way to to that.
My application is configured with release type 'Store' (the other options are 'Alpha', 'Beta', 'Enterprise', 'Production'), is this enough to specify that the destination is the Google's playstore?
When I go in Releases and try to do a new release the only format I can upload is apk.

[dennispan]

@gcastaldi See if this helps (in case you haven't seen it): https://docs.microsoft.com/en-us/appcenter/distribution/stores/googleplay#publish-your-aab-to-the-google-play-store

[jonathanpeppers]

a lot of the process that goes into building the respective APKs from the AABs for individual devices is internal to Play Store.

Just to put this out there, the tool behind App Bundles and Google Play, bundletool is on Github and open source: https://github.com/google/bundletool

Google did this so that third parties could support the App Bundle format. It seems completely feasible to make a web service that could deliver device-specific APKs using bundletool. I am not aware of any doing this yet, but I would guess someone like the Amazon App Store would be one of the first.

[matthiaswenz]

Indeed, building individual APKs which are targeted at specific device and runtime configurations is possible with bundletool - I might have not been specific enough:
The distribution, transparent delivery and background installation of these configuration or feature module APKs however is handled in concert with a component on device such as Play Core library - which only supports downloading from Play Store.

I'm not saying this is impossible to also replicate a similar functionality for App Center, i.e. in App Center's SDK - it is currently not on our roadmap.
If other app stores will support processing and distributing from AABs in the future, this is something we will consider supporting - note, that we currently only support Play Store and Intune as stores for distributing Android apps.

[slang25]

I've had a situation where I only found out about a bug (related to AAB packaging) once we got to our Google Play closed track.

Supporting extracting APKs from AAB in AppCenter is a must for us.

[johnthiriet]

In our case, we do not build our application using AppCenter but using Azure Devops directly with our own mac machines. Our process is the following one :

• Azure Devops Build
• Azure Devops Release -> Push to AppCenter Distribute
• AppCenter -> If we are happy push to the store.

It is a pity that AppCenter handles AppBundle when it build it itself but we cannot send one.
I would be ok for AppCenter not being apple to deliver a working app using bundletool for the moment as long as we can push a aab file from Azure Devops and then decide to push it to Google Play Store from AppCenter.

Please consider this scenario which is a real pain for us and prevents us from totally considering the move to AppBundles.

[Maragues]

@matthiaswenz couldn't appcenter use the mode=universal flag?

bundletool build-apks --bundle=my_app.aab --output=my_app.apks --mode=universal

According to the documentation

Set the mode to universal if you want bundletool to build only a single APK that includes all of your app's code and resources such that the APK is compatible with all device configurations your app supports.

We use Jenkins and appcenter plugin to distribute the application. If we have to upload an .apk and also generate an .aab, our CI build times will suffer a lot.

[aaronlabeau]

Really wish AAB was supported to go from Azure Dev Ops to App Center. This is a big problem for us and really makes using App Center almost impossible for Android for complex pipelines. Any word on getting support for this working?

[nilofer]

@aaronlabeau can you share more about what you're expecting for Azure DevOps and App Center integration? Distributing to testers or the store?

[matthiaswenz]

@Maragues Yes, this is what App Center could do - however it has implications on what the distribution part of App Center would have to do or how to decide which artifact to forward to distribution from a completed build. In its current form, the distribution pipeline only supports one artifact to upload per release.
As a workaround, you could perform an AAB build and then using a post build script build the universal APK from it, and upload it to App Center using the included CLI on the build agents.

[Maragues]

@matthiaswenz thanks, that's our plan. Our only fear is that testers won't actually test the artifact we deploy. That's why it would be ideal if appcenter supported app bundle format.

I understand a huge infrastructure like yours needs to put a lot of thinking into each decision. Thanks for the support and looking forward to the development of this feature request

[aaronlabeau]

@aaronlabeau can you share more about what you're expecting for Azure DevOps and App Center integration? Distributing to testers or the store?

We would like both. We use App Center for our QA team to quickly get builds. Those builds if signed off are published to Google Play or Microsoft InTune.

[carstenhag]

For some reason I can't give +1 to the above commenters, but our workflow is the following:

• Azure Devops Pipeline for just the CI on master branch
• Pipeline to build development releases for tester, built via DevOps and distributed via AppCenter
• Pipeline to build prod releases for the Play Store, built via DevOps and distributed via the Play Store.

We already fixed bundle-specific issues, which we luckily found while regression-testing on the "third"/final pipeline. We would have found it earlier though, if we also had been able to use bundles on the second pipeline.

[godboutj]

@c-lamont since resx files are embedded resources as a debug in production sort of thing you might add something for yourself to see what resources are embedded in the assembly...

foreach(var name in GetType().Assembly.GetManifestResourceNames())
{
    Console.WriteLine($"Found embedded resource: {name}");
}

We did work around that by downloading the languages package at runtime or on user demands through the native Play API from Xamarin. This work well, just needed to add the Google Play wrapper to access native library.

[godboutj]

@msioen Manual upload of AAB is supported in App Center only for distribution to the Play Store at this time. Our goal with this feature was to enable the typical scenarios for developers which involve AAB at this stage, which we identified earlier as being able to build an app with an AAB and distribute said AAB to the Play Store.

App Center itself currently does not support distributing AABs directly to users of App Center, as AAB is not an installable format itself and a lot of the process that goes into building the respective APKs from the AABs for individual devices is internal to Play Store.

You will be able to push AABs to Store destinations through App Center's portal and the API (as well as the Azure Pipelines task) but not to App Center distribution groups or individual testers. If that is what you're looking for, I would recommend opening a new feature request for this specifically, although based on the discussion here above, there would be a lot of effort connected to getting full support of AABs in App Center Distribution.

You could simply convert the .aab to given .apk:
https://stackoverflow.com/questions/53040047/generate-apk-file-from-aab-file-android-app-bundle

just need to call the bundletool:

bundletool build-apks --bundle=/MyApp/my_app.aab --output=/MyApp/my_app.apks --mode=universal
--ks=/MyApp/keystore.jks
--ks-pass=file:/MyApp/keystore.pwd
--ks-key-alias=MyKeyAlias
--key-pass=file:/MyApp/key.pwd

AppCenter could generate the universal .apk out of the .aab and serve it on demand.

[icyleaf]

Hello everyone, I would like to recommend an open source project zealot, the latest release 4.3.0 version already supports .aab file format upload and parsing, the project supports docker self-deployment is very simple, welcome feedback on any suggestions: https://github.com/tryzealot/zealot

[mikaoelitiana]

Hi @icyleaf is there a way to find English documentation for the project?

[thisisthekap]

@icyleaf English docs would be very much appreciated.

[icyleaf]

@mikaoelitiana @thisisthekap Yeah, i published the English document: https://zealot.ews.im/docs/next/user-guide/

[fash97]

apk doesn't work with Play Asset Delivery. If AppCenter supports apks, that will unblock developers using Play Asset Delivery.

[heart2friend]

App Center In-App updates are failing when aab is uploaded. Getting error message "Failed to install app updates". any idea how to resolve it?