mobile-ai-agents 1.0.23

package/agents/android/android-crash-analyzer/example-output.md

@@ -0,0 +1,225 @@
+# Example Output — Android Crash Analyzer
+
+This is the agent's full response to the crash log in [`example-input.md`](example-input.md).
+
+---
+
+## Crash Summary
+
+`IllegalStateException: Fragment ProfileFragment not attached to a context` thrown at `ProfileFragment.kt:124` inside a LiveData observer callback. The crash occurs when a photo upload completes (or fails) after the user has already navigated away from the Profile screen, causing the `viewModelScope` coroutine to post to `_uploadState`, which triggers the still-active LiveData observer, which calls `requireContext()` on a detached Fragment. **HIGH** severity — intermittent, proportional to upload latency and user navigation speed.
+
+---
+
+## Root Cause
+
+There are two compounding bugs that together produce this crash:
+
+**Bug 1 — Observer registered with wrong LifecycleOwner (`this` vs `viewLifecycleOwner`):**
+```kotlin
+viewModel.uploadState.observe(this) { state -> ... }
+//                           ^^^^
+// 'this' = the Fragment's lifecycle, which starts at onCreate and ends at onDestroy.
+// The Fragment's VIEW lifecycle (onCreateView → onDestroyView) is shorter.
+// When the user navigates back, the view is destroyed but the Fragment object
+// may still exist in the back stack. The observer remains active.
+```
+
+**Bug 2 — `requireContext()` called inside that active observer:**
+```kotlin
+private fun showUploadSuccess(photoUrl: String) {
+    val ctx = requireContext()  // throws if Fragment is not attached to an Activity
+```
+
+When the upload finishes on the `viewModelScope` coroutine (which survives navigation), it posts `UploadState.Success` to `_uploadState`. LiveData dispatches this on the Main thread. The observer fires — because it was registered with `this` (Fragment), not `viewLifecycleOwner` (view). Inside the callback, `requireContext()` throws because the Fragment has been detached from its Activity during back-navigation.
+
+**Secondary bug — `Context` passed into `ViewModel`:**
+```kotlin
+fun uploadPhoto(context: Context, bitmap: Bitmap) { ... }
+```
+The ViewModel stores or uses a `Context` from the Fragment. If the repository retains this reference (e.g., for file access), it creates a memory leak tying the Fragment to the ViewModel.
+
+---
+
+## Why This Happens
+
+Think of a Fragment as having two lifecycles: the Fragment itself (like the employee) and its View (like the employee's desk). When you use `observe(this)`, you're saying "keep watching until the employee leaves the company." When you use `observe(viewLifecycleOwner)`, you're saying "keep watching until the employee clears their desk."
+
+When the user navigates back, the desk is cleared (`onDestroyView`) but the employee is still around (the Fragment stays in the back stack). Your upload finishes, and it tries to show a Snackbar — but the desk is gone. `requireContext()` is like asking "where's my desk?" when there is no desk anymore.
+
+The fix is always to watch with `viewLifecycleOwner`, so the observer self-cancels the moment the view is destroyed — no desk, no watch.
+
+---
+
+## Risk Level
+
+**HIGH**  
+Reproducibility: **Intermittent** — triggered when:
+- Upload takes longer than the user's back-navigation (more likely on slow networks)
+- Device has background CPU throttling (common on budget devices)
+
+Affected users: proportional to upload success rate on slow connections × navigation-back rate. In a social app with profile photo uploads, expect this crash in the top 10 Crashlytics issues within weeks of shipping.
+
+---
+
+## Recommended Fix
+
+**Step 1 — Change observer to use `viewLifecycleOwner`**
+
+This is the primary fix. The observer self-cancels when the view is destroyed, preventing the callback from ever reaching `showUploadSuccess` after navigation.
+
+**Step 2 — Remove `requireContext()` from the observer callback**
+
+The Fragment always has access to its context through the view binding root (`binding.root.context`) without calling `requireContext()`. This is safer because `binding` is only accessible when the view exists.
+
+**Step 3 — Remove `Context` parameter from `ViewModel.uploadPhoto()`**
+
+ViewModels must never hold Activity or Fragment context. Use `application.applicationContext` (inject `Application` via Hilt's `@HiltViewModel`) for any context-dependent work in the ViewModel or Repository.
+
+**Step 4 — Cancel the upload when the user navigates away (optional but recommended)**
+
+If you want uploads to stop when the user leaves, cancel the coroutine Job and expose cancellation via a `cancelUpload()` function.
+
+---
+
+## Updated Code
+
+```kotlin
+// ProfileFragment.kt — AFTER
+
+class ProfileFragment : Fragment(R.layout.fragment_profile) {
+
+    private val viewModel: ProfileViewModel by viewModels()
+    private var _binding: FragmentProfileBinding? = null
+    private val binding get() = _binding!!
+
+    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
+        super.onViewCreated(view, savedInstanceState)
+        _binding = FragmentProfileBinding.bind(view)
+
+        // FIX 1: Use viewLifecycleOwner, not 'this'.
+        // The observer now self-cancels when onDestroyView() fires.
+        // 'uploadState' is now a StateFlow — collected with repeatOnLifecycle
+        // to guarantee cancellation and avoid the race window.
+        viewLifecycleOwner.lifecycleScope.launch {
+            repeatOnLifecycle(Lifecycle.State.STARTED) {
+                viewModel.uploadState.collect { state ->
+                    when (state) {
+                        is UploadState.Success -> showUploadSuccess(state.photoUrl)
+                        is UploadState.Error   -> showError(state.message)
+                        UploadState.Loading    -> binding.uploadProgress.isVisible = true
+                        UploadState.Idle       -> binding.uploadProgress.isVisible = false
+                    }
+                }
+            }
+        }
+
+        binding.uploadButton.setOnClickListener {
+            // FIX 3: No longer passes Context to the ViewModel.
+            viewModel.uploadPhoto(getSelectedBitmap())
+        }
+    }
+
+    private fun showUploadSuccess(photoUrl: String) {
+        // FIX 2: binding.root.context is always valid here because
+        // repeatOnLifecycle guarantees this block only runs while STARTED.
+        // No requireContext() needed.
+        binding.uploadProgress.isVisible = false
+        Snackbar.make(binding.root, "Photo updated!", Snackbar.LENGTH_SHORT).show()
+        Glide.with(binding.root.context).load(photoUrl).into(binding.avatarImage)
+    }
+
+    override fun onDestroyView() {
+        super.onDestroyView()
+        _binding = null
+    }
+}
+
+// ProfileViewModel.kt — AFTER
+
+@HiltViewModel
+class ProfileViewModel @Inject constructor(
+    // FIX 3: Inject Application for context-dependent work.
+    // Application context does NOT leak — it lives as long as the process.
+    private val application: Application,
+    private val photoRepository: PhotoRepository
+) : ViewModel() {
+
+    // Migrated from MutableLiveData to MutableStateFlow.
+    // StateFlow + collectAsStateWithLifecycle/repeatOnLifecycle is the modern pattern.
+    private val _uploadState = MutableStateFlow<UploadState>(UploadState.Idle)
+    val uploadState: StateFlow<UploadState> = _uploadState.asStateFlow()
+
+    private var uploadJob: Job? = null
+
+    fun uploadPhoto(bitmap: Bitmap) {
+        // Cancel any in-flight upload before starting a new one.
+        uploadJob?.cancel()
+        uploadJob = viewModelScope.launch {
+            _uploadState.value = UploadState.Loading
+            try {
+                // Repository now receives applicationContext — no leak.
+                val url = photoRepository.uploadPhoto(application.applicationContext, bitmap)
+                _uploadState.value = UploadState.Success(url)
+            } catch (e: CancellationException) {
+                // User navigated away and the coroutine was cancelled — do not emit Error.
+                _uploadState.value = UploadState.Idle
+                throw e  // Always re-throw CancellationException
+            } catch (e: Exception) {
+                _uploadState.value = UploadState.Error(e.message ?: "Upload failed")
+            }
+        }
+    }
+
+    fun cancelUpload() {
+        uploadJob?.cancel()
+        _uploadState.value = UploadState.Idle
+    }
+}
+
+// UploadState.kt — sealed class for type-safe state
+
+sealed class UploadState {
+    object Idle    : UploadState()
+    object Loading : UploadState()
+    data class Success(val photoUrl: String) : UploadState()
+    data class Error(val message: String)   : UploadState()
+}
+```
+
+---
+
+## Edge Cases
+
+- **ViewPager2 tabs:** Fragments in a ViewPager2 have their views destroyed and recreated when the user swipes away. Using `observe(this)` accumulates a new observer on every tab-return. With the `viewLifecycleOwner` fix, each view creation registers exactly one observer.
+
+- **Bottom navigation with `FragmentManager` backstack:** A Fragment that is added to the back stack retains its Fragment instance. After `onDestroyView()`, any observer registered with `this` continues firing. The fix eliminates this entirely.
+
+- **Configuration change mid-upload:** The ViewModel survives rotation, but the Fragment is recreated. Without the fix, both the old and new Fragment's observers fire. With the fix, only the new Fragment's observer is active.
+
+- **Deep-link navigation to ProfileFragment:** If a deep link arrives while a previous ProfileFragment is still alive in the back stack, the upload from the back-stack Fragment can still post to the ViewModel's StateFlow — but with `repeatOnLifecycle(STARTED)`, only the foreground Fragment collects.
+
+- **Application context for Glide:** `Glide.with(context)` where `context` is an Activity or Fragment that has been destroyed will log a warning and sometimes throw. Always use `Glide.with(applicationContext)` for background or long-lived loads.
+
+---
+
+## Testing Checklist
+
+- [ ] Open Profile screen → start a photo upload → immediately press Back → confirm **no crash** in logcat or Crashlytics
+- [ ] Open Profile screen → start a photo upload → rotate the device mid-upload → upload completes → confirm result appears correctly in the new Fragment instance
+- [ ] Open Profile screen → start a photo upload → switch to another tab (bottom nav) → switch back → confirm upload state is restored correctly
+- [ ] Open Profile screen → start a photo upload → throttle network to 3G (Developer Options → Network speed) → press Back → confirm no crash
+- [ ] Run the app with LeakCanary enabled → complete a photo upload → navigate away → confirm **no Fragment or Activity leak** is reported
+- [ ] Enable "Don't keep activities" in Developer Options → start upload → press Home → return to app → confirm no crash and UI state is correct
+- [ ] Verify that calling `uploadPhoto()` twice rapidly does not produce two concurrent uploads (second call cancels the first)
+
+---
+
+## Prevention Tips
+
+- **Rule:** Always use `viewLifecycleOwner` when observing LiveData or collecting Flow inside a Fragment. Add this to your code review checklist.
+- **Lint:** Enable the AndroidX Lint rule `FragmentLiveDataObserve` — it flags `observe(this)` inside Fragments automatically.
+- **Migration:** Replace `MutableLiveData` + `observe()` with `MutableStateFlow` + `repeatOnLifecycle(STARTED)` + `collect {}` in all new Fragments. The structured concurrency model eliminates the observer lifecycle class entirely.
+- **Architecture:** ViewModels must never accept `Activity`, `Fragment`, or `View` as parameters. Use `AndroidViewModel` for Application context, or inject `@ApplicationContext` via Hilt.
+- **CancellationException:** Never catch `CancellationException` generically. Use `catch (e: Exception) { if (e is CancellationException) throw e; ... }` or separate `catch` blocks.
+- **Testing:** Add a `WhenFragmentDetachedTest` to your test suite that verifies ViewModel state changes after `fragmentScenario.recreate()` do not crash the Fragment.
+- **Static analysis:** Add `detekt` or `ktlint` rules banning `GlobalScope` and `requireContext()` inside observer callbacks.

package/agents/android/anr-investigation/README.md

@@ -0,0 +1,78 @@
+# Android ANR Investigation Agent
+
+> ANR traces, Play Console clusters, and thread dumps -> root cause, production fix, and verification plan.
+
+---
+
+## What It Does
+
+- Reads Play Console ANR clusters, Crashlytics ANR reports, `traces.txt`, bug reports, and `ApplicationExitInfo`
+- Classifies input dispatch, service, foreground service, broadcast receiver, JobService, startup, binder, lock, and deadlock ANRs
+- Finds the main thread state and any thread that owns the dependency blocking it
+- Detects main-thread database, disk, network, startup, rendering, SDK, and synchronization bottlenecks
+- Produces production-ready Kotlin fixes with structured concurrency and lifecycle-safe ownership
+- Defines verification steps using StrictMode, system traces, macrobenchmarks, low-end devices, and Play Console monitoring
+
+---
+
+## Files
+
+| File | Purpose |
+|---|---|
+| [`agent.md`](agent.md) | Input/output contract and system prompt |
+| [`example-input.md`](example-input.md) | Real ANR-style trace and related code |
+| [`example-output.md`](example-output.md) | Full deterministic investigation output |
+
+---
+
+## Quick Start
+
+```text
+Use the agent at agents/android/anr-investigation/agent.md.
+
+APP_VERSION: 4.8.0 (480)
+ANDROID_VERSION: 14
+DEVICE: Pixel 6a
+ANR_SOURCE: Play Console
+ANR_REASON:
+Input dispatching timed out
+USER_ACTION:
+Cold launch, then tapped Sign in.
+TRACE:
+<paste full ANR trace or thread dump>
+RELATED_CODE:
+<paste Activity, ViewModel, repository, service, receiver, or database code>
+```
+
+Install only this agent:
+
+```bash
+npx mobile-ai-agents add agent anr-investigation
+```
+
+---
+
+## Design Principles
+
+- The main thread is often the victim, not the cause.
+- A high-confidence ANR report needs the main thread plus lock owner, binder peer, or blocking dependency.
+- Do not wrap unknown code in `Dispatchers.IO` blindly.
+- Keep receiver, service, and job lifecycle callbacks short.
+- Reduce lock scope instead of moving lock contention to another thread.
+- Every fix needs a reproducible timeout test or measurable performance check.
+
+---
+
+## Related
+
+- [`skills/android/anr-investigation.md`](../../../skills/android/anr-investigation.md)
+- [`agents/android/android-crash-analyzer`](../android-crash-analyzer/)
+- [`agents/android/code-reviewer`](../code-reviewer/)
+- [`agents/android/axiom`](../axiom/)
+
+---
+
+## Official References
+
+- [Android Developers: ANRs](https://developer.android.com/topic/performance/vitals/anr)
+- [Android Developers: Diagnose performance issues](https://developer.android.com/topic/performance)

package/agents/android/anr-investigation/agent.md

@@ -0,0 +1,117 @@
+# FREEZE — Android ANR Investigation Agent
+
+**Platform:** Android (Kotlin / Java / Jetpack / Compose)  
+**Personality:** Main-thread forensic analyst. Every freeze has a blocking chain.  
+**Category:** Debugging / Performance / Reliability  
+**Complexity:** High  
+**Tested With:** GPT-5.4
+
+---
+
+## Purpose
+
+Analyzes Android ANR traces, Play Console clusters, Crashlytics ANRs, thread dumps, bug reports, `ApplicationExitInfo`, and related source code to identify the blocking chain, root cause, smallest safe fix, and verification plan.
+
+---
+
+## Input Format
+
+```text
+APP_VERSION: <version/build>
+ANDROID_VERSION: <version/API or unknown>
+DEVICE: <device/model or unknown>
+ANR_SOURCE: <Play Console | Crashlytics | traces.txt | bugreport | ApplicationExitInfo>
+ANR_REASON:
+<timeout reason, cluster title, or user-perceived ANR reason>
+USER_ACTION:
+<what the user was doing>
+TRACE:
+<full ANR trace, main thread, and related worker/binder/lock owner threads>
+RELATED_CODE:
+<Activity, ViewModel, repository, service, receiver, worker, database, SDK init, or Compose code>
+```
+
+---
+
+## Output Format
+
+````text
+ANDROID ANR INVESTIGATION
+=========================
+Result: CONFIRMED | LIKELY | INCONCLUSIVE
+Confidence: HIGH | MEDIUM | LOW
+ANR Type:
+Trigger:
+
+EVIDENCE SUMMARY
+----------------
+| Evidence | Observation |
+|---|---|
+
+THREAD ANALYSIS
+---------------
+| Thread | State | Waiting On / Work | Significance |
+|---|---|---|---|
+
+ROOT CAUSE
+----------
+<proven causal chain, or what remains unknown>
+
+FIX
+---
+<smallest safe fix>
+
+UPDATED CODE
+------------
+```kotlin
+<corrected code, or "Not available without related source">
+```
+
+VERIFICATION
+------------
+- <step>
+
+MISSING EVIDENCE
+----------------
+- <item or "None">
+
+NEXT ACTION
+-----------
+<one concrete action>
+````
+
+---
+
+## System Prompt
+
+```text
+You are FREEZE, a senior Android ANR investigator specializing in Kotlin, Java, Android vitals, Play Console ANR clusters, traces.txt, ApplicationExitInfo, thread dumps, startup performance, Room/SQLite, coroutines, binder, services, broadcast receivers, JobService, Compose, locks, and deadlocks.
+
+Analyze evidence before giving fixes. Locate the main thread, record its state, then identify the dependency that prevents it from processing input, lifecycle callbacks, broadcasts, services, or jobs. The top app frame can be a victim; find the blocking owner when locks, binder, futures, joins, latches, or monitors appear.
+
+Rules:
+1. Classify the ANR as input dispatch timeout, service timeout, foreground service start timeout, broadcast receiver timeout, JobService timeout, main-thread I/O/computation, binder stall, lock contention, deadlock, slow startup, rendering/layout stall, or unknown.
+2. For BLOCKED main threads, identify the monitor/lock and owner thread. For WAITING, identify Future.get, CountDownLatch.await, join, runBlocking, wait, semaphore, mutex, or synchronous callback. For NATIVE, inspect binder, file, database, graphics, or native SDK frames.
+3. Check related code for main-thread Room/SQLite, disk, network, SharedPreferences commit, JSON parsing, bitmap work, crypto, eager DI, ContentProvider/Application startup, synchronous SDK init, long receiver/service/job callbacks, and broad synchronized sections.
+4. Propose the smallest safe production fix. Use structured coroutines and appropriate dispatchers, WorkManager for deferrable persistent work, shorter service/receiver/job callbacks, reduced lock scope, async SDK initialization, or startup deferral as evidence requires.
+5. Do not blindly suggest Dispatchers.IO when the cause is lock contention, binder stall, deadlock, or lifecycle misuse.
+6. Include corrected Kotlin/Java when source is present. Preserve cancellation, lifecycle, and error handling.
+7. Include verification with reproduction, low-end device testing, StrictMode or tracing, Macrobenchmark/startup measurement when relevant, and Play Console ANR cluster monitoring.
+8. If trace evidence is incomplete, mark confidence LOW or MEDIUM and list exactly what is missing.
+
+Output MUST follow the exact format specified. Do not add extra sections or omit any section.
+```
+
+---
+
+## Example
+
+See [`example-input.md`](example-input.md) and [`example-output.md`](example-output.md).
+
+---
+
+## Notes
+
+- ANR reports need full thread context; a single main-thread frame is rarely enough.
+- Use the dedicated `/anr-investigation` skill for smaller inline analysis.
+- Pair with PERF for startup traces and with Mobile MCP QA for device reproduction.

package/agents/android/anr-investigation/example-input.md

@@ -0,0 +1,62 @@
+# Example Input — Android ANR Investigation Agent
+
+```text
+APP_VERSION: 4.8.0 (480)
+ANDROID_VERSION: Android 14 / API 34
+DEVICE: Pixel 6a
+ANR_SOURCE: Play Console
+ANR_REASON:
+Input dispatching timed out. The application was too busy to process user input.
+USER_ACTION:
+Cold launch, then tapped Sign in while session refresh was running.
+
+TRACE:
+"main" prio=5 tid=1 BLOCKED
+  at com.sampleshop.session.SessionStore.read(SessionStore.kt:42)
+  - waiting to lock <0x1234> (a com.sampleshop.session.SessionStore) held by thread 18
+  at com.sampleshop.auth.AuthRepository.currentSession(AuthRepository.kt:27)
+  at com.sampleshop.ui.MainActivity.onCreate(MainActivity.kt:31)
+  at android.app.Activity.performCreate(Activity.java:8595)
+
+"DefaultDispatcher-worker-3" prio=5 tid=18 RUNNABLE
+  at java.net.SocketInputStream.socketRead0(Native Method)
+  at okhttp3.internal.connection.RealCall.execute(RealCall.kt:153)
+  at com.sampleshop.session.SessionApi.refreshTokenBlocking(SessionApi.kt:21)
+  at com.sampleshop.session.SessionStore.refresh(SessionStore.kt:68)
+  - locked <0x1234> (a com.sampleshop.session.SessionStore)
+  at com.sampleshop.session.SessionRepository.refresh(SessionRepository.kt:51)
+
+RELATED_CODE:
+class SessionStore(
+    private val api: SessionApi
+) {
+    private var cachedSession: Session? = null
+
+    @Synchronized
+    fun read(): Session? = cachedSession
+
+    @Synchronized
+    fun refresh(): Session {
+        val response = api.refreshTokenBlocking()
+        val session = response.toSession()
+        cachedSession = session
+        return session
+    }
+}
+
+class AuthRepository(
+    private val sessionStore: SessionStore
+) {
+    fun currentSession(): Session? = sessionStore.read()
+}
+
+class MainActivity : ComponentActivity() {
+    @Inject lateinit var authRepository: AuthRepository
+
+    override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+        val session = authRepository.currentSession()
+        setContent { App(session = session) }
+    }
+}
+```

package/agents/android/anr-investigation/example-output.md

@@ -0,0 +1,103 @@
+# Example Output — Android ANR Investigation Agent
+
+````text
+ANDROID ANR INVESTIGATION
+=========================
+Result: CONFIRMED
+Confidence: HIGH
+ANR Type: Lock contention causing input dispatch timeout
+Trigger: Cold launch while session refresh holds the SessionStore monitor
+
+EVIDENCE SUMMARY
+----------------
+| Evidence | Observation |
+|---|---|
+| ANR reason | Input dispatching timed out |
+| Main thread | BLOCKED in `SessionStore.read(SessionStore.kt:42)` |
+| Lock | Main waits for monitor `0x1234` |
+| Owner thread | `DefaultDispatcher-worker-3` owns `0x1234` |
+| Owner work | Blocking OkHttp refresh inside `SessionStore.refresh()` |
+
+THREAD ANALYSIS
+---------------
+| Thread | State | Waiting On / Work | Significance |
+|---|---|---|---|
+| main | BLOCKED | Waiting for `SessionStore` monitor `0x1234` | Cannot finish launch or process input |
+| DefaultDispatcher-worker-3 | RUNNABLE | Blocking network call while holding `SessionStore` monitor | Prevents main from reading cached session |
+
+ROOT CAUSE
+----------
+`SessionStore.refresh()` is synchronized and holds the object monitor while performing a blocking network request. During cold launch, `MainActivity.onCreate()` calls `AuthRepository.currentSession()`, which calls the synchronized `SessionStore.read()`. Because the worker thread owns the same monitor until the network request completes, the main thread blocks and cannot process the user's sign-in tap. That produces the input dispatch timeout.
+
+FIX
+---
+1. Do not hold the `SessionStore` monitor during network I/O.
+2. Replace method-level `@Synchronized` with a narrow lock only around cached state reads/writes.
+3. Make refresh suspendable and perform the blocking call on `Dispatchers.IO` only for the network operation.
+4. Keep launch rendering independent from refresh completion; read cached state quickly and let the UI observe refresh state asynchronously.
+
+UPDATED CODE
+------------
+```kotlin
+class SessionStore(
+    private val api: SessionApi,
+) {
+    private val lock = Any()
+    private var cachedSession: Session? = null
+
+    fun read(): Session? = synchronized(lock) {
+        cachedSession
+    }
+
+    suspend fun refresh(): Session {
+        val session = withContext(Dispatchers.IO) {
+            api.refreshTokenBlocking().toSession()
+        }
+
+        synchronized(lock) {
+            cachedSession = session
+        }
+
+        return session
+    }
+}
+
+class AuthRepository(
+    private val sessionStore: SessionStore,
+) {
+    fun currentSession(): Session? = sessionStore.read()
+
+    suspend fun refreshSession(): Session = sessionStore.refresh()
+}
+
+class MainActivity : ComponentActivity() {
+    @Inject lateinit var authRepository: AuthRepository
+
+    override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+        val cachedSession = authRepository.currentSession()
+
+        setContent {
+            App(session = cachedSession)
+        }
+    }
+}
+```
+
+VERIFICATION
+------------
+- Add a test fake that delays `refreshTokenBlocking()` by 10 seconds while launching `MainActivity`.
+- Confirm `MainActivity.onCreate()` returns without waiting for refresh.
+- Enable StrictMode and verify no main-thread disk/network violations during startup.
+- Capture a Perfetto trace during cold launch and confirm the main thread is not BLOCKED on `SessionStore`.
+- Run startup on a low-end Android device or emulator with CPU throttling.
+- Monitor the Play Console ANR cluster after staged rollout.
+
+MISSING EVIDENCE
+----------------
+- None
+
+NEXT ACTION
+-----------
+Replace method-level synchronization in `SessionStore` with narrow cached-state locking, then rerun the delayed-refresh cold-launch reproduction.
+````