Just started looking into a bit of programming for the android and was playing with this simple example. It runs just fine when compiled in Standard mode, but when compiled in Android mode and run on a nexus one the rectangle just sits there, not moving at all. I'm using boxwrap2d from this link: http://jbox2d.nfshost.com/processing/boxwrap2d.zip and processing 0194.
The other thing is that I have to call physics.defaultDraw() otherwise nothing gets drawn at all.
Same thing happens in the emulator, btw. I've been poking around a bit more, and it seems to me that the physics doesn't get updated. If I call the world.step(dt, iter) method manually, in the draw method, then the box starts jumping around, but the updates aren't done nicely, the physics don't get updated smoothly.
There's something odd about fisica though. Or maybe it's normal, I don't know. Here's the experiment. I setup a bunch of "bins" using rectangles that were very thin (a few pixels) but long from top to bottom. Then I dropped boxes or circles in each bin. The boxes and circles were a few pixels narrower than the distance between two rectangles (walls). The odd thing is that after some bouncing, the boxes or circles went through the "walls", i.e. through the rectangles, migrating to the neighboring bin. I was under the impression that objects don't go through each other.
This might be due to the scale of your world being out of the limits where the physics simulation works correctly.
I'm guessing that you work with the default scale of Fisica. This is something I still haven't found a good default for. You may try changing it by using Fisica.setScale() after initializing it. This defines the pixels/meter scale. And it is a very important parameter. You must also have in mind that jBox2D (the library that Fisica uses) works correctly for objects of certain sizes (in terms of meters) which I don't remember right now.
Another possibility is to use the myBody.setBullet(true) (before adding the object to the world) method so that the physical interaction between the objects is fully calculated. This will slow down a bit your simulation, but may avoid some of these problems.
If you still don't get around it, let me know and send a small example applet so that I can look into the problem.