Chapter 38
Handling Platform
Changes
Android will continue to rapidly evolve over the next few years. Perhaps, in time, the rate of change will decline some. However, for the here and now, you should assume that there will be significant Android releases every 6 to 12 months, and changes to the lineup of possible Android hardware on an ongoing basis. So, while right now, the focus of Android is phones, soon you will see Android netbooks, Android tablets, Android media players, and so on.
Many of these changes will have little impact on your existing code. However, some will necessitate at least new rounds of testing for your applications, and perhaps changes to those applications based on the test results.
This chapter covers a number of the areas that may cause you trouble in the future as Android evolves, with some suggestions on how to deal with them.
Brand Management
As of the time of this writing, the Android devices that have been released have been Google Experience phones. This means they get the standard Android interface—the things you find in the emulator—along with the standard roster of add-on applications like Google Maps and Gmail. In turn, manufacturers are allowed to put the “with Google” brand on the device. But not all devices will be this way.
Some manufacturers will take Android as a base and change what is included, adding some of their own applications and perhaps even changing the look and feel (menu icons, home screen structure, etc.).
Others may use Android solely from the open source repository, and while they may ship with the standard look and feel, they will lack the commercial add-on applications.
Even today, some devices have a different mix of applications based on where they are distributed. US recipients of the T-Mobile G1 have an Amazon MP3 store application; not all international recipients do.
If your application is independent of all of this, then it should run anywhere. However, if your application code or documentation assumes the existence of Google Maps, Gmail, Amazon MP3 store, and the like, you may run into trouble. Be certain to test your application thoroughly in environments where these applications are not available.
More Things That Make You Go Boom
Most of the items noted in the previous section focused on hardware changes. Now, let’s examine some ways in which Android can cause difficulty to you when the operating system itself changes.
View Hierarchy
Android is not designed to handle arbitrarily complicated view hierarchies. Here, view hierarchy means containers holding containers holding containers holding widgets.
The Hierarchy Viewer program, described in Chapter 35, depicts such view hierarchies well, as shown in Figure 38–1. In this example, you see a five-layer-deep hierarchy, because the longest chain of containers and widgets is five (from PhoneWindow$DecorView through to Button).
Android has always had limits as to how deep the view hierarchy can be. In Android 1.5, though, the limit was reduced, so some applications that worked fine on Android 1.1 would crash with a StackOverflowException in the newer Android. This, of course, was frustrating to developers who never realized there was an issue with view hierarchy depth and then got caught by this change.
The lessons to take from this are as follows:
- Keep your view hierarchies shallow. Once you drift into double-digit depth, you are increasingly likely to run out of stack space.
- If you encounter a
StackOverflowException, and the stack trace looks like it is somewhere in the middle of drawing your widgets, your view hierarchy is probably too complex.
Figure 38–1. Hierarchy Viewer Layout view
Changing Resources
The core Android team may change resources with an Android upgrade, and those may have unexpected effects in your application. For example, in Android 1.5, they changed the stock Button background, to allow for smaller buttons. However, applications that implicitly relied on the former larger minimum size wound up breaking and needing some UI adjustment.
Similarly, applications can reuse public resources, such as icons, available inside of Android proper. While doing so saves some storage space, many of these resources are public by necessity and are not considered part of the SDK. For example, hardware manufacturers may change the icons to fit some alternative UI look and feel. Relying on the existing ones to always look as they do is a bit dangerous. You are better served copying those resources out of the Android open source project (http://source.android.com/) into your own code base.
Handling API Changes
The core Android team has generally done a good job of keeping APIs stable, and supporting a deprecation model when they change APIs. In Android, being deprecated does not mean it is going away—just that its continued use is discouraged. And, of course, new APIs are released with every new Android update. Changes to the APIs are well documented with each release via an API differences report.
Unfortunately, the Android Market (the primary distribution channel for Android applications) allows you to upload only one APK file for each application. Hence, you need that one APK file to deal with as many Android versions as possible. Many times, your code will “just work” and not require changing. Other times, though, you will need to make adjustments, particularly if you want to support new APIs on new versions while not breaking old versions. Let’s examine some techniques for handling these cases.
Detecting the Version
If you just want to take different branches in your code based on version, the easiest thing to do is inspect android.os.VERSION.SDK_INT. This public static integer value will reflect the same API level as you use when creating AVDs and specifying API levels in the manifest. So, you can compare that value to, say, android.os.VERSION_CODES.DONUT to see whether you are running on Android 1.6 or newer.
Wrapping the API
So long as the APIs you try to use exist across all Android versions you are supporting, just branching may be sufficient. Where things get troublesome is when the APIs change, such as when there are new parameters to methods, new methods, or even new classes. You need code that will work regardless of Android version, yet lets you take advantage of new APIs where available.
There is a recommended trick for dealing with this: reflection, plus a wee bit of caching.
For example, back in Chapter 8, we used getTag() and setTag() to associate an arbitrary object with a View. Specifically, we used this to associate a wrapper object that would lazy-find all necessary widgets. You also learned that about the new versions of getTag() and setTag() that are indexed, taking a resource ID as a parameter.
However, these new indexed methods do not exist on Android 1.5. If you want to use this new technique, you need to wait until you are willing to support only Android 1.6 and beyond, or you will need to use reflection. Specifically, on Android 1.5, you could associate an ArrayList<Object> as the tag, and have your own getTag()/setTag() pair that takes the index.
This seems straightforward enough, so let’s look at APIVersions/Tagger. Our activity has a simple layout, with just a TextView:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>
<TextView android:id="@+id/test"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
/>
</LinearLayout>
The source code to our Tagger activity looks at the API version we are running, and routes our getTag() and setTag() operations to either the native indexed one (for Android 1.6 and above) or to the original nonindexed getTag() and setTag(), where we use a HashMap to track all of the individual indexed objects:
package com.commonsware.android.api.tag;
import android.app.Activity;
import android.os.Build;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.TextView;
import java.util.HashMap;
import java.util.Date;
public class Tagger extends Activity {
private static final String LOG_KEY="Tagger";
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView view=(TextView)findViewById(R.id.test);
setTag(view, R.id.test, new Date());
view.setText(getTag(view, R.id.test).toString());
}
public void setTag(View v, int key, Object value) {
if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.DONUT) {
v.setTag(key, value);
}
else {
HashMap<Integer, Object> meta=(HashMap<Integer, Object>)v.getTag();
if (meta==null) {
meta=new HashMap<Integer, Object>();
}
meta.put(key, value);
}
}
public Object getTag(View v, int key) {
Object result=null;
if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.DONUT) {
result=v.getTag(key);
}
else {
HashMap<Integer, Object> meta=(HashMap<Integer, Object>)v.getTag();
if (meta==null) {
meta=new HashMap<Integer, Object>();
}
result=meta.get(key);
}
return(result);
}
}
This looks great, and if we build it and deploy it on a Android 1.6 or greater emulator or device, it runs like a champ, showing the current time in the activity.
If we build it and deploy it on an Android 1.5 emulator or device, and try to run it, it blows up with a VerifyError. VerifyError, in this case, basically means we are referring to things that do not exist in our version of Android, specifically:
- We are referring to
SDK_INT, which was not introduced until Android 1.6. - We are referring to the indexed versions of
getTag()andsetTag(). Even though we will not execute that code, the classloader still wants to resolve those methods and fails.
So, we need to use some reflection.
Take a look at APIVersions/Tagger2. This is the same project with the same layout, but we have a more elaborate version of the Java source:
package com.commonsware.android.api.tag;
import android.app.Activity;
import android.os.Build;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.TextView;
import java.lang.reflect.Method;
import java.util.HashMap;
import java.util.Date;
public class Tagger extends Activity {
private static final String LOG_KEY="Tagger";
private static Method _setTag=null;
private static Method _getTag=null;
static {
int sdk=new Integer(Build.VERSION.SDK).intValue();
if (sdk>=4) {
try {
_setTag=View.class.getMethod("setTag",
new Class[] {Integer.TYPE,
Object.class});
_getTag=View.class.getMethod("getTag",
new Class[] {Integer.TYPE});
}
catch (Throwable t) {
Log.e(LOG_KEY, "Could not initialize 1.6 accessors", t);
}
}
};
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView view=(TextView)findViewById(R.id.test);
setTag(view, R.id.test, new Date());
view.setText(getTag(view, R.id.test).toString());
}
public void setTag(View v, int key, Object value) {
if (_setTag!=null) {
try {
_setTag.invoke(v, key, value);
}
catch (Throwable t) {
Log.e(LOG_KEY, "Could not use 1.6 setTag()", t);
}
}
else {
HashMap<Integer, Object> meta=(HashMap<Integer, Object>)v.getTag();
if (meta==null) {
meta=new HashMap<Integer, Object>();
v.setTag(meta);
}
meta.put(key, value);
}
}
public Object getTag(View v, int key) {
Object result=null;
if (_getTag!=null) {
try {
result=_getTag.invoke(v, key);
}
catch (Throwable t) {
Log.e(LOG_KEY, "Could not use 1.6 getTag()", t);
}
}
else {
HashMap<Integer, Object> meta=(HashMap<Integer, Object>)v.getTag();
if (meta==null) {
meta=new HashMap<Integer, Object>();
v.setTag(meta);
}
result=meta.get(key);
}
return(result);
}
}
First, when the class is initially loaded, the static initialization routines run. Here, we see what version of Android we are running, using the old SDK String instead of the new SDK_INT integer. If we are on Android 1.6 or newer, we use reflection to attempt to find the indexed getTag() and setTag() methods, and we cache those results. Since those methods should not change during the lifetime of our application, it is safe to cache them in static variables.
Then, when it comes time to actually use getTag() or setTag(), we look to see if the cached Method objects exist or are null. If they are null, we assume we need to use the old versions of those methods. If the Method objects exist, we use them instead, to take advantage of the native indexed versions.
This version of the application works fine on Android 1.5 and above. Android 1.6 and above uses the built-in indexed methods, and Android 1.5 uses our fake version of the indexed methods.
There is a little extra overhead for going through the Method-based reflection, but it may be worth it in some cases, to access APIs that exist in newer versions of Android, rather than restricting ourselves to only the older APIs.. There are even ways to use this technique for cases where entire classes are new to newer Android versions (see http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html).