RetroArch Android black-screen and resume troubleshooting / 2026-08-08

Fix RetroArch black video with audio after returning to the app on Android

Distinguish a lost or recreated Android surface from a stopped core, bad content, audio focus, and a process restart.

10 minute black-screen diagnosisCurrent RetroArch on Android; surface lifecycle and video-driver behavior vary by OS, device, and build

Fix RetroArch black video with audio after returning to the app on Android

Do not change ROMs when audio and input still advance the same session. Pause, open the Quick Menu, and capture one verbose log while reproducing Home and return. If the menu also fails to draw, restart RetroArch once with default video settings and no shader; if only content is black, isolate the core and renderer. A background transition can recreate the Android surface without proving content corruption.

Do this in order

  1. 01

    Record Android, RetroArch, core, content receipt, video driver, shader, orientation, and whether audio, input, and emulation time continue.

  2. 02

    Create an in-game save, pause, and reproduce once with Home and return while verbose logging is enabled.

  3. 03

    Open Quick Menu: if it draws, the frontend surface exists and the failure is narrower than the whole app; if it does not, test the frontend path first.

  4. 04

    Close content safely, disable the shader, restore default video synchronization/driver settings, and cold-launch the same authorized content.

  5. 05

    Compare one other known-good core or authorized title without changing the original files, then classify frontend, core, renderer, or content scope.

  6. 06

    If the process restarted, inspect Android battery/memory policy and restore progress from the in-game save; if the session lived, retain the log and change only one video option per test.

Decision and diagnostic table

ObservationLikely boundaryNext action
Quick Menu draws over black contentCore or content video outputTest core/default renderer
Menu and content are both blackFrontend surface or video driverCold-start with defaults and log
App opens a fresh sessionAndroid removed the processReview lifecycle policy; restore normal save
Video returns but audio cracklesTiming or performance after resumeMeasure speed before latency changes

Audio proves less than it seems

Continuing sound suggests the core or process may still be alive, but it does not prove that Android retained the same drawing surface. Test the Quick Menu and input rather than treating audio as a complete health signal.

Android owns the surface lifecycle

Activities move through pause, stop, and resume, and a visible drawing surface can be destroyed and recreated. Memory pressure or device policy can also remove the entire process, which is a different recovery case.

Change one video layer

A shader, video driver, threaded-video choice, core renderer, and display synchronization are separate layers. Start with defaults, capture a clean log, and add back one setting only after a successful cold launch.

First-party sources

Related guides