IssueTracker

The crash started from content capture.

So getting more and more crashes from this as more and more pixel users have updated.

What is needed to have this investigated and fixed ?

Ok so I have a way to reproduce and there's a race somewhere with that capture call .... But I have no idea what is that capture things and when it runs.

On SDK 12L there's

    public void setText(CharSequence text, BufferType type) {
        setText(text, type, true, 0);

        if (mCharWrapper != null) {
            mCharWrapper.mChars = null;
        }
    }

That set the array to null.

So when reaching CharWrapper (Called from TextUtils.writeToParcel)

        public String toString() {
            return new String(mChars, mStart, mLength);
        }

We end up with java.lang.NullPointerException: Attempt to get length of null array since the array is null.

Sounds to me that allowing and putting null in a value and reading without check is an SDK issue that should be fixed, but since it's all internal it would be nice that the race introduced on latest Pixel was looked into also to stop those crashes.

I would have fixed that by reflexion but unfortunately:

Accessing hidden field Landroid/widget/TextView$CharWrapper;->mChars:[C (max-target-o, reflection, denied)

So I'm stuck.

This happens sometimes for still to be discovered reason when updating the text from a child of AppCompatTextView (With emoji disabled)

One way to force the issue is from onSizeChanged to mainHandler.post { text = "AAA" }

I guess no proper ellipsis for Pixel phones for now.

Ok so after some fresh air, this is the same issue as emoji but triggered by my code.

Once a TextView have it's text set via setText(char[] text, int start, int len) it must not be set again via any other setText methods as the mCharWrapper reset is wrongly done and will fail on some calls like the .toString().

This was the cause of EmojiCompat crashes https://issuetracker.google.com/issues/206859724 that was fixed but not fully if there was the need to actually replace the text with proper emojis.

Don't know what have changed on Pixels to trigger this now and not before, but this is definitively an SDK error.

Of course all the setText are final so can't be fixed on child classes. For my case I'll stop using the char array version for Pixels for my ellipsis version. But this is something that will bite anyone using EmojiCompat and char arrays when the emoji do update the text.

So it seems that the code path also triggers memory leaks by keeping the spannable (Causing leaks via ClickableSpan and the lambdas)

┬───
│ GC Root: Global variable in native code
│
├─ android.content.pm.BaseParceledListSlice$1 instance
│    Leaking: UNKNOWN
│    Retaining 216.5 kB in 3312 objects
│    Anonymous subclass of android.os.Binder
│    ↓ BaseParceledListSlice$1.this$0
│                              ~~~~~~
├─ android.content.pm.ParceledListSlice instance
│    Leaking: UNKNOWN
│    Retaining 216.0 kB in 3311 objects
│    ↓ BaseParceledListSlice.mList
│                            ~~~~~
├─ java.util.ArrayList instance
│    Leaking: UNKNOWN
│    Retaining 216.0 kB in 3310 objects
│    ↓ ArrayList[104]
│               ~~~~~
├─ android.view.contentcapture.ContentCaptureEvent instance
│    Leaking: UNKNOWN
│    Retaining 1.2 kB in 18 objects
│    ↓ ContentCaptureEvent.mNode
│                          ~~~~~
├─ android.view.contentcapture.ViewNode instance
│    Leaking: UNKNOWN
│    Retaining 1.1 kB in 17 objects
│    ↓ ViewNode.mText
│               ~~~~~
├─ android.view.contentcapture.ViewNode$ViewNodeText instance
│    Leaking: UNKNOWN
│    Retaining 688 B in 13 objects
│    ↓ ViewNode$ViewNodeText.mText
│                            ~~~~~
├─ android.text.SpannableStringBuilder instance
│    Leaking: UNKNOWN
│    Retaining 640 B in 12 objects
│    ↓ SpannableStringBuilder.mSpans
│                             ~~~~~~
├─ java.lang.Object[] array
│    Leaking: UNKNOWN
│    Retaining 36 B in 1 objects
│    ↓ Object[0]
│            ~~~
├─ org.leetzone.android.yatsewidget.helpers.media.
│  MediaHelper$makeCastClickable$1$1 instance
│    Leaking: UNKNOWN
│    Retaining 40 B in 2 objects
│    Anonymous subclass of android.text.style.ClickableSpan
│    ↓ MediaHelper$makeCastClickable$1$1.$clickAction
│                                        ~~~~~~~~~~~~
├─ org.leetzone.android.yatsewidget.ui.fragment.
│  InfoLoaderFragment$updateView$15 instance
│    Leaking: UNKNOWN
│    Retaining 16 B in 1 objects
│    Anonymous subclass of kotlin.jvm.internal.Lambda
│    ↓ InfoLoaderFragment$updateView$15.this$0
│                                       ~~~~~~
╰→ org.leetzone.android.yatsewidget.ui.fragment.InfoLoaderFragment instance
​     Leaking: YES (ObjectWatcher was watching this because org.leetzone.
​     android.yatsewidget.ui.fragment.InfoLoaderFragment received
​     Fragment#onDestroy() callback and Fragment#mFragmentManager is null)
​     Retaining 16.1 kB in 452 objects
​     key = ad4a77e9-1e59-477b-b4b1-e1d1c8ed963d
​     watchDurationMillis = 6693
​     retainedDurationMillis = 1687

ClickableSpan is known to leak from the lambdas, and unfortunately there's not many options there (aside: this is why we haven't yet added the same feature to Compose, we're designing the lambdas out).

Taking a look at the other issue

Looks like it's a NPE that's been possible since API 1, but an easy fix

Yes fix is easy, set the wrapper to null not just the buffer on the reset.

About the leak, the question is more what was changed on Pixels to that contentcapture (don't know what it's supposed to do) things that now triggers it (and also trigger this bug) I do clean the spannable in ondestroy and did not face leaks before.

That I don't know - can you make a separate bug with a repro for that so it can be passed to content capture?

Based on both of these bugs, I'm getting the impression that something is calling .getText() and storing it longer than expected.

I'm not sure I'll have enough time to build a repro, currently trying to find time to build repros for Compose and some nasty mem leaks :(

And well this issue was first assigned to content capture and was just ignored, so no high hopes, as often if I can't ping the proper guy issues falls in limbs.

Ack. I'll make an internal bug and try to chase it down. I've fixed the NPE in U, and am trying to hotpatch it into a quarterly release.

Thanks for the incredibly high quality bug reports!

Thanks,

Sean

Thanks to you for answering on the ping on the other one and previous interaction :)

It's most of the time a pleasure to work with final target Googlers, but after 10 years bugs reports it's often incredibly hard to reach the good one or even be triaged.

About the fix I have a doubt will, compiling with the future SDK embed the fix and so backport on all Android, or is the SDK just a wrapper and it will require the actual OS bump on devices?

The fix I made is in TextView.java (exactly as you suggested). The NPE has been possible since API 1, and is pretty easy to trigger. The new behavior is in content capture, but we could fix it in TextView so triaged it as priority.

It will require a OS bump on devices to apply.

We do triage all bugs that come in, though we can't reply to every one. Recent regressions are prioritized on Text, FYI. So if you see something start breaking in a new release definitely mention that.

Bugjuggler: b/239080094

Bugjuggler: b/239080094

Sorry about email spam there.

ag/19267003 fixes this crash.

Adding content capture in case any other CLs are inbound from. Please assign this back to me if no CL is pending from b/239080094.

Thanks Sean

Cherry-pick to tm-qpr-dev: ag/19340644

So the crash is fixed but we still have a memory leak? Sean, let's keep b/239080094 to track the leak fix and close this bug out for the crash.

Makes sense to me. Thanks!