Android Canary leak - Billing and ViewBinding

user_10191400 0
Viewed 449

I imported LeakCanary into my project to understand which and how many memory leaks I had inside, to then be able to fix them. I noticed these two that I can't fix. To put it better, I don't know how to act in code to solve them. Would anyone know how to give me some advice about it?

LeakCanary: 2 APPLICATION LEAKS
LeakCanary: References underlined with "~~~" are likely causes.
LeakCanary: Learn more at https://squ.re/leaks.
LeakCanary: 16523886 bytes retained by leaking objects
LeakCanary: Signature: 4594f3337285a2a3dd854a7bf9c944f5598ae18b
LeakCanary: ┬───
LeakCanary: │ GC Root: Global variable in native code
LeakCanary: │
LeakCanary: ├─ android.app.LoadedApk$ServiceDispatcher$DeathMonitor instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 144 bytes in 4 objects
LeakCanary: │    ↓ LoadedApk$ServiceDispatcher$DeathMonitor.this$0
LeakCanary: │                                               ~~~~~~
LeakCanary: ├─ android.app.LoadedApk$ServiceDispatcher instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 622 bytes in 8 objects
LeakCanary: │    mContext instance of com.example.packagename.ApplicationContext
LeakCanary: │    ↓ LoadedApk$ServiceDispatcher.mConnection
LeakCanary: │                                  ~~~~~~~~~~~
LeakCanary: ├─ com.android.billingclient.api.BillingClientImpl$zza instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 41 bytes in 3 objects
LeakCanary: │    ↓ BillingClientImpl$zza.zzd
LeakCanary: │                            ~~~
LeakCanary: ├─ com.example.packagename.fragments.ShopFragment$setupBillingClient$1 instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 12 bytes in 1 objects
LeakCanary: │    Anonymous class implementing com.android.billingclient.api.BillingClientStateListener
LeakCanary: │    ↓ ShopFragment$setupBillingClient$1.this$0
LeakCanary: │                                        ~~~~~~
LeakCanary: ╰→ com.example.packagename.fragments.ShopFragment instance
LeakCanary: ​     Leaking: YES (ObjectWatcher was watching this because com.example.packagename.fragments.ShopFragment received
LeakCanary: ​     Fragment#onDestroy() callback and Fragment#mFragmentManager is null)
LeakCanary: ​     Retaining 16523886 bytes in 33489 objects
LeakCanary: ​     key = b2ebfeff-4177-4587-b7f5-e4c89bc4afaa
LeakCanary: ​     watchDurationMillis = 40425
LeakCanary: ​     retainedDurationMillis = 35424
LeakCanary: 2804 bytes retained by leaking objects
LeakCanary: Signature: 71c80305d50d16354a6bec910e7f529c72e4296
LeakCanary: ┬───
LeakCanary: │ GC Root: Local variable in native code
LeakCanary: │
LeakCanary: ├─ android.os.HandlerThread instance
LeakCanary: │    Leaking: NO (PathClassLoader↓ is not leaking)
LeakCanary: │    Thread name: 'queued-work-looper'
LeakCanary: │    ↓ HandlerThread.contextClassLoader
LeakCanary: ├─ dalvik.system.PathClassLoader instance
LeakCanary: │    Leaking: NO (ViewDataBinding↓ is not leaking and A ClassLoader is never leaking)
LeakCanary: │    ↓ PathClassLoader.runtimeInternalObjects
LeakCanary: ├─ java.lang.Object[] array
LeakCanary: │    Leaking: NO (ViewDataBinding↓ is not leaking)
LeakCanary: │    ↓ Object[].[881]
LeakCanary: ├─ androidx.databinding.ViewDataBinding class
LeakCanary: │    Leaking: NO (a class is never leaking)
LeakCanary: │    ↓ static ViewDataBinding.sReferenceQueue
LeakCanary: │                             ~~~~~~~~~~~~~~~
LeakCanary: ├─ java.lang.ref.ReferenceQueue instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 724 bytes in 30 objects
LeakCanary: │    ↓ ReferenceQueue.head
LeakCanary: │                     ~~~~
LeakCanary: ├─ androidx.databinding.ViewDataBinding$WeakListener instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 52 bytes in 2 objects
LeakCanary: │    ↓ ViewDataBinding$WeakListener.mObservable
LeakCanary: │                                   ~~~~~~~~~~~
LeakCanary: ├─ androidx.databinding.ViewDataBinding$LiveDataListener instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 16 bytes in 1 objects
LeakCanary: │    ↓ ViewDataBinding$LiveDataListener.mLifecycleOwner
LeakCanary: │                                       ~~~~~~~~~~~~~~~
LeakCanary: ╰→ com.example.packagename.fragments.InventoryFragment instance
LeakCanary: ​     Leaking: YES (ObjectWatcher was watching this because com.example.packagename.fragments.InventoryFragment
LeakCanary: ​     received Fragment#onDestroy() callback and Fragment#mFragmentManager is null)

As you can see, there are mainly 2 leaks but I'm not sure I know how to fix them.

leakcanary memory-leaks android
1 Answers

The first leaktrace shows that ShopFragment sets up a BillingClientStateListener in ShopFragment$setupBillingClient, probably by calling BillingClient#startConnection(). The BillingClientStateListener implementation in an anonymous class and has a reference to an instance of its outer class, ShopFragment. Looking at the Javadoc, it seems that you need to call BillingClient#endConnection() once you're done, i.e. when the fragment is destroyed. The billing documentation does not mention this at all so you might want to file a documentation bug.

The second leaktrace shows that the ViewDataBinding.LiveDataListener associated with the destroyed InventoryFragment is held in memory by ViewDataBinding.sReferenceQueue (see the sources here. The fact that ViewDataBinding$WeakListener is in the queue means that ViewDataBinding.WeakListener is not strongly reachable. ViewDataBinding. processReferenceQueue() is in charge of doing that, so it looks like it hasn't been called in a while. It's hard to say for sure without a heap dump, but this looks like a DataBinding library bug and you should file a ticket.

user_7036460
Related