Consequences of Targeting Android SDKs

Tuesday Feb 8th 2011 by Lauren Darcey & Shane Conder

Share:

Choosing which Android SDKs your application will support is a decision with far-reaching ramifications.

As all seasoned developers know, you've got to make tradeoffs each and every day you're designing or developing applications. Many factors can influence your decisions: deadlines and time pressure, client contentment, quality control and more. There's the never-ending tug of war between getting it done now, and getting it done right. One development decision that can significantly affect your Android development project is which Android SDKs (or API Levels) you target.

Choosing the Android SDKs your application will support is a decision with far-reaching ramifications that should be considered by the whole team. This decision affects:

Which devices are supported and not supported

Code complexity and maintenance

Project schedules

The size and performance of your application package

Product management

Effects of Target Android SDK on Device Support

Of course, every developer wants their app in the hands of every user. This is ideal, and sometimes even achievable. But it's not for everyone. Let's look at some of the decisions people might make when it comes to choosing API levels to support.

Some might say: let's only support the latest version. As of this writing, the majority of Android users were not running devices with the newest SDK (less than 1%; see Figure 1 below). By limiting your app support, you cut off most Android users -- sometimes whole countries -- but at the same time, you may benefit from being one of the few apps available to bleeding edge users running what the latest the platform has to offer, thus raking in the early adopters looking for all the shiny new features of their new device.

If you're a developer with an app that relies upon the latest APIs, then this may be a reasonable choice. The new SDKs will eventually percolate throughout the devices and users of the world through upgrades (OTA upgrades or users simply upgrading their devices after dropping them in hot tubs), but you run the risk of having too small of a pool of users for your app to thrive immediately.

Okay, then, let's support everything! Many rookie developers think one should simply target the widest range of platform versions you can, in order to reach the most users and devices. While you want to encourage everyone on earth to install your apps and pay you for the privilege, this is not always as easy as one would hope. If your application is not pushing the boundaries of the platform, you may be able to achieve this. In other words, if your app only needs to use APIs that have been around since Android 1.6, for example, then you may very well be able to achieve this in a reasonable fashion. However, if you are building that state-of-the-art application that relies upon the newest features of the platform, you are basically forced to create a hybrid application that supports the latest SDK features, but also provides alternative functionality for those on older versions of the platform. More on this in a moment.

Here are some common Android SDK version cutoffs, as determined by Figure 1:

Android 1.6+ (to support most devices available today). This currently represents over 96% of the devices actively accessing the Android Market.

Android 2.1+ (to support most "newer" devices). This currently represents about 90% of the devices, but certain regions and user demographics are left out.

Android 2.3+ (to support the "latest" devices only). This currently represents just under 1% of the devices accessing the Android Market.

Although it might seem like you aren't losing many potential customers at the Android 2.1 cutoff -- just 10% -- that accounts for several million devices. In just the fourth quarter of 2010, around 33 million Android devices were sold. You can see that every percent can easily account for quite a lot of users. Determining if they're your users is something that can be done through market research and analysis.

Another aspect of the SDK versions is that some, though not all, devices are upgraded after they've shipped. This has the effect of shifting the SDK support forward. This is a good thing, but it can't be guaranteed. You can't just look at the chart and say, "Well, when those last four percent of Android 1.5 devices are upgraded, we'll never have to worry about Android 1.5 again." Just recently, users heard from a manufacturer that their Android 1.5 devices were, in fact, not going to be upgrade despite hearing otherwise for a long time.

Effects of Target Android SDK on Code Complexity and Maintenance

Let's say you go down the route of trying to support all devices. Well, this prompts other development decisions. Will you simply restrict yourself to only APIs (and methods) that are available across all API Levels you plan to target, or will you use techniques like Java reflection to test for, and call, methods when they are available?

If you choose the first option and simply provide one generic solution for all devices (i.e. use the lowest API Level classes and methods only), your application is not taking advantage of the latest and greatest features that newer devices have to offer, but at least your code is straightforward and easier to maintain. If you can deliver all the features your users demand and expect, then by all means, this is your best bet.

If you choose the second option and provide alternative functionality depending on the API Level, then your code will be awash in conditional statements that can be incredibly difficult to read and maintain. The more device-specific characteristics you try to accommodate, whether we're talking API levels, screen resolutions, or what have you, the more code paths you create and the more complex your application becomes. On the bright side, you are providing users with the "best" version of your application for their specific device.

There is a third choice: make different app packages for different platform versions. This is certainly feasible, but it involves substantial source control management trickery that small teams may find difficult to manage. It also adds publishing complexity.

Effects of Target Android SDK on Project Schedules

Perhaps it has already dawned on you that these choices can have significant impact on your project schedule. Still, we call this out specifically because it's often not communicated well between clients/project management ("I want to support everyone!") and the developer ("Uh, do you know what that means?" or "Sure! The schedule isn't my problem!"). The short answer is: providing alternative functionality for different device API levels is likely to impact your development schedule as well as your quality assurance team's hardware budget and testing schedule, not to mention your configuration management situation and published app management.

Effects of Target Android SDK on Application Package Size

Much like code complexity, your application package will grow in size substantially as you provide alternative resources and code for different API Levels and device characteristics. The larger codebase alone might be acceptable, but if you are also including significant quantities of alternative resources and assets in your package, you may find your application package rapidly approaching or even exceeding the app size limitations imposed by publication channels like the Android Market. Also, you may be doing your users a disservice by forcing them to install an enormous application package, most of which doesn't even apply to them. When you see this happening, it's likely time to consider breaking your application up into logical "versions" and publishing them separately. You'll need to familiarize yourself with various Android Market filters to pull this off properly, adding further complexity but creating a better experience for your users.

Although the current 50MB limitation on the Android Market may seem huge for mobile, keep in mind that on competitive systems there are plenty of applications and games that exceed this size without carrying the extra graphics around for alternate versions.

Effects of Target Android SDK on Project Management

If you've broken your application package up into logical "version" packages, then you need to consider and plan how you will keep track of them. Often product management doesn't really care about the "versions", but wants to treat it as one application for reporting and revenue purposes. This makes a lot of sense, but unfortunately, it's not how most publication channels, like the Android Market, function. In terms of reporting, ratings, etc. your app "versions" are separate apps and are managed separately.

For example, when you want to change your app's price, you'd need to changing it numerous times -- once per package. Want to know how much money you've made on your application? Well, you'll have to do the math yourself by summing the individual "version" totals. To make matters worse, you as the developer may inevitably receive a frantic email from a well-meaning higher-up saying that there's some horrible bug that needs fixing right this very minute -- but you won't necessarily know which "version" has the issue without some extra legwork.

Conclusion

Each decision you make regarding SDK versions has its own set of issues, with its own set of pros and cons. We have discussed many of these pros and cons in theory, but each product is unique. If you were hoping that we were going to propose the perfect solution to this problem, we'll apologize now: there isn't one. Our personal approach is one of moderation -- support as many appropriate devices as possible, trend towards the generic solution when you can, diverge when necessary or highly beneficial, and always consider the impact of your design decisions and educate your team and clients. Do your very best to keep your packages lean; your app versions minimized, clear and well labeled; and your users happy.