New Public APIs In The ICS

Nadia Naila

Tuesday, November 1, 2011

Since Android is open source, anyone can see the code and see how it works inside. If you do this, you will notice that most but not all APIs are publicly documented.

If they are publicly documented, they are part of what we consider the Android application framework. This means that their evidence appear in the compatibility test suite (CTS) for hardware partners have to demonstrate that the work of the API, and we are committed to an effort not to change and break your code.

In almost all cases, there is only one reason to abandon the undocumented API: We're not sure that what we have now is the best solution, and we might have to improve, and we are not willing to make the compromises of the tests and conservation.

We are not saying they are "private" or "secret" - How could they be, when nobody in the world can discover? Nor are we saying it is not: If used, the code compiles and probably run. And indeed we know of some apps out there that developers have used undocumented APIs, often with good results. It's hard to be too bothered by this in cases where there is a useful API that we have not had time to stabilize.

But developers using the API must be prepared to deal with the situation arises when immigrants move from outside the Android application framework. Fortunately, this is quite simple. Also take a look at Android Market, using our own tools of analysis to get an idea of ​​the impact when we know that one of these changes is to come.

There are some changes as it comes in the Android 4.0 "ice cream sandwich" (ICS) release of Android. We wanted to have the opportunity to combine these words in the undocumented API with some details about the changes.

Calendars

Let's start with the good news: From the ICS, the Framework for Android includes a full work-out set of APIs for accessing calendar data. You can guess the bad news: Very few developers have created applications (including many good ones), using the Calendar API immigrants, some with fairly low level of access to the calendar database. Unfortunately, these integrations are not supported, and prone to breakage by updates to the platform or OEM customization calendar functions.

We see a lot of good timing and application extensions that work reliably through Android devices, and not broken by updates to the platform. So we decided to create a clean API, and a range of purposes, to manage the calendar data in the ICS. Now anyone can code against the new API and we know that Android is committed to support them, and that partners have to support these APIs, as part of CTS.

Once the new API to get, you have to update their applications before going to work correctly in ICS while working in previous versions. There are a variety of techniques to do so, many of which have appeared in this blog, including reflection and lazy loading. Recently, we introduced multiple APK support could also be used to help with this type of transition.

Text To Speech

Android has never really had a text to speech API in the framework level, but had official access to the C + + level. With ICS, which will be a complete thought through application-level API that run on Dalvik, so you can access it with the ordinary application code of the Java language.

The old C + + API will no longer be supported, but we will have a compatibility layer that can be used to save it to the new API. We believe it should be easy to update to ICS with very little work.

Doing the right thing

We recognize that this means work for developers affected by these changes, but we are confident that Android programs in general, and both the calendar and TTS applications, in particular, will succeed. And we also think that most developers know that when using undocumented APIs that are making a commitment to doing the right thing when API changes.

Tag : New public APIs in the ICS