Working on Flatstone Grove is fun. We get to talk about bees, making honey, why flowers are so colourful, child development and sometimes worms. We also write a lot of code and use quite a bit of Unity, including the Addressables system. But, roughly two weeks ago, we had a few non-fun days. Out of the blue, when starting the app on Android, the Addressables system started throwing CRC errors. We knew we had something to fix.
Investigation phase 1
At first, we thought we uploaded incorrect platform data. It is not immediately apparent to everyone, but the output is supposed to only run on the target platform. We organise our data into platform folders on the CDN provider we use. We have one for Windows and one for Android, and so on. If you accidentally upload Windows-specific data to Android, the app running on the platform won’t like it. When checking the data files, we noticed that our automated build publish solution contained a bug, which resulted in uploading way too many and potentially incorrect files. Yaay – I thought we caught it.
We didn’t. We ran the builds, re-published the data… and the CRC error was still there.
Investigation phase 2
I looked online, and people recommended turning off CRC checking in the asset groups for CRC errors. That sounded like a hack rather than a fix. I gave it a try. The player no longer reported the CRC errors, but for some reason, the app stopped working. So this was not a solution either.
I started doing what I should have done the first time around, finding out which change in Git broke the functionality. First, we locked the main branch, so we don’t have new changes piling up on a broken base. Then, I started traversing the branch backwards, getting each change and testing it.
It was quite a lengthy process as each change needed a complete data build. Finally, after many steps, I found the change that caused this problem. Before I get to it, here’s a bit of background.
A while back, we noticed that the inspector in Unity became unusably slow. When renaming an instance of anything, it took seconds to see the characters appear in the field. It turned out to be caused by the current, verified, version of the Addressables system. We saw a newer version, but as it was not marked verified, we decided not to upgrade in case something else in it would cause issues. So instead of upgrading, we decided to fix the problem differently.
It seemed the slow-down was related to assets not directly marked as addressables. It turned out we had a few materials we used via their parent folder. When setting them as addressables, the performance was back to normal. So we had them manually added to the asset group and had their parent folder added to the same group. This setup, not sure why caused CRC errors in the runtime.
In the end, the fix was to remove the assets from the group, keep their parent folder in and upgrade to the non-verified version of the Addressables system. So, a tiny change caused many hours of pain. This one was one of those fixes where testing every change came with a considerable delay due to building and deploying data, thus making the whole process feel very long.
Thanks for reading. I hope it was helpful for you.