The AAB of our game is ~1GB in size.
As expected, GooglePlay refused it, because of the 150MB size limit.
I then used the Unity-internal splitting feature (Android Publish settings → Split Application Binary) to create an AAB with AssetPacks.
I was shocked to see that this creates a UnityDataAssetPack-master.apk which is 2,9GB in size! Three times the size of the unsplitted AAB. GooglePlay now of course rejects it because it violates the 2GB total size limit.
What is the reason behind the fact that the AssetPack APKs are generated uncompressed in the AAB?
Is there a possibility (and is it even feasable) to get them generated compressed?
I read a lot about the possibilities to generate custom AssetPacks out of Adressables/AssetBundles, but if these will also be created as uncompressed, then that will not solve my problem at all.
It will not be possible to reduce the total asset size of our project by a whole 1GB to stay within that limit.
Does anyone have a suggestion about what options/alternatives we have to get the app to Google Play?
Is the only option for us to host the Assets at an own CDN or in the Unity Cloud?
When examining the generated UnityDataAssetPack-master.apk, it can be seen that everything under assets/bin/data gets added uncompressed to the apk (See the 7z screenshot → Method: store).
This looks like a bug to me.
No, we don’t have custom gradle templates yet.
I exported a gradle project, and here is our launcher gradle.conf (The unitylibrary gradle.conf has the same noCompress line. I don’t know which of them applies to the AssetPacks)
We tested it with Unity 2021.1.28f and 2021.3.16f with the same results.
Gradle Version : 4.0.1
Compile Sdk Version : 31
Target Sdk Version : 31
BuildToolsVersion : 30.0.2
Something seems to be fishy in the generation of the UnityDataAssetPack:
Steps to reproduce:
Use Unity 2021.3.f16 (but it should be reproducable with any version supporting the “Split Application Binary” AssetPack generation)
Have a unity project with at least a second scene with some assets in it (so that the “Split Application Binary” option will generate an install-time UnityDataAssetPack)
Build an AAB with the Split Application Binary option, using the internal gradle config (no custom gradle files).
Extract the APKs from the AAB using bundletool.
Observe that the generated UnityDataAssetPack-master.apk contains unompressed assets. Because of this, it can become very large.
The size of this APK matters when uploading the AAB to google play. It gets rejected when larger than 1024MB (install-time pack limit) or 2048MB in total (total size limit), and this can happen very fast because it is not compressed.
Here is another thread, where a user explains the explosion of the apk size, including stats from the google console:
I digged a bit into the problem:
It seems that how bundletool generates the APK depends on the BundleConfig.pb in the root of the AAB.
Unity’s BundleConfig.pb (decoded using protoc.exe) has the following content:
The "uncompressed_glob"s do not match any of the uncompressed asset files. Refering to the .proto-File for BundleConfig.pb (see bundletool/src/main/proto/config.proto at master · google/bundletool · GitHub) install-time AssetPacks should default to compressed content. And refering to gradle.conf of the UnityDataAssetPack module (see the built Gradle project) it is configured to be install-time. So the content should get compressed in theory. The mystery is, why it does not.
Another observation is that the AssetPack-PostProcess Job in the Unity Android Build toolchain (UnityEditor.Android.PostProcessor.Tasks.PreparePlayAssetPacks/AssetPacksDistribution:WarnAboutSizeLimits)
also seems to add up the uncompressed asset sizes for giving warnings about it being too large.
This indicates to me that somehow it could be on purpose that the UnityDataAssetPack-master.apk does not get compressed.
However, having generated an uncompressed Master-AssetPack will make the feature absolutely unusable, because it lets the download size double or triple, and making it often impossible to meet Googles size limit of 2GB.
Should I report this to the Unity Bugtracker or is there any unknown purpose behind it?