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.
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.
Here's the thing – Android has lots of cool stuff, but if you want to reach beyond yo have to cheat. Chatting in forums with Android/Google staff (for example Dianne Hackborn) it becomes very clear that they didn't think of certain stuff and now it's not in the SDK. This does not mean there is a heaven-sent written in stone law that it is wrong to put such a thing in the SDK. For example – there is no screen-saver or equivalent in Android. Other phones have it so it's not as if it's an insane idea. But talk to Android staff and they tell you all about how much of a battery drain it is and how the underlying calls to the operating system make this impossible. It's nonsense. The simple fact is they didn't think of it, and now it's not in.
If we want to advance this supposedly open-source OS along we need to push the boundaries so there is new stuff added into future SDKs. Who will know they want a good screen saver if they don't give them at least a semi-good one? Why NOT standardize the SMS SDK so people can write their code correctly? Show people how much better you could do SMS than HTC does and them let them clamour for the "new" SMS to work on all phones.
Will changing the SDK afterwards break these new apps? Probably, but hey, we're hackers – we worked it out one time, we'll do it again – and if it makes a better SDK , everyone will have benefited.
Relying on the beneficence of Google to make a new SDK means assuming they always know what people want…and they don't.They follow users just like everyone else…visionaries show users (and Google) the way.
You are certainly welcome to your opinion. I don't agree with the vast majority of what you wrote, since you seem to be advocating creating products that rely upon beyond-the-SDK APIs. I have no problem with people poking past the SDK for proofs of concept, private demos, and the like, and that should be all that true "visionaries" need to get their points across vis a vis areas where the SDK needs improvement. Trying to get the SDK improved is great — having ordinary users be collateral damage along the way is not.
2 years on and SMS content provider is STILL not standardised. what do u expects devs to do. saying that Google will spot your personal demo amongst thousands of others as a great addition to the SDK is naive, you get attention through users and popularity.
2 years more, and SMS content provider is STILL not standardised! WTF? I’ll have you know, that my pointy-haired boss and his pointy-haired bosses have had an APK that I helped build in the marketplace for over a year that goes WAY beyond the SDK. I don’t condone it, but what does Android expect us to do? The SMS part of the SDK sucks!
@Kibi:
The problem is that most android-phone owners are not hackers. If owners get an OS update, or their phone-model doesn't support the 'hidden api', and their installed applications start failing, this will reflect badly not only on the developers of these applications, but on the whole android eco-system.
I can imagine that sometimes you can't get around 'going around' the SDK, but you'd better have the resources to handle and fix the issues that your customers possibly will encounter.
You can still work your wizardry – just add or modify the SDK so everyone else can use it.
An SDK for SMS may be one of the most problematic issues because it's a very basic phone feature that is used by many applications. For example, my application (Dindy) sends SMS text messages in response to incoming calls and it was requested by users that it will do the same for incoming SMS messages.
I refused because of the reasons mentioned in your article. I charge for my application and it makes me liable if it breaks in the future. But:
1. If someone else implements the same functionality plus the SMS capability then my application will be inferior and users will not care for the reason and will simply switch and I will potentially lose money.
2. Now that there are many applications that actually query the content provider for SMS messages, Google will probably be forced to have a compatibility layer for these applications even if they change the underlying implementation. This is the same as Microsoft does in new Windows because users will blame the OS if their applications break even if the OS vendor is not responsible.
I completely agree that the lack of a common SMS message store is big, and I sincerely hope it gets addressed sooner rather than later. I'm not convinced that "Google will probably be forced to have a compatibility layer" — heck, the compatibility layer for some official-but-deprecated APIs is a little shaky (e.g., the old Contacts provider API on top of the ContactsContract doesn't work well in the emulator).
Yeah are normal position is that we have an app that isn't working with a new version of the platform, and find that app is using any private APIs, then it goes the bottom of the list of things to fix. The focus needs to be on taking care of well written apps rather than going off in the weeds dealing with apps that are doing bad things.
Google engineers think app/process manager apps are not necessary since android will manage all the processes correctly (wishful thinking). But many users NEED app/process manager apps to release memory and stop certain apps/services in one short.
Also the new 2.0 ContractContacts ContentURI/API breaks alot things that used to use the PEOPLE ContentURI/API. Not backward compatible. Forced developers to update codes or spawn multiple versions for 1.5, 1.6 and 2.0 SDK.
Just some whining but there must be a better way to contribute and make Android better than its current state.
While I won't be using an undocumented API in my first production app, I might start using one in subsequent updates. So far every major update breaks some apps (regardless if they are using non standard APIs or not). The broken apps get update fixes in a few days and everything is fine again.
I don't think this is a major problem. The fact that android alerts users of new updates greatly reduces the problems with apps breaking when the platform updates.
I think if in api is stable enough for Google to use then its stable enough for a developer to use as long as that developer is planning on keeping there application current.
What do you mean by "stable enough for Google to use." There are lots of APIs that are private that the -platform- uses, because well it is the platform and it is the one implementing those APIs. There are also some platform apps (the phone app being a prime example) that use private APIs because… well, they are also part of the platform, ship with the platform, and are not in any shape to be placed on Market.
However, Google's apps by and large don't use APIs. Any Google apps that is on Market — such as Maps — uses only public APIS. Because that is the correct thing to do.
If you are writing an app that gets built and shipped as part of the system image and doesn't go on the market, have at the private APIs. But if you do put your app on Market, you are expected to stick to the public APIs, Because those are the ones that will work.
And updates are not a guaranteed fix — what if different devices are implementing this private API in different ways?
Regarding Maps only using the public API. That's interesting. The Maps add-on source code is not available so we don't don't know. Or if Google Maps on Android is not implemented with MapActivity then we really don't know – but we can take your word for it. MapActivity appears to rely heavily on the system image maps shared library that is hopefully (again not documented) on all major devices. Apparently the Maps app and the MapActivity add-on use a non SDK API (the Maps shared library).
Server push is another technology that developers are trying to work out on their own with mixed success and sometimes with platform degrading side effects. This feature is built-in on other mobile platforms. For things like SMS and server push it would help if there was a roadmap so developers could plan on future integration with applications.
The problem is that Google is using the public API as a means of restricting the types of applications that third-party developers can write.
Two times I’ve gone outside the public API, once to access SMS and again to access emails. These are fundamental operations of a phone. For a phone OS to not provide unified access to data produced by fundamental phone operations, is ludicrous.Â
So because Google hasn’t pushed the SMS content provider into the public API, no one can write a widget that displays SMS messages. Really? What is Google trying to do? Why have they left such blatant holes in the API? WHY???
I would argue that users want these kinds of applications (like gnobal mentions below) and with no other recourse, people are going to use private APIs to write them, thereby taking money from the white hat developers that stick to the public API.
So where’s the incentive? Why shouldn’t I use the private API to provide the apps that users want, when it is my only means of doing so?
I agree with Kibi. My clients’ projects often require functionality which is not supported by standard APIs because manufacturers forgot it. This makes it hard to use some telephone equipment in special situations and still comply with the law.
This is really like a Yin and a Yang of 2 worlds. Plus and Minus. Pro and Contra.
For default apps like AlarmClock. It should be universal. And don’t go past SDK. Hurts for developers. This is “software” fragmentation. A very friend for Android hardware screen resolution fragmentation already.
Anyone Please answer this question http://stackoverflow.com/questions/28791461/ipackagestatsobserver-cannot-be-resolved-to-a-type-android