Android OpenGL ES挂起在x86_64模拟器上

我有一个基于OpenGL的应用程序，当用户按下按钮时，它在本机仿真器上运行时会挂起。主线程陷入glTexSubImage2D调用中，据我所知，该调用正在内部写入连接到模拟器内某个服务器进程的套接字（QemuPipeStream:：Writebly）：

lldb) thread backtrace
* thread #1: tid = 5036, 0xb73b2706 libc.so`write + 22, name = 'foo.bar', stop reason = signal SIGSTOP
    frame #0: 0xb73b2706 libc.so`write + 22
    frame #1: 0xabf81611 libOpenglSystemCommon.so`QemuPipeStream::writeFully(void const*, unsigned int) + 97
    frame #2: 0xab8069bf libGLESv2_enc.so`??? + 273
    frame #3: 0xab7a5668 libGLESv2_emulation.so`glTexSubImage2D + 120
    frame #4: 0xa41287a2 libbeeb.so`Beeb_drawFrame + 98
    frame #5: 0xa41110d0 libbeeb.so`Java_libbeeb_BeebView_bbcDrawFrame + 32
  * frame #6: 0xa4a56765 base.odex`int libbeeb.BeebView.bbcDrawFrame() + 105 at BeebView.java:0
    frame #7: 0xa4a56ab5 base.odex`void libbeeb.BeebView.videoCallback() + 57 at BeebView.java:28
    frame #8: 0xb3a17a83 libart.so`art_quick_invoke_stub + 339
    frame #9: 0xb3a235c5 libart.so`art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*) + 213
    frame #10: 0xb3dec47d libart.so`.L1360 + 74
    frame #11: 0xb3cd3216 libart.so`art::JNI::CallVoidMethodV(_JNIEnv*, _jobject*, _jmethodID*, char*) + 589

---

该应用程序有点不同寻常，因为它从主线程执行所有OpenGL渲染。这是因为它不是游戏，保持单线程比引入专用渲染线程和相关同步更有意义。

这肯定是Google/Intel的x86 Android模拟器中的一个缺陷，因为该问题不会在Genymotion或硬件上出现。

这肯定是Google/Intel的x86 Android模拟器中的一个缺陷，因为问题不会发生在Genymotion或硬件上