[READ] Step 1: Are you in the right place?
Yes — this is a bug in the Firebase Performance Monitoring Android SDK.
[REQUIRED] Step 2: Describe your environment
- Android Studio version: Android Studio Panda 1 | 2025.3.1 Patch 1
- Firebase Component: Performance
- Component version: 34.14.1 (firebase-bom)
[REQUIRED] Step 3: Describe the problem
Steps to reproduce:
Calling Trace.start() on the main thread during Application.onCreate() causes an ANR. The root cause is that ConfigResolver.getDeviceCacheBoolean() reads SharedPreferences synchronously every time Trace.start() is called until the value is cached in-process. On the affected OS versions, this disk read is slow enough to trigger an ANR when it happens during app startup.
The ANR only occurs on the first 1–2 invocations — subsequent calls hit an in-process cache and return immediately.
Full ANR stack trace:
main (runnable): tid=1 systid=17353
at com.google.firebase.perf.config.ConfigurationConstants$CollectionEnabled.getDeviceCacheFlag(ConfigurationConstants.java:77)
at com.google.firebase.perf.config.ConfigResolver.getDeviceCacheBoolean(ConfigResolver.java:892)
at com.google.firebase.perf.config.ConfigResolver.getIsPerformanceCollectionEnabled(ConfigResolver.java:143)
at com.google.firebase.perf.config.ConfigResolver.isPerformanceMonitoringEnabled(ConfigResolver.java:118)
at com.google.firebase.perf.metrics.Trace.start(Trace.java:209)
at com.deliveryhero.pelican.performance.InternalFirebaseTrace.start(InternalFirebaseTrace.java:10)
...
Relevant Code:
// Called during Application.onCreate() on the main thread
val trace = FirebasePerformance.getInstance().newTrace("app_init")
trace.start() // ← ANR: reads SharedPreferences synchronously
Expected behavior:
Trace.start() should either cache the SharedPreferences value eagerly at SDK init time, or perform the read asynchronously, so that calling it on the main thread does not risk an ANR.
Actual behavior:
Trace.start() performs a synchronous SharedPreferences read on whichever thread it is called from. When called on the main thread during app startup, this causes an ANR.
[READ] Step 1: Are you in the right place?
Yes — this is a bug in the Firebase Performance Monitoring Android SDK.
[REQUIRED] Step 2: Describe your environment
[REQUIRED] Step 3: Describe the problem
Steps to reproduce:
Calling
Trace.start()on the main thread duringApplication.onCreate()causes an ANR. The root cause is thatConfigResolver.getDeviceCacheBoolean()readsSharedPreferencessynchronously every timeTrace.start()is called until the value is cached in-process. On the affected OS versions, this disk read is slow enough to trigger an ANR when it happens during app startup.The ANR only occurs on the first 1–2 invocations — subsequent calls hit an in-process cache and return immediately.
Full ANR stack trace:
Relevant Code:
Expected behavior:
Trace.start()should either cache theSharedPreferencesvalue eagerly at SDK init time, or perform the read asynchronously, so that calling it on the main thread does not risk an ANR.Actual behavior:
Trace.start()performs a synchronousSharedPreferencesread on whichever thread it is called from. When called on the main thread during app startup, this causes an ANR.