Yes, it's save and it's cheap. However, compiling the object fixes the texture stage count for it. That's why you are getting that exception with the TextureInfo. YOu could assign a TextureInfo with the same amount of stage but using some dummy textures, compile, assing the actual textures. That should actually work.

16k and 32k...it's absurd IMHO to use those. A 16k texture with 32bit and no compression but mipmaps would require ~2GB auf GPU memory and almost the same in VM memory. Still not very feasible IMHO.

Blitting is just like rendering an object except that the data of that "blitting object" is dynamic and changes every frame. That's not a problem per se, animate objects do exactly the same. A lot of apps using jPCT-AE are doing it all the time (including mine) without any problems. However, I'm well aware that it might cause trouble, which is why there are these config settings for it (which are just some shots in the dark as well). The actual problem is, that I've no idea why this happens and when. I've checked the code at least a dozen times because of this and it's just fine. It's the same code that desktop jPCT uses as well and it doesn't have this problem. My current app is blitting stuff before doing anything else and that is fine as well.

Your apps...are these all wallpapers or standard apps?

No, they aren't using an emulator for sure, but...from my own experience, crashes happen mostly on MALI-based GPUs. Can you confirm this based on the Google Play stats?

...you would have to write yourself a line algorithm that not just interpolates x and y but also z (or the reciprocal of z) just like the polygon rendering routines do.

About the PolyLine in software mode: I've no plans to add support for this, I'm afraid.

The software renderer doesn't support multiple texture layers. Or at least not in the way in which the hardware renderer does. You could use a different path for the software renderer and use setBlending(true). Then assign three textures to it (diffuse, envmap and envbump) but use a single colored texture with (128/128/128) as color value for the envbump texture. That should give you some kind of blending between diffuse and env.

To answer your last question: The textures and other native data is using that RAM.

About the render targets: As long as you don't create a new FrameBuffer, nothing happens for the textures if your rotate the device. However, I've no idea how it's supposed to work that way, because rotating the device should destroy the context (simply because width and height are changing) and so you should need a new instance of the buffer. But anyway...as long as the buffer doesn't change, there's actually no need to unload the render target texture at all. Have you tried what happens if you don't do that at all?

Then why don't you do the loading in a different thread and let the main thread render the splash screen? That's what I'm doing in Naroth as well.