Ошибка Android "процессор может быть привязан"

Question

Предисловие: эта серьезная ошибка может привести к блокировке устройств Android (невозможно нажать кнопки «Домой» / «Назад», требуется полный сброс).Он связан с поверхностями OpenGL и воспроизведением аудио.Logcat повторяет что-то с эффектом

W/SharedBufferStack( 398): waitForCondition(LockCondition) timed out (identity=9, status=0). CPU may be pegged. trying again.

раз в секунду, отсюда и название этой ошибки.Основная причина этого, вероятно, связана с тупиком при буферизации данных, будь то звук или графика.

Я иногда получаю эту ошибку при тестировании моего приложения на планшете Asus EEE Transformer.Сбой происходит, когда звуковой поток заполняет MediaPlayer объекты, используя MediaPlayer.create(context, R.raw.someid);, а поток GLSurface загружает текстуры из растровых изображений, используя

Bitmap bitmap = BitmapFactory.decodeResource(context.getResources(),
                R.drawable.textureMap,opts);
gl.glGenTextures(1, texAtlas, 0);
gl.glBindTexture(GL10.GL_TEXTURE_2D, texAtlas[0]);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_NEAREST);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_LINEAR);
GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, bitmap, 0);
bitmap.recycle();

Я не думаю, что причиной является звук, так как аудиофактически все еще воспроизводится (поток, который загружает аудио, затем воспроизводит его через x промежуток времени).Если это так, то причина кроется в буферизации OpenGL ES с использованием приведенного выше кода.

Материалы по теме

• Этот пост SO относится кэта ошибкаОни используют OpenGL ES 2.0 и NDK.Я использую OpenGL ES 1.1 (хотя большинство устройств эмулируют 1.1–2.0, поэтому технически они используют 2.0), и я не использую NDK.Кроме того, они используют Android 2.1, и мой сбой происходит на Android 3.2.1.
• Этот сайт связывает ошибку с объектом AudioTrack.Тем не менее, я не использую это в своем приложении.
• Android Bug Tracker перечисляет это как известную ошибку, но до сих пор нет решения (и оно не исправлено в Honeycomb +).

Общие элементы

• Замораживание происходит при буферизации.Буферизируемая вещь, как правило, довольно велика, поэтому изображение (ошибка чаще встречается при увеличении размера изображения) или аудио обычно затрагиваются.
• Заморозка происходит только на некоторых устройствах.
• Замораживание не связано с определенной версией Android - было записано в 2.1 и 3.2.1, среди других.
• Замораживание не связано с использованием NDK.
• Замораживание не связано ни с одной практикой программирования (порядок буферизации, типы файлов и т. Д.)

Мой вопрос довольно прост.Есть ли решение этой проблемы?Если вы не можете предотвратить это, есть ли способ элегантно выйти из строя и предотвратить блокировку всего устройства?

Answer 1

В случае моей игры была обнаружена проблема «waitForCondition» на Samsung Galaxy S (Android 2.3.3).Конечно, я не знаю, была ли проблема замечена на разных устройствах, но, вероятно, проблема существует и там.К счастью, я смог воспроизвести его, так как один из моих друзей получил устройство, и он был достаточно любезен, чтобы одолжить мне его на неделю.В моем случае игра практически полностью написана на Java (мало обращений через NDK к функциям OpenGL), поэтому я не совсем уверен, применимо ли это и к вашей проблеме.В любом случае кажется, что проблема как-то связана с внутренними буферами OpenGL.В представленном ниже коде закомментированная строка (1) была изменена на (2) - выбор конфигурации вручную.Я еще не проверил это полностью, но с тех пор я не заметил никаких зависаний, поэтому есть надежда .. ОБНОВЛЕНИЕ 1: В качестве дополнительной информации, я думаю, что я где-то читал, что у кого-то была такая же проблема с привязкой его ЦП, и его решением было настроить все компоненты OpenGL Surface на 8 бит (тоже альфа-компонент)а не 565 или 4 бита (я точно не помню, какая была неисправная конфигурация) ОБНОВЛЕНИЕ 2: Также можно рассмотреть возможность использования следующей реализации EGLConfigChooser: GdxEglConfigChooser.java .Если это не поможет, в конечном итоге используйте подход, представленный в GLSurfaceView20.java . ОБНОВЛЕНИЕ 3: Также немного помогло упрощение шейдеров программы.

// in Activity...
glView = new GLSurfaceView(this);
glView.setEGLContextClientVersion(2); // OpenGL ES 2.0
//      glView.setEGLConfigChooser(false); // (1) false - no depth buffer
glView.getHolder().setFormat(PixelFormat.TRANSLUCENT);
glView.setEGLConfigChooser(8,8,8,8,0,0); // (2) TODO: crashes on devices which doesn't support this particular configuration
glView.setRenderer(new MyRenderer(this));

Answer 2

Увеличение виртуальной памяти устройства снижает вероятность возникновения этой проблемы.Конечно, это не вариант, если вы не являетесь производителем устройства.