Fix a RetroArch black screen after changing the video driver on Android
Start with a cold launch and a known-good authorized game, remove shaders and per-game overrides, and capture the active video driver plus the first error in a RetroArch log. If the menu also disappears immediately after a driver change, restore the previous documented driver or a backed-up configuration rather than reinstalling content. Change only one video setting per restart: a driver failure, a shader mismatch, a core render path, and an incomplete ROM/BIOS/CHD audit require different repairs.
Do this in order
- 01
Record the RetroArch package channel, version, Android version, device GPU, core name/version, content identity, and the last video, shader, or override change.
- 02
Cold-launch RetroArch without loading content; if the menu renders, load one authorized known-good game with shaders disabled and no game or directory override.
- 03
Generate a verbose log for the first failing launch and capture the active video driver, graphics-context error, core message, and any missing content or firmware line before changing settings.
- 04
If the failure began with a driver change, restore the previous driver through the menu when visible; if the menu is black, restore a backed-up configuration or only the documented video-driver key while preserving the original file.
- 05
Restart after each single change, testing driver baseline first, then core, then shader or filter, and finally scaling or threaded-video performance; do not change audio, latency, and content paths at the same time.
- 06
Save the smallest working configuration at the narrowest scope, re-enable one visual feature at a time, and keep the log plus rollback copy for the next app, OS, or GPU-driver update.
Decision and diagnostic table
| Symptom boundary | First evidence | Next safe action |
|---|---|---|
| Menu and every core are black | Active video driver or graphics-context log | Restore previous driver/configuration |
| Menu works; one core is black | Core version and render-path log | Test the core at default video settings |
| Only one game is black | Content, BIOS, CHD, and driver audit | Resolve the first named dependency |
| Image returns when shader is off | Shader format versus active driver | Use a compatible preset or keep baseline |
Prove whether the frontend can draw
A visible RetroArch menu shows that the package can create at least one graphics context. It does not prove that every core, hardware-rendered path, shader format, or content dependency is valid.
When the menu itself is black after a driver change, loading different ROMs adds no useful evidence. Recover the driver or configuration layer first and preserve the failing file for comparison.
Shaders and drivers share a compatibility boundary
Libretro documents driver-specific shader formats and recommends disabling shaders while diagnosing low frame rate or video faults. A preset that worked under one video driver may not be valid under another.
Remove the preset at the narrowest game, directory, or core scope. Re-enable it only after the same core and lawful content render at the driver's default baseline.
A black game can still be a content failure
If the menu and other authorized games render, read the first core or content error before blaming the GPU. Missing BIOS, parent, device ROM, or CHD data can stop the machine after the frontend has drawn normally.
Keep graphics recovery and content audit separate. A video-driver switch cannot repair wrong bytes, and downloading an anonymous pack cannot prove a graphics diagnosis.
Video troubleshooting does not justify downloading replacement ROM, BIOS, CHD, shader packs, artwork, or proprietary GPU files from unreviewed sources. Diagnose with your own lawful dump or explicitly authorized content and official app/device update channels.