I have an app that’s about 320Kb - 5mb on all other platforms, but is over 74 MB on Android with latest haxelib upgrades.
The app is just a test app with a single jpg image that’s about 300kb large.
I compile the app with a command: “haxelib run openfl run “C:\Users\CreativeMagic\Documents\TestApp\application.xml” android”
Also, the compilation takes over 10 min no matter if it was compiled before or a fresh compilation.
Any ideas how to get a normal size output file?
Did you try removing the export folder? Maybe there’s something in it messing with the build process.
My build folder is called “bin” since I use FD project template, but even I remove it - it’s still the same.
Are you measuring the size of your “bin” directory, or are you measuring the size of the final APK? There will be added file size in the export directory due to the C++ object code generated during compilation, etc, though this will not affect your final APK
The size is the size of a single APK file. I’m still investigating the issue, the APK is normal size if the project is created with a console, not through FlashDevelop template.
That’s a highly useful tidbit, that it’s different with FD than from the CLI. I’m also getting this behaviour, that e.g. flash target gives a 1.5 MB .swf, while android gives a 67 MB .apk. I’ll have to try CLI, I guess. Did you have any luck narrowing down the problem?
The APK is just a ZIP file so you can open it and check what is so heavy.
Good point. The culprit: “lib”, which is 229 MB unpacked. Yikes.
It’s split into x86 and armeabi, each of which have a libApplicationMain.so that takes up most of the space (100+ MB).
… which might, uhh, turn out to be necessary, because Android devices these days come in two flavors.
It’s a little bit unfair to compare the size of “an .swf file” to “a stand-alone executable,” because such a comparison completely ignores “the size of ‘the software that makes it go.’ ” Both an interpreted file, such as swf, and a dynamically-linked executable, can basically ignore this … albeit at the price of only being able to run in “appropriate” environments. A stand-alone executable must, by definition, “carry enough luggage with them to cover any eventuality.” Including, in this case, not-knowing which type of microprocessor(!) might be running the show.
Sure, but within each microprocessor you have a 100+ MB file.
It’s possible it was due to compiling in debug rather than release mode, since now I seem to be getting much more reasonable apk sizes (4 MB) than before. Indeed, a debug rebuild is now 70 MB total. Not sure what exactly changed since the 200+MB APK to make it only 70, but either way, release = 4 now.
Also, it’s a bit funny that it was including both arches in the first place, because I have <architecture name="x86" if="android debug" /> in my Project.xml. Shouldn’t that make it only include x86, and not arm?
Nope, that just makes sure the x86 architecture is included, in addition to whatever other architectures are there by default.
To exclude arm, you have to do this:
<architecture exclude="armv7" if="android debug" />
Oh! Thanks, that’s great to know (how to exclude, and that I wasn’t doing that.)
Is this a debug build? Curious why its so big. Lots of embedded assets?
Yes, as I mentioned the release build is much much smaller. No, hardly any assets.
Hi! I’m developing with HaxeFlixel, but I assume the problem goes beyond that library. I found out that embedding assets will add two copies of each asset to the APK, one as code (in libApplicationMain.so) and the other directly in the package (assets folder). In short, you shouldn’t command the compiler to embed assets for Android, for example (in Project.xml):
<assets if=“mobile” path=“assets/mobile/images” rename=“images” embed=“false” />