--- title: "Two Bugs, One Setting: How DKA Silently Broke Our Fragments" url: https://daily.dev/posts/two-bugs-one-setting-how-dka-silently-broke-our-fragments-vota4mfhb source_url: https://proandroiddev.com/two-bugs-one-setting-how-dka-silently-broke-our-fragments-de9567449e6c type: article source: "ProAndroidDev" published: 2026-08-11T19:35:17.664Z updated: 2026-08-11T19:35:54.648Z tags: ["android", "kotlin"] reading_time: 15 upvotes: 2 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Two Bugs, One Setting: How DKA Silently Broke Our Fragments **[ProAndroidDev](https://daily.dev/sources/pand)** · 15 min read · 2 upvotes · 0 comments ## Summary A deep-dive into two production bugs caused by Don't Keep Activities (DKA) mode on Android, both rooted in the same pattern: state initialized in a lifecycle callback that doesn't fire when a Fragment is recreated with a retained ViewModel. Bug #1 involved a media picker whose callbacks were set on a stale Fragment instance cached via a lazy property, causing a 2.3 MB memory leak per navigation cycle. Bug #2 involved a profile screen's MVI side-effect delegate going uninitialized after DKA restoration, silently swallowing all navigation commands. The fix in both cases was switching from lateinit fields initialized in ViewModel-creation callbacks to Kotlin lazy delegates that initialize on first access. The post also covers a DKA checklist, instrumentation testing with ActivityScenario.recreate(), LeakCanary integration, and how the same bug class appears in Jetpack MVVM, MVIKotlin, and other architectures with asymmetric component lifetimes. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does my Android Fragment stop working after navigating away and back with Don't Keep Activities enabled? With Don't Keep Activities (DKA) enabled, the Activity and Fragment are destroyed on navigation, but the ViewModelStore survives. If critical state — callbacks, delegates, navigation handlers — was initialized in a ViewModel-creation callback like onCreateFeature or ViewModel.init, that initialization does not run again on Fragment recreation. The Fragment gets a fresh instance but the ViewModel is reused, leaving fields uninitialized or pointing to dead objects. _Android developers debugging silent DKA failures track patterns like this on daily.dev._ ### How do I test that my Android Fragment survives activity recreation with a retained ViewModel? Use ActivityScenario.recreate() in an instrumentation test. This destroys the Activity and recreates it while reusing the ViewModelStore, exactly replicating what DKA does. If any lateinit field is only initialized in a ViewModel-creation callback, the test will fail on assertions that depend on that field. This catches both stale Fragment instance references and uninitialized delegates without needing DKA enabled on a device. _Teams shipping Fragment-heavy apps catch recreation regressions earlier by following Android testing discussions on daily.dev._ ### What causes a memory leak when caching a Fragment instance in a lazy property inside a ViewPager2 FragmentStateAdapter? FragmentStateAdapter.createFragment() is called every time the adapter needs a Fragment instance, not just once. If the host Fragment caches the returned instance in a lazy property, after Activity recreation the adapter creates a new Fragment while the lazy property still holds the old detached one. The old instance is kept alive through the ViewModelStore GC root, retaining its entire View hierarchy — measured at ~2.3 MB per navigation cycle on a Pixel 6 running API 34. _Developers profiling Android memory issues find retention chain analyses like this on daily.dev._ ## Similar posts on daily.dev - [One Badge, Three Deliveries: How Android, Flutter, and Compose Keep Your UI in Sync](https://daily.dev/posts/one-badge-three-deliveries-how-android-flutter-and-compose-keep-your-ui-in-sync-fph6mmdcv) · Medium · 0 upvotes · 0 comments - [My Flutter App Gained 40 MB Every Time I Opened a Screen](https://daily.dev/posts/my-flutter-app-gained-40-mb-every-time-i-opened-a-screen-7q7umiv1z) · Medium · 0 upvotes · 0 comments - [State-Leak Bugs Aren’t Edge Cases. Move Them to Rule One.](https://daily.dev/posts/state-leak-bugs-aren-t-edge-cases-move-them-to-rule-one--codeebnjm) · Medium · 1 upvotes · 0 comments --- Tags: [#android](https://daily.dev/tags/android), [#kotlin](https://daily.dev/tags/kotlin) [View this post on daily.dev](https://daily.dev/posts/two-bugs-one-setting-how-dka-silently-broke-our-fragments-vota4mfhb)