Android apps

Say you are an Android application developer. You have a last-generation Nexus or Droid phone, and you use for development a recent Android SDK version 2.1. Yet more than a half of your potential users have older phones with older versions of Android: 1.5 (Cupcake) or 1.6 (Donut).

You can simply ignore the not-up-to-date user base, and write your application exclusively for Android 2.0 (Eclair) or more. For this you set minSdkVersion=5 in your AndroidManifest, and you’re done. This is the simplest solution from the developer point of view, but also the worst solution from the user point of view (since half the users don’t have access to the application at all).

Or you can think about making your application backwards compatible, so that it can still be used on Cupcake and Donut. How to do this?

First, you need to look carefully at the API version for the SDK classes and methods that you use. This is indicated in the Android SDK documentation, on the right. For example looking at MotionEvent.getPointerCount() you read Since API level 5, which means that this method is available starting with Eclair — it is not available in Cupcake or Donut, although the class MotionEvent itself is available.

If you mark your application minSdkVersion=3 (Cupcake) but still use the method MotionEvent.getPointerCount(), the application will crash at runtime with a Dalvik VerificationError exception, because the method is not found. Note that you’ll only see this error at runtime and not earlier — not at compile time, and not at Market upload time. So you really have to test your application on Cupcake and Donut in order to catch these crashes. If you don’t test, users with Cupcake will download and try out the application, which will crash on them, and they’ll give you 1-star rating in exchange. Sometimes a helpful user may even drop you an email informing that your app is having a FC (forced close) on G1 with Android 1.5.

Let’s say your application wants to use multiple-touch where available, otherwise the application is still usable with single touch. For multi-touch you use, among others, the method MotionEvent.getPointerCount(). Multiple finger support was introduced in 2.0, Eclair.

You test on Cupcake and you realize that MotionEvent.getPointerCount() does not exist in Cupcake, although MotionEvent with most of the other methods is available. What to do to take advantage of getPointerCount() and multi-touch on Eclair, while not crashing on Cupcake? There is a trick related to how Dalvik loads the Java classes.

Dalvik uses a delayed class loading. The class is only verified when it is used for the first time in the application, i.e. when one of its methods or members is called/accessed. Simply referencing the class name somewhere in the code does not count as class use, and does not produce a class verification.

The second element that we use is android.os.Build.VERSION.SDK_INT. This is an integer giving the OS version installed on the phone (the same as minSdkVersion, 3 for Cupcake, 4 for Donut, 5 Eclair). We use this information to know which of the recent APIs are available and to adapt the code behavior on different OS versions depending on the available APIs.

And now you hit the API joke. By testing on Cupcake, you realize that the app crashes when accessing Build.VERSION.SDK_INT! You double-check the documentation, and indeed SDK_INT is not available on Cupcake, it was introduced in Donut. In other words, the mechanism for version-checking itself is not available on older versions, nice eh?

The workaround is to use Build.VERSION.SDK, which is a String containing the same integer as SDK_INT (e.g. “3″ on Cupcake), and this is available on Cupcake. You wonder why some developer thought that using a String for storing an integer is a good API choice… an API mistake, in other words.

Anyway, let’s go back to the code.

class WrapNew {
    static int getPointerCount(MotionEvent event) {
        return event.getPointerCount();
    }
}

You create a class that wraps the calls to the new Eclair API. Instead of calling the MotionEvent.getPointerCount() directly, you call through the wrapper class. You only call the new method after you verified that the Build.VERSION.SDK is hight enough that the new API exists.

public boolean onTouchEvent(MotionEvent event) {
    boolean hasMultiTouch = Integer.parseInt(Build.VERSION.SDK) >= 5;
    int nPointer = hasMultiTouch ? WrapNew.getPointerCount(event) : 1;
    // ...
}

The Dalvik trick is: as long as we don’t call WrapNew.getPointerCount(), the WrapNew class is not loaded by Dalvik and does not generate a VerificationError by referencing the non-existing API MotionEvent.getPointerCount().

You test again the application on Cupcake, and it does not crash anymore with VerificationError! It also supports multi-touch on Eclair, and the solution is pretty clean and simple code.

One more note: if you use Proguard to optimize your Android application, be sure to mark the wrapper class as non-inlinable, because otherwise Proguard would optimize it out of existence, denying it’s purpose.
-keep ,allowobfuscation class package.WrapNew { *; }

You can see all this in practice, real-life working code, in the Arity Calculator application, which is Open Source so you can freely explore the code. Arity Calculator is available on Market on Android phones, for Cupcake, Donut, Eclair and on.

And here is the missing table from the Android documentation:

According to the Nexus One specs, it has a 800×480 AMOLED display.

According to Wikipedia, this is what makes an AMOLED display different from standard LCD:

• It does not need a backlight, the pixels emit light themselves. This allows for thinner display.
• Only the turned-on pixels consume power. In average AMOLED uses less power than LCD. The power usage is dependent on the color displayed — a black screen uses much less power than a white screen.
• The contrast is very good. The black is very deep (as there’s no backlight leakage).
• The viewable angle is very large; this is often a problem with LCD, particularly TN (twisted-nematic), which have small viewing angles.
• OLED has better reponse rate than LCD.
• The lifetime of OLED is shorter than LCD. Only the period a pixel is lightened (turned-on) counts towards the lifetime. The blue subpixels have the shortest lifetime.

Glossing over the technical details, the result is that the Nexus One has a *great* display. It is the highest quality display I’ve ever seen (but I can’t say how it compares to the Droid display as I have not seen a Droid phone yet). The Nexus display is large and high-density, is very crisp, the colors are very saturated, and the black is indeed very deep. WVGA, 800×480 is quite a high resolution for a display of this size (a more typical resolution for this size would be HVGA, 480×320 as on the G1).

After getting used to the Nexus display, when you look back to your previous phone’s display you’ll be shocked by how low-quality the old LCD seems now.

The AMOLED display on Nexus has one more surprise on hold: On Nexus, each pixel is composed of only two subpixels instead of the usual three (Red, Green, Blue) subpixels of an LCD. The following picture should help understand the subpixel pattern on a Nexus: (source)

So every pixel contains a green subpixel, and alternating a red or a blue subpixel. A pixel has either red or blue subpixels but not both.

Why is it done this way? This technique allows for a larger physical area for the blue and red subpixels, thus increasing their lifetime. It also allows to implement the high pixel count (800×480) by using only two thirds of the subpixels that would normally be needed (2subpixels/pixel instead of 3subpixels/pixel).

What is the impact of this unusual subpixel pattern? Natural images (such as pictures, movies etc) are very well reproduced and likely the subpixel impact is not perceivable. Synthetic images that contain pixel-aligned thin and saturated lines (red or blue) allow to discern the “alternating” subpixel pattern. But as the display is very high density and the pixels are very small, most likely you would never become aware of the subpixel pattern if not looking explicitly for it.

What is the impact of AMOLED for application developers:

• First of all, you may not care at all about AMOLED vs LCD, and everything will work just fine.
• You can use darker colors to save power. You may prefer white-text-on-black-background to black-on-white-background, as the dominant black color uses less power on AMOLED. (the dominant color makes no power difference on classical LCD).
• You may prefer using darker colors to increase the display lifetime. You may prefer avoiding displaying intense blue (as it has the lowest lifetime) for long periods of time.
• If you want to draw highest-resolution thin lines, they are best rendered in green — because the green subpixels have double the resolution of red and blue subpixels.

It seems the choice of subpixel pattern is also related to human eye physiology, as the human eye is more sensible to green than to blue, and keeping green at full resolution gives rich image information to the eye.

When a Java program creates new objects (using new), it results in the subsequent invocation of the Garbage Collector to free up memory. On Android an invocation of the GC takes of an order of 100ms, so it produces a user-visible short freeze of the application. Especially when the application is doing some form of animation the freeze is visible. In addition the GC is expensive (CPU & battery).

In order to avoid the GC invocations one can use allocation-free code. This is code that allocates most of the needed objects up-front, once, and then keeps reusing the existing objects while in the animation loop. Of course, be careful to balance the pre-allocation and object reuse (which speeds things up by avoiding GC) with the size of the allocated objects which may increase the memory usage of the application. In general, do not keep large objects alive longer than necessary.

For example in a View you can create a Paint object once and keep reusing it for all the onDraw() calls, instead of creating one or more “new Paint()” for each onDraw(). And similarly for a Point or an array of Points, etc.

String is immutable and thus can’t be reused, but you can use StringBuilder instead, which is pretty similar to String and can be reused.

Of course, it is easier to avoid the object creations that happen in the application code and thus are visible (look for “new”); it is a bit harder to detect and avoid the allocations that happen in the framework code as they are not so obvious. You can use the ddms Android tool to track down the object creations done by an application.

After taking care to remove the object creations from the hot areas of code you may be surprised by how fast and smoothly the application runs.

I installed today the Kreactive Calculator from the Android Market and I realized that it uses my Arity library. As I released Arity under the Apache 2.0 License (a very permissive license), a new user of the library is usually good news. But Kreactive does not seem to be a good open-source citizen: they repackaged Arity under their own package “com.kreactive.arithmatic” instead of the original “org.javia.arity”, and they don’t acknowledge anywhere their use of the library. Basically it looks as if they imply it is their own code. Given Arity’s Apache 2.0 license, they really didn’t have to do this ’stealing’ — but I’ll take it as a compliment.

Anyway, good luck Kreactive with your Android apps, and don’t forget to be a good citizen next time!

In the Java “class” file format specification, the length of the bytecode of any method is limited to 64KB. This arbitrary limitation is bad in itself, but see below what it does in conjunction with the other stupider Java ‘feature’.

In any normal language, a literal array constant (used for array initialization) is represented as a compact block of data. For example when initializing an array with 1000 byte values, you’d expect the initialization data to take up 1KB (1000 x 1B). But not so in Java, not at all.

Let’s consider a long array of bytes, initialized with some data.
static final byte B[] = {10, 20, 30, 40, 50, 60, 70, 80, …};

In the “class” format there is no provision for storing the array initialization data in a compact format. Instead, bytecode instructions are generated for filling-in the array, a small block of bytecodes for each entry of the array data:

dup          //1 byte; duplicate the array address on the stack
sipush 300 //3 bytes; the array index where to store the value
bipush 99   //2 bytes; the value to store
bastore      //1 byte; do the store

This adds up to 7 bytes for each entry of the array. So if you initialize an array of 5000 bytes, this would generate 35KB of bytecode instead of the 5KB that would normally be enough to store the data.

For an array of int, float or larger types, the bytecode structure is a bit different, in that the integer value is not inlined in the bytecode, but instead read from a constant pool.

dup          //1 byte
sipush 300 //3 bytes; the array index
ldc_w  400 //3 bytes; load int from constant pool position
iastore      //1 byte

Let’s put in a small table the amount of data Java uses for initializing arrays of different types:

This form of doing array initialization is in my opinion the stupidest miss of the “class” file format.

But lets see where Stupidity Synergy comes into play. Synergy means that sometimes, when you put together one stupid feature with another stupid feature, you get a result that is larger than the sum of the parts. Java achieves synergy by combining the 64KB method size limit with the peculiar way of compiling the array initialization.

As we’ve seen, bytecode (i.e. method code) is needed for any array initialization. Even initializing a static array at the class level produces an invisible method that contains the code for array initialization. Combining this with the method size limit produces very restrictive limits on the size of array initializations.

Nice powerful language, where you get a “code too large” compilation error when you try to initialize a byte array with more than 9K entries…