All these steps are to be done under Eclipse on Windows, I don't know whether they work using a command line build, or Eclipse under any other platform. It builds against the current version of Andriod, which is m5 rc15 at the time of writing.

Create a new Android project under Eclipse

This should be easy, there's heaps of documentation on how to do this in the Android project. It is important to fill in the New Android Project dialog correctly however. These values should work

Project name: <Anything you like>
Create new project in workspace (highly recommended)
Package name: j2ab.android.app
Activity name: J2ABMIDletActivity
Application name: your application name

You should have a skeleton project created for you.

Copy in the J2AB Code and Resources

Things rapidly starting going south from here. Android doesn't suppose multiple projects, so you need to dump all your sources into the same project, starting with the J2AB source. Unzip the J2AB bridge (not dummy) source and copy and paste the following

J2AB src	Your Project Destination
src/main/java	your source directory
res	res

Overwrite anything that gets in your way.

Copy in your J2ME Code

Just to re-iterate, Android doesn't support multiple projects. You can, however, link source directories in Eclipse. In my experience this is a little risky as sometimes the linked source doesn't get updated if you change it (or something, I've had a few scares), but it's probably better than the alternative. You could make a new source directory under the new project to maintain some kind of separation.

For simplicity, I'm going to say copy your source straight into a source folder under your new project and let you work out exactly where you want to put it.

Any resources (like images) you have need to get copied into a directory called res/raw.

Change your Code

Unpopular move I know. There are a couple of classes in the Android jar that have names that clash with ones in the midpapiXX.jar, as the Android classes always appear before our classes on the classpath, we've got to work around this. You need to rename the following import statements

original	new
javax.microedition.lcdui.Image	j2ab.android.lcdui.Image
javax.microedition.ldcui.Graphics	j2ab.android.lcdui.Graphics
javax.microedition.lcdui.Font	j2ab.android.lcdui.Font

Now, rather than do a straight find and replace, if you are the kind of person who likes to have one code base (and you should be), you can use the excellent WTKPreprocess tool available with Antenna to #ifdef out these import statements. So your import statement could look a bit like this:

//#ifdef use_android
import j2ab.android.lcdui.Image
//#else
//# import javax.microedition.lcdui.Image
//#endif

While Eclipse does have a plug in for the WTKPreprocessor that may help with this, there is a project j2ab_dummy, that you can use to provide placeholders for the Android implementations of Image, Graphics, and Font, so you don't get nasty error warnings in your IDE when you aren't coding against the Android libraries. You shouldn't execute or compile against these placeholders as they do nothing.

If you're over it already, then just do the find and replace way.

Change your Code Some More

Android doesn't support Class.getResourceAsStream (it's in the API, it just does nothing). If you need to access any resources using this mechanism, then you'll need to use the workaround class instead. So

o.getClass().getResourceAsStream( "/myresource.txt" );

becomes

j2ab.android.langResourceAsStreamClassLoader.getRawResourceAsStream( "/myresource.txt" );

If you are trying to keep the same source for both Android and J2ME streams of your MIDlet, then I'd recommend you use a preprocessor to use the native Java method where it is available, however the dummy implementation will work if you can't be bothered.

Tell the Bridge About your App

In the res/raw directory you need to create a file called

jad.properties

this is the equivalent of the jad file for a normal midlet. Any information you want to have available through the MIDlet.getAppProperty method should be put in here, however you MUST specify one value, the class name of your MIDlet. For example

midlet=name.of.my.midlet.package.NameOfMyMIDlet
param1=The first application parameter
param2=The second application parameter
xyz123=The third application parameter

GO!

OK, so you're done. Done like a fox.

The adapter libraries aren't complete, so if you use parts of J2ME that aren't covered by the adapter you're going to get compile problems. At this stage, you don't have many options except to implement the missing parts of the J2ME API yourself (see the next section).

If you haven't got any compilation problems, run up your program in the Android debugger (under Eclipse) and see what happens. Hopefully you'll see your application in all its glory.

Any System.out.println statements should be appended to the Android logger, so keep an eye on it.

Implement the Missing Bits of the Adapter

Take a look at the existing code to get an idea of how to implement the missing parts. Of particular note are the lcdui widgets, which use the Android layout xml to configure them. You don't have to do this, but it adds a certain amount of configurability to the style that you wouldn't otherwise enjoy.

Apart from that, lay off the static factory pattern as much as you can while still being faithful to the J2ME spec.

Make a Splash Screen

For technical reasons, we've introduced a splash screen into the loading phase of the bridge. This is used to ascertain the size of the client portion of the screen. You can, however, change the splash screen to look like anything you want in res/layout/splash.xml file, provided it has the attributes

android:layout_width="fill_parent"
android:layout_height="fill_parent"

If that isn't appealing, work out how to return the portion of the screen usable to Display implementations at the time of creation of the Display and fix up the code.