what is the financial work involved to get a certificate that the java phones would like?
-Thom
I'm sorry to revive a posting from April 2008, and am new to the , but reading through the remainder of the thread it seemed that this didn't get a definitive answer, and it's info we will want as we go through this to work on as many phones as possible around the world.
Option A: Adding your own certBasically, for a large % of the JavaME phones out on the market, you can't add your own cert to the root cert on the device, which means you have to sign with a certificate chained off the root cert baked onto the phone. Even in some of the devices where you can, it's inconsistent since some operators block it, others don't, others didn't bake the root certs on, etc (see
http://www.spindriftpages.net/blog/dave/2006/06/18/midlet-jar-signing-a-tutorial-revised/... So the add-your-own-cert route doesn't really work consistently -- plus we'd get into distribution issues (you have to get the cert out to people, they have to put it into their certificate chain, etc.).
Option B: Getting someone with the root cert to sign it for youThis means getting the cell phone carriers to sign a midlet. Good luck. Some cell providers do make this somewhat simpler through their developer programs (Vodafone, Sprint, Orange) but you still have to pass through some hoops. Plus this only ends up working on their phones.
Option C: Java Verified certThis
might be desirable if we (a) get the MIDlet to a point where it is completely stable and released and (b) we are willing to deal with the fact that any changes to the midlet invalidate the signature and (c) it involves paying someone to test the application and validate it works. It's not expensive (about USD$120 per midlet), and the suite checks that the MIDlet doesn't misbehave in very known conditions that cause MIDlets to misbehave (incoming calls, incoming SMS, reduced memory conditions, low battery,poor coverage, etc.). I'd be willing to pay for a couple of cycles of certification if it meant we would get a solid codebase. But this also means that once we get a signature, we have to get into a release-cycle mode of thinking. This option is not very consistent with the FOSS mindset in general -- but mobile devices are really not in the FOSS universe in any event. The benefit of doing this is that once you have the midlet signed with Java Verified, you know it will install with full permissions on any phone that has a Java Verified root cert.
The good newsThe good news, however, is that the vast majority of JavaME phones out there that support JSR 82 don't block Bluetooth access from untrusted midlets completely -- they usually are set to prompt only once in midlet execution permission, and a very large number of them let the user override this setting to let the midlet have permanent permission. This varies device-by-device. So it means we probably don't have to pursue this avenue. Most I've seen enable it without difficulty by default.
BTW -- I'm saying "we" here a lot. Hari -- you've done a great job with this. Please count me in for development assistance -- I've been working with Java ME developer communities for years and can weave my way around a MIDlet pretty well. I'll spend some time looking through the most recent code from svn and see if there are any common MIDlet gotchas we can foresee.
Cheers
- jf
