Leakcanary: Android System Autofill Leak

Created on 10 Sep 2019  ·  6Comments  ·  Source: square/leakcanary

(Reopen of #776 since it appears closed issues are not monitored)

LeakTrace information

ApplicationLeak(className=com.myapp.Activity, leakTrace=
┬
├─ android.app.assist.AssistStructure$SendChannel
│    Leaking: UNKNOWN
│    GC Root: Global variable in native code
│    ↓ AssistStructure$SendChannel.mAssistStructure
│                                  ~~~~~~~~~~~~~~~~
├─ android.app.assist.AssistStructure
│    Leaking: UNKNOWN
│    ↓ AssistStructure.mWindowNodes
│                      ~~~~~~~~~~~~
├─ java.util.ArrayList
│    Leaking: UNKNOWN
│    ↓ ArrayList.elementData
│                ~~~~~~~~~~~
├─ java.lang.Object[]
│    Leaking: UNKNOWN
│    ↓ array Object[].[0]
│                     ~~~
├─ android.app.assist.AssistStructure$WindowNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$WindowNode.mRoot
│                                 ~~~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[0]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[1]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[0]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[0]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[5]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mText
│                               ~~~~~
├─ android.app.assist.AssistStructure$ViewNodeText
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNodeText.mText
│                                   ~~~~~
├─ android.text.SpannableStringBuilder
│    Leaking: UNKNOWN
│    ↓ SpannableStringBuilder.mSpans
│                             ~~~~~~
├─ java.lang.Object[]
│    Leaking: UNKNOWN
│    ↓ array Object[].[0]
│                     ~~~
├─ com.myapp.spans.ClickSpan
│    Leaking: UNKNOWN
│    ↓ ClickSpan.listener
│                ~~~~~~~~
├─ com.myapp.MyFragment
│    Leaking: YES (Fragment#mFragmentManager is null)
│    ↓ MyFragment.textBox
├─ com.myapp.views.MyTextView
│    Leaking: YES (MyFragment is leaking and View.mContext references a destroyed activity)
│    mContext instance of com.myapp.Activity with mDestroyed = true
│    View#mParent is set
│    View#mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 1
│    ↓ MyTextView.mContext
╰→ com.myapp.Activity
​     Leaking: YES (MyTextView is leaking and Activity#mDestroyed is true and ObjectWatcher was watching this)
​     key = 61f611e3-b757-4c34-9a4f-d5369ba35865
​     watchDurationMillis = 4924
​     retainedDurationMillis = -89
, retainedHeapByteSize=124)

This is on OnePlus 7 Pro (GM1913) running Android 9.

leak
Source
picture matejdro

Most helpful comment

You can add your own custom "library leak patterns", and those could possibly match your own code. However LeakCanary has to analyze the heap to know what each leak is about, so you'll pay the cost anyway, it's only a classification difference. You're better off actually fixing that leak ;) . Even android framework leaks can be fixed with enough imagination and hackery.

picture pyricau on 27 Nov 2019
👍2

All 6 comments

I've been using version 2.0-beta-5 which should include the fix for this, however I'm still having LeakCanary report the following:

Known leak pattern: instance field android.app.assist.AssistStructure$ViewNodeText#mText
Description: AssistStructure (google assistant / autofill) holds on to text spannables on the screen. TextView.ChangeWatcher and android.widget.Editor end up in spans and typically hold on to the view hierarchy
1347879 bytes retained
┬
├─ android.app.assist.AssistStructure$SendChannel
│    Leaking: UNKNOWN
│    GC Root: Global variable in native code
│    ↓ AssistStructure$SendChannel.mAssistStructure
│                                  ~~~~~~~~~~~~~~~~
├─ android.app.assist.AssistStructure
│    Leaking: UNKNOWN
│    ↓ AssistStructure.mWindowNodes
│                      ~~~~~~~~~~~~
├─ java.util.ArrayList
│    Leaking: UNKNOWN
│    ↓ ArrayList.elementData
│                ~~~~~~~~~~~
├─ java.lang.Object[]
│    Leaking: UNKNOWN
│    ↓ array Object[].[0]
│                     ~~~
├─ android.app.assist.AssistStructure$WindowNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$WindowNode.mRoot
│                                 ~~~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[0]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[0]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[1]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[0]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[0]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mChildren
│                               ~~~~~~~~~
├─ android.app.assist.AssistStructure$ViewNode[]
│    Leaking: UNKNOWN
│    ↓ array AssistStructure$ViewNode[].[6]
│                                       ~~~
├─ android.app.assist.AssistStructure$ViewNode
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNode.mText
│                               ~~~~~
├─ android.app.assist.AssistStructure$ViewNodeText
│    Leaking: UNKNOWN
│    ↓ AssistStructure$ViewNodeText.mText
│                                   ~~~~~
├─ android.text.SpannableStringBuilder
│    Leaking: UNKNOWN
│    ↓ SpannableStringBuilder.mSpans
│                             ~~~~~~
├─ java.lang.Object[]
│    Leaking: UNKNOWN
│    ↓ array Object[].[0]
│                     ~~~
├─ RedactedActivity$StyleableClickSpan
│    Leaking: UNKNOWN
│    ↓ RedactedActivity$StyleableClickSpan.onClick
│                                        ~~~~~~~
├─ RedactedTextViewExtensionsKt$sam$java_lang_Runnable$0
│    Leaking: UNKNOWN
│    Anonymous class implementing java.lang.Runnable
│    ↓ TextViewExtensionsKt$sam$java_lang_Runnable$0.function
│                                                    ~~~~~~~~
├─ RedactedFragment$onViewCreated$3
│    Leaking: UNKNOWN
│    Anonymous subclass of kotlin.jvm.internal.Lambda
│    ↓ RedactedFragment$onViewCreated$3.this$0
│                                    ~~~~~~
╰→ RedactedFragment
​     Leaking: YES (Fragment#mFragmentManager is null and ObjectWatcher was watching this)
​     key = f0834154-b892-4b6e-a0ba-3b624b675fba
​     watchDurationMillis = 5401
​     retainedDurationMillis = 389


METADATA

Build.VERSION.SDK_INT: 28
Build.MANUFACTURER: Google
LeakCanary version: 2.0-beta-5
App process name: redacted
Analysis duration: 24689 ms

This is on an API 28 emulator. Is there a reason why it's still being reported?

martino2k6 picture martino2k6 on 26 Nov 2019

In the logs, you see:

Leaks coming from the Android Framework or Google libraries.

and in the trace you pasted, at the top:

Known leak pattern: instance field android.app.assist.AssistStructure$ViewNodeText#mText
Description: AssistStructure (google assistant / autofill) holds on to text spannables on the screen. TextView.ChangeWatcher and android.widget.Editor end up in spans and typically hold on to the view hierarchy

This is still being reported because leakcanary cannot fix leaks for you.

pyricau picture pyricau on 26 Nov 2019

Ah, so AndroidReferenceMatchers fills in details for _known_ leaks. It doesn't ignore them when they happen. I think I misunderstood it's purpose! Thanks.

martino2k6 picture martino2k6 on 26 Nov 2019
👍1

Yep! What made you think it would ignore them / what do you think we could do to clarify this confusion for others as well?

pyricau picture pyricau on 26 Nov 2019

I suppose my thinking was that if it is a known platform memory leak then there is no use in reporting it, as the app will likely not be able to fix the issue. Although in hindsight it may be able to do something else to mitigate/avoid it, so still worth showing.

Looking at https://square.github.io/leakcanary/api/shark-android/shark/-android-reference-matchers/ it's clearer now, but I only found this after I posted my first comment. This page explains the difference between known and ignored (false positives?) leaks and I think that makes general sense. I think this is more a case of RTFM on my side.

That said, let's say I have a particular case where we can't avoid this leak and it happens each time we go through a specific flow in the app, which ends up being an annoyance during development. Is there a way to ignore it? Is this actually even a good idea?

martino2k6 picture martino2k6 on 27 Nov 2019

You can add your own custom "library leak patterns", and those could possibly match your own code. However LeakCanary has to analyze the heap to know what each leak is about, so you'll pay the cost anyway, it's only a classification difference. You're better off actually fixing that leak ;) . Even android framework leaks can be fixed with enough imagination and hackery.

pyricau picture pyricau on 27 Nov 2019
👍2
Was this page helpful?
0 / 5 - 0 ratings

Related issues

hidroh picture hidroh  ·  3Comments
edgelv34 picture edgelv34  ·  7Comments
msfjarvis picture msfjarvis  ·  6Comments
devism picture devism  ·  6Comments
pyricau picture pyricau  ·  4Comments