I'm not sure but I think you need to use radians for the rotate methods

// old
clockBar[i].rotateZ(((float) i / 10) * 361f);

//new
clockBar[i].rotateZ(((float) i / 10) * ((float)Math.PI)*2f);

Oh... Ehm, nevermind maybe it was scaling..? Ah nevermind this.

However, is it safe to apply textures after having having the Object3D's built and compiled?
It seemed to work just fine? Though, not sure about performance...
However, a multi-textured TextureInfo would give an ArrayOutOfBoundsException when I apply the TextureInfo after having built and compiled.

I also wondered if 16k and 32k textures could be enabled, devices these days can handle quite a lot hehe

Any ideas about which "in the wild" crash rate we are taking here? 50% 1% 0.1%...any clues?

Well it depends on the context..? Higher polygon count seems to make it more likely to crash. While lower polygon models don't crash at all...

And because fiddling around with the blitting config seems to changes things for you: Are you actually blitting stuff? What happens if you don't?

Yes, I do blit things before the first world.draw() call.
=> Texture blits (some of these textures are used for the Object3D's, so the textures get uploaded to the GPU and removed from VM heap memory)
=> Loading screen (probably 50+ blits of a 2x2 texture with variable greyscale color) per frame

I tried to comment out the texture blits (so they'd stay in VM heap memory) => it would still crash
But when I removed all blits (texture+loading blits) before the first draw call, it would work fine.

Also, only have texture blits (without loading screen blits) would still be able to crash but not so likely.

Interesting results I guess...

I once again tested the crashing likelyness (with higher polygon models and with blitting before the first world.draw() call)
=> Config.blittingMode = 8
Runs: 25
Crashes: 17
Result: More than the 50% of last time...
=> Default Config.blittingMode
Runs: 25
Crashes 25
Result: About the same result as last time (100% vs. 96%)

So could it be that blitting anything before having all Object3D data loaded could cause this SIGSEGV issue?

PS: I actually do blit (2D background behind 3D world) before calling the first world.draw() in the other app too actually...

Which buffer size do you mean exactly?

03-05 10:19:44.749: I/jPCT-AE(2711): Blitting buffer size: 600
^ this one

I tried to test with the default Config.blittingMode and with Config.blittingMode = 8;
I used higher polygon count models for this test.
Compat mode => Config.blittingMode = 8;
No compat mode => Default Config.blittingMode
compat mode:
runs: 10
succes: 5
crashes: 5

no compat mode:
runs: 10
succes: 1
crashes: 9

compat mode:
runs: 10
succes: 4
crashes: 6

no compat mode:
runs: 10
succes: 0
crashes: 10

compat mode:
runs: 10
succes: 5
crashes: 5

no compat mode:
runs: 10
succes: 0
crashes: 10As you can see it drops the chance of crashing from ~96% to ~53%.
Whether this is just a coincidence, I can't tell but I tested this multiple times (swapping between the two config values after every 10 runs).

And which device are you using to test this?

I'm currently using a Genymotion emulator (With a Nexus 5, Android 5.0.1 build) to reproduce these crashes. (I can reproduce crash on older physical devices, just to make sure... Plus many people reported this SIGSEGV crash through the Google Play Store and I think I can assume they are not using an emulator...  )

For now I'll just assume my device is the only device with this unloading issue... Oh well, it's a custom ROM...

Anyway, about the SIGSEGV error that keeps happening at the first world draw call, I think it's because of my custom shaders... Which I don't really understand though...
On most high-end devices there are no issues at all with my custom shaders
And I don't really understand why the default shaders would work just fine (always..) while they look more complicated than some of the custom shaders I'm using. Although, on devices where my custom shaders crash, it does NOT always crash, which completely blows my mind... It seems to happen just randomly basically.

Unlike the default shader, my custom shaders use:
-> pre-processor things with #
-> setting uniform variables in onDraw
-> defined functions within the shader
Though, I don't think these are really the issue...

While Googling this issue I did find some weird OpenGLES shader crash reports by other people that could be solved by work-arounds such as changing the order of operands...
Anyway, what would be do's and don't for writing a GLES shader? Or maybe: how did you manage to create the 'perfect?' default shader which never seems to crash?
Does jPCT-AE perhaps treat custom shaders differently than default shaders?

Another thing that seems to reduce the probability of the random crash at the first draw call was to use lower polygon models...

Also... What could be an explanation of the randomness of the crashes since it does not always happen, well the positions of the Object3D's are always different but would that make a huge difference...? I'd think not but apart from that nothing else is really different and yet it somehow manages to render/crash
And once the first draw call has successfully completed (assuming all Object3D's are visible) then it won't crash in future world draw calls

Another possible solution: increase the buffersize of the framebuffer even more? I thought Config.blittingMode = 8; did impact the probability of crashing in a positive way (I think it had to do with vertex upload buffer maybe, I don't really know...)
Is there any way for me to determine what is actually causing the crash as in which call in the jPCT-AE jar is causing the SIGSEGV error?
Might help for solving the issue...

I tested rendertarget textures with rotating screen on the following devices

My device (ZTE Axon 7 @ Android 7.1.1 Custom ROM):
-> Low VM RAM (discard what I said about 300 MB RAM usage in VM earlier... It's about 30 MB actually (I guess my eyes added a digit... derp))
-> No memoryleak when rotating screen in VM (but there is in native/video memory)
-> However, in developer options -> Active services, the RAM usage keeps rising (300+ MB+ here (could go much higher though (1,8+ GB after many many screen rotations => device will kill other processes and might even reboot here) so I suppose it's not VM but native+video+VM that is being displayed here)

Some old tablet (Difrnce DIT4350 @ Android 4.0.4)
-> Low VM RAM
-> No memory leak with rendertarget textures
-> Crashes after many screen rotations..?

Old tablet 2 (Asus TF101 @ Android 4.0.3)
-> Low VM RAM
-> Crashes after many screen rotations?

Emulator #1 (Android 4.1.1):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM

Emulator #2 (Android 4.2.2):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM

Emulator #3 (Android 7.1.0):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM
-> I don't see the VM+Video+Native memory usage as high as on my own device here in developer options... Unloading seems to work just fine here
-> No memory leak with rendertarget textures in native+video

For the sake of clarity also a test without rendertarget textures on my main device:
-> Low VM RAM
-> No memoryleak with rotating screen
-> Memoryleak with renderers when restarted in native+video RAM (renderer restarts when a setting is changed)
How does it restart:
-> Change a setting
-> (I believe it still uses the same GL context as before)
-> Removing and unloading textures from texturemanager (but it won't go through another draw call to actually unload them I suppose...)
-> Framebuffer is disposed
-> Reference to the renderer is gone now
-> A new Framebuffer is created
Now that I think of it... I think I could re-use the framebuffer... :|
10 minutes later... -> Re-using the same FrameBuffer but the memory leak remains..?

In the end, it seems that textures aren't unloaded untill the whole wallpaper engine is killed.
(restarting doesn't kill the wallpaper engine...)

Starting to think it could be a driver issue on my device... Egh

I'll try to test it with other physical devices

Uhm, I'm not sure if the context is lost...
I don't re-initialize the Framebuffer ever (I just use #resize() whenever the device is rotated).

I already had Config.unloadImmediately set to true, which did not work... Setting it to false did not work either unfortunately.
Whenever I don't use a rendertexture but just the FrameBuffer, RAM usage does not increase on screen rotations.

Is there perhaps a rotate function/method possible for rendertextures/NPOTTextures since screen rotations usually just swap the width and the height? (But these rendertextures would hold the same amount of data eventually for the different orientations)
Probably my solution for now would be to create these two rendertextures at start (one with default orientation and one with rotated orientation) and just switch between these two rendertextures.

---

Another thing about my application:
I don't keep my texturedata for rendertextures nor any other texture in VM.
TextureManager.getMemoryUsage() would indeed show that just 1024 bytes is stored by the VM. (Basically nothing)
However, when I use "Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()", it would show that there's muuuch RAM usage more by the VM, up to 300 megabytes (by jPCT, I assume). What could be using all the RAM?