This has been a debate ever since last fall, when Android 1.6 (codenamed "Donut") started hitting devices like the G1/Dream and the MyTouch 3G/Magic while other devices like the Hero or Moment were left behind with Android 1.5. Since then, this situation has been commonly described as "Android fragmentation". Now, we don't know who used this word for the first time, but we do know who's trying to use it for the last time: Google. It all began at last month's Google I/O, when Google gave their view (for the first time) on this matter, and now, it's time for some reflection.
First of all, what did Google say? Android's open source and (device) compatibility lead, Dan Morrill, said the so-called "fragmentation" does not exist, since applications designed for an Android version, say 1.5, will work on all newer versions (1.6, 2.1, 2.2, and so on), and because this is guaranteed by the Android framework, we shouldn't call it fragmentation. Fragmentation happens when an application does not work in all devices it should, and that doesn't happen. Why? Because no Android device is authorized to ship with the Android Marketplace app unless it can run apps written with the official Android Software Development Kit or SDK. The Android Marketplace app has the responsibility of only showing the user of a specific device the apps that device can run; for example, if we're using an HTC Tattoo (3.2" screen, 320x240 pixels, Android 1.6 with Sense UI) we will not see apps in the Market such as Adobe Reader, ASTRO File Manager, Google Earth or the official Twitter app, because they wouldn't work, and they use APIs not supported by Android 1.6. The Android Market app also filters other elements, such as Live Wallpapers which require Android 2.1. This is good, right? The Android Market takes care of these issues but, what about the devices? Every device is different, so Android has to be tweaked and adapted to work using each device's hardware (screen, buttons, microphone, cameras, etc.) and sometimes, the device's manufacturer alters Android itself, adding a layer on top, like HTC, Motorola and Samsung do. How do we, users and developers, know if these devices, running modified versions of Android, will not cause our apps to crash? That's where Google and the Open Handset Alliance come in with the Android compatibility program. The Android compatibility program (which includes the full Android OS source code) states what an Android Marketplace compatible device is, and to ensure all devices meet the requirements, they need to pass a battery of at least 20,000 tests. Only then a device is suitable to ship with the Android Marketplace app.
Shortly after Dan Morrill's statements at Google I/O and his post in the Android Developers Blog, Android visionary & Google VP of Engineering Andy Rubin gave Gizmodo an interview sharing with the world his own views about multiple versions of Android being used at the same time, and for him, there's no fragmentation, only legacy. Andy had actually expressed this at Google I/O, but it came to our knowledge when he spoke with Gizmodo. So, what's legacy about? In short, legacy means taking care of old software. Old in which sense? In the sense that Android must maintain compatibility with the software (apps) written for old iterations of the OS, but at the same time, keep innovating and moving forward. For example, what happens with our (or our parents') MS-DOS based desktop applications? They're legacy too, and in the desktop world, we moved on from MS-DOS to NT, and Windows introduced a compatibility mode to ensure at least some old MS-DOS applications worked with the new OS. Similarly, Android apps targeted for old versions will be compatible with the new versions, and even if we leave behind devices running old software, we must still move on, and keep introducing new and ground-breaking features. Users on first generation hardware will eventually upgrade to devices running (or expected to run) Android 2.x, and when the next iteration of Android arrives, we might see how devices sold in this year start falling behind, leaving us (users) with the challenge of upgrading again. In the desktop world though, we do not call this fragmentation, and moreover, we do not complain, because in the desktop world we know we can update our machines to the latest OS from Microsoft (XP to Vista/7, anyone?), and it's our choice. However, it's also true that Microsoft does not release a new version of their flagship OS every six months, and that manufacturers will stop updating their old devices at some point, forcing us to root our "old" devices and install hacked ROMs. Still, it's much better than nothing.
With fragmentation and legacy explained, is everything solved? Are developers and the press happy about Google's answers? Not quite. The blogosphere understood for a while what legacy meant, but with the incoming release of Android 2.2, fragmentation is being used again. But what about us, the devs? Why aren't we satisfied? Well, this question is best answered with the help of a picture:
This is the latest chart showing the platform versions currently in use today delivered by Google, and it shows our concerns. A quarter of Android users are using Android 1.5, another quarter is using Android 1.6, and the other half is running the about to be outdated Android 2.1. Why is this a problem? Well, the problem comes because when we want to make what Android users love, apps, we can't use the latest APIs the Android platform can offer, because if we do, we lose a lot of potential users. If today we release an application for Android 2.1, we are releasing it to only half of the current Android population, and not using Android 2.1 means we cannot use the APIs which allow us to offer functionality half Android users expect like Bluetooth, Multi-touch, OpenGL ES 2.0 graphics, Live Wallpapers, integration with the user's contacts, and more. With Android 2.1 though, the impact of making apps for this release is becoming lower and lower because the latest devices are shipping with it, but let's go with Froyo. Froyo adds a lot of functionality we will cover soon, so let's go with something we've already spoken about, the Cloud to Device Messaging API. What if we wanted to release an application which relied exclusively on this new API? As of now, we'd have no users, and we'd have to wait for the Over-The-Air (OTA) updates to hit devices around the world to start getting some Return for our Investment (ROI). Now let's look at it from the other side: to target all Android users, we're stuck using Android 1.5, which was released more than a year ago. Don't get me wrong, Android 1.5 was a major milestone, but knowing we have so many APIs available in Android 2.1 and beyond, can be quite depressing. This doesn't mean though, that we can't build an app for Android 2.1 or 2.2 and have it work too on Android 1.5 devices, because we can. Thanks to Android's main development language, Java, we can use certain APIs in the device only if they're available in the device running the app, and we can tell the Android Market the app uses Android 2.1/2.2 specific APIs but that at the same time it can run in 1.5 & above using older APIs. However, it's not a path all developers want to take, especially since Apple allows developers to use only the latest APIs, since only now, for the first time, there is "legacy" within iOS, with the first-generation iPhones and iPod Touch not receiving the iOS 4 update.
Besides which release we need to target in our apps, devs are also concerned about bugs in devices, which make their way into shipping hardware and cause our apps to crash which, of course, is a major cause of user dissatisfaction. Even so, this only becomes a concern after our apps are released, and the first choice we have to make remains to be which version of Android we should target in our apps.
After studying the current situation, it's time to draw some conclusions. Android 2.2 is about to roll out (if it's not rolling out to Nexus Ones in the United States already) and there'll be a couple of devices left in Android 2.1 while (we expect) the majority of them will receive the update before summer ends or before the holidays, but what can we conclude? Android is becoming more and more like Windows for mobile devices, and yes, we know there is an OS called Windows Mobile, but Android is becoming a lot more mainstream, and it's giving us (devs) tools to target all users if we need to, since there'll be times when we won't. Most importantly, from my point of view, I doubt we'll see all Android devices running the same OS release, ever. Why? To begin with, we've already got legacy going on, and with every major Android release, we enter the possibility of adding another wave of legacy devices, which I believe might happen before year's end. However, we could see more than 50% of Android devices running the same release if the releases slow down, but in any case, we have three big groups of Android devices: legacy devices running old versions, devices running the previous release and new or updated devices running the latest. Of these three, I expect the second group to be the largest, and as time flows after a new release, those devices will either join the last or the first group, at which point everything will start again, making a loop.
In one sentence: call it how you will, but we will always have multiple versions of Android running at the same time.
2 comments:
Re "Thanks to Android's main development language, Java, we can use certain APIs in the device only if they're available in the device running the app, and we can tell the Android Market the app uses Android 2.1/2.2 specific APIs but that at the same time it can run in 1.5 & above using older APIs."
I have heard this before but I don't believe it works in practice. If you try (using Eclipse plugin) to create an application that targets the 2.1 API but you want to set a MinSDK of 1.6, for example, it barfs and does not let you.
If you think that your app could run on any version and you can omit the MinSDK attribute, I still do not understand how an app compiled against the 2.1 API could get installed on a handset running a lower version of the OS?
I was under the impression from reading the Google market documentation that they filtered applications based on the OS of the handset, so I am assuming that what I said above is true. I posted the same comment on Stack Overflow and nobody has disabused me yet.
In the end I had to create two version of my app using different names. I can cope with two maybe but what do I do if there is further fragmentation and my app breaks again on upward versions?
Hi, thanks to both of you for answering.
Rob, I'm going to be completely honest, I've never tried it myself, and I wouldn't have said it unless I was convinced about it, and I am because of a post in Google's Android Developers Blog: http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html
About how is this possible, I believe it might be related to the Dalvik Virtual Machine and the fact that we're compiling against APIs; the basic idea, when building an app with minimum SDK version 3 and targeting version 7, is to check whether we can perform a call for an API not supported in version 3 before doing so, and if we can’t, we must have a solution for API level 3. The trick must be in the fact that we’re checking if the API is available instead of executing it, because trying to do so even if it’s in a try/catch block would crash the app if the API isn’t available, since we’re trying to execute code which doesn’t exist. As to how apps targeted for API level 7 with minimum API 3 can be executed in a device with the latter revision of Android, it must be because the code Dalvik “understands” hasn’t changed from API level 1 to 8, and probably never will, or else making one app compatible with all current and future versions of Android would be impossible. The problem comes when Dalvik tries to execute code which doesn’t exist, for example, calling an API above level 3 even if it’s in a try/catch block, and this is what we avoid with reflection.
This is my theory as to how it’s possible, so please, correct me if I’m wrong.
Post a Comment