[BUG] 1.8.x generates extremely large AAB/APK (300MB-900MB)

Hi everyone,

I’ve encountered a serious issue when building my watch face project using Watch Face Studio version 1.8.x. Whether I export as AAB or APK, the resulting file size is extremely large — typically between 300MB to 900MB. This makes publishing and testing quite difficult.

However, when I use Watch Face Studio 1.7.x, the same project builds into a much more reasonable size — around 10MB to 20MB.

Has anyone else experienced this issue with version 1.8.x?
Is there something new in the build process or settings that could cause this dramatic file size increase?
Any advice or workaround would be greatly appreciated!

Thanks in advance :folded_hands:

edited:
I did some deeper testing, and I think I’ve found a way to consistently reproduce the problem.
It seems that if the project contains a large number of images that use conditional expressions in the Color field, like this:
[SC_PER] < 50 ? 100 : 0
Then the build process creates duplicated copies of the same image in the final APK/AAB file.
But when I remove these expressions, the APK size becomes normal again — no redundant images.

I did some further investigation by unpacking the generated AAB/APK files.

It turns out that there are hundreds of duplicated image assets inside the package — the same images are copied many times. This seems to be the main reason for the huge file size.

This issue only happens when I build using “Publish” mode.

When I use “Run on Device”, the debug APK generated under rod_<watch_face_name> is totally fine — it’s only around 20–30MB, which is expected.

So the problem seems to be related specifically to the publish build process in version 1.8.x.

I believe this might be a bug in Watch Face Studio 1.8.x.
If anyone from the official team is reading this, please take a look :folded_hands:

This issue is currently preventing me from updating my published watch faces, as the file size exceeds the acceptable limits.

Thanks again, and I really hope this can be fixed soon!

I’m sorry to hear that you’re having trouble with your work.

It would be helpful if you could tell me your work environment first.
Is it a Windows or Mac environment, and what design the watch face is.
In my case, it’s 2-3 MB, whether it’s AAB or APK.

It has quite a few design elements, but the capacity is not large.

I’m using 8.10 in a Windows 11 environment.
The watch design is made with CorelDRAW (a vector image creation tool).

-example

Thank you so much for your kind reply — I really appreciate it! :folded_hands:

To answer your question:
I’ve tested this issue on both Watch Face Studio 1.8.7 and 1.8.10, and on both macOS and Windows environments. Unfortunately, I encountered the same problem across all setups.

My watch face design is quite complex — it includes many conditional layers and logic, as well as a large number of graphical assets.
Even in normal cases, the final build size would be around 10–20MB, which is understandable given the design.
Here is my Watch Face: https://play.google.com/store/apps/details?id=com.linkt.stepquest
But when the publish build balloons to 300MB+, it becomes a serious issue, especially for end users trying to download and install the watch face.

Thanks again for your attention.

wow…even 10-20 MB is absolutely huge to me. I rarely have .AAB’S over 1 MB and I am not one of those “simple/boring” watch face makers. I make all my assets in Illustrator and Photoshop and save them as .png’s and my faces certainly are not simple. Many faces such as my tourbillons and Isometrics have numerous layers and components. I am not using much in the way of logic and conditional layers though. I really have no explanation for how you can have files that are so big? how much can one pack into a 450x450 work space? :grinning_face: I’m curious to find out!

EDIT: but hey, you got 10K downloads on it so WTF do I know anyway?

1 Like

Thank you for your curiosity and follow-up!

Yes, 10–20MB does sound big compared to many simpler faces — but that’s because my design involves dozens of backgrounds, characters, and enemies. Each background alone takes up about 100–300KB, and that’s just one part of the asset library.

In WFS 1.7.13, these assets are packed correctly without duplication, keeping the total size within a reasonable range.
But in 1.8.7 and 1.8.10, every single asset seems to be duplicated 10+ times in the AAB, which causes the final file size to grow exponentially.

That’s why I’m confident this is a build bug, rather than a matter of design optimization. Hopefully the dev team can look into it.

Thanks again for the interest — it’s always fun to compare different creative approaches :grinning_face_with_smiling_eyes:

2 Likes

Some times if you Load and save a Face File a few times the memory load gets reduced as the cache is cleared . But I guess you have done that a few time looking at it .

Yes, I’ve definitely tried various methods like saving, reloading, and cleaning the project — but unfortunately, the issue persisted.

However, today I did some deeper testing, and I think I’ve found a way to consistently reproduce the problem.
It seems that if the project contains a large number of images that use conditional expressions in the Color field, like this:

[SC_PER] < 50 ? 100 : 0

Then the build process creates duplicated copies of the same image in the final APK/AAB file.
But when I remove these expressions, the APK size becomes normal again — no redundant images.

So it looks like the issue is specifically triggered by conditional expressions in the Color property when used across many images.

Hope this helps narrow it down further!

2 Likes

It migt be worth going back and tying
( [SC_PER]<=50?100:0)
I know it is a bit childish to use the () I sometimes helps .

1 Like

Thanks a lot for the suggestion! :folded_hands:
I actually tried using parentheses as you mentioned.
Unfortunately, the issue still persists. :cry:

Looks like it’s something deeper in the build process that only the official team can fix.
For now, I guess I’ll either have to wait for a fix or keep using WFS 1.7.13, which still works fine for my needs.

Really appreciate your help and insights! :blush:

1 Like

I note that the change history for WFS 1.8.7 mentions “optimizing aspects of … resources”. I wonder if WFS has taken it upon itself to edit image files (presumably to be of more appropriate sizes). If the algorithm is sloppy, it could result in duplicating images instead of reusing them.

3 Likes

Yes, your suspicion is quite plausible.
I’ve compared the APK generated by WFS 1.8.7 and 1.7.13, and the internal structures are noticeably different.

1 Like