In the Code Pollution series, I’ll be writing about topics where a coding anti-pattern may work tactically for an individual application, but strategically will be bad for Android as a whole, just as pollution may benefit one firm while harming many others.
Android has a fairly rich SDK — take it from somebody who’s been writing about it continuously for quite some time.
We're giving stuff away to help celebrate our tenth anniversary. Are you in?
That being said, the SDK does not cover every feature, even every feature in Android itself. The core Android team’s philosophy is to avoid putting things in the SDK until the API has stabilized to the point they feel confident in supporting it over the long haul. And, even then, some things may not be added to the SDK, simply to preserve implementation flexibility.
The problem is, too many parties are reaching past the SDK.
The SDK is, in effect, a three-way contract. Developers who agree to stick to the SDK are assured that their application should run without issue on current and future Android Market-enabled devices. Device manufacturers that wish to ship the Android Market are given latitude to morph Android as they see fit to run on their hardware, so long as they continue to adhere to their side of the SDK and do a quality job of running third-party applications. And Google itself is committed to making deprecated APIs work as well as possible given inevitable advances in the platform.
I wrote about this in a recent post on another site, but I want to dig more into the developer side of this contract.
There are many tantalizing Android features just out of reach, from modifying the SMS inbox to proactively powering off the screen. Some developers go past the SDK boundaries and use such features. Sometimes, this is because the developer really wants to build app X with feature Y, and feature Y can only be implemented with things beyond the SDK. Sometimes, this is because a pointy-haired boss, who cares not a whit about customers or Android, is demanding it. Sometimes, developers use these capabilities to demonstrate 1337 hax0r sk1llz. And so on.
The problem is: reaching past the SDK is bad for all parties.
It is bad for the developer, because they will forevermore be chasing “bugs” because what they tried using is not stable, by accident or by intent. For example, device manufacturers are welcome to replace anything inside Android that is not part of the SDK, such as the SMS client. Developers can reach past the SDK and manipulate the SMS client’s content provider…assuming the device in question has such a content provider, and assuming the device in question has not changed the schema of the content provider, etc.
It is bad for the end user, because apps will break. Developers who reach past the SDK may not be able to keep up with new Android releases or new device firmware that break their apps. As such, users will wind up downloading apps based upon product descriptions that are, at best, pleasant-sounding hopes, that may or may not be fulfilled on the user’s specific device.
It is bad for the developer community, because we lose the moral high ground when trying to get device manufacturers and Google itself to adhere to their sides of the SDK “contract”. For example, it is hypocritical to complain about device manufacturers tweaking the contacts content provider and breaking apps when developers do the equivalent.
And it is bad for the Android ecosystem, if enough of these apps fail on enough devices that Android gets a reputation for incomplete device compatibility, like other mobile operating systems have had. We are going to have a rough enough time with this from manufacturers working off of the Android open source project and eschewing the Android Market. Developers who add to the problem, by reaching past the SDK, are going to make it that much worse — doing unfortunate things in the swimming pool, as it were.
The good news is that I think most apps available for Android stick to the SDK. After all, by and large, you need to be doing some fairly unusual stuff to go past the SDK: using reflection to access hidden classes and methods, using findViewById() to manipulate Android-supplied composite widgets like the TabWidget, using undocumented content providers, etc. I suspect there are fairly few developers who have accidentally gone past the SDK, and probably a bunch of those just copied and pasted some irregular sample they found on a blog post somewhere.
I urge Android developers everywhere to consider all of the impacts of reaching past the SDK when making the decision to use such techniques, not just those impacts that they will feel immediately. It’s not too outlandish to say that Android depends upon everybody — developers, manufacturers, and Google — adhering to the boundaries of the SDK.