mobile programming

W910i J2ME Bluetooth Stack Problems


I’ve been programming with the W910i recently. Theoretically, it should be a great phone to work with. Plenty of optional APIs included, has a J2ME accessible accelerometer, BUT, Bluetooth keeps failing randomly with the following error message (in console output, testing in Java Developer mode using Sony Ericsson Device Explorer/Connection Proxy):

[Java/OJEX] bt.core[Util.raiseBluetoothConnectionException] FAILED_NOINFO

I’m using a separate thread that keeps making a serial profile connection (BTSPP://) to a GPS device that outputs in NMEA-0183 format. During random times (sometimes 20 secs, sometimes 5 mins) the thread locks up and any attempt to access it locks up that thread too. It must be to do with some of the bugs listed here – even after updating my firmware using the auto update within the device it’s not fixed. There seems to be no fix available anywhere!

I’m going to do a more simpler test later to see if it’s my code, but I doubt it will make any difference.

This is just a warning for those fellow developers out there tearing their hair out. For now, I’m sticking with Nokia phones and my Sparkfun accelerometer… Just need to re-solder that power connection!

mobile programming

Java Verification? Not For Me!

Apparently, the Java ME code verification system is a joke. One developer has said that if you want to use anything other than the buttons and screen, you need your code signed. All of this was supposed to make code signing in Java ME centralised, being based upon impartial third parties like Verisign, Thawte, and others, but now some carriers (particularly in the US) have implemented their own certification processes, which defeats the point of having a centralised verification service like the Java Verified Program. Cingular’s lock-down in the US is a prime example of this evil – developers can only use the Bluetooth API (JSR-82) if you’re an enterprise partner with $1000 to spare for Cingular to test your application. JSR-179 (location services) is banned altogether. “PIM, SMS, and internet connectivity services are also heavily restricted, with most things requiring at least a 3rd party cert ($500 or so per year) to use.”


Here’s how it goes for the poor developers who want maximum market penetration with their app, but are locked-down by carriers. To get your program verified by the “official” verification system – Java Verified, you need to pay an independent testing lab. For each bug fix release, you need to pay them to re-test. Your Java Me application can get around the security dialogs once it’s verified, but as soon as you want to release new versions you can understand that costs build up. Read more about the signing process here.

Bedroom developers, and freeware developers need to start charging to maintain useful applications – not an ideal way to encourage innovation is it?. Google chose to not bother signing their Google Maps for mobile application, as a testament to how bad the whole process is. I can understand that you need to go through a complicated process to allow application developers to access your personal information and phone numbers, but what about bluetooth access? How much harm can be done? Even so, what about giving users the choice to silence all future security dialogs with a “remember my decision” option?

Alas, when the restricted APIs are used in research in the UK it isn’t so bad – we don’t have operators like Cingular here. On the Nokia and Sony Ericsson phones I have tested the security dialogs only appear when you start the program. For the purposes of my experiments, I can just tell users to pick “allow” every time, and the problem is solved. I don’t really need to sign my applications.

More reading and good summary here: How Midlet Signing is Killing J2ME/