I didn't think there'd be a third one of these. When Google Disability Support told me my bug report was outside the scope of their support, it read like a door being closed, and I wrote about it on that basis. A bug that kills touch exploration for every screen reader on Android until you reboot had, according to their internal team, nothing to do with a team whose job is helping disabled people with broken accessibility features. I was pointed at the developer documentation and a community forum, and that was that.
Then, in the early hours of this morning, another email arrived on the same case. And what do you know. It's back in scope.
The apology
It opens with an apology. A sincere one, it says, "for the inconvenience you experienced during the initial interactions with our support team." And then it says something I genuinely didn't expect to read from Google Disability Support, or from anybody at Google, ever: that I was "entirely right" that someone who has investigated a system-level issue and provided technical evidence and patches "should not have to face repetitive troubleshooting steps or hurdles just to get an accessibility bug in front of the right team."
That's almost word for word what I wrote to them, and almost word for word what I've written here, twice. Which is nice to see. It would have been a lot nicer to see a week ago, before the cache clearing, before the out-of-scope verdict, before two blog posts, and before a public issue tracker thread full of people who aren't happy about it.
Because I want to be clear about what changed between Saturday night and this morning, and it wasn't the bug.
What changed
On Saturday night the team, having reviewed my case internally, said that "custom Android framework patches fall outside the scope of our support."
This morning, the same team says that their "internal engineering and accessibility teams have re-evaluated your report specifically given that this issue also impacts TalkBack," and that they're "actively continuing the investigation and would like to proceed further."
Specifically given that this issue also impacts TalkBack.
I told them it affected TalkBack in my original report, in the second paragraph. I told them again in my first reply, with version numbers: TalkBack 16, 16.1, 16.2 and 17.0. I told them again in my second, and my third, and it's in the first line of the description on the issue tracker. The very first email they ever sent me asked whether it happened with official TalkBack, and I said yes. There is no version of this case, at any point in its history, in which they didn't know that this affects TalkBack.
So it isn't new information that's moved them. Here's what is new since Saturday night.
I published a second post, about being told it was out of scope, and about what that same answer would mean for a blind user who isn't a developer.
The issue on the tracker has gone from 114 +1s to 139.
Somebody has reproduced it on a Pixel 10 running Android 17, which settles the question of whether this is a Samsung problem. It isn't. It's Google's phone, Google's operating system, Google's screen reader.
And somebody else has left a comment on Google's own issue tracker, in capitals and with a lot of exclamation marks, telling them to fix the bug and to fix their support while they're at it, because support should be filing the bugs, not the users, and 99% of users will have no idea how to.
Make of that what you will. I know what I make of it. A team doesn't go from "outside our scope" to a sincere apology and "you were entirely right" in under 48 hours because it reread an email it had already read five times. It does it because somebody further up noticed the noise. This is damage control. And damage control is about the damage to the company's reputation, not the damage to the users.
What they want now
So, now that it's in scope, what do they want? Two things.
The first is a bug report, taken with TalkBack's logging set to verbose. The email gives me the steps. Open Settings, go to Accessibility, open TalkBack's settings, find Advanced, then Developer, then Log, and pick Verbose. Then, to generate the bug report: go to About phone, double-tap Build number seven times until it says I'm now a developer, go into Developer options, turn on USB debugging, turn on the bug report shortcut, restart the phone, recreate the issue, open the power menu and choose Bug report. Then attach it to the email.
Let's take that apart, because it's the same template-shaped thinking all over again, just politer.
I already have a bug report taken while the phone was stuck. I told them so on the 15th, and listed it under "Evidence available", along with every log and dump I'd captured. I asked how to send it to them. Nobody answered that question in two emails. Now they want me to make another one.
I don't need to be told how to become a developer by tapping on my build number. I found this bug with adb. I wrote a patch for the input dispatcher. They have it. It's attached to the issue that they say they're linking this case to.
"Restart the phone and recreate the issue." The bug is cleared by restarting the phone. It can't be recreated on purpose by touching the screen; it happens when it happens, which I've said from the first email. I can reproduce it reliably from a shell, and I wrote exactly how in the issue, but that's not what they're asking for, because the instructions weren't written for this case. They were written for every case.
Verbose TalkBack logging won't show the bug. I've been saying for a week that the bug isn't in TalkBack. It's in system_server, in TouchExplorer and the input dispatcher, which is exactly why turning TalkBack off and on didn't fix it. TalkBack's own log can only tell you what TalkBack sees, and what TalkBack sees is nothing, which is the symptom, not the cause. The email even says it wants this "to help them pinpoint the behavior directly within TalkBack." It isn't within TalkBack. It never was. That's the whole point.
And attach it to the email. My bug report from the 15th is 37 megabytes. Gmail's attachment limit is 25. This is the same team whose web form wouldn't let me submit a text file. They have now gone from not being able to accept my logs at all to asking me to email them a file that their own email service won't send.
On the subject of that form, someone left a comment on the issue suggesting workarounds, and I want to be fair to it, because it was kindly meant. One idea was to paste the text of the logs into the "Problem(s) encountered" field of Google's "Report an Issue Related to Accessibility" form, which, through trial and error, they'd found would take up to 32,768 characters. The other was that the Disability Support chat had let them attach a text file, though they hadn't tested whether it would actually send.
For the record, here's what happened when I tried. I went straight to Disability Support, attached a text file, and the submit button simply became unavailable. I also had four files to send, and the form would only take one at a time. If it now accepts text files and leaves the submit button working, that's changed very recently, in the last few days, and silently.
But think about the paste workaround for a second, because it says everything. My three filtered log captures come to about 1.8 megabytes of text. At 32,768 characters a go, that's 56 separate submissions of the same form, each one a numbered fragment, and that's before the input and accessibility dumps, which would be about seven more. The full bug report they're now asking for is 37 megabytes. At 32 KB a paste, that's more than 1,100 submissions.
Nobody should have to work that out. A blind user trying to send logs to the disability support team should not be relying on a stranger on an issue tracker who's measured the character limit of a form field by trial and error. It's a good-hearted suggestion, and the fact that it's the best available option is an indictment of the people who built the form.
There's one more line in that section that's worth quoting exactly, because I think it explains more than anything else in the email. Right after the bug report instructions, it says:
"If the user is still having difficulties, you may also share this helpful YouTube video on how to submit a bug report."
If the user. You may also share.
That isn't written to me. That's written to the agent. It's a note from a script, an instruction about what to do with a customer, pasted straight into the email to the customer without anyone reading it. In an email whose first paragraph is an apology for treating me like I was being run through a script.
The screen recording
The second thing they want is "a screen recording, if possible, that clearly demonstrates the issue with touch interactions visible so the team can observe the pointer behavior directly."
I need to explain why this one made me laugh out loud.
The stuck pointer isn't a real finger. It's a fake one, injected by the system on device -1, which exists only as an entry in the input dispatcher's internal records. It doesn't draw anything. Turning on the developer option that shows touches won't show it, because that option shows real touches from the real touchscreen, and the stuck pointer never came from the touchscreen. There's nothing to see.
And what does the bug actually look like? A blind person drags a finger over the screen, and the screen reader says nothing. The symptom is silence. A screen recording of this bug is a video of a working phone with a finger moving across it, while nothing happens. And it's being requested from a blind person, by Google Disability Support, so that a team can "observe the pointer behavior directly."
They can observe the pointer behaviour directly. It's in the dumpsys output in my original report, the first thing I sent them: Touching pointer IDs by device: DeviceId(-1), pointer 3. It's in the issue. It's in the log lines rejecting every hover event, over a thousand times per capture, each one naming the stuck pointers. That's what directly observing it looks like. A video of a hand would tell them less than any of that.
The link
And finally, there's this: "Regarding the public bug you filed on the Android issue tracker, please rest assured that we are linking this support case directly to that issue so that your diagnostic evidence, reproduction steps, and patches stay unified for the engineering and input teams."
That's the thing I asked for. It's the only thing I asked for, in my last email, on the 16th, and it's the first time anyone at Disability Support has acknowledged that the issue exists. The email before this one, on Saturday, didn't mention it at all, and sent me to a forum instead.
So yes. Four days after I gave them the link, after being told the case was out of scope, after two blog posts, after 139 +1s and a Pixel reproduction, the case is being linked to the issue. Good.
But think about what that sentence means. The engineering teams already have the issue. It was assigned to a Google engineer 102 minutes after I filed it, on Friday morning. The evidence, the reproduction and the patches are already unified, on the issue, because I put them there. Linking the support case to it doesn't help the engineers find anything. It helps Disability Support be able to say it was involved.
And if the engineers working on that issue want a bug report, or anything else, there's a comment box on it. They can ask me there, and I'll see it, and I'll answer. That's what it's for.
Why this is worse, not better
It'd be easy to read this email as a win. They apologised, they said I was right, they reversed the out-of-scope decision, and they're linking the case. If you squint, the system worked.
It didn't. Every one of those things happened because of public pressure, not because of the report. Nothing in my case changed between Saturday night and this morning. The bug didn't change, the evidence didn't change, and the fact that it affects TalkBack, which is now apparently the reason it's in scope, didn't change either. What changed was how many people were watching.
Which brings me back to the person I wrote about last time. The blind user who isn't a developer, who reports "my phone stopped reading when I touch it, swiping still works, restarting fixes it." That person doesn't have a blog. They don't have readers, or the ability to file a report on the issue tracker that gets a Pixel reproduction and a hundred-odd +1s in a weekend. They don't get the apology. They get the cache clearing and the reboot, and then, if they push, they get "outside the scope of our support". And then they get nothing, because nobody is watching.
If the only way a disabled person gets taken seriously by Google Disability Support is by embarrassing Google in public, then it isn't a support channel. It's a reputation management channel with a help desk bolted to the front.
I'm glad the bug is with engineers. I'm glad the case is linked. I'll believe things have changed when the next person to report something like this gets this morning's email on the first day, instead of the fifth, without needing to write three blog posts to get it.
The issue, if you've hit this bug and want to add a +1 or tell them which phone you've seen it on: TouchExplorer leaves injected pointers down; InputDispatcher then rejects all touch exploration events until reboot.