What color and shade is the original png image, and what shade are you using for the additional color?  I would try starting with a darker green png image for the texture and using a darker green for the additional color as well to see if you can get it down to the total brightness and color you are looking for.

While looking though the jPCT-AE javadoc, I saw that Textures can be made from Bitmap instances, which basically have all the functions needed to easily port my GIF loader to jPCT-AE.  It only took about 30 minutes once I figured out how to use the Android SDK (this was my first real Android project).  It seems to run quite well - no serious performance issues that I can detect (although my example is very simple)

Example App  (source code)

I have several quads for which I want to change their textures' u/v coordinates periodically.  What is the proper way to do this in jPCT-AE?

Currently, I am calling build( false ) on the Object3D, then to change the u/v coordinates:

                tex1 = new TextureInfo(
                          TextureManager.getInstance().getTextureID( "Front" ),
                          quadUVs.u1, quadUVs.v1, quadUVs.u2, quadUVs.v2,
                          quadUVs.u3, quadUVs.v3 );
                tex2 = new TextureInfo(
                          TextureManager.getInstance().getTextureID( "Front" ),
                          quadUVs.u3, quadUVs.v3, quadUVs.u4, quadUVs.v4,
                          quadUVs.u1, quadUVs.v1 );
                gifBox.getPolygonManager().setPolygonTexture( polyIdOffset,
                                                              tex1 );
                gifBox.getPolygonManager().setPolygonTexture( polyIdOffset + 1,
                                                              tex2 );quadUVs is just a simple class that holds 8 floats to represent the u/v coordinates of the four corners of a rectangle.  These values are changed periodically.  I pulled the code out of a previous normal jPCT project, so I'm pretty sure I'm using the correct u/v values.  However, if there is nothing obvious you can think of that I need to do to make u/v changes work, I'll try and create a simpler test-case to look at.

Haha, and don't say short answer is switch to Windows...

I should point out that running these apk's on my actual Droid X behaves the same way as in the emulator, which would indicate there is a problem with how I am creating them, rather than a problem with the emulator.

Reading and processing the GIF information from the file should work fine on Android without modification, because it's based on my own GIF loading code that I wrote some time ago in C++ (so it isn't Java-specific).  The part that won't work on Android is the drawing stuff (the part where I take the loaded information and use it to generate instances of java.awt.image.BufferedImage for each frame of the GIF).  What you need to be able to do is create 2D images with transparency on Android.  With that knowledge, you should be able to work with Egon to figure out how to use those images to create Texture instances in jPCT.  From there, it should be pretty easy to port the code over (in fact, I'll do the port for you if you do the initial research).

An alternative method would be to download the sourcecode for a JRE, such as OpenJDK, and pull out just the .java files you need to make my GIFImage class work as-is without modification (this would probably be more tedious than the first option, I'm guessing).

As for speed, I'm not sure how it would perform on Android.  It switches frames by changing the u/v coordinates on a "mosaic texture" containing all the frames in tiles.  This works quite fast in normal jPCT (much better than using a texture effect), but I have no idea how fast u/v changes are on AE version.  Changing it to use texture effects instead would be fairly easy (I've already written such a version of GIF loading for normal jPCT on this thread).  Obviously this method would also require the changes I mentioned above before it would work on Android.

I assume the back of the box looks different than the front?

Also, make sure your vecCameraTarget vector is normalized, and also make sure that it forms a right-angle with whatever up-vector you use.