[Firebase Sessions] Startup ANRs during DataStore construction and native shared-counter loading (NewWeakGlobalRef)

[jiahaoBCN]

[READ] Step 1: Are you in the right place?

Issues filed here should be about bugs in the code in this repository. If you have a general
question, need help debugging, or fall into some other category use one of these other channels:

• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general Firebase discussion, use the
  firebase-talk google group.
• For help troubleshooting your application that does not fall under one of the above categories,
  reach out to the personalized Firebase support channel.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: Android Studio Quail 4 | 2026.1.4
• Firebase Component: Firebase Sessions, included transitively through Firebase Crashlytics
• Component version: Crashlytics 20.0.6 confirmed in representative production event metadata; Sessions 3.0.6 resolved in our investigation worktree
• Firebase initialization: Automatic initialization through the default FirebaseInitProvider
• Application: Glovo Android — com.glovo
• Representative affected app version: 2026.37.0 (413910)
• Representative affected device/OS: realme RMX3830 / Android 15

The investigation worktree's release runtime dependency graph resolves:

Component	Resolved version
Firebase BoM	34.15.0, enforced platform
Firebase Crashlytics	20.0.6
Firebase Sessions	3.0.6
Firebase Common	22.1.0
Firebase Components	19.0.0
AndroidX DataStore core Android	1.2.1
Kotlin coroutines core JVM	1.11.0

Evidence qualification: Crashlytics 20.0.6 is confirmed in the representative production event. The remaining versions above were established using Gradle dependency reports for our investigation worktree. The affected release's source declarations align with this baseline, but we have not recovered its complete historical resolved dependency graph.

Sessions 3.0.6 requests DataStore 1.1.7 in its published POM, while our application graph resolves DataStore 1.2.1. We include this distinction in case it is relevant.

[REQUIRED] Step 3: Describe the problem

We are investigating production ANRs whose sampled main-thread stacks pass through eager Firebase Sessions initialization, including DataStore construction and native shared-counter loading.

This report appears related to:

• #7518 — ANR in createDataStore
• #7728 — ANR in createDataStore
• #7614 — ANR in SessionsSettings.getDataStore
• #6523 — ANR in FirebaseSessionsRegistrar

Those issues were closed and locked when checked on 18 September 2026. We are filing a new report following the requests for complete details in #7728 and for reports of persistent problems in #7518.

We have confirmed the sampled initialization paths, but have not demonstrated one blocking cause for all observed groups.

Steps to reproduce:

We do not yet have a deterministic reproduction or minimal sample project. The issue is observed in production Crashlytics reports.

Production observations

During 8–14 September 2026 UTC, four groups recorded:

Sampled location	ANR events	Distinct users within group
SettingsCacheImpl	53	37
createDataStore	54	46
sessionConfigsDataStore	47	37
loadDataStoreSharedCounter	28	17

• Total: 182 events, including 173 on Android 15.
• User counts are not deduplicated across groups.
• Device/OS exposure denominators are unavailable, so these counts do not establish device-specific failure rates.
• We retrieved 26 sample events containing 529 thread stacks, covering 16 reported variants.
• Four supplemental variant samples fall outside the baseline window and were not used to recompute its totals.
• All 26 main-thread stacks include FirebaseInitProvider and eager component resolution.
• Of these samples, 25 report background process state and one reports foreground state. That state alone does not identify the actual process-start trigger.

Crashlytics references

These links require access to our Firebase project. They do not grant access, and we do not assume that SDK maintainers can open them. Relevant stack excerpts and analysis are included below so the report can be assessed without console access.

• SettingsCacheImpl ANR group
• createDataStore ANR group
• sessionConfigsDataStore ANR group
• loadDataStoreSharedCounter ANR group
• Representative native-loading ANR event

The counts above use the fixed UTC investigation window. Opening a console link with its current/default time filter may show different totals.

Reproduction attempts

We completed 100 confirmed cold process starts on a Pixel 9 Pro XL running Android 17, with existing app data and 15-second Perfetto captures.

For each attempt:

1. Force-stop the application.
2. Verify that the application process is absent.
3. Capture process startup using Perfetto.
4. Launch the MAIN/LAUNCHER activity.
5. Verify cold-start classification and inspect startup/component timings and main-thread scheduling.

Play Store app version	Confirmed cold starts	First-frame median / maximum	Sessions initialization median / maximum
2026.38.0 (414970)	52	320.0 / 443.6 ms	6.05 / 16.20 ms
2026.39.0 (416140)	48	305.0 / 391.6 ms	6.92 / 18.47 ms

The production ANR was not reproduced.

There were 101 completed attempts; one warm launch was excluded from cold-start statistics. An interrupted attempt was retained separately and excluded. Google Play updated the application between test sessions.

The measured fire-sessions interval includes nested eager dependency construction; it does not isolate the native-library load.

Three brief main-thread Blocking on WeakGlobal access markers were observed, lasting approximately 1.6, 12.3, and 4.0 ms. All occurred after the first frame and outside the Sessions initialization interval.

An earlier set of 10 cold launches on a snapshot APK also did not reproduce the ANR. That dataset is separate from the 100 Play Store cold starts.

Test limitations:

• Android 17 Pixel hardware differs from the predominantly Android 15 production population.
• These were process-cold launches with retained app data, OS/filesystem caches, and compilation profiles.
• Two application releases were tested; this was not a controlled SDK before/after experiment.
• Exact SDK dependency graphs in the installed test APKs remain unverified.
• Genuine background process starts and upgrades retaining Sessions data were not exercised.
• The first cohort's event logger had a timestamp fallback, so intended log coverage is unverified.
• The resumed cohort's validated log capture contained no matching am_anr or am_crash entries. This cannot exclude failures outside the captured tags/windows.
• These non-reproducing tests do not establish that the production issue is fixed.

Relevant Code:

We have no minimal reproducer to attach. Below are captured stack excerpts and the initialization path reconstructed from SDK sources.

Representative main-thread stack

• Device: realme RMX3830
• OS: Android 15
• App: 2026.37.0 (413910)
• Crashlytics: 20.0.6
• Event timestamp: 2026-09-14T23:17:36Z
• Reported process state: Background
• Crashlytics event reference — project access required

The following is an excerpt from the captured stack. Intermediate frames are explicitly marked as omitted:

main (native): tid=1

libc.so
  syscall + 28

libart.so
  art::ConditionVariable::WaitHoldingLocks + 140
  art::JNI<false>::NewWeakGlobalRef + 1324
  art::JavaVMExt::LoadNativeLibrary + 964

libopenjdkjvm.so
  JVM_NativeLoad + 368

java.lang.Runtime.nativeLoad
java.lang.Runtime.loadLibrary0 (Runtime.java:1109)
java.lang.Runtime.loadLibrary0 (Runtime.java:1033)
java.lang.System.loadLibrary (System.java:1765)

com.google.firebase.sessions.FirebaseSessionsComponent
  $MainModule$Companion.loadDataStoreSharedCounter
  (FirebaseSessionsComponent.kt:204)

com.google.firebase.sessions.FirebaseSessionsComponent
  $MainModule$Companion.createDataStore
  (FirebaseSessionsComponent.kt:188)

com.google.firebase.sessions.FirebaseSessionsComponent
  $MainModule$Companion.createDataStore$default
  (FirebaseSessionsComponent.kt:181)

com.google.firebase.sessions.FirebaseSessionsComponent
  $MainModule$Companion.sessionConfigsDataStore
  (FirebaseSessionsComponent.kt:144)

[intermediate Sessions/Dagger construction frames omitted]

com.google.firebase.sessions.FirebaseSessionsRegistrar
  .getComponents$lambda$0

[intermediate component-resolution frames omitted]

com.google.firebase.components.ComponentRuntime
  .doInitializeEagerComponents
com.google.firebase.components.ComponentRuntime
  .initializeEagerComponents
com.google.firebase.FirebaseApp.initializeAllApis
com.google.firebase.FirebaseApp.initializeApp
com.google.firebase.provider.FirebaseInitProvider.onCreate

Representative libart.so Build ID:

cecb684d19b4f44ee3cbd66142c315f4

All four shared-counter samples we examined contain the NewWeakGlobalRef native-wait path.

Other threads in the representative event

• Measurement Worker: reported waiting for a Java monitor held by main. This shows the worker waiting for main, not Analytics blocking main.
• Firebase Blocking Thread #0: in ftruncate → NativeSharedCounter → DataStore initialization. We have no captured dependency proving that this worker's I/O causes main's native wait.
• The dump does not establish main's wait duration or the thread/condition that releases it.

Initialization path

The SDK source and captured stacks indicate this path:

FirebaseInitProvider.onCreate
  → FirebaseApp initialization
  → eager Firebase component resolution
  → Firebase Sessions dependency construction
  → sessionConfigsDataStore / createDataStore
  → synchronous shared-counter native-library loading

This provider initialization occurs before Application.onCreate.

Supplying a background dispatcher for coroutine work does not move constructor evaluation or the explicit native-library load off the calling thread.

For the other ANR groups, we see coroutine scheduler/class initialization and DataStore construction. We do not interpret a mutex constructor as proof of lock contention or a DataStore factory frame as proof of main-thread disk I/O.

Runtime hypothesis — not a confirmed root cause

AOSP Android 15 provides a possible lead:

• JavaVMExt implementation
• JNI implementation

These sources connect weak-global-reference creation with runtime weak-reference access gating and the Blocking on WeakGlobal access trace marker.

Our hypothesis is that runtime/GC coordination may be involved during the native-library load. However:

• We have not matched the OEM ART binary to exact source/symbols.
• We have not identified the releasing thread.
• We have not measured the production wait duration.
• We have not established one cause across all four ANR groups.

Two shared-counter samples also contain MarkCompact frames on HeapTaskDaemon. Snapshot coexistence does not establish that GC caused a prolonged main-thread stall.

Relationship to previous fixes and candidate updates

The maintainer response in #7518 references PR #7440 and Crashlytics 20.0.3.

Our inspected Sessions 3.0.6 source contains the directory-preparation logic associated with that change. We have not identified how that change would resolve the specific native-loading wait described here.

On 15 September, we also inspected BoM 34.19.0 / Crashlytics 20.1.1 / Sessions 3.0.8 as an update candidate:

• Across 50 published Sessions Kotlin/Java source files, only BuildConfig.java differed from 3.0.6.
• Published Sessions dependency declarations matched.
• Other Firebase libraries and build outputs can differ, so this does not establish identical runtime behavior.

A coordinated Firebase update is planned. We have not tested or claimed that this candidate fixes the ANRs.

Questions for the maintainers

1. Do these construction stacks and the loadDataStoreSharedCounter → NewWeakGlobalRef wait belong to an existing tracked Sessions issue, or should the native-loading case be investigated separately?
2. Is there a released or planned change addressing synchronous Sessions construction or shared-counter loading during provider initialization?
3. Is resolving DataStore 1.2.1 with Sessions 3.0.6, whose POM requests 1.1.7, relevant? Which dependency matrix would you recommend for a minimal reproduction?
4. What additional evidence would best distinguish ART weak-reference/GC coordination, class initialization, scheduling pressure, and worker I/O?
5. If construction deferral is appropriate, is there a supported approach that preserves early Crashlytics capture, session linkage, lifecycle handling, background initialization, and cross-process DataStore behavior?

We have retained complete API-returned thread data and local Perfetto captures. We can provide sanitized supporting evidence or share detailed traces through a private support channel if needed. No PDF or trace files are attached to this report.

We have not disabled Sessions, removed automatic Firebase initialization, or changed collection/consent behavior.