Traps of different Android SDK versions

Bitbar, the mobile devops company. Logo, large
Every Android developer knows how challenging it is to properly handle different screen sizes and different permissions. But there are other issues bugging developers. Let’s take an application, which works and looks fine on phone Y with resolution 480×800 and assume that it works & look OK also on phone X with the same resolution. During the testing it becomes clear that on phone X application just crashes at some point although on phone Y it doesn’t happen? And the difference is OS version: Tree View between versions of Android SDK. If your code is based on hard assumptions related to Tree View, you might have a problem.

Let’s take real life DatePicker example: On Android SDK 4.0.3 way from DatePicker to its plus/minus buttons is following: DatePicker->LinearLayout->NumberPicker->ImageButton. So when we write own custom control and we want to get to one of this button we can write something like this: ImageButton btn = (ImageButton)((ViewGroup)((LinearLayout)mDatePicker.getChildAt(0)).getChildAt(0)).getChildAt(0); But what if in another SDK version this path will be look like this: DatePicker->LinearLayout->LinearLayout->NumberPicker->ImageButton?

For instance in Android SDK 2.3.3 it looks like this: DatePicker->LinearLayout->NumberPicker->NumberPickerButton.

In this case fortunately NumberPickerButton inherits from ImageButton but when only any layout will be add in the middle of this path in future SDKs we will get ClassCastException.
We sometimes get question “why it doesn’t work in the cloud, it works locally for us”. And then often problem is related to basing on Tree View with assumption, that it is not changeable. Sometimes applications are working fine on Android SDK 4.1.1 but crash on Android SDK 4.0.4 because of mentioned ClassCastException as a result of trying cast some View to expected type of View where expected View turned out to be other type for instance additional LinearLayout.

That’s why testing on as many real devices as possible is important. And our Testdroid Cloud comes to rescue here.