Repository navigation
[Bug] Black flickering on Android Auto and frame stuttering on mobile with Samsung Exynos/Mali devices (Exynos 9611/9820/9810) starting from Mapbox v11.21.0 #2722
Description
Environment
- Android OS version: Android 10, 11, 12
- Devices affected:
- Samsung Galaxy A51 (Exynos 9611 SoC, Mali-G72 GPU)
- Samsung Galaxy S10 / S10+ (Exynos 9820/9825 SoC, Mali-G76 GPU)
- Samsung Galaxy S9 / S9+ / Note 9 (Exynos 9810 SoC, Mali-G72 GPU)
- Maps SDK Version:
- Affected Configuration (With Flickering/Stuttering):
val mapBoxVersion = "11.21.0" implementation("com.mapbox.maps:android-ndk27:$mapBoxVersion") implementation("com.mapbox.extension:maps-androidauto-ndk27:$mapBoxVersion")
- Working Configuration (No Flickering/Stuttering):
val mapBoxVersion = "11.3.0" implementation("com.mapbox.maps:android:$mapBoxVersion") implementation("com.mapbox.extension:maps-androidauto:$mapBoxVersion")
- Affected Configuration (With Flickering/Stuttering):
Observed behavior and steps to reproduce
Observed behavior:
- On Android Auto Projection (Car Screen): The MapView continuously flashes/flickers black during user interaction (zoom, drag, rotation) or whenever there are GPS location updates. Framebuffer synchronization with Android Auto's virtual display/video encoder appears broken.
- On Standalone Mobile Device Screen: The map does not flash black, but experiences significant performance degradation, micro-stutters, and frame drops during map interactions.
Steps to reproduce:
- Initialize a Mapbox
MapViewwith the default configuration on Mapbox SDK11.21.0-ndk27. - Connect one of the affected Samsung devices to an Android Auto Head Unit (or DHU simulator).
- Pan, zoom, or drag the map.
- Observe continuous heavy black flashing on the Car Screen, and frame stutters on the Mobile Screen.
Expected behavior
The MapView should render smoothly at 30 FPS without any black flashing on Android Auto or stuttering on mobile screens on all Samsung devices using Exynos chipsets and ARM Mali GPUs.
Notes / preliminary analysis
- The bug is highly correlated with the transition to Android NDK r27 which enforces 16 KB memory page size alignment in newer Mapbox v11 releases (specifically the
-ndk27variants of the SDK and Android Auto extension). - The older ARM Mali GPU drivers (Mali-G72, Mali-G76) running on 4 KB page size kernels seem to struggle with memory page allocation and sync fences in virtual display environments (Android Auto projections), which breaks the video encoder pipeline. On the local screen, it manifests as pipeline stalls leading to visual stutters.
Activity
[-][Lỗi] Hiện tượng nhấp nháy màn hình đen trên Android Auto và giật hình trên thiết bị di động Samsung Exynos/Mali (Exynos 9611/9820/9810) bắt đầu từ Mapbox phiên bản 11.21.0[/-][+][Bug] Black flickering on Android Auto and frame stuttering on mobile with Samsung Exynos/Mali devices (Exynos 9611/9820/9810) starting from Mapbox v11.21.0[/+]nemoneph commentedon Jul 2, 2026
@lyydikoi I'm experiencing what appears to be the same issue in my mobile application (not Android Auto).
After upgrading from Mapbox to 11.21.0, several Samsung users started reporting severe map stuttering and blackmap. The issue is still present with 11.25.0.
Here are two affected devices from my crash/diagnostic reports:
Hopefully this additional information helps narrow down the root cause.
nemoneph commentedon Jul 10, 2026
maybe @pengdev you have an idea ?
iboalali commentedon Sep 15, 2026
Same problem here on an Exynos 9611 / Mali-G72. We measured it and bisected it. Details below.
Environment
com.mapbox.maps:android:11.30.1, common 24.30.1, search 2.30.1. We run this today, and we measured on it.FollowPuckViewportStateWe are not on the
-ndk27artifacts. 16 KB page support is still opt in. We use the plaincom.mapbox.maps:android, so NDK 23 and 4 KB pages. We ship outside the Play Store, so we do not need 16 KB. We still see the flicker. So NDK r27 is not the cause, at least not ours.We first saw it on the stock setup. Default
SurfaceView, nosetMaximumFps, nothing custom. TheTextureViewand fps cap variants below are our workaround attempts, not the cause.It arrived with Maps 11. Our first v11 version was 11.24.2, straight from 10.19.0. Two versions show up in this report: 11.24.2 is where we first saw it, 11.30.1 is where we measured it.
Timings are from a debuggable build with tracing and StrictMode on, so they are inflated. The defect does not depend on that.
What happens
The map has nothing new to draw. It does not hold the last frame. Instead it shows three older frames, in a loop, always in the same order. Those three were drawn while the camera was still moving, so they sit at three different zoom levels. It looks like the map flickers between three views. Depending on the config it clears after a second or keeps going as long as we watched.
To reproduce: keep location fixes coming, pan the map, lift your finger. A pinch or a finishing camera transition does the same. Anything that draws a few views and then stops leaves them in the loop.
After a pinch the three frames are three zoom levels. That reads as "the map flickers between zoom levels". We first filed that as a separate bug. It is the same one.
Caveat. We only see the outside of the SDK. The renderer is closed to us, so we cannot tell whether a given frame was really drawn. We are not proposing a cause. Everything below is measured from pixels.
Numbers
Screen recording, frames pulled with
ffmpeg -vsync 0, compared by mean pixel difference over the map area.43 seconds, 555 frames, three distinct images: 185 / 184 / 186.
Dropping repeats leaves 428 changes. They rotate strictly:
Three more checks:
The loop turns once per three presents. At
setMaximumFps(10)that is 3.3 Hz and you see three separate views. At ~35 fps it is 11.6 Hz and reads as shimmer. A lower cap makes it more visible.Bisect: it starts in 11.20.0
Same device, stock config (SurfaceView, no cap), plain artifacts. Maps and Search kept on one minor train.
We measured the clean one too. Without a cap the loop runs at 11-16 Hz, which is easy to miss by eye. Over 120 seconds on 11.19.6, with pans and follow-puck presses:
On 11.30.1 the same test gives three images. The idle case is the exact opposite: 11.19.6 holds one frame, 11.30.1 rotates three.
So the change that causes this landed in 11.20.0. That is one minor before the 11.21.0 this issue names. Dates: 11.20.0 shipped 2026-03-13, 11.19.6 shipped later, 2026-04-10. The 11.19 line carried on and never picked it up, so it is a change on the 11.20 line.
Surface type and fps cap change the rate, not the defect
setMaximumFps(10)All four combinations show it. Nothing we change on our side removes it.
Duration and frequency are the clear differences. On TextureView it does not recover: two bursts in one 180 second recording, 15 seconds and 43 seconds, the second still going when the recording ended. On SurfaceView with the cap it is a short burst after a pan that clears itself, and it is rare: a 180 second recording of that config contained no loop at all, so what we report there is from watching the device, not from a capture.
Attached
Four clips, cropped to the map, same encode settings. Same device throughout, puck parked with fixes still arriving.
There is no clip of SurfaceView with the cap, because we never caught that one on camera.
The last clip is the clean anchor of the bisect, and it is longer on purpose. It starts in the idle hold and then covers a full round of panning and pinch zooming, so you can see the map stays correct through the gestures that trigger the loop on every other version.
0-surfaceview-uncapped.mp4
1-textureview-uncapped.mp4
2-textureview-10fps.mp4
3-surfaceview-uncapped-11.19.6-clean.mp4
Disclaimer: This analysis was with aid of an AI tool
mcastets commentedon Oct 22, 2026
Same issue here on a Samsung Galaxy Note 9 (SM-N960F, Exynos 9810 / Mali-G72), Android 10.
SurfaceView, no fps cap. The style imports Mapbox Standard (monochrometheme) with a few classic layers on top, plus one symbol layer for our markers.What we see matches the description above: layers flicker after a zoom gesture, then the map shows a mix of stale frames drawn at different zoom levels (bands of the map offset or at the wrong scale). It happens most often while zooming back and forth between zoom 12 and 13, when road labels appear.
Our previous production build used 11.18.2, and no similar report came from that period. That is consistent with the 11.20.0 bisect above, although we have not bisected it ourselves on this device yet.
Screenshots: