Which Version of Android Should I Develop For? (Part 1)

Android has a whole lot of platform versions, splintering the market. For some developers it’s really hard to choose between compatibility and new features. Developing for Android 2.2 means that you’ve got lots of new and handy features, but there’s still a lot of phones with an Android version below 2.2, which means your app won’t run on most phones.

Pie chart of devices that accessed the Android Market within a period of two weeks, data collecting ended on October 1, 2010

As you can see, Android 2.1 Eclair has the biggest market share, followed by Froyo. Froyo offers some real nice features, like a new Dalvik-compiler, offering a 2-5X better app performance for CPU-heavy tasks. You can find a complete list of changes over here.

For these kinds of apps, Froyo is definitely the best choice:

  • Games. Froyo uses a new Dalvik-JIT (Just In Time) compiler which offers a 2-5X better performance on CPU-heavy tasks, as mentioned above. Most Android-phones don’t use a GPU, which means that everything is done by the CPU, and that’s exactly what Froyo is optimized for. This picture shows a few Froyo benchmarks compared to benchmarks of Android 2.1, just to give an indication of how fast Froyo is. Android 2.2 also offers a few new APIs for OpenGL ES 2.0, but those are just minor updates. Multitouch was already available in Android 2.1, Froyo has just improved it a bit.
  • Apps that use a lot of storage. With the introduction of Froyo, you don’t need to root your phone in order to put apps on your SD-card anymore. Froyo offers a native option to install apps on your SD-card, saving costly storage on your phone. Of course installing apps on your SD-card gives a performance-drawback sometimes.
  • Apps with an embedded WebView. The browser has been given a huge performance-boost through the new V8 Javascript rendering engine, giving it a much better Javascript performance. Watch an example below: [youtube]http://www.youtube.com/watch?v=sJZ8NpdJg3g[/youtube]
  • Apps that require a lot of processor-capacity. This is exactly the same story as the first point (Games). The biggest improvement in Android 2.2 is the performance, thanks to the new JIT-compiler. Take a look at this video, it shows two phones with the same 1GHz processor, the Motorola Droid 2 and Droid X. The left phone runs Android 2.2, the right one Android 2.1[youtube]http://www.youtube.com/watch?v=64zQwRumK94[/youtube]
  • Buggy apps. Well, it might sound a little strange, but if you’re developing buggy apps, you should definitely develop on Froyo. Google has built in a new error-reporting system, making it much easier for developers to see where the errors in their app are located.

That were all the advantages, but of course there are also a few disadvantages. In fact, all the disadvantages are related to one thing: Android apps aren’t downwards compatible. This means that if you develop an app for Android 2.2, it won’t run on Android 1.6 or 2.1. Meanwhile, apps are sure thing upwards compatible.

If you don’t care about you’re app getting downloaded less, I would definitely recommend Android 2.2. If you want to reach as many devices as possible, I recommend developing for Eclair, you’ll reach about 75% of all Android devices, fairly enough I suppose.

  • Nice pointers and all, but I think it is important to understand that even if you choose to support 1.6 to get the largest market share, your apps will run faster on 2.1 and 2.2. So it really boils down to needing some API in 2.1 or 2.2 for your app.

    And even if that is the case … with some magic you can make an app run on 1.6 and still use 2.1 or 2.2. API if the app happens to detect that it runs on 2.2 …


  • Really bad advice here I reckon.

    If you develop with 1.5 as your target/minimum SDK, your app will still be able to take advantage of the JIT compiler in Froyo, just the same as if your target/min SDK was 2.2

    Unless there are specific APIs introduced in a version that you want to use, develop for the lowest one currently supported (1.5).

    You’ll still be able to implement install to SD too, and this feature just won’t show up on anything except phones running 2.2 (as documented on the Android Developers website) but the app will still run just the same.

    You advice here will only increase fragmentation issues IMO.

    Proof of this is found simply by running the same app on an N1 with eclair and one with Froyo – exactly the same code, but can install to SD and runs faster.

    Just saying 🙂

    • I would love an upvote feature for this comment. The article is in my opinion plain wrong. Developing for Android 2.2 only because your app will run faster? This is the android world and this is the world of users choice. If I want to run an app that is slow and laggy on my magic, hero, flipout whatever why shouldn’t I? The performance boost is a nice thing that comes to every app that is developed for every API.

      Maybe find a real developer for writing such articles the next time.

      Sorry for such hard words but a site that is that prominent should not advocate such a bad advise to new Android Developers. This will increase the talk about fragmentation and make fragmentation a real problem for the user and not only a little challenge for the developer.

  • Kevin

    Lots of those Froyo features you pointed out are available at runtime on Froyo, without any intervention of the developer. Such as JIT and error reporting. I just recently switched my development from 1.5 to 2.1.

  • Schorre

    This article was not quite what I expected. You mention one actual feature from a new API version, moving apps to SD.

    The rest of the points are all about the performance of Froyo over Eclair, which is somewhat irrelevant for a developer as there will always be slower and faster hardware. Fast hardware with Eclair can still beat low-end hardware with Froyo. A certain level of OpenGL ES support might be required for some games, but that version says little about the framerate the developer can expect as the hardware can vary.

    I personally see little reason for a developer to leave out support for older versions simply because Froyo is faster. The app will run slower, that’s still better than not being available at all. It uses more space on the phone, many users may still think the app is good enough to deserve that precious space. The app may behave better in Froyo, but that doesn’t make it unusable for all users with lower versions.

    Most new features in new versions can actually be used while retaining compatibility with older versions if one puts a little thought into the development. If your app is based entirely on a feature found in a new API, perhaps for example android-cloud integration, then obviously you will have to accept that you can’t support older versions, but those features are rare.

    I’ve developed a quite resource demanding app that is compatible with Cupcake and still supports brand new Froyo APIs such as the extended camera API and storing the app to sd-card. I can say from experience that supporting these features with a single app didn’t require much extra effort once I understood the concept it relies on (java reflection).

    I hope this thread of articles won’t add to the myth about fragmentation being a problem. I hope the following parts will show developers that it isn’t a big deal and that many users with older phones appreciate when their phone is supported. You can actually eat Froyo and still have Cupcake. 🙂

  • Ben

    I agree that I think this post has a good subject, but misses the mark a bit.

    Some of the above features are available to any app that declares its target SDK version to be Froyo, but if you declare the min SDK version to be something lower, like Cupcake, the app will still run on those earlier versions as long as you’re careful not to use newer methods and constants. It’s still possible to take advantage of Froyo APIs without breaking backwards compatibility by using reflection, but in my opinion that’s a painful hack.

    I think the real question is, should developers consider abandoning backward compatibility for 1.5/1.6? If you want to make extensive use of the newer API’s this would greatly simplify development, and they’re quickly becoming the IE6 of mobile platforms. There are valid reasons to consider this, but features like installing to the SD card don’t require this sacrifice.

  • Chefgon

    Literally every single feature of Froyo that you mentioned is equally available to 1.5 apps that happen to be running on a Froyo device. You don’t need to target 2.2 to take advantage of any of those.

    Additionally, you can code against the push notifications server in a 1.5 targeted app. It’ll only work on Froyo devices, of course, but you don’t need access to any Froyo APIs to write the code.

  • Mats

    As previously stated – Use the lowest API you can, while still making your app happen. If you can’t do what you want with the lowest API – Sure, go ahead and use a later. Seems to me, many apps are using later APIs just because it is available, not because it gives some advantage.

  • JJ

    Next time, let a developer write an article like this…