Android crash on device orientation change

Android
1

I have OpenGL support running on Android, w/ JUCE 4 (I cannot upgrade to 5).

Everything is fine, with the exception of crashing on device orientation change, after a few rotations (usually between 3 and 6). Note: if I use the SW renderer instead, I don’t see the crash.

I believe this has been fixed in JUCE 5, but it’s untenable for me to upgrade. Has anyone solved this on JUCE 4? Specifically, the crash backtrace is:

  • android/Surface/hook_perform/ANativeWindow
  • eglCreateWindowSurface
  • OpenGLContext::CachedImage.runJob

Above that it’s calling a pure virtual function and then crashing.

2

Anyone?

3

@fabian – any input?

4

It’s hard to narrow it down as there were a lot of changes in the Android code between JUCE 4 and 5. If you know roughly where it was fixed then you can run git bisect to track down the specific commit which fixed it.

5

I’m not even sure that 5 did fix the issue, though it sounds like it has since people have stopped complaining about GL crashes. I was hoping that someone who had worked on this would be able to give a more direct answer.

6

I seem to have hit this issue after adding landscape support for an Android app using JUCE.

I hit the assertion within

if (window == nullptr)

The stack trace:

juce::OpenGLContext::NativeContext::initialiseOnRenderThread(juce::OpenGLContext&) juce_OpenGL_android.h:163
juce::OpenGLContext::CachedImage::initialiseOnThread() juce_OpenGLContext.cpp:490
juce::OpenGLContext::CachedImage::runJob() juce_OpenGLContext.cpp:445
non-virtual thunk to juce::OpenGLContext::CachedImage::runJob() juce_OpenGLContext.cpp:0
juce::ThreadPool::runNextJob(juce::ThreadPool::ThreadPoolThread&) juce_ThreadPool.cpp:384
juce::ThreadPool::ThreadPoolThread::run() juce_ThreadPool.cpp:36
juce::Thread::threadEntryPoint() juce_Thread.cpp:96
juce::juce_threadEntryPoint(void*) juce_Thread.cpp:118
juce::threadEntryProc(void*) juce_posix_SharedCode.h:834
__pthread_start(void*) 0x000000797c0047bc
__start_thread 0x000000797bfa3578

I’ve tried detaching from the OpenGLContext in the Activity onDestroy and reattaching in onCreate but this seems to make no difference.

7

Due to the lack of responsiveness of the JUCE team, I abandoned JUCE a while ago and though it was a lot of effort to do so, I’m a happier coder now. I wish you luck in finding a solution, but don’t count on the JUCErs to help you out.

8

TBH I think it’s just that Android issues are generally low priority. My recent experience (which does not include Android issues) has been that the JUCE team have been very responsive.

9

Right, I know; but I was only using JUCE because of multi-platform support; if they don’t actually support the platforms, it’s much less useful to me. There are (or were) a lot of missing features in the Android port.

Anyway, best of luck!

1 Like
10

I have read this for 10 years. :slight_smile:

So the question is, in this new paradigm of JUCE 6, if there are experienced Android devs that can push the Android part farther, how hard is it to integrated fixes from the community. :wink:

11

I’m curious, did you adopt another cross platform framework? If so, which one?

12

Yes. For GUI I adopted Nuklear; for sound miniaudio; for outer wrapper SDL2. The resultant binary is around half as big as it was with JUCE.

1 Like