Nov 22 AT 9:56 PM Taylor Wimberly 36 Comments

What does Android fragmentation look like?

Android fragmentation is real and it is not going away. Ask any developer and they will tell you about the difficulties of supporting multiple versions of Android and their different screen sizes.

So what exactly does Android fragmentation look like?

Android visitors to

Android visitors to

The above data was generated by Google Analytics and it shows the number of visitors to our site using Android devices. This data was collected between November 6, 2009 (Droid launch) and November 21, 2009.

Nearly 50 percent of Android users are running version 1.6, 26 percent are on the new 2.0, and the remaining 24 percent have 1.5.

Android 1.6 leads the way because the HTC Dream (G1) and HTC Magic (myTouch 3G) phones have been out the longest and sold the most units. T-Mobile has updated both of these devices to Android 1.6 and HTC has made the 1.6 images available on their developer’s site.

I’m a little surprised to see Android 2.0 is the second highest used version. There is currently only one phone (Droid) with this build, but we have heard reports of over 250,000 units sold already. The Droid is being heavily marketed towards the hardcore geek and this site also leans towards the hardcore user so that might be the reason for the elevated numbers.

Android 1.5  has the highest number of devices available right now, but it is coming in 3rd in usage. There really is no excuse for the carriers and handset makers to be shipping phones with the outdated Android 1.5. I know some of these phones have custom UIs (Sense UI, Motoblur, TouchWiz) but they should be easily updated to Android 1.6.

The following is a break down of Android phones and their current versions (United States only).

Android 1.5 devices

  • Archos MIDs
  • Sprint HTC Hero
  • Sprint Samsung Moment
  • T-Mobile Motorola Cliq
  • T-Mobile Samsung Behold II
  • Verizon HTC Droid Eris

Android 1.6 devices

  • T-Mobile HTC G1
  • T-Mobile HTC myTouch 3G

Android 2.0 devices

  • Verizon Motorola Droid

Update (11/23): Added Admob information from their latest report which confirms our stats are pretty accurate.

Most recent Android handset distribution.

Most recent Android handset distribution.

Handset breakdown for last seven months.

Handset breakdown for last seven months.

Admob market trends:

  • HTC has taken an early lead, thanks to availability of three different devices.
  • Motorola Droid launched on November 6 already represented 24 percent of all Android requests in AdMob’s network worldwide even though the device is available only in the US.
  • Worldwide requests from Android devices increased 5.8 times since April 2009 in the AdMob network.
  • In the US, Android has 20 percent share of smartphone traffic versus 7 percent in April 2009.
  • The Motorola CLIQ generated 6% of Android traffic worldwide as on November 18th 2009.
Taylor is the founder of Android and Me. He resides in Dallas and carries the Samsung Galaxy S 4 and HTC One as his daily devices. Ask him a question on Twitter or Google+ and he is likely to respond. | Ethics statement

    Most Tweeted This Week

  • Alberto Vildosola

    Google should stop releasing minor updates so frequently, a huge update every six months would be better to give time the manufacturers to update.

  • SliestDragon

    You know, all Google has to do is wait and update to a new version once all skins are updated, and be more strict about skins being compatible with apps. Then app developers would have less to worry about.

    Plus stop letting people make more skins. Do we really need a skin for every hardware manufacture?

    By the way, when I read this post I decided I wanted to comment so I hit the sign in button on the top of the page which redirected me to the home page, but when I enter a post it signs me out again. Do you know what would be wrong?

    • SliestDragon

      Well, when I entered my username and email down below it apparently knew it was me, so carry on.

    • Taylor Wimberly

      Sounds like an issue with your cookies. Clear your cache and try signing in again.

    • ari-free

      they could change the code all they want but if they do, they shouldn’t be able to call it “Android” or “by Google”

      • ari-free

        I should also say that if the stock android UI was really high polished and professional, there wouldn’t be a reason for all these skins. android vs Sense is like comparing windows 95 to macos x.

        • enki

          …except widgets IMO

  • buhasko

    Ok about that fragmentation, did anyone see the official video from google about android 2.0? In it youj can see you run the same version of an application on different screen sizes. So the only other fragmentation would hardware keyboard vs none. I don’t see this such a big fragmenation except for games maybe. Some phones would have different processor speed, but you can still run the same apps just different speed performance. I don’t see fragmentation as a problem from 2.0 after as it would be able to run same applications on different devices. Currently there is fragmentation but within a year everything that less than android 2 would obsolete, so why the big fuss. It like saying that iphone 3g and 3gs cause fragmentation. The only difference is performance not capability to run the apps. again the only fragmentation I see is in games with or without hardware controls.

    • Taylor Wimberly

      The main problem is the custom skins (motoblur, sense ui, touchwiz) which break many apps. Some of them replace the dialer and other core pieces of Android which makes life difficult for developers.

      • enki

        There is one feature on HTC I love..activesync. But it is all made wrong way, Google should force all development of core functions to be OSS. And in core I mean everything what came with mobile itself (maybe there is place for better media player, photo player etc), but no phonebook, calendar and mail replacements.

    • Khürt Williams

      So you are saying that I should just buy a new expensive smart phone and repurchase all my apps every time a new OS version is released?

      • Taylor Wimberly

        The apps you purchase are tied to your Google account. They are easily transferred from phone to phone and you do not have to repurchase them.

  • Ted

    Is there any way to see how many of those phones are using custom rom’s?

  • Craigo

    And to make it worse, you have carriers (eg Optus in Australia) that sold the G1, but now have discontinued it, so the users are still on Android 1.5, and will likely be so forever.

    • A man

      Right, because they’ll probably never buy a new phone. :P

  • Chrees

    Android 2.1…wat?

  • Taha

    Wow @ Droid’s market share. Either that means amazing sales of the Droid, or really pathetic sales of Android phones before the Droid… or both?

    • Clark Wimberly

      its most likely due the anyone with a Droid playing with it nonstop (like I do anytime I get a new phone)

  • Yves

    Samsung Galaxy also runs 1.5

  • Yves
    • Clark Wimberly

      from your post: An app coded for 1.5 will still run flawless on 2.0.

      absolutely not true. every time a new build drops there are dozens of busted apps.

  • Filipe

    “Android fragmentation is real and it is not going away.”

    In my opinion, whoever thought that Android would somehow be immune to the fragmentation hog, was wrong right from the start (maybe that would make sense if Google would have considered a “GPhone” market approach).

    Device fragmentation is a general issue / trade-off of a multi-vendor supporting platform (different screen sizes, ratios, CPU, RAM, driver dependency, etc).

    However, this diversity allows manufacturers to compete with each other with a common goal: to address different market requirements and reach different niches of end users.

    I came from a Java ME environment where I developed a GUI engine which aimed to circumvent fragmentation and provide a nice tool for my next projects at that time (in order to make single binary releases) and trust me, that was really hard to accomplish since Java ME provides little or none fragmentation control (unless some runtime checks, but it is up to the developer to implement branch control mechanisms and alternative procedures, from scratch).

    In other hand, the Android platform does provide a really good dev support for multi targeted apps, especially with 1.6, with virtual resize capabilities and multiple resource fetching mechanisms.

    I also understand that most of the concerns are probably related to low level game design (opengl / 2d primitives), and those are really interesting issues. If you look at the current mobile market, heavy game development is based solely on 1-configuration platforms (PSP,Nintendo,Ipod/Iphone). I expect that the solution to this problem will eventually reside in open source game engines (which can handle the portability issues) and platform maturity.

  • JayMonster

    The problem isn’t Android at all… it is HTC (and Samsung, and Motorola) with all these skins. Why? I mean, sure I understand why WinMo 5 was skinned… but Android? It is pointless window dressing that causes devices with these skins to be left behind until the skin can catch up.

    Me, I’m sticking with the “Google Experinece” phones so I can get my updates and not be forced to stay on an earlier version while awaiting an updated skin.

  • Mark

    Development will continue, but it may mean fewer free aps and more paid apps as it takes more effort to code for multile devices. Maybe it will weed out the weaker developers putting out crappy apps.

  • Pingback: Hands on updated Google News for Android – Android and Me()

  • Mike Leahy

    >>I also understand that most of the concerns are probably related to low level game design (opengl / 2d primitives), and those are really interesting issues. I expect that the solution to this problem will eventually reside in open source game engines (which can handle the portability issues) and platform maturity.

    Here is a slightly modified comment on a similar topic posted on Wired last week

    Indeed this is quite the issue and the main ones that have held up the release of Typhon (http_//typhon_egrsoftware_com/) and subsequently the Android tutorials here: http_//www_android-tactelus_com/ The good news is that I’m about done with absorbing all of the recent OS changes and a release is quite imminent. There are four major additions to Android resources w/ Typhon since the 2.0 release / Droid.

    - The 1st is the ability to start up OpenGL ES with multiple sets of attributes / configuration parameters then dynamically select a render path depending on which set of configuration parameters were accepted by the device.

    - The 2nd if any errors occur the next GL config set is tried, but if there are unrecoverable errors (or uncaught exceptions on the Typhon clock/timing thread) instead of just crashing with a generic force closed dialog a specific GL error or the exception + stack track is printed to a custom force close dialog. Also listed is the device and Android build info. In addition to a force close button there is a “force close & email dev” button and this will close the app, but load the error message + device build info into an email and allow it to be sent to one or more defined dev bug addresses. So detailed error info can be sent to devs in 2 clicks by a user from any device. This not only empowers the user giving them specific error info, but also a 2 click incentive to send it to the developers.

    The 3rd is a way to set keyboard defaults and any necessary overriding parameters for input control sensitivities (in case the accelerometer is different on a particular device) via a static XML document.

    The final addition is a default activity to allow the user to change the key defaults. This is applicable of course with any game/app using Typhon on Android. The user defined key defaults take precedence over the static XML defined ones.

    With these additions I’m fairly confident now that for game/app development Typhon provides a good set of additional resources to deal with the Android ecosystem.


    Sadly a major thorn on a per device situation is the underlying implementation of OpenGL; the device driver and GPU specific work, etc. I’ve already noticed that things fail with the underlying implementation of OpenGL between the G1 and Droid. I can get the Droid to spin wait on particular GL configuration functions and the G1 doesn’t fail this way.

    There are also more in depth discussions on how to solve even deeper per device OpenGL ES issues such as GPU specific extensions that require additional entry points / API that can not be handled by providing a static android.jar file to compile against. IE for instance the Droid supports OpenGL 2.X (and 1.X too), but because all devices don’t support 2.X (android.jar API) all of Android is limited to 1.X right now. Also as mentioned there are particular extensions available on the Droid / PowerVR SGX that are not exposed because their entry points can’t be added to android.jar. The only way to solve this is to provide additional device specific jar files with the API to be compiled against then implement some sort of dynamic loading mechanism (I’ve chosen OSGi for Typhon; though it’s not implemented for Typhon yet on Android) that after the GL configuration process can dynamically load a jar file with the render path appropriate for the GPU on the device. Without this it’s impossible to support specific GPU functionality (extension specific).


    The rapid growth of Android and the fact that it is important to address the Android ecosystem of devices _is_ a legitimate challenge and for a lot devs a problem especially new ones unfamiliar with the different OS versions prior to their 1st device/OS experience. The largest problems I’ve seen between 1.5/1.6/2.0 stock (no carrier/manufacturer mods) Android SDK/OS releases are the following:

    - In 1.6 with the addition of various screen sizes and such the AndroidManifest entries for “supports-screens” fails on 1.5. It’s important to include this for an app to utilize/manage the full screen size of a device otherwise it’s automatic compatibility mode.

    - The ability in the resources directory to distinguish resources for different screen sizes or “-nodpi” fails on 1.5. I do a lot of games/game engine work and if you don’t have “-nodpi” on 1.6 and 2.0 your images are scaled for automatic compatibility. While “ok” with a general application this is undesirable for games / GL development due to image size power of 2 requirements.

    - It doesn’t help that the standard way to reach Android build and device info is located at android.os.Build which is present 1.6 and beyond.

    The above is specific Android API / manifest additions. The following are general OpenGL issues:

    - It’s necessary to address devices with various attribute configurations. For instance the G1 supports a depth size max of 16 where the Droid w/ better GPU supports up to 24. If you make an app requesting depth size of 24 then it’ll fail on the G1. Yes this is general GL app concern, but each developer will need to custom code this or see below for an API that solves it already. Google doesn’t provide some assistance API to do this.

    - To make things worse the underlying implementation in “eglChooseConfig” changed between 1.6 and 2.0, and while it was changed to the correct OpenGL ES specification this change alone has broken most GL apps on 2.0 as prior to 1.6 you could request a 565 RGB config and receive one; now you get the highest rated EGLConfig returned first (different order than pre 2.0) and that may be 888. The fix here is custom developer code to choose the correct EGLConfig after receiving the list from “eglChooseConfig”, but each developer has implement this now and it totally is unclear that this is necessary except for complaints/messages of the dev email list; again see platform / API solution below.

    Ah yes.. Now for the plug.. :) I’ve had a real time oriented API for developing Java apps on the desktop that deals with configuration issues and provides a healthy component oriented platform to do GL app/game development. I’ve ported it to Android and have added features that edge off Android dev; for GL dev this is a standard way to setup GL with multiple attribute paths and linking to separate render paths. There are lots of goodies for game development and by using Typhon 98% of GL app can cross-compile between desktop and Android leaving just a little bit of setup code that is unique to both.

    Some info on Typhon; http_//typhon_egrsoftware_com

    In addition a client of mine, Tactel, has sponsored the release of Typhon for Android and a major tutorial series on doing real time app/game development. This is (and will be) available here: http_//android-tactelus_com

    Now note I’ve been reeling with all the OS changes and updates to Typhon and making sure it addresses the Android ecosystem and not one device or OS release. The good news is that I’ve essentially got it covered for Android 2.0. Check out the tutorial site and hit up Twitter or RSS to get an announcement. It’ll be worth it.. :)

  • CJ

    I hate to say this but the open nature of Android is going to present a big problem as the OS becomes more widely used. Google needs to mandate that all apps for Android will work on all Android phones whether they be touchscreen only, keyboard only, or both. When a new version of Android is released it should be mandatory that the manufacturers make it available for their phone. If this doesn’t happen you will a system of haves and have nots with some phones running the latest OS and others stuck running outdated OSes. One only needs to look to Apple for why this becomes important. All iPhones get updated to the latest software. 1 can argue that Apple only has to support 1 form factor but even if they released an iPhone with a keyboard they’d surely make the software compatible between touchscreen only and keyboard only. Freedom is good but only if there’s someone to keep it from running a muck!

  • Mike Leahy

    @CJ – A little wishful thinking. Google itself can’t even provide developers with adequate access to the SDK in a timely manner (1.6/2.0) before public / OTA / new device release let alone require everyone to synchronize efforts. The Open Handset Alliance should set best practices, but enforcement is not really possible. The 80%/20% release w/ bugs & problems mindset has thoroughly taken hold in the tech world; besides we’re talking about corporations whose bottom line is to make money, so there is little incentive on updating devices after release (or we’ll see who plays nice soon enough in the Android ecosystem; support those manufacturers/carriers who update their devices and ignore those who don’t!). As mentioned in my post I can’t wait for the device specific OpenGL crashes due to non-standard low level device driver implementation and such.. Fun fun fun…

    Regarding my above post. A week or so ago I had a G2/Ion in my hands w/ 1.5 for a couple hours and such and made the mistake in not examining if there was any new API level 4 fields in the android.os.Build & android.os.Build.VERSION classes; there are, so that tripped me up until I got some more testing done today on 1.5 devices; Cliq & Hero. So my statement on android.os.Build not being present until 1.6 was hastily made.

    Now a reasonably cool tool to use for testing and this should be reasonably known out there in the mobile world is DeviceAnywhere ( I of course have a bitter pill to swallow as I was the 1st US dev hired there and basically took the prototype through several serious revisions over 3 years adding most of the major features and dealing with scalability/performance and had a large hand in making it what it is on the software side as an architect (what I was doing before Android dev), but the founders are greedy as hell and sharing with no one in that company; no engineer (or other employee) left there happy; IE it’s not a good place to work if you are an engineer. Just saying.. ;P

    Anyway… ;P I recommend it for testing Android devices particularly devices with out of date OSes. Here is a press release regarding which Android devices are currently available:

    I successfully tested Typhon/tutorials on the Cliq & Hero today with DeviceAnywhere. There is a 3 hour free trial and when signing up you need to assign all the carriers (Verizon/T-Mobile/Sprint/etc) that have Android devices that they support as they don’t have an Android package available yet to choose. Now this is going to be of limited use for an app that is crashing with the generic force close dialog as there is no access to adb/debug log, however if using Typhon since there is extended force close dialog w/ error reporting and email support it’s possible to email stack traces and such and examine things that way. So this is a workable solution for testing on Android devices without owning one and you can also test on world wide carriers. I’ll definitely continue to use this service and only buy the really hot new devices as needed. It sure kicks the emulators rear at least for GL dev as you are working on a real device albeit remotely. I might even write a tutorial on the service as it actually is way better to use it than the emulator for any GL dev sans device in hand.

  • Pingback: Android and Me()

  • http://Website Brando

    Why is it in all these pools i never hear mention of the rogers magic, I have a rogers magic and last time i checked it was an official HTC phone running android, so when u guys are taking your polls and whatnot and then proceed to state which phone are still stuck on 1.5, don,t forget the rogers magic……….

  • Mike Leahy

    Well.. I know this is not a developer forum, but I’ll just mention what solved the 1.5/1.6 fragmentation issues for Typhon & me (mentioned above in a couple posts). It’s been the case many times a need to fish in the dev email group or via web searches to put together the right info and this is just one more location some Android dev might stumble across, so here it goes.

    The goal is the ability to build 3D/GL apps with Android to work on 1.5+ without the need for special cases / multiple apks. The problem is that 1.6+ can scale images, but 1.5 does not recognize the 1.6 solution for no scaling. Scaling images is a no-no with OpenGL due to power of 2 requirements for textures, so if Android platform scales images this can break the GL app.

    The solution:

    1. Add the following into the AndroidManifest.xml:

    Also add the tag with everything set to true for all screen sizes and density.

    2. Put all desired unscaleable images into just the drawable resource dir. Sadly drawable-nodpi is rejected on 1.5 as it’s a new API feature of 1.6 / API level 4.

    3. Create a small helper class (UnscaledBitmapFactory in Typhon) that uses reflection on 1.6+ to set inScaled of BitmapFactory.Options to false when loading bitmaps. With Typhon there are texture loading utilities that will use it under the hood, so end user/dev doesn’t have to use the helper class, however, use this helper class as necessary for unscaled images.

    4. Compile with API level 4 and make sure no specific API level 4 code is used such that things will run on 1.5 / API level 3. When doing a GL app/game this is quite possible.

    Result: A GL app that is 1.5+ compatible that plays nice with 1.6+ high density / DPI devices w/ no image scaling and thus power of 2 textures are consistent and one apk / app release in the market will hit all devices.

    Relevant dev group email threads:

    You can implement the above or just use Typhon for GL app creation; coming really darn soon.. ;)

  • haydenTheAndroid

    I’d love to see this as a monthly feature…pretty useful stats to have access to

  • Pingback: Android and Me()

  • Pingback: Game scope()

  • Pingback: Sprint mis-steps (again) | VanishingPoint()