本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Outside the Scope of Our Support

Outside the Scope of Our Support Published on October 18, 2026 A few days ago I wrote about reporting a bug to Google Disability Support. It’s a bug that kills touch exploration for every screen reader on Android until you reboot the phone. In return I was asked to turn TalkBack off and on again, clear the cache of an app I don’t use, and reboot, which is the one thing I’d already told them was the only workaround. If you haven’t read that one, Have You Tried Turning TalkBack Off and On Again? has the whole story, and this post won’t make much sense without it. There’s been more since. I’m going to go through it, because the ending is better than anything I could have made up. But I can tell you how I feel about it in four words, so I’ll get them out of the way now. Quite simply, fuck you.

“超出我们的支持范围”发布于 2026 年 10 月 18 日。几天前，我写了一篇关于向谷歌残障人士支持团队（Google Disability Support）报告漏洞的文章。这是一个会导致安卓系统上所有屏幕阅读器的触摸探索功能失效，直到重启手机才能恢复的漏洞。作为回应，他们要求我关闭再重新开启 TalkBack，清除一个我从不使用的应用程序的缓存，并重启手机——而重启恰恰是我之前告诉过他们唯一的权宜之计。如果你还没读过那篇文章，《你试过关闭再重新开启 TalkBack 吗？》里有完整的故事，没有它，这篇文章可能很难理解。此后又发生了更多事情。我打算把这些经历写出来，因为结局比我能编造出的任何情节都要精彩。但我可以用四个词来表达我的感受，所以现在就先说出来：简单来说，去你的。

Where we left it When I published the first post, I’d answered every question Google’s support team asked. I’d done every troubleshooting step they gave me, including the ones that couldn’t possibly work, and reported the results. They’d said that once I’d done that, the case could be forwarded to their internal team for further review. So I did it, and I waited to be forwarded. I didn’t only wait. The bug happened again the next morning, and this time I was ready for it. I took a full bug report while the phone was stuck. I captured every log buffer, before and after. I worked out exactly why the fake finger gets left on the screen: TouchExplorer gets itself into a dragging state with no valid pointer, tries to build an up event with no pointers in it, MotionEvent throws, the exception gets swallowed, and the up event that would have lifted the finger is never sent. I worked out why nothing short of a reboot clears it: the input dispatcher keeps the record of injected pointers in a verifier that is only ever thrown away when a display is removed, so turning accessibility off, turning every accessibility service off, even tearing down the whole input filter does nothing. I proved that on the phone. I found a way to clear it from the shell with a single cancel event, and a way for a screen reader to clear it with no special permissions at all. And then I wrote fixes, one patch for the accessibility code in frameworks/base and one for the input dispatcher in frameworks/native, and sent a summary of all of it back to the case, along with a request, again, for some way to get the files to an engineer, because their form still wouldn’t take anything that wasn’t a screenshot. That’s a root cause, a recovery method, two patches and a reproduction you can trigger on demand, all done for free, on my own time, on a phone I could only half use.

故事进展到这里：当我发布第一篇文章时，我已经回答了谷歌支持团队提出的每一个问题。我完成了他们给出的每一个故障排除步骤，包括那些根本不可能奏效的步骤，并报告了结果。他们曾说，一旦我完成了这些，案件就可以转交给他们的内部团队进行进一步审查。所以我照做了，并等待转交。我不仅仅是在等待。第二天早上漏洞再次发生，这次我做好了准备。在手机卡住时，我获取了完整的错误报告。我捕获了之前和之后的所有日志缓冲区。我准确地找出了为什么“虚拟手指”会留在屏幕上：TouchExplorer 进入了一种没有有效指针的拖拽状态，试图构建一个不包含指针的“抬起”事件，MotionEvent 抛出异常，异常被吞掉，导致本应抬起手指的事件从未发送。我还找出了为什么除了重启之外没有任何方法能解决它：输入调度程序（InputDispatcher）将注入指针的记录保存在一个验证器中，该验证器只有在显示设备被移除时才会被丢弃，因此关闭辅助功能、关闭所有辅助服务，甚至拆除整个输入过滤器都无济于事。我在手机上验证了这一点。我找到了一种通过 shell 发送单个取消事件来清除它的方法，以及一种让屏幕阅读器在没有任何特殊权限的情况下清除它的方法。然后我编写了修复程序，一个针对 frameworks/base 中辅助功能代码的补丁，另一个针对 frameworks/native 中输入调度程序的补丁，并将所有内容的摘要发回给支持团队，同时再次请求提供一种将文件发送给工程师的方法，因为他们的表单仍然只接受截图。这就是根本原因、恢复方法、两个补丁以及一个可以按需触发的复现方案，所有这些都是我免费完成的，利用我自己的时间，在一台我只能勉强使用的手机上。

The second agent The next reply came from a different agent, stepping in for the first. And I’ll be fair here, because I want to be: it was the best reply I’d had. It read like someone had actually read what I’d sent. It summarised the problem correctly, in proper terms: TouchExplorer failing to release injected pointers after an invalid dragging pointer state, with InputDispatcher rejecting the hover events that follow. It said it recognised the impact on screen reader users. It said it didn’t want to give me an unverified technical answer to my three questions, and that they needed the team responsible for those framework components. It said, finally, that it understood the troubleshooting steps had been exhausted. What it couldn’t say was whether anyone on an engineering team would look at any of it. It didn’t have an upload link, or an engineering contact. It told me to hang on to my files in case a way to send them ever turned up in the case. It was polite, honest about what it didn’t know, and it went nowhere. So I stopped waiting, and filed the bug myself.

第二位代理人：下一封回复来自另一位代理人，他接替了第一位。我在这里要公正一点，因为我愿意这样做：这是我收到过的最好的回复。读起来就像真的有人阅读了我发送的内容。它正确地总结了问题，并使用了恰当的术语：TouchExplorer 在无效的拖拽指针状态后未能释放注入的指针，导致 InputDispatcher 拒绝了随后的悬停事件。它表示承认这对屏幕阅读器用户的影响。它说不想对我的三个问题给出未经证实的专业回答，他们需要负责这些框架组件的团队来处理。最后，它表示理解故障排除步骤已经穷尽。但它无法说明工程团队是否会有人查看这些内容。它没有提供上传链接，也没有提供工程联系人。它告诉我保留好文件，以防案件中出现发送文件的方法。回复很礼貌，对自己不知道的事情也很诚实，但它毫无进展。所以我不再等待，自己提交了漏洞报告。

102 minutes Android has a public issue tracker. Anyone can file on it, and it has an Android Accessibility component. I wrote up everything: device and build, the natural trigger and a reliable reproduction from the shell, what happens in the logs during the trigger, why only a reboot recovers, the on-device test results, the workaround a screen reader can use, and both patches, with the reproduction helper attached. I filed it at 08:17 on a Friday morning, and sent the link to the support case so they could attach it and pass it on. At 09:59 it was assigned to a Google engineer, with a comment saying it had been passed to the development team. That’s an hour and forty-two minutes. Disability Support had had the case for four days by then, and in four days it hadn’t got as far as an engineer. The tracker did it before I’d finished my second coffee. It’s still moving. At the time of writing it’s marked as assigned, severity S2, priority P2. It’s on five hotlists. 114 people have given it a +1, and one of them commented that this is something that has “continued to plague users”, and that it’s been reported on forums like Blind Android Users. So it isn’t just my phone and it isn’t just me. Blind people have been hitting this for a long time, rebooting their phones, and getting nowhere, because the route Google gives them goes nowhere.

102 分钟：安卓有一个公开的问题追踪器。任何人都可以提交，并且它有一个“安卓辅助功能”组件。我写下了所有内容：设备和版本、自然触发方式以及可靠的 shell 复现方法、触发期间日志中发生的情况、为什么只有重启才能恢复、设备上的测试结果、屏幕阅读器可以使用的权宜之计，以及两个补丁，并附上了复现辅助工具。我在周五早上 08:17 提交了报告，并将链接发送给支持团队，以便他们可以将其附上并转交。09:59，它被分配给了一位谷歌工程师，并附有一条评论，称其已转交给开发团队。这只用了 1 小时 42 分钟。当时残障人士支持团队已经处理这个案件四天了，四天时间里，他们甚至没能把问题转给工程师。而追踪器在我喝完第二杯咖啡之前就完成了。它仍在进展中。在撰写本文时，它被标记为“已分配”，严重程度为 S2，优先级为 P2。它出现在五个热门列表中。114 人给它点了 +1，其中一人评论说，这是一个“持续困扰用户”的问题，并且已经在“盲人安卓用户”（Blind Android Users）等论坛上被报告过。所以这不仅仅是我的手机问题，也不仅仅是我个人的问题。盲人用户长期以来一直遇到这个问题，不断重启手机却毫无进展，因为谷歌给他们的路径根本走不通。

Outside our scope Then, late on Saturday night, Disability Support replied for the last time. They’d reviewed my case with their internal team, it said, and the team had clarified that Google Disability Support “primarily assists with troubleshooting existing accessibility features and assistive technologies within Google products, including unexpected behavior or broken functionality.” Read that sentence again, because it’s a perfect description of what I reported. Touch exploration is an existing accessibility feature. It’s built into Android, which is a Google product. TalkBack, which it breaks along with every other screen reader, is a Google product. Touch exploration stopping system-wide until you reboot is, by any definition anyone could come up with, broken functionality. I didn’t just fall within their scope. I was the textbook example of it. But the very next paragraph explai

超出我们的支持范围：周六深夜，残障人士支持团队进行了最后一次回复。回复称，他们与内部团队审查了我的案件，团队澄清说，谷歌残障人士支持团队“主要协助排查谷歌产品中现有的辅助功能和辅助技术，包括意外行为或损坏的功能。”请再读一遍这句话，因为它完美地描述了我所报告的内容。触摸探索是一项现有的辅助功能。它内置于安卓系统中，而安卓是谷歌的产品。TalkBack 以及它所破坏的其他所有屏幕阅读器，都是谷歌的产品。触摸探索在全系统范围内停止工作直到重启，无论从谁的定义来看，这都是“损坏的功能”。我不仅在他们的支持范围内，我简直就是教科书般的案例。但紧接着的下一段解释了……