Does Defold have any plan to reduce the build size of the Android Release with the Android App Bundle in the later version?
I get the same message.
We have some plans yes, but nothing in our upcoming sprints (…yet. It might change soon)
Note that your gain is fairly small, the engine is ~3.5mb uncompressed for each Android architecture (armv7, armv8a).Compressed, one such engine is ~1.6mb.
As always, we are dedicated to keeping the builds as small and fast as possible, so the .aab feature is definitely something we’ll look into.
One such “build size” feature we have in the sprint is to start using ProGuard, to minimize the bundle size (we’re seeing a 5mb decrease in the .dex file)
Also it possible to upload two different
apk with different architecture as the one release: Multiple APK
You know why I get this message? I didn’t receive this message for previous versions. Currently my project is in closed alpha version. Thanks!
Google tried to motivate (or even force) use of their new feature because most applications are too big, we don’t have such a problem with Defold.
You shouldn’t have any problems with the release because of this warning.
We will look into the AAB format, but can’t make any promises yet. As @Mathias_Westerdahl points out the gain will be very small. The biggest advantage of AAB for large Defold games would be that it raises the allowed download size over 4G from 100Mb to 150Mb.
It is just a warning. I never heard that it will prevent roll out of an internal test. Can you please verify that it is the same problem?
Yes. we faced same problem when publishing flutter app and after submitting .aab file the issue resolved.
This is the detailed warning,
Can you please verify that you have completed the store listing and any other sections with a greyed out checkmark?
@uditha did it work?
After configuring all the store listing and any other sections it works. but kindly provide a solution for this problem(Export project to .aab file).
@britzl thanks for quick reply and guide
We plan to add AAB support this year but it will take several months before it is ready. We are not working on it yet. First step is to update to a newer app signing version. Then we can start looking into AAB support.
Any updates on AAB support?
Sadly, we still haven’t had time to start with this, the other gradle improvements were more urgent.
May I ask what your use case is? What do you wish to achieve with the AAB support?
Yes and no. No actual work has been done, but it’s now in the pipeline of things we want (and to some extent must) do in 2020. Our priority list of Android specific work items are:
- Android Billing 2.0 - New version with better fraud prevention. We should be able to update our IAP extension with support for billing 2.0 in May
- Google Play Services - Focus on more of the Game services. Next is Leaderboards which we should be able to support end of March/beginning of April
- Android App Bundles - June/July
- Google Play Instant
When it comes to Android App Bundles there’s a lot of functionality and we will not support all of it from the start. What do you see as the main benefit of the AAB format?
In my case - nothing special I’d need from AAB right now, but I just feel uncomfortable not going the way that Google persistently points me to
Yes I understand. As a first step we’ll start generating Android builds using the AAB format.
Solved in 1.2.170