• Building
  • Extreme attempts at reducing the .apk size of the game

I've been experimenting with apk size reduction lately and I'd like to share my experiences:

I have developed a quite simple snake clone (source) whose assets take up less than 300 kb of space. As you might already acknowledge, games exported for Android with default export templates usually end up taking lots of space even if they are so minimal in design. Thus, I built my own export templates without any modes or modules I don't need. By this way I managed to reduce the .apk size from ~30 mb to ~7 mb (and the installed app size from ~60 mb to 25-30 mb).

I think this is acceptable for an average game but I wanted to make this one as lightweight as possible, so I started to look for other methods to reduce its size. I tried to follow the steps mentioned in this Github issue when building new templates, but it was very troubling for me:

  • My game uses around 10 types of nodes so I tried to comment out all calls to nodes I don't use in scene/register_scene_types.cpp. For some reason, I couldn't observe any difference in the result. Thus, I just decided to erase the files themselves in my next try. It ended up giving lots of errors compiling as you might expect, many source files were referencing to each other. When I finally managed to get it working with all those missing files, it didn't turn out to be very efficient for me anyway: I could only reduce a couple of megabytes at best. I thought it wasn't worth risking the game's core stability so I reverted these changes for the time being.
  • I have tried to use ProGuard for further size reduciton but I couldn't get it working either. I have read that code shrinking is configured through the project's build.gradle file so I messed with platform/android/java/build.gradle a few times. It wasn't succesful: sometimes Gradle overwrote my modified file and sometimes produced a non-functional .apk build. Guess I just don't know the right configurations.
  • Also, a "compressed size" is mentioned in the Github issue, but I don't know if it would help me further reduce the game's size.

So, I think I will stick to my older reduced template for now. Did anyone else ever try such reductions too? How was the result or how did you manage to get it working? Or, do you know if newer versions of Godot plan to make size reduction easier?

Any feedback is greatly appreciated!

I have tried to use ProGuard for further size reduciton but I couldn't get it working either. I have read that code shrinking is configured through the project's build.gradle file so I messed with platform/android/java/build.gradle a few times. It wasn't succesful: sometimes Gradle overwrote my modified file and sometimes produced a non-functional .apk build. Guess I just don't know the right configurations.

I considered adding ProGuard support to the Gradle build process, but the code size reduction would likely be minimal since it only operates on Java code. In Godot, Java is only used to bridge the engine to Android; it represents a tiny part of Godot's codebase.

Also, a "compressed size" is mentioned in the Github issue, but I don't know if it would help me further reduce the game's size.

APKs are automatically compressed upon creation, as they're essentially ZIP archives. if someone refers to an uncompressed libgodot_android.so, they're talking about the native library size when it's not packed into the APK yet.

4 years later

Reducing the size of an Android application package (.apk) is often crucial for optimizing performance, user experience, and download times, especially for mobile games. Here are some extreme attempts and strategies for reducing the .apk size of a game:

Texture Compression: Implement aggressive texture compression techniques to reduce the size of image assets without significantly compromising visual quality. Tools like ETC1 or ASTC can be used for this purpose.

Asset Stripping: Remove unnecessary assets, textures, sounds, or levels that are not essential to the core gameplay. This involves meticulous analysis to identify elements that can be excluded without affecting the overall gaming experience.

Procedural Generation: Generate assets dynamically during runtime instead of storing them in the .apk. This approach reduces the need for pre-packaged assets, resulting in a smaller initial download size.

Code Obfuscation and Minification: Use advanced code obfuscation and minification techniques to shrink the size of the executable code. This makes reverse engineering more difficult and decreases the overall .apk size.

Dynamic Delivery: Utilize Google Play's dynamic delivery features to deliver only the necessary assets to specific device configurations. This ensures that users download only the assets relevant to their device, reducing unnecessary bloat.

Binary Size Optimization: Optimize the game's binary code by removing unused functions, classes, or libraries. Techniques such as tree shaking and dead code elimination can help in this regard.

Custom Compression Algorithms: Implement custom compression algorithms tailored for specific types of game assets. This may involve creating a balance between compression ratio and decompression speed.

Texture Atlases: Combine smaller textures into larger texture atlases to reduce the number of draw calls and decrease the size of individual texture files.

Audio Compression: Use efficient audio compression algorithms to reduce the size of sound files without compromising audio quality. Formats like Opus or Ogg Vorbis are commonly used for this purpose.

Conditional Loading: Implement conditional loading of assets based on in-game events or player progression. This ensures that assets are loaded only when needed, reducing the initial download size.