How to make Android App Bundle ( aab ) file from apk?

pozirk · September 30, 2019, 4:57pm

As for me, OpenFL now generates one .apk with armv7a and arm64 libs.
And I simply stopped uploading any x86 version.

bappydebp · December 9, 2019, 1:41pm

Just Change This line dddd

hoang_dung · January 9, 2020, 4:42am

I was able to upload multiple .apk files on Google Play Dev Console. One for 32 bit and One for 64 bit. The file sizes are decreased.
64-bit

>  <architecture name="arm64" />
>  <architecture exclude="armv7"/>

32-bit

> <architecture name="armv7"/>
> <architecture exclude="arm64"/>

gbelo · January 19, 2020, 6:00am

Hey, I’m getting the same error noted above:

Error

This release is not compliant with the Google Play 64-bit requirement

The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: 26.

Include 64-bit and 32-bit native code in your app. Use the Android App Bundle publishing format to automatically ensure that each device architecture receives only the native code it needs. This avoids increasing the overall size of your app. Learn More

This is with the following lines in my Project.xml (minus the spaces between < and architecture):

< architecture name=“arm64” if=“android” />
< architecture exclude=“armv7” if=“android” />

I’m using:

Lime Command-Line Tools (6.4.0)
OpenFL Command-Line Tools (8.2.2-LWWQ62)

Do you know whether I’d need different versions of either of these? Something else in my Project.xml? Any other info that I can paste that would be useful?

hoang_dung · January 19, 2020, 7:56am

You should upload two apk files at the same time using same versionNumber and different versionCode.

gbelo · January 24, 2020, 12:59am

Thanks for the feedback. I’ve got a more fundamental question, unfortunately.

In the lime/OpenFL setup, how do I change the versionCode? I searched through the files and I see references to versionCode and VERSION_CODE, but can’t see a place where it’s actually defined.

hoang_dung · January 25, 2020, 12:27am

You shoud create your own manifest file
And add it to the project.xml. You can google for a basic Androidmanifest.xml file.
https://player03.com/2014/08/14/template-basics/

gbelo · January 28, 2020, 8:20am

Thanks again. I’m leaving that issue aside from now and am looking to get a build up on Google Play that “just works” for beta testing – meaning that, say, I’m fine with one huge bloated .apk if it’ll get listed and I’ll optimize later. I’m also fine with only supporting 64-bit devices for now.

As I understand it, the lib directory in the .apk contains, well, the different versions of the libraries.

But even in including this:

<architecture name="arm64" if="android" />

I end up with lib/armeabi in my .apk, which I understand is a 32-bit library. My understanding is that I’d need to somehow include a arm64-v8a version instead. How can I go about that in the building process? Anything else I need in my Project.xml?

singmajesty · January 28, 2020, 9:37pm

I believe this is incremented automatically with each build or can be manually overridden using <meta version="" />. I think you also can force it on the command-line using --meta-version=

Holger_Wagner · January 30, 2020, 9:20am

Is <architecture name="x86_64" /> supported?

singmajesty · January 30, 2020, 8:01pm

I believe it would be <architecture name="x64" />

I think the current Lime should be all set up to configure this architecture properly but whether it builds depends upon the HXCPP toolchain… it might not have been working fully last I tried?

EDIT: We do support ARM64 though and include it by default in Android builds, in-case that’s what you’re looking for

Holger_Wagner · January 31, 2020, 8:33am

Yeah, that was what i was looking for!
But when i used it, liblime-x86_64.so was missing. I had to hack Architecture.X64 into HXProject.hx for the lime rebuild to create it

gbelo · January 31, 2020, 8:15pm

I’ve tried grabbing the latest lime and OpenFL–

Lime Command-Line Tools (7.7.0)
OpenFL Command-Line Tools (8.2.2-LpgCLS)

– but I’m getting this:

Error: OpenFL 8.2.2 is not compatible with Lime 7.7.0 (version 6.4.* is required)

Is there some toolchain with versions of these that are compatible and that support arm64?

singmajesty · January 31, 2020, 9:26pm

You can try adding -Ddisable-version-check to allow OpenFL 8.2 to build with Lime 7.7 (I’m not sure if it would be compatible or not?) or changes from the Lime tools could be backported for an older release

gbelo · January 31, 2020, 11:24pm

No luck, unfortunately – doesn’t look like lime 7.7.0 and OpenFL 8.2.2-LphCLS are compatible. But from what I can tell, it’s due to something missing on the lime side that OpenFL now checks for…?

C:\HaxeToolkit\haxe\haxelib run lime build “project.xml” android -64 -Ddisable-version-check C:/HaxeToolkit/haxe/lib/openfl/8,2,2/src/openfl/display/Stage.hx:7: characters 7-25 : Type not found : lime.app.Preloader

If I run through Stage.hx and simply comment out what’s missing, it looks like there are three packages OpenFL can’t find:

lime.app.Preloader;
lime.graphics.Renderer;
lime.ui.Mouse in LimeMouse;

And then, of course, past that, other files break (e.g. DisplayObject.hx can’t find lime.graphics.utils.ImageCanvasUtil), which is to be expected…

singmajesty · February 1, 2020, 12:08am

Have you tried a newer OpenFL version with your app?

gbelo · February 1, 2020, 1:37am

I thought I was using the latest but I wasn’t – .dev specified 8.2.2 and .current specified the latest (8.9.6), so I had to make sure I was using .current. Thanks for the catch.

With 8.9.6, it gets farther.

Link: libApplicationMain-v7.so
Error: Source path “C:/HaxeToolkit/haxe/lib/lime/7,7,0/ndll/Android/liblime-x86_64.so” does not exist

In that directory, I have a liblime-64.so among others, though. I’m not sure why it’s trying to include an x86_64, since I’ve specified

<architecture name="arm64" if="android" />

and the output seems to verify that it’s using arm…?:

C:\HaxeToolkit\haxe\haxelib run lime build “project.xml” android -64
Creating C:/Users/greed/Documents/Temp/lst/builds/export-released/android/obj/obj/android-v7/__pch/haxe/hxcpp.h.gch…

Compiling group: haxe
arm-linux-androideabi-g++ -Iinclude --sysroot=C:\Users\greed\AppData\Local\Android\ndk\android-ndk-r10e/platforms/android-16/arch-arm -IC:\Users\greed\AppData\Local\Android\ndk\android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.8/include -IC:\Users\greed\AppData\Local\Android\ndk\android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi/include -DHXCPP_ARMV7 -DHXCPP_VISIT_ALLOCS(haxe) -DHXCPP_API_LEVEL=331(haxe) -IC:/HaxeToolkit/haxe/lib/hxcpp/4,0,64/include -Iinclude -fpic -fvisibility=hidden -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -Wno-overflow -D_LINUX_STDDEF_H -Wno-psabi -DHXCPP_CPP11 -DHXCPP_ARMV7 -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -fomit-frame-pointer -fexceptions -fno-strict-aliasing -finline-limit=10000 -DANDROID=ANDROID -DHX_ANDROID -DHXCPP_ANDROID_PLATFORM=16 -Wa,–noexecstack -O2 -DNDEBUG -c … tags=[haxe,static]

src/__ASSET__levels_dlc_5_tmx.cpp

src/openfl/system/SecurityDomain.cpp [haxe,release]

But the error leads me to this thread: Does openfl support 64-bit devices on Android?, though it also seems to deal with x86_64.

singmajesty · February 3, 2020, 11:44pm

We don’t include x86_64 builds for Android in the Lime releases right now. Could someone using the dev version of Lime try lime rebuild android -64 and see if it works with the current version of HXCPP?

Holger_Wagner · February 4, 2020, 7:00am

Works like a charm with hxcpp: [4.0.64]

gbelo · February 6, 2020, 4:25am

In toying around, I think I’ve got a better understanding of what’s going on here:

From what I can tell, lime’s including -v7.so as it should… but it’s also trying to include -x86_64.so and it sounds like it shouldn’t be. Is my interpretation correct? Is that what it should be doing, or should we expect a different sort of behavior?

I’m currently running through building the dev version of lime (branch ‘develop’) and will try that as well when I can.