不在我们的支持范围内

# 超出我们支持范围 — fireborn Source: https://fireborn.mataroa.blog/blog/outside-the-scope-of-our-support/ 几天前，我写了一篇关于向 Google Disability Support 报告 bug 的文章。这个 bug 会导致 Android 上所有屏幕阅读器的触摸探索功能失效，直到重启手机才能恢复。而我得到的回复是：把 TalkBack 关掉再打开、清除一个我根本不用的应用的缓存、重启——这最后一步，我已经告诉过他们这是唯一的临时解决办法。如果你还没读过那篇，《你试过把 TalkBack 关掉再打开吗？》（https://fireborn.mataroa.blog/blog/have-you-tried-turning-talkback-off-and-again/）讲了整个事情的来龙去脉，不看那篇的话，这篇可能会有些看不懂。 之后又发生了不少事。我打算把它们都讲一遍，因为这个结局比我能编出来的任何情节都精彩。不过我可以先用四个字告诉你我的感受，现在就把这四个字说掉吧。 简单来说：去你的。 ## 上次说到哪了 我发布第一篇文章时，已经回答了 Google 支持团队问的每一个问题。我做了他们给出的每一步排查，包括那些根本不可能起作用的步骤，并汇报了结果。他们说，等我完成这些后，案件就可以转交给内部团队进一步审查。于是我照做了，然后等待转交。 我并不是干等。第二天早上 bug 又出现了，这次我早有准备。手机卡住时，我抓取了一份完整的 bug 报告。我把所有日志缓冲区都抓了下来，问题出现前后都有。我弄清楚了为什么那根假手指会一直留在屏幕上：TouchExplorer 在没有有效指针的情况下进入了拖动状态，试图构建一个不包含任何指针的抬起事件，MotionEvent 抛出异常，异常被吞掉，那根本该抬起手指的抬起事件就永远不会被发出。我也弄清楚了为什么除了重启之外没有任何办法清除它：输入分发器（input dispatcher）把注入指针的记录保存在一个 verifier 里，而这个 verifier 只有在显示设备被移除时才会被丢弃，所以关掉无障碍、关掉每一个无障碍服务，甚至拆掉整个输入过滤器都无济于事。我在手机上证实了这一点。我找到了一种方法，从 shell 用一个取消事件就能清除它，还找到了一种让屏幕阅读器完全不需要特殊权限就能清除它的方法。然后我写了修复代码，一个补丁给 frameworks/base 里的无障碍代码，另一个给 frameworks/native 里的输入分发器，并把这一切的摘要发回了案件，同时再次请求一个能把文件交给工程师的途径，因为他们的表单仍然只接受截图。 一个根因、一种恢复方法、两个补丁、一个可随时触发的复现步骤——全部免费、利用我自己的时间、在我只能半用的手机上完成的。 ## 第二位客服 下一条回复来自另一位客服，代替了第一位。我在这里要说句公道话，因为我确实想说句公道话：这是我收到过的最好的回复。读起来像是真的有人看了我发的东西。它正确地概括了问题，用的是专业术语：TouchExplorer 在无效的拖动指针状态后未能释放注入指针，导致 InputDispatcher 拒绝随之而来的悬浮事件。它说它理解这对屏幕阅读器用户的影响。它说它不想给我一个未经核实的技术答案来回答我的三个问题，而这些问题需要负责那些框架组件的团队来回答。最后，它说它理解排查步骤已经穷尽了。 它说不出口的是，工程团队里到底会不会有人来看这些东西。它没有上传链接，也没有工程联系人。它让我先保管好那些文件，以防案件里哪天冒出一个发送途径。它很礼貌，对自己不知道的事很诚实，然后就没下文了。 于是我不再等了，自己去提交了这个 bug。 ## 102 分钟 Android 有一个公开的问题追踪系统。任何人都可以在上面提交问题，而且它有一个 Android Accessibility 组件。我把所有内容都写好了：设备和构建版本、自然触发方式和一个可靠的 shell 复现方法、触发期间日志里发生了什么、为什么只有重启才能恢复、设备上的测试结果、屏幕阅读器可用的临时解决办法，以及两个补丁，附上了复现辅助脚本。我在周五早上 08:17 提交了它，并把链接发给了支持案件，好让他们附上并转交。 09:59，它被分配给了 Google 的一位工程师，并附有一条评论说已转交给开发团队。 一小时四十二分钟。到那时，Disability Support 持有这个案件已经四天了，四天里它连工程师的面都没见到。问题追踪系统在我还没喝完第二杯咖啡就搞定了。 它还在推进。撰写本文时，它被标记为已分配，严重程度 S2，优先级 P2。它在五个热门列表上。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，被告知去清缓存。证明缓存跟这毫无关系，被告知需要先做排查。做完排查，找到原因，写好修复，被告知修复不归他们管。在这个循环里，从来没有一个步骤是把报告送到工程师手里，而且永远也不会有。我只是不停在找那个步骤。 然后那封回复给我发了一些链接。Android 开发者无障碍指南，那是给做应用适配屏幕阅读器的人看的文档，跟输入分发器的 bug 的相关程度大概相当于菜谱书之于写代码。一页额外的无障碍资源。还有 Android Accessibility Help Community，据它说，我可以在那里"分享你的发现，讨论触摸探索行为，与其他无障碍开发者交流"。那是一个论坛。是其他用户免费互相回答问题的地方，而这个 bug 多年来一直在那里发生，也正是因为如此它才至今还在。 那封邮件里从头到尾没提问题追踪系统。我上一条消息已经把链接发给他们了。他们写这封邮件的时候，那个 bug 已经在工程师手里待了一天半了。审查我案件的人要么没看到那个链接，要么看到了，然后认为告诉一个盲人开发者"你的 bug 已经分配给 Google 工程师了，去求助论坛上发帖吧"才是正确的做法。 然后它以这样一句话收尾，这句话最终说透了一切："如果您遇到涉及 Google 无障碍功能的具体功能损坏问题，或希望提出改进建议以提升无障碍体验，请随时再次联系我们。" 我联系过了。整件事就是为了这个。 ## 这说明了什么 我在第一篇文章里说过我不怪那些客服，现在也还是不怪。第二位确实很不错，而且我猜最后一封邮件根本就不是他们写的：读起来像是内部团队的结论，传下来让一线的人签个字。这些人是在一个系统里工作的人，而系统决定了他们被允许做什么。 既然我全程走了一遍，那就来说说这个系统到底是干什么的。 Google Disability Support 是一个使用 Google 无障碍功能的帮助台。如果你找不到某个设置，它会帮你找。如果 TalkBack 说得太快，它会告诉你去哪里调慢。它在这方面可能做得不错，这也有价值。但它不是向 Google 报告无障碍 bug 的渠道，也不可能成为这种渠道，因为它内部没有任何环节会通向能修复 bug 的人。当一个盲人告诉它有东西坏了，它能告诉他们如何关了再开，等这招用完了，它就告诉他们超出了范围。然后把他们送到一个论坛。 它不做的是一个支持渠道存在的唯一意义：把某个东西坏了的报告，送到能修它的人面前。 ## 现在想象一下，中招的不是我 很容易把这一切读成一个大团圆结局的故事。bug 最终到了工程师手里，而我是绕开 Disability Support 才做到的。所以教训是去问题追踪系统上提交，对吧？下次跳过帮助台。 不。他妈的不。 想想真正碰到这个 bug 的人是谁。不是那个有 adb、有笔记本电脑、对输入管线有基本了解的开发者。是一个盲人，可能是刚用 Android，也可能是年纪大了，可能手机就是他读帖子、跟家人聊天、叫出租车的唯一方式，有一天他突然用触摸找不到屏幕上任何东西了。他们不知道 TouchExplorer 是什么。他们从没听说过输入分发器。他们不知道屏幕上卡了一根假手指，而且他们没有任何办法去搞清楚，因为每一个能告诉他们这件事的工具都需要电脑、数据线、开发者选项和命令行。 于是他们照 Google 说的做。他们联系 Disability Support，说："我一触摸屏幕手机就不朗读了。滑动还正常。重启能修好，但老是反复出现。" 这是一份完全合格的 bug 报告。有症状、有临时办法、有会复发的事实。这正是我们对世界上任何地方的任何用户应该期待给出的信息，说实话，这已经比大多数人能做到的更多了。 而我们现在确切地知道它会遭遇什么。他们收到九个问题。他们被告知把 TalkBack 关掉再打开，还附带一个警告让他们找个视力正常的人在旁边。他们被告知更新 Android Accessibility Suite 并清除其缓存，他们照做了，小心翼翼，一步一步，因为他们信任告诉他们这些的人知道自己在干什么。他们重启了，问题解决了，他们反馈说好了，案件被关闭为已解决。一周后问题又出现了，他们重新来一遍。或者他们不再做了，因为他们已经明白这毫无意义，于是在手机余生里每天重启几次，以为用 Android 的盲人体验就是这样的。 如果他们不接受重启这个答案，如果他们坚持追问，他们能得到的最好结果就是我收到的那封邮件。超范围。去读开发者文档。去论坛上问。 我们能指望那个人自己找到 Android 问题追踪系统吗？注册一个账号，在几百个组件里找到正确的那个，然后写一份工程师会认真对待的报告，附上设备指纹和复现步骤？还要附上他们根本没能力抓取的日志？当然不能。这对用户来说不是合理的要求，而通过专为残障用户设立的支持渠道向残障用户提出这种要求，简直是无耻的。没有人会指望一个手机屏幕不响应的视力正常用户自己去开发者追踪系统上提交 bug。他们期望 Google、或者三星、或者买手机的那家店来处理这件事。把这项工作甩给最没能力做的人，等他们来问的时候又说超出范围——整个问题就是这一句话。 这就是为什么这比我的经历更糟。我有绕开系统的能力，这仍然花了四天、一篇博客、一次根因分析和两个补丁。其他人只有这个系统。而这个系统对"触摸探索坏了"的回答，归根结底是：触摸探索坏了不关它的事。 所以不，答案不是"去追踪系统上提交"。答案应该是 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 (https://issuetracker.google.com/issues/574059457)。如果你有 Google 账号并愿意的话，登录并给它点个 +1。如果你能补充一些信息，比如一台不是 Samsung、最好是 Pixel 的设备、一个 Android 版本、或者问题发生时你正在做什么，那就加条评论。你本来也不应该被要求做这些。但这是这份报告唯一真正送达能修复它的人手里的地方，说碰到的人越多，它的优先级就越高。 而如果你碰到了任何其他无障碍 bug 并被告知超出了范围，那么你报告它没有错，你要求的东西也没有错。你只是在要求对的人做他们该做的事。 简单来说，去你的，Google。把 bug 修了，然后再把渠道修了，让下一个发现问题的盲人不必替你的工程师干活才能被听见。