backwards compatibility: strategies and tactics

Copyright © 2012 CommonsWare, LLC

AnDevCon III

Backwards Compatibility: Strategies and

Tactics


Device Mix

image Copyright © 2012 Google, Inc. – reprinted with permission


Device Mix

● The Market Is Not the World● Kindle Fire● NOOK Tablet● Wearables (WIMM, I'm Watch, etc.)● Miscellaneous non-Market devices

● If You Distribute to These, Take Their Versions Into Account!


Device Mix

● Predictions Sure To Go Wrong● November 2012: ICS and newer reaches majority status

– New device sales– Upgrades for existing devices

● December 2012: Mayan Apocalypse● April 2013: Android 2.x below 20%● September 2013: Android 2.x below 5%● December 2013: Ragnarök


Competing Strategies

● Old API-Centric● Lowest common denominator● Today: Android 2.3, maybe 2.2● Only deal with newer things when unavoidable

● New API-Centric● More aggressively support newer capabilities

– Particularly with respect to UI

● Today: ICS● Gracefully degrade for older devices


Forwards, Not Backwards

● Older Ain't Gettin' Any Bigger● Aim for the increasing market share, not the decreasing

share

● Sneezers' Devices● Bloggers, media, etc.● Tend towards newer devices● If you look stale, may impact their interest in you


Forwards, Not Backwards

● Distinctive, Not Decomposing● Are there new features that can give you a competitive

edge?– Even if not all the users can take advantage of them

● It's the Way the (Web) World Works● IE6-only versus graceful degradation● Well-trod path, needing Android-specific tactics


Targets and Strategies

● Old API-Centric● Build target = min SDK version = lowest common

denominator● Target SDK version no higher than min SDK version

● New API-Centric● Build target = oldest version that has everything you are

using directly (or via library)● Min SDK version = oldest you are supporting● Target SDK version = current-ish Android version


Validating Compatibility

● Compile-Time: Lint● Keep your Android SDK tools/ADT updated!● Will warn you when you try using newer stuff on older minSdkVersion– Requires manual lint run from Eclipse menu

● Use annotations to suppress warnings– @TargetApi(NN)


Validating Compatibility

● Testing● Directly via emulator● Directly via available hardware● Bulk-testing Services

– TestDroid Cloud– LessPainful– Apkudo– Etc.


Libraries for Compatibility

● Android Support Package● Fragments

– Large subset, but not everything from native API Level 11+

● Loaders● GridLayout● *Compat Classes

– Access to newer constants– Helper methods to get at newer capabilities while gracefully

degrading to no-ops/defaults

● Separate Implementations


Libraries for Compatibility

● Action Bar Sherlock● Implementation of ActionBar for Android 2.x● Same API as native API Level 11+

● Nine Old Androids● Implementation of android.animation framework

for Android 1.x/2.x


Ad-Hoc Backports

● Find AOSP Code, Clone, Fix● New widgets (e.g., Switch)● Other stuff largely separable from firmware● Challenges

– Finding resources– Dealing with package-private methods


Library/Backport Strategy

● Use as Temporary Scaffolding● Know which API levels a given library or backport is

addressing● May vary by what you are using

● Remove In Time● Once you no longer are supporting the older API levels,

drop the scaffold and re-test


Java Version Guards

● Android 2.x+● Wrap any references to items from newer API level in a

test of the API level

if (Build.VERSION.SDK_INT>Build.VERSION_CODES.GINGERBREAD) { // do something}


Java Version Guards

● Android 2.x+● Wrap any references to items from newer API level in a

test of the API level

if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.GINGERBREAD) { @TargetApi(11) // do something needing API Level 11+}


Java Version Guards

● Scenario: AsyncTask● Serialized if targetSdkVersion >= 14● Use executeOnExecutor() to force to classic thread

pool model● Problem: executeOnExecutor() new to API Level 11● Solution: version guard block


Java Version Guards

● Android 1.x● Problem: Dalvik complains if you load a class that refers

to items from a newer API level● Solution

– Isolate newer-API items in a separate helper class– Only refer to that helper class within a version guard block


Java Version Guards

● The Old API-Centric Approach● Use version guard to detect newer API level● Use reflection to access items that only exist at that API

level● Benefit: can leave build target on older API level

– Build target only affects what you directly reference


Versioned Resources

● Use -vNN Resource Set Suffix● Apply to resources valid for API Level NN and higher● Scenario

– res/values/ = good for anything– res/values-v11/ = good for Honeycomb and newer

● Example– Style in -v11 that references Theme.Holo– Style with same name in default directory that does not

reference Theme.Holo


Versioned Components

● Components Valid for Certain API Levels● Activity only needed on Android 3.1+● Different app widgets for API Level 11, older devices

● Technique● Boolean resource, contained in two resource sets

– Default plus -vNN set

● Use boolean resource in android:enabled attribute in manifest– Disabled components do not show up anywhere


Scenario: Preferences

● Goals● Want to use PreferenceFragments and headers on API

Level 11 and higher● Want preferences to still work on Android 2.x

● Option #1: Different PreferenceActivity Classes● Use versioned components trick to dictate which one is

available● Use action, not component, in launching Intent● Reuse preference XML as best you can


Scenario: Preferences

● Option #2: Version Guards● One PreferenceActivity● onBuildHeaders() only called on API Level 11+● Reuse preference XML as best you can

● Option #3: Backport● Find current implementation (source, resources)● Convert to use Android Support fragments● Most difficulty, but consistent implementation,

look-and-feel


QOTD

“You’re a Web developer in Java” is the first thing I tell every person mentioning fragmentation. There are no tablets. There are no phones. There’s no Google TV. There is only an unlimited set of configurations of every conceivable feature. Write your application in a dynamic, progressively enhancing manner that follows well-documented patterns and you will be just fine.

Jake Wharton

backwards compatibility: strategies and tactics

Technology

newerapi items

newer api level solution

native api level

api level nn

api level benefit

newer api level use

older api level build

java version guards