Binder calls to system services or other processes are synchronous and can block for tens to hundreds of milliseconds — more under system load. CallingDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/AmolPardeshi99/android-performance-skills/llms.txt
Use this file to discover all available pages before exploring further.
PackageManager, ActivityManager, ContentResolver.query, or any other IPC on the main thread is a direct ANR risk.
Binder IPC on the Main Thread
Every call to a system service crosses a process boundary via the Binder driver. The calling thread blocks untilsystem_server responds. Under normal conditions this takes a few milliseconds, but under system load — other app launches, ContentProvider queries, heavy CPU usage — the same call can block for hundreds of milliseconds or longer, pushing past the 5-second input ANR threshold.
Bad: synchronous Binder calls in a lifecycle callback
Correct: move Binder calls to Dispatchers.IO
Detecting violations with StrictMode
Enable StrictMode in debug builds so that any Binder call on the main thread surfaces immediately in Logcat rather than silently shipping to production.ContentProvider and AppInitializer on Main Thread
ContentProviders are initialized on the main thread during process startup, beforeApplication.onCreate(). Any heavy work in ContentProvider.onCreate() directly blocks cold start and can cause startup ANRs.
Bad: synchronous SDK init inside a ContentProvider
Correct option A: initialize on a background thread in Application.onCreate
Correct option B: Jetpack App Startup with an async initializer
Binder Thread Pool Exhaustion — System-Induced ANR
The Binder driver limits each process to a maximum of 15 threads in its thread pool (BINDER_MAX_POOL_THREADS = 15). When all Binder threads in system_server are busy, your Binder calls block indefinitely on the calling side — regardless of how clean your main thread is. This is a system-induced ANR, but you can reduce your exposure to it.
Bad: sequential system service calls at startup
Correct: batch all system service calls on the IO dispatcher
ANR log diagnosis signal for Binder thread pool pressure
When reading an ANR trace, look for this pattern in the main thread stack:BinderProxy.transact and the CPU log shows system_server at very high usage (>100% across its threads), suspect Binder thread-pool pressure rather than app logic. The fix is to move calls off the main thread and reduce burst volume at startup.
OEM App-Freezing ANR (Power-Optimization False Positive)
OEM Android distributions — particularly Asian-market ROMs from OPPO, Vivo, Xiaomi, and Huawei — implement aggressive app-freezing policies (e.g.,HansManager, RefrigeratorManager) to save battery. When the screen turns off, they send a SIGSTOP-equivalent to background apps. If your app receives an input event while frozen, the system may time out waiting for an acknowledgment and generate an ANR — even though your app code is entirely correct.
How to identify in the log
unfreeze … reason: Signal appearing within 1–2 seconds after the am_anr event. The app was correct — it was simply not allowed to respond.
OEM freeze ANRs are a system bug — don’t spend time profiling your app code. The freeze/unfreeze log pattern is definitive evidence that the failure occurred at the OS layer, not in your application.
Resolution steps
Do not profile your app code
The thread stacks will look normal because the app was externally frozen. Time spent in Perfetto or StrictMode here is wasted.
Report to the OEM
Collect the freeze/unfreeze log and file a report through the OEM’s developer relations channel. Include the exact log lines and the
am_anr timestamp for correlation.Minimize work in onResume and onStart
As a mitigation, keep
onResume and onStart as lightweight as possible so your app can re-respond quickly after being unfrozen.