Up until very recently, all my Android development has been focussed on devices that have passed Google’s compatibility test suite. That is, devices that have included Google’s apps such as Gmail, Maps, and Market or as Google call them ‘Google Experience Phones’. Incidentally, there’s a great article How Google controls Android for those interested in why OEMs’ might choose (or not) to get their devices sanctioned by Google.
For situations where my or my clients’ apps have ended up running on non compliant end user phones, the situation has generally been buyer beware. If it works, all well and good but if it doesn’t then don’t expect any support. However, times are changing. With new devices such as the Amazon Kindle Fire and the shipping of larger numbers of ‘noname’ Android devices, there’s a greater expectation for apps to run on these devices.
A project I am currently working on needs to run specifically on one of these devices (not however the Amazon Fire) due to some unique technical features of the device. For reasons of commercial confidentiality I can’t elaborate more about the device or app but I can talk briefly about the problems and a technique I have had to use to get the app working.
The problem with non CTS tested devices is that the device APIs might not conform to the SDK. This manifests itself in two ways. The first can be APIs that simply don’t work. The other is that APIs have been added that you can’t see because they aren’t in the Google SDK. There’s not much you can do about the first problem but I have learnt that you will usually find a new API has been added to replace the one that doesn’t work. After all, the built-in device apps have to still work (after also having been modified by the OEM) so there’s usually an API to get things done, even if it’s not the official one.
How do you find and use the new non-official APIs? In practice, hardware OEMs won’t have veered too far from the official Android OS source code and APIs. They will have been concentrating on getting the device up and working and will have preferred to add new calls to existing Android classes rather than totally invent new software mechanisms.
Almost all of my problems have been solved by using Java reflection to inspect classes and discover new methods. There’s a great tutorial how to use relection at tutsplus. With some experimentation it’s possible to call these discovered methods.
Up until now, Android fragmentation has been minimal compared to other ‘old World’ platforms. However, as non Google sanctioned Android devices become more popular, developers are unfortunately going to need to be spending more time on coding for the differerences.