Androids

Androids, Androids... Where ever you look you see people using them. So it was about time we get Android support for our own in-house engine. While working for our publisher BigFishGames we had a deal that all our mobile projects in that time must support all 3 mobile platforms:

iOS
Android
Windows Phone

The iOS we got working pretty easy.There were few ups and down but we got it working. The Windows Phone was left to be implemented last as at that point in the time only 2% of all mobile users were using Windows Phone, the android was on its order. When we are implementing new platform we divide work on following parts:

OS Related Changes
Engine - Script Related Changes
Build Tool - Related Changes

OS Related Changes

OS Related Changes include all the changes that we need to do prior we start working on Engine / Scripts related changes. This changes may or may not include:

Supporting Right Graphics Driver and Texture Format
Supporting OS Events
Touch and different gesture handling
Services and different SDK

Supporting GPU Drivers and Texture Format

In that time we had very limited choice of which GPU Rendering Driver to use and which texture format. Taking in consideration availability of phones, quality and speed we have decided to implement ETC1 Texture Format and to work on OpenGLES2. Now you may told me that why did you use ETC1 you could use ETC2 or go to different formats!? The answer is simple: We knew ETC1 is expensive texture format, as it doesn't support alpha channel so you need to build it eaither sa separate atlas or as vertical alpha, then on GPU to split it, we still used it as majority of devices support it by default.As for rendering GPU Version from our research we saw in that time most supported OpenGLES version is 2.0, there were few of 3.0, 3.1, 3.2. You may also ask me: Why just one texture format, why dont we support multiple? The answer is that: Try to build right building system for all those textures and teach people! Well yeah we didnt want to confuse people when they are making atlas textures for android in choosing different varity so we stick with two types: BMP - for HD quality textures and ETC1 (ktx) for lower quality one.

Supporting OS Events

When it comes to supporting OS events i didnt had hard time figuring it out, but i did had a little bit hard time to figure out exact order or some events, or how on best possible way to report those events to our engine. There were 2 cases on which i had to considerate when implementing OS Events:

Engine is not Loaded -> Store Events and push them as soon Engine lib is loaded
Engine is Loaded -> Delegate Events to Engine System

This implementation used Observer / Delegate pattern with exception that it had a flag, if engine was loaded or not. Later on this system was used for reporting all other service based events to our engine.

Touch and different Gestures Handling

When you start working on mobile platform first what comes to your minde is:"How cool would be to use zoom (pich) features, or how about multiple touch!"
And this is very cool thinking as long the other systems designed around touch system can perform it. Currently due to design in our Engine, we have limited our self to only single touch events, so no multi touch :(, but geatures such as pinch zoom, swipe, drag or custom geatures could still be implemented. Luckly this didn't require us to work on native level to get it done as SDL did all that heavy work for us!
So Touch system was done

Services and different SDKs

This is when then hell started with me. So in our engine we always had hard time testing and implementing purchasing process for obviously reasons and on this platform it didnt go smoothly.
How so?
Firstly since we had to port all of our HOPA games to Android with our publisher BigFishGames we had to integrate their sdk, which controlls overall process of everything.
Rating the game, promotions, purchasing, content locking, ... With rating and promotions I didnt have trouble implementing it, but with purchasing, there were always back and forth with me and Bigfish SDK / Producer team. What is not configured right, what is left to be configured, what was needed to be configured but somehow information slept through...
Somehow i managed to get it working on GooglePlay but it was time now to get it working on Amazon. Suprisingly their API and SDK-s (at least for me) are much more simpler to use and i didnt have trouble implementing it what it was needed to get it going.
Ok so i got most of the all SDK's going and now well, now we reach at the point at something called .obb file.
Obb file is nothing other then game asset archive and it is used only if your main application is larger than 100mb and only on GooglePlay.
Great! Another archive like we don't have it already. Implementing obb is not so naive. Why!?
First you have to implement special downloader and validator for downloading obb file from google servers. Then you have to implement reading this obb file and this can get quite tricky.
For a while we had to make sure our obb was set to use Store compression and to not have password at all.
There were some problems between c++ and java communication while reading encrypted file within obb file. (This we solved later on.)
GooglePlay got working, now Amazon. It starts then BAM CRASH! And you must love debugging on Amazon and specially android at all. Most of them times you will be wondering between a lot of 0x0000 and 0xabacad values. Few and there you will get a valid response at least the one that make sense to you. And problem to become more harder all the crashes that occure are stored on special folder on device called tombstones, and this folder can only be accessed if you root your phone :( :( :( .
I have spent at least a week figuring out this and trying to make a sense from bunch of 1 and 0. But sadlly i don't know binary. I managed to solve this crash and turns out it wasn't hard just the errors were miss leading and solution to this crashing issue will be explained in Build Tools section.