ANR when adding GraphicsOverlays with large graphic counts

CristhianSanchez — Wed, 24 Jun 2026 23:27:52 GMT

Hello, our app loads user-submitted map features onto a map. Each feature has a geometry type (point, line, polygon) and a color. We group features into GraphicsOverlay objects by (type, color) pair — so a dataset with 3 geometry types × 5 colors produces at most 15 overlays, each containing N graphics. In production we see datasets with up to 15,000 total graphics spread across a small number of overlays (e.g. 2 overlays: 8,000 red points + 7,000 blue polygons).

We are seeing an ApplicationNotResponding error rooted in CoreVector.nativeAdd via pthread_mutex_lock:

at java.util.AbstractCollection.addAll
at com.arcgismaps.internal.collections.MutableListImpl.add
at com.arcgismaps.internal.jni.CoreVector.nativeAdd
at UnknownClass.RT_Vector_add
...
at UnknownClass.NonPI::MutexLockWithTimeout
at UnknownClass.__futex_wait_ex
at UnknownClass.syscall

This occurs most reliably on app resume after a long background period (60+ minutes) during which the SDK appears to have queued a large number of tile loads. When the app resumes, the rendering thread holds the native mutex during a tile burst, and our main thread blocks waiting to acquire it.

We came across the following post, which may be related to this issue: MapView is disposed way too long with a lot of Graphic in certain conditions

What we do off the main thread

We build all GraphicsOverlay objects and populate overlay.graphics on a background IO dispatcher before touching mapView.graphicsOverlays:

// IO dispatcher return withContext(Dispatchers.IO) { val overlay = GraphicsOverlay(renderingMode = GraphicsRenderingMode.Static) overlay.renderer = SimpleRenderer(symbol) overlay.labelDefinitions.add(labelDefinition) overlay.graphics.addAll(graphicsList) // 8,000 graphics added here, off main overlay // returned as a plain object, not yet registered } // Main dispatcher — MapView withContext(Dispatchers.Main) { mapView.graphicsOverlays.add(overlay) // registration: only this on main }

Questions for the community:

1. Thread safety of graphicsOverlays.add()
Is it strictly required to call mapView.graphicsOverlays.add() on the main thread, or does the SDK provide any thread-safe API for registering overlays? GeoView extends FrameLayout, so we assume the Android single-threaded view rule applies — but we want to confirm.

2. Thread safety of overlay.graphics.addAll() before registration
We populate overlay.graphics on a background thread before calling graphicsOverlays.add(). Is this safe? Our assumption is that an unregistered overlay has no native render-thread involvement yet, so off-thread mutation is safe. Is this correct?

3. Recommended pattern for large graphic counts
Is there an recommended maximum number of graphics per overlay or per map view for GraphicsRenderingMode.Static before frame drops become significant? For 15,000 total graphics across 2 overlays on a modern high-end device, is per-overlay batching the right approach, or should we consider a different architecture (e.g. feature layers, clustering)?

4. Mutex contention on app resume
The ANR stack trace shows NonPI::MutexLockWithTimeout blocking on a futex. Is there a way to explicitly yield or pause the SDK's rendering pipeline during bulk overlay registration to avoid this contention on resume?

5. Alternative APIs for large static datasets
For a use case involving large numbers of static geometries — potentially 10,000+ features that do not change until the visible area is refreshed — is GraphicsOverlay the recommended API, or does the SDK provide alternative rendering approaches better suited to this scale? We are looking for guidance on what architecture would recommend when graphic counts grow beyond what GraphicsOverlay handles comfortably.

Thanks in advance!

Re: ANR when adding GraphicsOverlays with large graphic counts

NicoleLeiva25 — Mon, 27 Jul 2026 14:57:25 GMT

Hello everyone,
I wanted to kindly follow up on this thread to see whether there are any updates on this ANR issue.

We’re still seeing multiple variations of the same underlying problem in production, and it’s having a significant impact on our users. We’d greatly appreciate any guidance from the team, whether that’s known workarounds, recommended mitigation strategies, or confirmation that this is being investigated.

If helpful, we can also share additional traces and reproduction details from our side.

Thank you very much for your time and support.

Re: ANR when adding GraphicsOverlays with large graphic counts

dev4567 — Thu, 30 Jul 2026 10:45:10 GMT

I believe this is related question https://community.esri.com/t5/kotlin-maps-sdk-questions/mapview-is-disposed-way-too-long-with-a-lot-of/m-p/1659251#M611

topic Re: ANR when adding GraphicsOverlays with large graphic counts in Kotlin Maps SDK Questions

ANR when adding GraphicsOverlays with large graphic counts

Re: ANR when adding GraphicsOverlays with large graphic counts

Re: ANR when adding GraphicsOverlays with large graphic counts