Android browser code dumps; The mobile Web bane of existence
Posted by Dion Almaer about a year ago on android mobile
There is a chance that I will look fondly at the extra effort required to get rich Web apps running in IE6. We will remember how quaint it was when we complained about the harshness of having multiple versions of IE on the same machine so we could test them.
As we saw the modern mobile Web (the “there is only one Web” version vs. the WAP one) spring to life, we had smiles on our faces as we whipped up some -webkit-* and saw it work on our new iOS devices. Then we saw more devices come into the mix, and Android grew first to be a platform that you had to think about ([insert Opera mobile... big... blah blah]).
Fast forward to today and we have the following looming over us:
- A ton of devices coming onto the market quickly
- The devices are not coming to market with the latest OS/WebKit versions
- The devices are not updating quickly
- The WebKit builds are often quite bad!
This came to light again when a project I am working on was able to easily core dump the Android browser on a few devices (such as HTC Evo 4G Shift … but not the other HTC Evo 4Gs mind!).
02-24 16:35:07.589 I/DEBUG ( 1253): pid: 6315, tid: 6329 >>> com.android.browser <<< 02-24 16:35:07.589 I/DEBUG ( 1253): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000011 02-24 16:35:07.589 I/DEBUG ( 1253): r0 00000008 r1 49329435 r2 45e5d374 r3 47055720 02-24 16:35:07.589 I/DEBUG ( 1253): d30 0000000000000000 d31 3ff0000000000000 02-24 16:35:07.589 I/DEBUG ( 1253): scr 20000013 02-24 16:35:07.589 I/DEBUG ( 1253): 02-24 16:35:07.639 I/DEBUG ( 1253): #00 pc 47055778 02-24 16:35:07.639 I/DEBUG ( 1253): #01 lr 4704e724 02-24 16:35:07.639 I/DEBUG ( 1253): 02-24 16:35:07.639 I/DEBUG ( 1253): code around pc: 02-24 16:35:07.639 I/DEBUG ( 1253): 47055758 e1a0d00b e8bd4800 e28dd008 e12fff1e 02-24 16:35:07.639 I/DEBUG ( 1253): 02-24 16:35:07.639 I/DEBUG ( 1253): code around lr: 02-24 16:35:07.639 I/DEBUG ( 1253): 4704e704 e5987017 e597000b e59b100c e52d0004 02-24 16:35:07.639 I/DEBUG ( 1253): 02-24 16:35:07.639 I/DEBUG ( 1253): stack: 02-24 16:35:07.639 I/DEBUG ( 1253): 45edd8cc 00000002 02-24 16:35:07.639 I/DEBUG ( 1253): 45edd8d0 a861c3b9 /system/lib/libwebcore.so
I shouldn’t be able to dump your core. From looking online I was shocked at the number of people complaining about some of these devices. To them, their browser crashes all the darn time. Why not use Chrome for Android I hear you ask… well that is only available for Ice Cream Sandwich, and hardly anyone has been able to upgrade to that. What about Dolphin HD? Or Firefox…. sure, but how many users are going to think to update their browser on their mobile like that? Not many…. unless they get used to awful default browsers as we did on Windows.
As I went through the myriad of devices to test things, I started to cry as I thought about the amount of effort it would take to get massively broad coverage that doesn’t crash some users. This is why being able to target an engine would be nice.
It is also why efforts such as the latest push for decent mobile Web standards and support are important. It isn’t just about passing the tests, but how well we pass them.
Brendan Eich talked about the tough task of pushing 60fps at all times on a mobile device. I am glad that Mozilla is pushing for this and doing pretty well I might add with their Boot 2 Gecko platform…. which gives you view source for your OS.
I hope that we can all turn this around and get away from the hell that is debugging for all of these platforms…. but can we?