Dalvik Differences

Every now and then you can read in the press that the different Android versions out there in the wild and different implementations are a challenge for programmers. Few if any of these reports, however, give specific examples. So how big is the issue really? I can’t give a definitive answer, either, but in the course of putting together my cell logger program I encountered two differences across devices and Android versions that really shouldn’t be there.

The first difference is something I can’t do anything about. In theory, there are standardized handler functions that can be used to get notifications of signal strength changes and standardized methods for retrieving cell-id and other network related data they don’t work in the same way across devices. The signal strength change notification failed to work completely on one device. I would only get one notification when the program started with a completely wrong signal strength value. Afterward the handler was never called again. On all other devices, the behavior was as desired and signal strength changes were always reported as they happened. Strange.

When it comes neighboring cell information there is also a great variety of implementations. On some devices I get full neighboring cell information for GSM while nothing at all for UMTS. On other devices, even GSM neighboring information is missing. This issues might stem from a different implementation of the Radio Interface Layer (RIL) which is in the hands of the device manufacturer and not Google itself.

The second thing, which I was able to fix, is the way registered handlers are treated when the app goes to the background. One most devices, the handler gets removed automatically and has to be put in place again once the app comes to the foreground again. On another device, the handler was not removed and thus my app coming to the foreground again would install another one, resulting in several copies of the data in the log file. The issue can be fixed by removing the registered handler before the app goes to the background which works on all devices I have tested it on. But why the difference? Is it an Android version issue or did the manufacturer meddle with something? I can’t say.

In summary, I can confirm the reports that an Android device is not equal to another Android device of a different manufacturer from an app point of view. My examples might be benign but if I already stumbled over those two things with my 300 line program, there is likely to be more divergence. So one has to be a bit careful and test the app across a number of different models before it is released. Not what a programmer really wants to do…

If you are into Android programming, have you encountered similar things as well?

Comments

[BicouQ]

I am developping applications for android, and I have to say that I did not have such issues. I had problems for example on one app that needs Google maps, and I didn't put proper error handling if maps is not installed. This happens on devices that don't come with google apps, such as archos tablets.
Overall, I think the discrepancies are documented by Google and you can even get hacks and workarounds (I'm thinking Honeycomb API available to android 1.6).

But I guess it's a different story when you deal with stuff closer to hardware, such as telephony.

[Kamil]

Yep, I agree with BicouQ. It has also been my experience that functionalities close to the hardware, like ex. video encoders, are highly dependent on the handset used, while other api's are working as expected virtually everywhere. Good thing is that the latter api's are much more numerous.