Leak while integrating with navigation component
See original GitHub issue┬───
│ GC Root: System class
│
├─ android.view.inputmethod.InputMethodManager class
│ Leaking: NO (InputMethodManager↓ is not leaking and a class is never leaking)
│ ↓ static InputMethodManager.sInstance
├─ android.view.inputmethod.InputMethodManager instance
│ Leaking: NO (DecorView↓ is not leaking and InputMethodManager is a singleton)
│ ↓ InputMethodManager.mNextServedView
├─ com.android.internal.policy.DecorView instance
│ Leaking: NO (LinearLayout↓ is not leaking and View attached)
│ mContext instance of com.android.internal.policy.DecorContext, wrapping activity com.mpierucci.android.hiltmemleak.MainActivity with mDestroyed = false
│ Parent android.view.ViewRootImpl not a android.view.View
│ View#mParent is set
│ View#mAttachInfo is not null (view attached)
│ View.mWindowAttachCount = 1
│ ↓ DecorView.mContentRoot
├─ android.widget.LinearLayout instance
│ Leaking: NO (MainActivity↓ is not leaking and View attached)
│ mContext instance of com.mpierucci.android.hiltmemleak.MainActivity with mDestroyed = false
│ View.parent com.android.internal.policy.DecorView attached as well
│ View#mParent is set
│ View#mAttachInfo is not null (view attached)
│ View.mWindowAttachCount = 1
│ ↓ LinearLayout.mContext
├─ com.mpierucci.android.hiltmemleak.MainActivity instance
│ Leaking: NO (NavHostFragment↓ is not leaking and Activity#mDestroyed is false)
│ ↓ MainActivity.mFragments
├─ androidx.fragment.app.FragmentController instance
│ Leaking: NO (NavHostFragment↓ is not leaking)
│ ↓ FragmentController.mHost
├─ androidx.fragment.app.FragmentActivity$HostCallbacks instance
│ Leaking: NO (NavHostFragment↓ is not leaking)
│ ↓ FragmentActivity$HostCallbacks.mFragmentManager
├─ androidx.fragment.app.FragmentManagerImpl instance
│ Leaking: NO (NavHostFragment↓ is not leaking)
│ ↓ FragmentManagerImpl.mPrimaryNav
├─ androidx.navigation.fragment.NavHostFragment instance
│ Leaking: NO (Fragment#mFragmentManager is not null)
│ ↓ NavHostFragment.mNavController
│ ~~~~~~~~~~~~~~
├─ androidx.navigation.NavHostController instance
│ Leaking: UNKNOWN
│ ↓ NavHostController.mOnDestinationChangedListeners
│ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
├─ java.util.concurrent.CopyOnWriteArrayList instance
│ Leaking: UNKNOWN
│ ↓ CopyOnWriteArrayList.elements
│ ~~~~~~~~
├─ java.lang.Object[] array
│ Leaking: UNKNOWN
│ ↓ Object[].[0]
│ ~~~
├─ androidx.navigation.ui.ToolbarOnDestinationChangedListener instance
│ Leaking: UNKNOWN
│ ↓ ToolbarOnDestinationChangedListener.mContext
│ ~~~~~~~~
├─ dagger.hilt.android.internal.managers.ViewComponentManager$FragmentContextWrapper instance
│ Leaking: UNKNOWN
│ ViewComponentManager$FragmentContextWrapper wraps an Activity with Activity.mDestroyed false
│ ↓ ViewComponentManager$FragmentContextWrapper.fragment
│ ~~~~~~~~
╰→ com.mpierucci.android.hiltmemleak.LeakFragment instance
Leaking: YES (ObjectWatcher was watching this because com.mpierucci.android.hiltmemleak.LeakFragment received Fragment#onDestroy() callback and Fragment#mFragmentManager is null)
key = 257b183a-777d-43c3-a1b0-0d470d6d415c
watchDurationMillis = 19270
retainedDurationMillis = 14268
METADATA
Build.VERSION.SDK_INT: 28
Build.MANUFACTURER: Google
LeakCanary version: 2.4
App process name: com.mpierucci.android.hiltmemleak
Analysis duration: 7339 ms
The following leak is reported when integrating Hilt with fragments and navigation components. A full project to reproduce the leak can be found Here
Basically you just need to add @AndroidEntryPoint
to a fragment that updates the toolbar ( as suggested by the official documentation) and you’ll get a leak when navigating back and forth.
Since this issue does not happen if:
- you do not add the entry point annotation
or
- you do not update the toolbar through navigation component
I´ll report it in both libraries
Issue Analytics
- State:
- Created 3 years ago
- Reactions:8
- Comments:44
Top Results From Across the Web
android Navigation UI Component Memory leak - Stack Overflow
As we can see, you are adding a listener to your navController which is a new instance of ToolbarOnDestinationChangedListener() . Because you do ......
Read more >Navigation | Android Developers
The NavController is responsible for managing the back stack of destinations, adding destinations to the back stack when you navigate() to them ...
Read more >Navigation Component in Android: Simplifying ... - Innominds
Integrate the Navigation component: For each activity, we need to create a navigation graph that contains one or more fragments managed by that ......
Read more >Avoiding Conditional Navigation Pitfalls When Implementing ...
As a result, we looked at the following solutions: Replacing NavGraph at app start. Replacing start destination at app start.
Read more >Preventing and detecting memory leaks in Android apps
Memory leaks occur when an object that is supposed to be garbage ... is an Android Studio component that provides an integrated view...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I don’t see changes related to this issue in https://github.com/google/dagger/blob/dagger-2.32/java/dagger/hilt/android/internal/managers/ViewComponentManager.java Looks like the fix is not included to 2.32
Any updates on this bug? 2.33 doesn’t appear to contain a fix.