Hi!
I'm a developer with quite a bit of experience with OpenGL and C/C++
I've not done that much Java, but haven't found it too hard to get things up and running.

However, when it comes to performance, the does and donts of Java Opengl programming is something I need to learn/experiment with.

I thought this thread could be the place to put our experience in regards to that.
I've done programming on iPhone and next-generation mobile phones (the nvidia APX 2500 and the ARM Mali 200 chip)

http://www.youtube.com/watch?v=jwfUwNVdNsA (Skybound on iPhone)

http://www.youtube.com/watch?v=JEoo_w3Fuc4 (Racing game on nvidia APX 2500)

From these projects, here's some stuff I have experienced.

-Drawcalls tends to be costly, drawing hundred quads as hundred glDrawElements is very ineffecient.
-Use point-sprites if you can, it reduces bandwidth a lot. Point-sprites with size-array is a good option for 2d graphics if you can make it fit the constraints of being only square and no individual rotation.
-compressed textures is your friend, RGBA8 is 32 bits per pixel,
compressed format can be 4 bit per pixel, that is 8 times bandwidth improvement, really helps texture cache effeciency.
-Use profilers to identify your bottleneck. Be aware that some bottlenecks are hard to find.

-sorting front-to-back enables early-z-cull, if the gpu has that
-batch together geometry to reduce drawcalls, but remember that you also want things to be able to be culled, so there's a balance there on how large blocks of geometry should be batched together.
-use texture atlases, this is a given when you batch together geometry, so you won't get away without it.

I'll see if I can find Imagination's best practices for iPhone development. I suspect a lot of them are transferable to Android as well.

As I just posted in another thread I just wanted to point out that there appears to be
a problem with the way the android handles texture compression, it seems to load them
as compressed but store them in VRam with standard GL_RGBA internal format.

I implemented a palette4 texture in my application and it didn't improve performance in
the slightest over a normal RGBA when it came to the number of pixels it could handle
in the VRam at a single time.

If anybody gets a compressed texture implementation to actually work in android
I would be very curious to see how to do it correctly.

Well I have an update on the Compressed Texture Issue from an inside source
in driver development.

It seems that my source has seen the driver that google ended up using for
the G1s interface with its processor, and it's a hacked together piece of crap.

The implementation for Compressed textures, at least Palette4_RGB(A) is
incomplete and simply acts as a decompressor. Palette8 may be a different
story and for no apparent reason other compression formats are not supported
period, even though the graphics core in G1 supports them, being the same
core as in the iPhone's processor, just a different chip producer.

I will try and implement Palette8 and see if that functions at all. If not I don't
really know how OpenGL programs will ever work efficiently on android...

Seriously Google, try giving us a full implementation of OpenGL ES, instead of
a version that doesn't support all standard glGets...