As most of you know, I have been working on my wife’s game, Notespace, for the last year. It has been an epic adventure filled with joy and peril but treacherous waters of publishing on Android. You can avoid a lot of the problems by publishing multiple builds per texture compression but every now and then you get those sharp rocks that come out of no where. And that, for me, was the mysterious crashing on Kindle Fire HDX devices.
Now before I move on, for those that don’t already know, Android devices use an array of GPU’s where as iOS devices only use one (Power VR). This generally does not affect you in anyway except when it comes to texture compression that has alpha. Unity’s default Android compression setting is ETC 1/ RGBA16. What that means is that it will compress power of 2 textures with no alpha as ETC 1 (an older OpenGL format) and will set compressed textures with alpha to RGBA 16. On average, RGBA16 will be at least double the size as your compressed texture so it has the ability of sending your GPU memory usage over the edge. That being said, I have not actually seen that happen on a device but that kinda means nothing on Android with a gazillion devices on the market. Whats more important is that 16 bit textures can look really bad, especially if you have a lot of gradient work. So there is 2 ways around it. 1) Build a custom shader for your compressed images with alpha that takes in the RGB compressed texture and an Alpha 8 texture that contains your alpha. Its actually easy to do but can be a production nightmare. 2) Make 4 separate builds 3 that target the different GPU’s texture compression, and one as a fallback.
To do this, in the build settings window, once you have switched to the android platform, use the drop down box to specify your compression. Then make a build. Easy as that… but their is a small catch. Unity already alters you AndroidManifest.xml to restrict the installation of this build to the GPU compression type but its up to you to handle the order its all checked in. You do this by managing the build int/number. The fallback needs to be the lowest number and all the other builds will need to be successively higher. I increment my build int by ten for new release, and then increment the successive builds by one… like so
- ECT1 / RGBA 16: 01, 11, 21, 31, etc.
- ATC: 02, 12, 22, 32, etc.
- PVRTC: 03, 13, 23, 33, etc.
- DXT: 04, 14, 24, 34, etc.
Remember, upload the lowest build number first! You can only add to Google Play builds that are higher build numbers. If you do it in the wrong order you will have to rebuild all your builds with new, higher numbers.
Amazon, is slightly different. With amazon you only need to make 3 builds. 2 builds that are Kindle Fire exclusive builds and one for all the other android devices out there. This is not quite as ideal as the google play store but it allows you to ensure the Kindle Fire experience if fantastic! So for Amazon, you only need to make the first three:
- ECT1 / RGBA 16: 01, 11, 21, 31, etc.
- ATC: 02, 12, 22, 32, etc. (Kindle Fire HDX devices)
- PVRTC: 03, 13, 23, 33, etc. (All other Kindle Fire devices)
I am not quite sure if on Amazon it matters that you change your build number but its still a good practice. In the Amazon build settings, they will give you check boxes to specify what devices the build is for so its pretty straight forward. The thing to note is that all non Fire devices will be served the ETC 1 fallback because they only allow you to specify a single build for the non Fire devices that use the Amazon App Store. I have not found a way around this but hopefully they will change this soon. So make sure that your ETC 1 fallback is as tight as you can make it.
The Kindle Fire HDX Conundrum!
So now, the app is beautiful. Its been battle tested, banged on, tweaked, polished and approved. Its been working great on all the devices in the office and I have done the long and tedious nights of making production builds, checking them and uploading… playing a little Cookie Jam while I watch progress bars I’ll confess. Everything is good until we hear that the Amazon build fails. It straight out crashes on HDX devices. I’m internally freaking out because this is really weird and I was confident in my code and structure. I tweak some things and re-upload (with more Cookie Jam) and it passes. Yay, but wait! Amazon has a great Developer Select program. We almost qualify but don’t because… we are crashing on HDX. The Developer Select program is pretty amazing (you peeps should look at it if you are dev-ing for Amazon) and we need all the publishing help we can get so I run out To Best Buy and grudgingly fork out the dollars for the HDX device. And its true. Straight up crash!
After a couple hours of tinkering around, building testing and sleuthing the answer is … drum roll please …
*** Force OpenGL ES 2.0 ***
Turn out that the Adreno GPU they use for the Kindle Fire HDX can behave strangely with Unity android builds. It supports OpenGL ES 3.0 but in some cases, it causes a fatal error. Unity allows you to set “auto select” in the player settings for OpenGL type but if you don’t absolutely need OpenGL ES 3.0, OpenGL ES 2.0 is your best safest friend! After that, smoooooooth sailing! And now, I think I might need a little Holiday season drink!
For those of you that have an Android or Kindle Fire tablet, check out Notespace, my wife’s beautiful game. Its a musical activity book for girls and has some great stuff in there. It will be up in the iTunes store soon (oh please oh please oh please Apple Review gods!) Give us a rating (a good one would be nice) and I’ll shoot you over a promo code for some its content. Its free with IAP. We had a great musician work with us and, if you win all the 7 tuning forks, you can download the album to your device from the game. Happy Holidays!