Add aab (Android App Bundle) support

[misl6]

This PR adds aab (Android App Bundle) support to buildozer.

Shouldn't be merged until kivy/python-for-android#2467 is ready and merged into the p4a develop branch.

TODO:

• Force CI to build against aab-support branch of python-for-android (Not needed, aab-support branch for python-for-android has been merged in develop)
• We should add a CI test for aab (Tests are done in buildozer android release step)
• Document the (currently non-breaking) change from arch to archs (in buildozer.spec + warnings during run)
• Document the android.release_artifact usage (in buildozer.spec)
• Add a "missing migration" warning if the buildozer.spec uses arch instead of archs
• Add a "missing migration" error if the python-for-android pinned version doesn't have AAB support.

[ricrudo]

Hi, I confirm that this branch works both for independent APK and AAB, and the bundle was accepted by Google Store. Well done Mirko, Congratulations!

[tshirtman]

Didn't test, but looks good to me, and as others confirm it works :)

[RobertFlatt]

Tested this and it appears android.arch is ignored, and replaced by android.archs

A debug or release build of an existing buildozer.spec will default to android.archs = arm64-v8a, armeabi-v7a, which will produce a multi architecture apk. In the debug case (which is most builds) this will be an issue.

For backwards compatibility, I suggest removing android.archs and making android.arch a list.

[misl6]

@RobertFlatt , I think we reached both my target and yours with the latest changes. Can you take a look?

[RobertFlatt]

@misl6 misl6

@RobertFlatt , I think we reached both my target and yours with the latest changes. Can you take a look?

Works for me. 😀

This is my understanding of the current behavior https://github.com/Android-for-Python/Android-for-Python-Users#release-builds perhaps you could sanity check?

Unrelated to Buildozer, building Pillow with the develop p4a, now seems like the gating issue. For me kivy/python-for-android#2497 (comment) addresses the issue. Though I don't understand enough to know if there are side effects.

I also tried some new (for me) tests - just more confirmation of all good:

Run times with p4a develop are about the same as p4a master, and using p4a develop a two architecture build adds very roughly 60% run time to a one architecture build.

I also built a debug apk including androidx and Java source, which installed and ran.

Much to my surprise adb successfully installed a two architecture debug apk (picking one).

[tito]

Hi,

Since latest p4a broke android.arch numeric_version (different arch compilation ends up with the same numeric version)
I tried this PR and changed android.arch to android.archs with both arch.
It worked, and got an aab.

But deploy function doesn't work anymore, as it is not possible to install an .aab file with adb install.

My current method was to install bundletool on the system and i did manually:

bundletool build-apks --mode universal --bundle bin/myapp-0.3.5-armeabi-v7a_arm64-v8a-release.aab --output ./app.apks
bundletool install-multi-apks --apks app.apks

If by default this PR build aab, deploy command should be updated at the same time

[tito]

It got mentionned on discord that there is a configuration token to configure the output: either APK or AAB.
IMO, building in debug should always be APK no ? As there is no way to publish on google play APK in debug.

More than AAB, since buildozer is made for helping user, we could generate AAB + APK by default (especially in release mode). As APK is required for testing prior publication, and AAB for publishing.

[misl6]

@tito : Building both apk and aab, with the actual code, needs 2 builds passages and some not-so-small changes.

Considering that on Google Play Console there's a chance to set up an internal test (fast path) or external test (requires a validation) that could be used to test the AAB prior publication, how it sounds to merge this PR and then open a feature-request that targets the apk+aab build?

I'm thinking about something configurable as it follows:
android.release_artifact = aab --> Only release AAB is built (Already implemented)
android.release_artifact = apk --> Only release APK is built (Already implemented)
android.release_artifact = all --> Both AAB and APK are built

The main reason is the lack of time to implement these changes at this time, cause I'm prioritizing the Apple Silicon support 🔨 , but there's also a high demand for AAB support on buildozer mainstream.

[yukhnovskiy]

Hi, I have a question. If I changed locally p4a aab related changes in .buildozer (as I have a lot of my own changes there, no time to update to latest) and also buildozer.spec, and relevant buildozer aab related changes. But I still have apk created, not aab. Is it mandatory to invoke buildozer clean and buildozer init (I don't want to make p4a replaced in .buildozer)?

[tshirtman]

Any reason not to merge this? Seems pretty much mandatory at this point :)

[misl6]

Any reason not to merge this? Seems pretty much mandatory at this point :)

Considering that checks if the python-for-android pinned version is compatible with aab doesn't need to wait for a new python-for-android release, so let's merge it :)