「超出我们的支持范围」：Google 无障碍支持为什么送不出一个 bug 报告

几天前我写过一篇，讲的是向 Google 无障碍支持团队报 bug 的经历。这个 bug 会让 Android 上所有屏幕阅读器的触摸浏览失效，除非重启手机。而对方的回应是让我把 TalkBack 关掉再打开、清除一个我根本不用的应用的缓存，然后重启——重启这件事我一开始就说过，是唯一的临时解法。如果你还没看过那篇，完整经过在《你试过把 TalkBack 关掉再打开吗？》里，没读的话这篇会看不太明白。

之后又发生了不少事。我打算一件件讲，因为结局比我编得出来的任何东西都精彩。不过我对这件事的感受四个字就能说完，索性先说了吧。

很简单：去你妈的。

上次说到哪

发第一篇的时候，Google 支持团队问的每个问题我都答了。他们给的每一步排查我都做了，包括那些根本不可能有用的，然后把结果报了回去。他们说过，等我做完这些，案子就可以转给内部团队进一步审查。于是我做了，然后等着被转交。

我也不只是等。第二天早上 bug 又出现了，这次我早有准备。手机卡死的时候，我抓了一份完整的 bug report。前后每个日志缓冲区我都留了。我弄清楚了那个假手指为什么会被留在屏幕上：TouchExplorer 在没有任何有效指针的情况下把自己弄进了拖拽状态，试图构造一个不含任何指针的 up 事件，MotionEvent 抛出异常，异常被吞掉，那个本该抬起手指的 up 事件就永远发不出去。我也弄清楚了为什么除了重启什么都清不掉它：输入分发器把注入指针的记录保存在一个 verifier 里，而这个 verifier 只有在显示器被移除时才会被丢弃，所以关掉无障碍、关掉所有无障碍服务、甚至拆掉整个 input filter，都无济于事。这些我都在手机上验证过了。我还找到了一种从 shell 用一个 cancel 事件清除它的办法，以及一种让屏幕阅读器在完全不需要特殊权限的情况下清除它的办法。然后我写了修复，一个补丁针对 frameworks/base 里的无障碍代码，一个针对 frameworks/native 里的输入分发器，把这一切的摘要发回了案子，同时再次请求给我一个能把文件交给工程师的途径，因为他们那个表单仍然只收截图，别的一概不收。

这就是根本原因、一种恢复方法、两个补丁，外加一个随时可以触发的复现步骤，全部免费完成，用的是我自己的时间，用的还是一部我只能勉强操作的手机。

第二个客服

下一条回复来自另一位客服，他接手了前一个的工作。这里我得说句公道话，因为我也想公道：这是我收到过的最好的一条回复。读起来像是有人真的看了我发过去的内容。他用准确的术语正确地概括了问题：TouchExplorer 在进入无效的拖拽指针状态后未能释放注入的指针，随后 InputDispatcher 拒绝了随之而来的悬停事件。他说他明白这对屏幕阅读器用户的影响。他说他不想就我的三个问题给我一个未经核实的技术答复，这些问题需要由负责那些框架组件的团队来回答。最后他说，他明白排查步骤已经穷尽了。

他没法说的是，工程团队里究竟有没有人会去看这些东西。他没有上传链接，也没有工程方面的联系人。他让我把文件留着，说不定哪天案子里会出现一个发送它们的途径。他礼貌，对自己不知道的事也坦诚，但毫无下文。

于是我不再等了，自己去提了 bug。

102 分钟

Android 有一个公开的问题追踪器。任何人都能在上面提交，而且上面有 Android Accessibility 这个组件。我把所有东西都写了进去：设备和版本、自然触发方式以及一套从 shell 出发的可靠复现步骤、触发期间日志里发生了什么、为什么只有重启才能恢复、设备上的测试结果、屏幕阅读器可以采用的变通办法，还有两个补丁，并附上了复现用的辅助脚本。我在一个周五早上的 08:17 提交了它，并把链接发到支持工单里，让他们可以附上去并转交。

09:59，它被指派给了一位 Google 工程师，附有一条评论说已经转给了开发团队。

一小时四十二分钟。到那时，Disability Support 已经拿着这个工单四天了，而四天里它都没能走到工程师那一步。追踪器在我第二杯咖啡还没喝完的时候就做到了。

它还在推进。写这篇文章的时候，它的状态是已指派，严重程度 S2，优先级 P2。它被列进了五个 hotlist。114 个人给它点了 +1，其中一位评论说，这个问题“一直在困扰用户”，Blind Android Users 之类的论坛上也有人报过。所以这不只是我的手机，也不只是我一个人。盲人用户碰上这个问题已经很久了，重启手机，然后毫无进展，因为 Google 给出的路径根本走不通。

不在我们的支持范围内

然后，周六深夜，Disability Support 最后一次回复了。

邮件说，他们已和内部团队一起复核了我的案例，团队澄清了 Google Disability Support“主要协助排查 Google 产品内现有无障碍功能和辅助技术的故障，包括异常行为或功能失效。”

把这句话再读一遍，因为它精确地描述了我报告的问题。触摸浏览是一项现有的无障碍功能。它内置于 Android，而 Android 是 Google 的产品。TalkBack 也是 Google 的产品，这个问题会让它连同其他所有屏幕阅读器一起失效。触摸浏览在整个系统范围内停止工作、直到重启才恢复——按任何人的定义，这都属于功能失效。我不只是落在他们的支持范围内，我就是那个教科书式的例子。

但紧接着的下一段又说，“技术开发、自定义无障碍服务编码以及自定义 Android 框架补丁不在我们的支持范围内”，所以他们无法审阅这些补丁，也无法确认我提出的任何框架修复。

我从没要求 Disability Support 审阅补丁。我要求他们做的——到现在已经是第四次了——是把一份 bug 报告转交给代码的负责人，并给我一个把日志发给他们的途径。补丁是提供给工程团队的，因为修复本来就该这么处理：交到能用上它的人手里。“自定义无障碍服务编码”我猜指的是 Backtalk，而这和这个 bug 毫无关系，这一点我在第一封邮件里说过，第二封说过，第三封也说过。这个 bug 是在 TalkBack 上出现的。Google 的 TalkBack，跑在 Google 的 Android 上，用的是 Google 的触摸浏览。

我做得越多，案子就越被推得偏离他们的职责范围。带着日志报 bug，对方让你清缓存。你证明缓存与此无关，对方又说你得先自己排查。你排查完、找到原因、写好修复，对方却说修 bug 不归他们管。这个循环里自始至终没有任何一步是把报告转给工程师的，也永远不会有。只是我一直还在找那一步。

然后那封回信给我发了几个链接。Android Developers 的无障碍指南——那是写给开发者、教他们让自己的应用兼容屏幕阅读器的文档，跟输入分发器里的一个 bug 的相关程度，大概和一本菜谱差不多。一页额外的无障碍资源。还有 Android Accessibility Help Community，信里说，我可以在那里“分享你的发现、讨论触摸探索行为，并与其他无障碍开发者交流”。那是个论坛。是其他用户，免费地互相回答问题——这个 bug 多年来一直就是这样处理的，也正是它至今还在的原因。

整封邮件里没有一个字提到 issue tracker。我上一条消息里刚把链接发给了他们。他们写这封信的时候，那个 issue 已经在一个工程师手上放了一天半。审我案子的人，要么没看到链接，要么看到了，然后认定：对一个 bug 已经指派给 Google 工程师的盲人开发者，最该说的话是去一个求助论坛上发帖。

最后收尾的那句话，把一切都说明白了：“如果你遇到涉及 Google 无障碍功能的具体功能故障，或希望提出改进无障碍体验的建议，欢迎再次联系我们。”

我联系了。整件事就是这个。

这说明什么

我在第一篇里说过，我不怪这些客服，现在依然不怪。第二个客服确实还不错，我猜最后那封邮件根本就不是他写的：读起来像是内部团队的决定，传下来让一线的人署名。这些人是在一个系统里做事，而系统决定了他们能做什么。

这套系统到底是干什么用的，我现在算是从头到尾看明白了。

Google Disability Support 是一个帮助台，负责解答 Google 无障碍功能的使用问题。你找不到某个设置，它帮你找。TalkBack 语速太快，它告诉你在哪里调慢。它也许确实擅长这些，这本身有价值。但它不是向 Google 报告无障碍 bug 的渠道，也不可能成为这样的渠道，因为顺着它走，最终到不了任何能修 bug 的人手里。盲人用户告诉它某个功能坏了，它能教对方怎么关掉再打开；等这一招也用完了，它只能说自己管不了，然后把用户打发到论坛去。

而支持渠道存在的唯一理由，恰恰是它不做的那件事：接下一份故障报告，送到能修的人面前。

现在设想一下，遇到问题的不是我

很容易把这一切读成一个有圆满结局的故事。bug 最终到了工程师手里，而我是完全绕开 Disability Support 才做到的。所以教训就是去 issue tracker 提 issue，对吧？下次别找帮助台了。

不对。去他妈的。

想想真正会撞上这个 bug 的是谁。不是手里有 adb、有笔记本电脑、还懂输入管线的开发者。而是一个盲人，可能刚用上 Android，可能年纪不小，可能手机就是 他们 读邮件、和家人聊天、叫出租车的主要工具，然后有一天，他们 靠触摸在屏幕上什么都找不到了。他们 不知道什么是 TouchExplorer，从没听说过 input dispatcher，也不知道自己屏幕上粘着一根假手指，而且 他们 根本无从得知，因为能告诉 他们 的每一个工具都需要一台电脑、一根线、开发者选项和命令行。

于是 他们 按 Google 说的去做。他们 联系 Disability Support，说：“我手机触摸屏幕不读东西了。滑动还能用。重启能好，但老是复发。”

这是一份完全合格的 bug 报告。有症状，有绕过办法，还说明了会复发。任何地方的用户能给出这些就已经很好了，说实话，大多数人连这都做不到。

现在我们知道它究竟会怎样收场。用户会被问九个问题，被要求把 TalkBack 关掉再打开，并被告知要确保身边有一位视力正常的协助者。用户会被要求更新 Android Accessibility Suite 并清除其缓存，而他们确实照做了，小心翼翼地一步一步来，因为他们相信给出这些指示的人知道自己在做什么。他们重启手机，问题解决了，于是反馈说已恢复正常，工单便以“已解决”结案。一周后问题再次出现，他们又从头来一遍。又或者他们不再折腾了，因为他们已经明白这毫无意义，只是在手机剩下的寿命里每天重启几次，并默认用 Android 当盲人就是这样。

如果他们不接受“重启”这个答案，如果他们继续追问，能得到的最好结果就是我收到的那封邮件：超出范围。请去阅读开发者文档。请到论坛上提问。

难道应该指望这个人自己去找 Android 的问题跟踪系统吗？注册账号，从数百个组件中挑出正确的那一个，写一份工程师会认真对待的报告，附上设备指纹和复现步骤？还要附上他们根本无从获取的日志？当然不应该。向用户提出这种要求本身就不合理，而通过专为残障用户设立的支持渠道，向一位残障用户提出这种要求，简直令人不齿。没人会指望一个视力正常、手机屏幕突然失灵的人跑去开发者跟踪系统上提交 bug。他们指望的是 Google、Samsung，或者卖给他们手机的商店来处理这件事。把这项工作推给最没有能力完成它的人，等他们来问时又说超出范围——整个问题就浓缩在这一句话里。

这正是它比我的经历更糟糕的地方。我有能力绕过这套系统，即便如此，也花了四天、一篇博客文章、一份根因分析和两个补丁。其他人手里只有这套系统。而系统对“触摸探索坏了”这个问题的最终回答是：触摸探索坏了，不关它的事。

所以答案不是“去问题追踪系统提交”。答案是：应该由 Disability Support 去提交。那是 Google。它和公司其他部门一样，能访问同一套内部 bug 系统。当残障用户报告某个 Google 无障碍功能坏了，这个团队里就该有人把它写下来——用户能提供什么就记什么——提交给负责该功能的团队，再告诉用户已经提交了。这就是他们的工作。“升级处理”本来就该是这个意思。如果这个团队没有相应的培训、工具或权限，那不是告诉用户“不在受理范围”的理由，而是整改这个团队的理由。

Google 把残障人士引向 Disability Support。帮助页面上的那个渠道、那条由专人处理的无障碍路径、遇到功能用不了时该去的地方，就是它。可当我们中的某个人带着一个影响所有人的问题找上门，它却完全不知道该怎么处理。不是因为那里的人不称职，而是因为 Google 给这个岗位划定的职责，恰好停在它能真正派上用场的地方之前。

如果你遇到了这个 bug

如果你是 Android 盲人用户，触摸浏览突然失效，而滑动和点按仍然正常，那就是这个 bug。不是你的错，也不是你的屏幕阅读器的问题。目前重启可以暂时恢复。

至少这一个已经提交了：TouchExplorer leaves injected pointers down; InputDispatcher then rejects all touch exploration events until reboot。如果你有 Google 账号并且愿意，登录后给它点个 +1。如果你能补充信息，比如设备不是 Samsung、尤其是 Pixel，或者 Android 版本，或者出问题时你正在做什么，就留个评论。你本来也不该做这些。但这是这份报告唯一真正送到能修它的人手里的地方，说自己也遇到的人越多，它的优先级就越高。

如果你遇到过其他无障碍 bug，又被告知不在受理范围，那你报告它没有错，你要求的东西也没有错。你只是在要求该负责的人做好本职工作。

说白了，去你妈的，Google。把 bug 修了，再把路线也修了，好让下一个撞上这事的盲人不必替你们的工程师干活才能被听见。