Of CES, Fragmentation, and Ice Cream Sandwiches

Hear ye, hear ye, fellow tech nerds! The glorious Consumer Electronics Show is upon us and you know what that means, right? A crop of new Android phones! But with the bountiful harvest of these snazzy new gadgets comes…dun dun dun…fragmentation!

Ah, fragmentation. The Android application developers mortal coil. Different UIs from different OEMs, divergence in hardware, look and feel, behavior, APIs, etc, etc, we developers need a hero. Enter Ice Cream Sandwich. While ICS is a step in the right direction for fragmentation in some respects (e.g. unifying Honeycomb and Gingerbread), there are some ways it makes things a bit harder:

Screen Resolutions
The launch of ICS coincided with the new Galaxy Nexus touting an unprecedented 1280 x 720 display compared to the ‘ordinary’ 800 x 480 displays of the past. Plucked against Gingerbread, ICS also brings along a new method of reporting screen resolutions and adds a new kick with on-screen ‘hardware’ keys for phones. On devices without dedicated hardware keys, a portion of the screen is allocated to providing on-screen hardware keys, thus slightly altering the remaining available display region. Previous methods to report the screen resolution, display.getWidth/getHeight have been deprecated and replaced by display.getSize.

These differences may lead to complications with unusual object placement/layouts and simple incompatibilities. For example, the popular 3rd party keyboard, ‘Swype’ is problematic on the Galaxy Nexus with a message explaining an unsupported screen resolution. A temporary solution has been discovered by users by modifying the config file, ‘display0_SwypeScreen.ini’ to suit the appropriate screen size.

Menus
For devices without physical hardware keys, ICS programmatically displays a virtual menu key depending if the application requires it. A new ‘Action Bar’ has been brought over from Android 3.0 which is included if the activity uses the Theme.Halo theme – which is the default theme if either the targetSdkVersion or minSdkVersion is set to 11 or greater. In the presence of the action bar, a menu key will appear typically near the top right of the display. In absence, a menu key appears among the row of soft keys to the bottom of the display. However, even between standard Google applications like Gmail, Calendar, Maps, Gallery, Market, etc, which make use of the new Action Bar, the location of the virtual menu key varies making the user search around for three little dots.

In addition to the differences in the virtual menu key’s location, the operation of the menu key can occasionally be problematic. In certain apps such as Gravity Guy, Guerrilla Bob, and Market Enabler, a virtual menu key appears at the bottom next to the row of soft keys, yet it doesn’t serve any purpose. Pressing the menu key yields no response leading the user to think something has gone awry. Similarly before being updated, the popular application ‘Facebook for Android’ did not have any menu key appear at all despite the undoubted existence of a menu page.

Hardware Acceleration
As the display resolutions of Android mobile devices reach PC levels (many 13″ laptops are only at 1280 x 800), the demand for offloading screen rendering to the GPU is ever more important especially when a fluid 60fps experience is desired. ICS incorporates the level of hardware acceleration that existed with Android 3.0. Dianne Hackborn from Google:

“The implementation [of hardware acceleration] in Android 4.0 is not any more full than in 3.0… The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:hardwareAccelerated=”true” in their manifest.”

This similarity brings forth drawbacks for developers who may want to use hardware acceleration. A number of operations such as Canvas.clipPath, Canvas.drawPicture and Paint.setLinearText are not supported by hardware acceleration at the moment. Tiny Towers crashes with logcat citing ‘E/AndroidRuntime(20581): java.lang.

UnsupportedOperationException at android.view.GLES20Canvas.clipPath’ when GPU acceleration is forced. Whilst this may be a non-issue for Bob and Jane, developers may find it difficult and frustrating to have to re-develop their application to take advantage of hardware acceleration in order to improve user experience. In the case of new applications, a dilemma may arise between using a certain operation but not being able to gain hardware acceleration, against a possibly less favorable operation but able to be accelerated.

New API’s
Often with a major OS release comes a number of new additions. In the case of Android 4.0, one of these is a new set of documented APIs for accessing Calendar data. However, as this was only released with Android 4.0, a number of developers had previously developed their applications using old undocumented Calendar APIs, some of which use low-level access to the calendar database.

As mentioned here http://android-developers.blogspot.com/2011/10/ics-and-non-public-apis.html, some developers may find that their apps won’t run correctly on ICS without some updates being made. Applications such as SMS Backup+ were initially broken after ICS first released owing to a change in Calendar APIs, with recent specific changes just made in order to have Calendar features working once more. https://github.com/jberkel/sms-backup-plus/pull/206. It is without a doubt that these new API’s ease the task for future apps and developers, but in the mean time in order to support older releases, a bit of extra work needs to be done.

With all new OS version and device releases, there’s going to be some good and some bad. Google is trying to steer the Android ship away from fragmentation by offering a common base for all mobile devices and providing more official APIs for developers to use. However, changes need to be made. As developers we can’t rest on our laurels and wait for Google to figure it out, and we definitely can’t wait around for every OEM to push ICS updates for every Android model – some of the most popular devices may not even get it. We need to write code and then it to make sure it actually works on real devices. Unless everyone starts churning out code according to the books and the professors who jabbered on about ‘tightly coupled code’, certain things are going to break one way or another.

If only there were a way to see my app run on all of these devices so I could know with confidence that it works…oh, wait.

-Benjamin Tseng
Apkudo Engineer