Godot version:
All supported branches:
master: ffcb5cd3.0: 49929c12.1: f2a42e1OS/device including version:
Android 9.0+
Issue description:
Google's Android team just announced new requirements for 64-bit support in Android APKs, starting in August 2019.
The gist of it is that we need to include 64-bit libraries in the official templates APKs for our supported releases. By 64-bit architectures, Android implies arm64-v8a and x86_64. They do not deprecate 32-bit, so we should still provide armeabi-v7a and x86 libraries.
As far as I can tell, the current state of our releases is:
armeabi-v7a, arm64-v8a, x86: needs x86_64armeabi-v7a, arm64-v8a, x86: needs x86_64 (source)armeabi-v7a, arm64-v8a, x86: needs x86_64 (source)So it seems like we're all set for 64-bit ARM already, but we need to add x86_64 support. Currently platform/android/detect.py doesn't support x86_64 at all, but it should be trivial to add, then backport to the 3.0 and 2.1 branches to eventually prepare new releases.
3.1-beta2 ships x86_64 templates
This is OK for 3.1, so assigning to 3.0 milestone so that we remember about it for the next 3.0.x release.
Is there any plans for Godot to support Android App Bundles to combat the problem of growing .apk package size once we must include 64 bit libraries?
my android app got warning from google about 64bit requirement, my app is use 2.1.5 release.

is there a solution for this warning?
@SMaiLubis are you using official android templates?
@volzhs if you mean Godot_v2.1.5-stable_export_templates.tpz, yes i already use it.
and i use custom package for admob.
so you are using your own template for android.
you need to compile arm64 and build apk.
I'm not sure we backported the arm64 build support to the 2.1 branch yet, needs to be done and release 2.1.6 soon-ish.
I hope it will release soon (before August).
Is the only other way are migrate to 3.0 or 3.1?
I'm not sure we backported the arm64 build support to the 2.1 branch yet, needs to be done and release 2.1.6 soon-ish.
Actually it's referenced right above, the PR I made for arm64 support has been cherry-picked to the 2.1 and 3.0 branches. So you can compile the current 2.1 branch with android_arch=arm64v8.
I updated the docs for 2.1 and 3.0 (will be up in ~30 min): http://docs.godotengine.org/en/2.1/development/compiling/compiling_for_android.html
I'm not sure we backported the arm64 build support to the 2.1 branch yet, needs to be done and release 2.1.6 soon-ish.
Actually it's referenced right above, the PR I made for arm64 support has been cherry-picked to the 2.1 and 3.0 branches. So you can compile the current 2.1 branch with
android_arch=arm64v8.
The current 2.1 branch is 2.1.5 stable?
@SMaiLubis The current 2.1 branch is what's available on GitHub as 2.1 :slightly_smiling_face:
It's not the same as the 2.1.5 stable release.
Current status:
2.1 branch with 2.1.6-stable.3.0 branch, but we still need to release 3.0.7-stable with x86_64 binaries.master and 3.1 branches since 3.1-stable.Just a reminder, we're way past 2019 August 1st, and it has been over 1 year since Godot 3.0.6.
Does this issue still need to be open?
Google just sent me a "last-minute" reminder:
[Action Required] Create a 64-bit compliant version of your app(s) by February 1, 2020
My (3.1) apk included arm64 but only 32-bit x86 (as it wasn't available in the 3.1 template set).
Before I try it: It is possible (by switch) to build the x86_64 template in the 3.1 (or 3.1.2) release branch?
If not then I'd either have to release a version/apk without x86 or build my game with some beta brach by Februrary 1.
@wombatstampede Release your game with 3.1.2-stable, which contains the x86_64 template.
Edit: Actually, 3.1-stable also has x86_64 support already, as described in this issue. So you just need to tick the arm64v8 box when exporting.
@akien-mga What's the status of this? 3.0 is no longer linked from the main site. Since the work has already been done for 3.0 anyway, perhaps you should just do a 3.0.7 release (at which point we can just never touch the 3.0 branch again...?).
There isn't a lot of demand for a new 3.0.7 release, so indeed, I think we can consider this fixed.