Android Developers Blog: On Android Compatibility

Android Developers Blog: On Android Compatibility


[This post is by Dan Morrill, Open Source & Compatibility Program Manager. — Tim Bray]

At Google I/O 2010, we announced that there are over 60 Android models now, selling 100,000 units a day. When I wear my open-source hat, this is exciting: every day the equivalent of the entire population of my old home city starts using open-source software, possibly for the first time. When I put on my hat for Android Compatibility, this is humbling: that’s a whole lotta phones that can all share the same apps.

Another thing we launched at Google I/O was an upgraded and expanded source.android.com. The new version has refreshed info on the Android Open-Source Project, and some new tips and tools for device manufacturers — useful if you’re an OEM. However, it also has details on the Android compatibility program, now. This is also aimed mostly at OEMs, but Tim Bray suggested that developers might be interested in a peek at how we keep those 100,000 devices marching to the same beat, every day. So here I am, back on the blog.

The F-word, or, Remember remember the fifth of November
I remember sitting with my colleagues in a conference room in Building 44 on November 5, 2007, listening to Andy Rubin and Eric Schmidt announce Android to the world. I remember a lot of the press stories, too. For instance, Android was “just words on paper” which was especially entertaining since I knew we were getting ready to launch the first early-look SDK a mere week later.

Another meme I remember is... yes, “fragmentation”. Literally before the close of business on the same day we announced Android (4:46pm to be precise), I saw the first article about Android “fragmentation.” The first day wasn’t even over yet, and the press had already decided that Android would have a “fragmentation” problem.

The thing is, nobody ever defined “fragmentation” — or rather, everybody has a different definition. Some people use it to mean too many mobile operating systems; others to refer to optional APIs causing inconsistent platform implementations; still others use it to refer to “locked down” devices, or even to the existence of multiple versions of the software at the same time. I’ve even seen it used to refer to the existence of different UI skins. Most of these definitions don’t even have any impact on whether apps can run!

Because it means everything, it actually means nothing, so the term is useless. Stories on “fragmentation” are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. “Fragmentation” is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.

Compatibility
Now, that’s not to say that there aren’t real challenges in making sure that Android devices are compatible with each other, or that there aren’t very real concerns that keep app developers awake at night. There definitely are, and I spend a great deal of time indeed thinking about them and addressing them. The trick is to define them clearly.

We define “Android compatibility” to be the ability of a device to properly run apps written with the Android SDK. This is a deceptively simple way to frame it, because there are a number of things that can go wrong. Here are a few:

•Bugs - devices might simply have bugs, such as a buggy Bluetooth driver or an incorrectly implemented GPS API.

•Missing components - devices might omit hardware (such as a camera) that apps expect, and attempt to “fake” or stub out the corresponding API.

•Added or altered APIs - devices might add or alter APIs that aren’t part of standard Android. Done correctly this is innovation; done poorly and it’s “embrace and extend”.

Each of these is an example of something that can make an app not run properly on a device. They might run, but they won’t run properly. These are the things that I spend my time preventing.

How It Works
As stewards of the platform we realize that it’s vital to allow only compatible devices to participate in the Android ecosystem. So, we make compatibility a strict prerequisite for access to Android Market and the right to use the Android name. This means that developers can rely on the fact that Android Market — the keystone of the Android ecosystem — will only allow their apps to run on compatible devices. It’s pretty self-evident that a single app ecosystem is better than many small ones, so OEMs are generally pretty motivated to ship compatible devices.

But motivation alone doesn’t get us very far without tools to actually ensure compatibility, which is where the Android compatibility program comes in. This program is like a stool with three legs: the Android source code, the Compatibility Definition Document, and the Compatibility Test Suite.

It all starts with the Android source code. Android is not a specification, or a distribution in the traditional Linux sense. It’s not a collection of replaceable components. Android is a chunk of software that you port to a device. For the most part, Android devices are running the same code. The fact that all Android devices run the same core Android code goes a long way toward making sure those devices all work the same way.

However, this doesn’t solve the problems of missing components or altered APIs, because the source code can always be tweaked. This is where the Compatibility Definition Document (or CDD) comes in. The CDD defines in gory detail exactly what is expected of Android devices. It clearly states, for example, that devices may not omit most components, and that the official Android APIs may not be altered. In a nutshell, the CDD exists to remove ambiguities around what’s required of an Android device.

Of course, none of that overcomes the simple reality of human error — bugs. This is where the Compatibility Test Suite comes in. The CTS is a collection of more than 20,000 test cases that check Android device implementations for known issues. Device makers run the CTS on their devices throughout the development process, and use it to identify and fix bugs early. This helps ensure that the builds they finally ship are as bug-free as possible.

Keeping Up with the Times
We’ve been operating this compatibility process with our OEM partners for over a year now, and it’s largely responsible for those 60+ device models being interoperable. However no process is ever perfect and no test suite is ever 100% comprehensive, and sometimes bugs get through. What happens then?

Well, we have great relationships with our OEMs, and like I said, they’re motivated to be compatible. Whenever we hear about a serious bug affecting apps, we report it to our partners, and they typically prepare a bugfix release and get it out to end users. We will also typically add a test case to the CTS to catch that problem for future devices. It’s an ongoing process, but generally our partners are as interested as we are in the user experience of the devices they sell.

The mobile industry today is “very exciting”, which is code for “changes painfully fast”. We believe that the only way Android will be a success is to keep up with that change, and ultimately drive that change. This means that over time, the CDD will also change. We’ll add new text to handle problem cases we encounter, and the actual requirements will change to accommodate the innovations happening in the field. For example, in the 2.1/Eclair CDD, we tweaked the CDD slightly to make telephony optional, which allows Android to ship compatibly on non-phone handheld devices. Whenever we do this, of course, we’ll make corresponding changes to the Android APIs and Android Market to make sure that your apps are protected from ill effects.

On a somewhat related note, a lot of ink has been spilled on the fact that there are multiple versions of Android out there in users’ hands at the same time. While it’s true that devices without the latest software can’t run some of the latest apps, Android is 100% forward compatible — apps written properly for older versions also run on the newest versions. The choice is in app developers’ hands as to whether they want to live on the bleeding edge for the flashiest features, or stay on older versions for the largest possible audience. And in the long term, as the mobile industry gets more accustomed to the idea of upgradeable phone software, more and more devices will be be upgraded.

What It Means for You
All that is great — but what does it mean for developers? Well, we put together a page in the SDK Documentation to explain this, so you should take a look there. But really it boils down to this:

1.As a developer, you simply decide what features your app requires, and list them in your app’s AndroidManifest.xml.

2.The Android compatibility program ensures that only compatible devices have access to Android Market.

3.Android Market makes sure your app is only visible to those devices where it will run correctly, by filtering your app from devices which don’t have the features you listed.

That’s all!

There almost certainly will be devices that have access to Android Market that probably weren’t quite what you had in mind when you wrote your app. But this is a very good thing — it increases the size of the potential audience for your app. As long as you accurately list your app’s requirements, we’ll do the rest and make sure that your app won’t be accessible to a device where it won’t run properly. After all, we’re app developers ourselves, and we know how painful it is to deal with users upset about an app not working on a device it wasn’t designed for.

Now, that’s not to say that we think our current solution is perfect — no solution is. But we’re continuously working on improvements to the SDK tools and Android Market to make your life as an Android developer even easier. Keep an eye on this blog and on the Android Market itself for the latest info.

Thanks for reading, and happy coding!

Android

First of all, as Dan Morrill memorably explained in On Android Compatibility, “Android is not a specification, or a distribution in the traditional Linux sense. It’s not a collection of replaceable components. Android is a chunk of software that you port to a device.”


Linux · Underneath everything is a reasonably up-to-date Linux kernel (2.6.32 in my current Nexus One running Froyo), with some power-saving extensions we cooked up; the process of trying to merge this stuff into upstream Linux has been extended and public and is by no means over.

Android runs on Linux, but I’d be nervous about calling it a distro because it leaves out so much that people expect in one of those: libraries and shells and editors and GUIs and programming frameworks. It’s a pretty naked kernel, which becomes obvious the first time you find yourself using a shell on an Android device.

If it were a distro it’d be one of the higher-volume ones, shipping at 200K units a day in late 2010. But nobody counts these things, and then there are a ton of embedded flavors of Linux shipping in unremarkable pieces of consumer electronics, so there’s a refreshing absence of anyone claiming to be “the most popular Linux”. I like that.

Dalvik · The next big piece is Dalvik, comprising the VM and a whole bunch of basic runtime essentials. Its design is fairly unique, and judging by recent history, seems to be working out pretty well as a mobile-device app substrate.

All the standard APIs that you use to create Android apps are defined in terms of Dalvik classes and interfaces and objects and methods. In fact, some of them are thin layers of Dalvik code over native implementations.

It’s possible, and common practice, to call back and forth between Dalvik and native code using the JNI protocol, which is a neat trick since what’s running on Dalvik isn’t anything like Java bytecodes on a Java VM.

How It’s Generated · Native code is currently produced more or less exclusively by compiling C or C++ code; but there’s no reason it has to be that way. Dalvik code is currently produced by generating Java bytecodes and translating them; but there’s no reason it has to be that way.

I want to emphasize this point a little. Android apps are defined as code that runs on the platform and uses the APIs. As long as an app does these things properly, it’s really nobody’s concern how it got generated.

Special Apps · The picture is a little misleading, because some of those Dalvik-based apps are provided by Google and sometimes are seen as “part of Android”. I’m talking about the Dialer and Contacts and Calendar and Gmail and Chat and so on. Most of them are open-source and replaceable (and have been replaced by handset makers); a few are closed-source and proprietary, like Google Maps and Android Market.

That Open-Source Thing · In the big picture above, most of the stuff in green is Apache-licensed. The rest is a mixture of GPL and LGPL and BSD, with some Apache in there too. This excludes some low-level device drivers and of course the majority of non-Google apps, which are closed-source.

The Framework · This is the stuff that uniquely defines Android; more or less everything that Google wrote and you wouldn’t expect to find on a reasonably-configured GNU/Linux box. Its proper use is the subject of all the many pages on display at developer.android.com and of endless mailing lists, sample sites, and a growing number of books.


Libraries · The word “standard” here means “generally available to programmers working in an open-source environment”. The picture isn’t comprehensive.

Quite a few people, including me, have over-emphasized the role of the Harmony libraries. To start with, the Android selection excludes lots of stuff, for example AWT and Swing and OMG CORBA; all superfluous for apps using the Android framework.

Also, just counting roughly by code bulk of all the sort of stuff in this picture, the Harmony code comprises less than half the total. I don’t want to diss Harmony, they’re a wonderful project and I’m a huge fan; but it’s inaccurate to give the impression that Android is just Dalvik plus Harmony.



What’s In an App? · An Android app lives in what’s called an APK, which is simply a ZIP file, with a particular internal file layout that allows it to be run in place, without unpacking. There’s nothing magic about them, you can email them around and drop them on USB keys and extract pieces with unzip.

The Android Manifest is the interface between an app and the Android system, and that’s all I’m going to say here because it’s a key piece of the puzzle and deserves lengthy discussion if any at all.

The resource bundle contains your audio and video and graphics and so on, the pieces that come with the app as opposed to being fetched over the network.

Native or Not · Most apps these days are written for Dalvik. When I say “most apps” I mean “everything that isn’t a game”; game developers typically want to code in C/C++ and that’s it. Dalvik offers a nice fast gateway to OpenGL and all the phone’s hardware, but game devs just don’t want to hear about virtual machines, so they use the Android NDK.

If you’re writing code in the Java programming language you can use Eclipse and a pretty nice toolchain that makes the barrier to entry remarkably low. If you’re coding to the NDK, you’re going to be doing a lot of the build-time machinery yourself and living without some of the nice debugging and profiling candy, not to mention signing up to port your code to other CPU architectures if they run Android and have lots of users. But game developers revel in pain.

And that’s what Android is · Hope you liked the pictures.

Source: http://www.tbray.org/ongoing/When/201x/2010/11/14/What-Android-Is

Windows Live Writer: Post 1

Using this desktop blog-publishing application that is part of the Windows Live range of products. It features WYSIWYG authoring, photo-publishing and map-publishing functionality, and is currently compatible with Windows Live Spaces, SharePoint blogs, Blogger, LiveJournal, TypePad, WordPress, Telligent Community, PBlogs.gr, JournalHome, the MetaWeblog API, the Movable Type API, Blogengine, Square space and all blogs that support RSD (Really Simple Discoverability).