Fix ANR in Kotlin Multiplatform Apps (Android)

ANR (App Not Responding) in KMP apps

ANR, or Application Not Responding, happens when an Android app stops responding to user input for five seconds or more. The Android build of a Kotlin Multiplatform (KMP) app is a regular Android app, so it is subject to the same rule.

During an ANR the app appears frozen and Android shows a dialog offering to close the app or wait. Users often close the app, lose unsaved work and may not come back.

In KMP projects ANRs are easy to introduce without noticing: shared code is written once for both platforms, and a call that is cheap on one platform or in tests can block the Android main thread in production.

Why does this happen?

ANRs in KMP Android builds usually come from:

Blocking work on Dispatchers.Main: Shared repositories or use cases that run disk, database or parsing work on the main dispatcher instead of a background dispatcher.

runBlocking in shared code: Using runBlocking to bridge suspend functions into synchronous APIs blocks the calling thread, which is often the main thread.

Slow I/O and network calls: File access, SQL queries or synchronous network requests made from UI code or from shared code called by the UI.

Heavy app start-up and initialization: Initializing dependency injection, databases or SDKs synchronously in Application.onCreate() or the first screen.

Deadlocks and lock contention: Shared state protected by locks or mutexes that the main thread waits on while a background coroutine holds them.

How to fix it using Appxiom

• Analyze stack trace: The issue report provides the stack trace of the main thread and related threads, pointing to the line of code that blocked the UI.
• Trace activity trail: The activity trail shows the screens, network calls and events that happened before the ANR, so you can retrace what the user was doing.
• No extra code needed: ANRs are tracked automatically once Ax.init is called on Android. See Crash & Error Reporting for KMP.