Java Verified: What it is, and how you do it

Part 1 of 2

I’m putting the finishing touches on a little side project (to be announced in a few days) I’ve been working on for the past couple of weeks. The purpose of this project is to exercise the new J2ME Polish 1.3 beta release and get an application listed on mobile.java.com at the same time. To keep things simple, I decided to port a bluepulse widget (Amazon-OnTheGo) for this purpose.

I also promised to post my experiences with the listing process here. And apparently, at least one of you (one of the scant few readers of this blog) is looking forward to the outcome of this project.

The biggest hurdle is really the signing process, and while this is not overly difficult to do, there are such a large number of considerations, that application signing appears more difficult than it is. Of course, signing is one of the prerequisites of getting Java Verified, so I thought I’d break down my experience / research into two posts: one covering Java Verified and one covering signing MIDP applications (Part 2).

Java Verified Process

What is Java Verified?

It essentially boils down to a testing process that results in a widely accepted digital signature. The intent behind this initiative is to eliminate as much redundant J2ME application testing as possible, relying instead on unified testing done for Java Verification. The certification process ensures that applications being distributed via carriers, vendors, and other channels are of a consistent quality.

Why get Java Verified?

The two biggest reasons are: 1) for the GeoTrust application signing, and 2) access to sales channels.

The GeoTrust root certificate is the most widely available certificate on mobile handsets, appearing in the large majority of mobile devices. As support for the verified program continues to increase, we can expect the appearance of this certificate to near ubiquity in newer handsets. So if you want your application signed in such a way that the majority of handsets will run it, Java Verified is the way to go. I’m going to assume that you understand why application signing is so important. If you don’t, check out part 2 of this article.

Most sales channels require a high degree of rigor before accepting an application into their provisioning system. Some channels have their own certification requirements, but many also accept Java Verified certification as proof that the application will also meet their requirements. For example, to be listed on mobile.java.com, you must be Java Verified. To be listed in Nokia’s sales channels, you must either be Symbian-certified or Java Verified.

If wide application support and major sales channels appeal to you, then Java Verified is the way to go. If, however, you are deploying to a limited number of handsets, you know which root certificates are present on those handsets, and you have no need for the large sales channels, then you can likely get by without the certification.

Java Verification Process

Application Upload

Upload your application to the developer portal. You’ll need to create an account to do this. Once your application is signed, you cannot make any code changes, so if you want to include the Java Powered logo, make sure you include it before you upload your application. You may only upload Certificate Authority-signed applications; self-signed applications through the WTK are not acceptable.

Update (August 28, 2006): the JavaVerified web site states explicity: “If the application does not have a signature and certificate upon entry to the testing step, the developer is notified and asked to obtain a certificate and then to resubmit a signed copy of his or her application.” However, this does not seem to be the case. I’ve submitted several builds to two different test houses, and neither required a signature.

Application Pre-testing

If uploaded successfully, your application will go through pre-testing. During this step, automated compatibility and characterization checks will be run. These are really to assist with setting up the appropriate test cases later in the process (e.g. are you using Nokia UI classes, are you using RMS for storage). The only common hiccups in the process occur if something is amiss in your JAD file. If you make sure that your JAD matches the JAR, it’s in the proper format, and all required attributes are present, you should have no problem with this step. After this step, you’ll also get access to a device compatibility report.

Application Testing

The next step is application testing, which must be arranged with an approved third-party testing house (this is arranged through the developer portal). There is little that you need to do in this step (cross your fingers, perhaps?). You can send the application, and then retrieve testing results through the developer portal.

There are currently four approved testing centers: Babel Media Ltd, Cap Gemini, NSTL, RelQ. Testing seems to run about $125 to $200 per device, depending on the number of devices tested, and retesting runs about $125 to $150 per device, even if only one or two failures must be rechecked. The retesting rate also applies to future updates to verified applications. Only the updated features are tested, but you still must follow the verified process and pay the retesting fees.

For applications available in multiple languages, the application will be tested in English, and then the opening screens will be tested in each available language. This all counts as one device test. For J2ME Polish users, due to Polish creating separate builds for localization, and the fact that much of the application delivery and test process is automated, I assume that each language will be considered a separate testing effort. I’ll update this article when I learn more about this.

There are many tests that must be completed during this step. Most are obvious, if you’re being careful and conscientious of your users when developing the application. A sampling of the tests appears below, but download the “Unified Testing Criteria (UTC) 2.0 for Java™ Technology-based Applications for Mobile Devices” document for a full list of test criteria. You’ll also need to create and submit a simple workflow diagram of your application. This helps the tester ensure that all functions of your application are exercised. Here is the workflow diagram I used for Amazon-OnTheGo.

• Stability: checks to see if your application freezes or hangs on the device.
• Launch: application must install via OTA.
• Start-up: application must start-up within 15 seconds.
• UI: application must use full screen available, there must be no visual inconsistencies or abnormalities (e.g. overlapping graphics), commands must be labeled consistently and appear in consistent soft-key locations.
• Localization: there must be no typos or spelling errors.
• Interruptions: application must handle interruptions gracefully, e.g. when a phone call or text message is received.
• Main menu: must include About, Help, and Exit functions.
• Data: users must be warned when data is deleted, or must be able to undo deletions.
• Connectivity: application must gracefully handle situations of interrupted or no connectivity.

For those applications that employ targeted builds for different devices, this process can be quite expensive and tedious. For the sample project that I’ve completed for this purpose, I have nearly 40 builds. Add semi-annual updates to the mix, and we’re easily talking about $10,000 or more for testing costs. This is obviously cost prohibitive for those of us without deep pockets and/or with rapidly changing applications (which mobile apps aren’t?).

The cost and effort involved in this process have some obvious implications for deployment, so for my money, I use Thawte and Verisign code-signing certificates (depending on root certificates installed on target device) for device-specific builds, and plan on only running very general device builds through the verified process.

Sound Like Fun?

Before you begin the verified process, you must start with a digitally signed application, and part 2 ofd this article deals with some of the details invovled in MIDP application signing.

Tags: J2ME, Java ME, J2ME Polish, mobile software, mobile development, MIDP, code signing, Java, Java Verified