5.3f1 works nice but made my APK 52mb when it was only 32mb

5.3f1 works nice but made my APK 52mb when it was only 32mb why is that?
I didnt change anything and the textures are compressed normal.
I build with mono.

 

Bug report with project so we can be sure we know what the source of the problem is?

 

Ok, did that, 745440 case

 

Thanks, ushering it along through the QA process to investigate.

 

Please let me know if you get a reply from QA - im intrested in such issues..(smAll increase compared to my game ios (500mb) android (155mb) im sure something to do with textures..not specific to beta 5.3

 

Ok

 

Any news on my case?

 

Yes for ours, Android is 25MB bigger, and iOS is 70MB bigger.

 

Through QA and in developers hands. Still investigating.

 

In my case 30mb -> 80mb (for android).

 

thanks god Im not the only one!
In my case 25.3mb -> 98.6mb (ANDROID) totally insane.

 

I got a respond for the bug I submitted: "We were able to reproduce this issue and it will be forwarded to developers."

 

Not much info then, curious to know what is causing it?

 

Textures got broke and not compressed because they're being set to streaming. Investigating.

 

I hope this problem will be solved until you release the final version. This is critical.

 

Whats your size on IL2CPP?

 

Didn't try but last time I tried it was double.

 

Just encountered this bug as well: 140 MB -> 500 MB

 

Any news on this?

 

You guys should try to find ways to make our APKs a lot smaller not bigger!

 

Fix landing for RC3 that the async texture upload ability will be excluded on Android since it doesn't support that pathway for various technical reasons. (This restores apks back to 5.2 sizes)

 

Any plans for making the APK smaller somehow in the future?

 

It's always a concern for us, and we're looking always to see what's possible. However, there is nothing explicit in our roadmap in this regard as of yet.

 

Can you add the ability to save the graphics atlases in WEBP format in resources in the device and then convert them to each device graphics on load? This option will slow down the initial load but will make the game 50-70% smaller. I use this with a house build engine with SDL2 and I made a PNG adventure game from 250mb to 60mb in android with 2 seconds more time loading at the first load. This was huge.

 

I see you already have the feedback request:

https://feedback.unity3d.com/suggestions/webp-atlas-support-for-smaller-binaries

Thanks for that feedback. As you (and the commenter in your feedback entry) noted there are trade-offs, and they will need to be weighed against the various other possibilities.

 

So what about dithered 16-bit images, anyone planning to implement that?

I remember some Unity employee saying that all build size problems would be addressed with the upcoming asset compression. Now we have asset compression but it's only for asset bundles and there's "nothing explicit on the roadmap".

 

I know there are some trade-offs but it would be nice if we have the choice to do this. Implement a checkbox to activate or disable it. Many developers want to have the ability to control the size of the game. If you can do this with compressions I dont care, just do something towards this direction. And its no big deal to load the atlases at runtime from PNG or WEBP, it doesnt take that long and if it doesnt support texture compressions I can live with that.

 

This.

I know I was disappointed to find out that the much praised LZ4 compression turned out to be only for asset bundles, and not for all data as hyped. One option for 32 bit images is to use (crunched) DXT1 compression, so they don't take as much storage space. On Android they will be decompressed back to 32 bit (and Tegra devices can load them as is). Doesn't help with iOS though, it crashes quite badly when there are DXT1 textures present, so PVRTC needs to be used there.

In any case LZ4 for all player data would be the best option, to avoid using lossy compression for textures that need to stay nice and clean. Maybe some day.

 

https://feedback.unity3d.com/suggestions/png-and-jpg-texture-format
This feedback item has quite a lot of support and been around for almost 5 years. I have a hard time understanding why this can't just be implemented already. Yes, there are trade-offs but give the game developer the option so they can decide between the trade-offs.

 

I totally agree