What I do is orientate the object in the 3D program itself so it loads correctly in jPCT. Y pointing down and Z facing you does the trick (in Blender at least).

All 3D objects and textures should be loaded from the main OpenGL activity thread. The first call to the GLSurfaceView.Renderer onSurfaceChanged() function is a good place to load initialize the scene including all textures.

Do you have multiple Activity classes or launching multiple runnables/threads? If yes, those extra threads should not load anything 3D related.

Also ensure the texture files are placed in res\drawable-nodpi or res\raw so they don't get resized automatically by Android.

Ah that's what is using so much memory, I thought you had just a basic 3D scene.

I had the same issue when I jumped from Gingerbread to Honeycomb, the RAM usage was almost double and could not figure out why. I'm assuming it's the result of Android taking advantage of the larger RAM sizes in newer devices to minimize GC pauses.

There is a simple solution but you will need to have separate APK's for 2.x and ICS.
Honeycomb introduced the large heap parameter in the AndroidManifest.xml file which increases the application RAM from the usual 16GB/24GB/32GB size to 256MB.

Add android:largeHeap="true" to this tag:
<application android:icon="@drawable/icon" android:largeHeap="true" android:label="@string/app_name" android:debuggable="false">

Also ensure the minimum SDK is set to 11 if you want Honeycomb support, or 14 for just ICS support.

Something must be using too much memory. If you are allocating large arrays, null them after usage so the garbage collector frees them.

Use the below function at various areas during initialization to see how the RAM accumulates. For example, call logMem() before loading all the textures, and then after they are loaded.

public void logMem()
{
        DecimalFormat df = new DecimalFormat();
        df.setMaximumFractionDigits(0);
        df.setMinimumFractionDigits(0);

        String sRAMString = "RAM allocated: " + df.format(new Double(Runtime.getRuntime().totalMemory()/1048576)) + "MB of " + df.format(new Double(Runtime.getRuntime().maxMemory()/1048576))+ "MB (" + df.format(new Double(Runtime.getRuntime().freeMemory()/1048576)) +"MB free)";
        Log.v(TAG, sRAMString);
}

1024x1024 textures use a big chunk of memory when loading them so think about decreasing the size to 512x512

What res folder are the images placed in?

If they are in drawable-hdpi, drawable-mdpi, or drawable-ldpi, there is a good chance that they are being resized automatically to match the DPI of the screen.

Create a folder called drawable-nodpi, move the images in there, then clean and refresh the project.

Yes it matters. If you are modifying 3D objects while jPCT is drawing it can cause exceptions.

You should update the object movement and rotation in the same thread from within the onDrawFrame(GL10 gl) function. Use a frame delta (time elapsed since the previous frame) to move/rotate your objects, for example: translationVector.x += fSpeed * fDelta;

Remember to set it to 1 BEFORE calling clearRotation(). Or otherwise, setScale(x) won't scale by x but by former_scale/x.

..and setting the scale to 1f beforehand fixed the other issue I ran into.
All good now, cheers.

ok I'll make sure I do that. (edit: I thought setScale was absolute? whereas .scale() was incremental?)

In my own functions I prefer to implement internal fixes/workarounds for invalid parameters rather than throw an exception to keep my functions solid/reliable (in this case, default to 0.001f as the scale if invalid) , but I can see how throwing an exception can help with debugging for others in general.