我们已开始在https://developer.android.com/guide/topics/ui/accessibility/services.html查看适用于Android的Building Accessibility Service。根据此文档，我们可以代表用户执行自定义手势，如第34节中所述;为用户采取行动＆＃34;在https://developer.android.com/guide/topics/ui/accessibility/services.html#act-for-users。 我们根据此文档提出以下问题。
1）据我们了解，用户会执行手势，我们的代码会听。让我们称这些听力手势。然后，我们的代码可以为用户执行手势。让我们称这些表演手势。问题是表演手势的影响 - 触摸和探索层还是触摸和探索层下面？有关其他信息，触摸和探索是Android操作系统的功能，可由辅助功能服务部门请求。
2）Performing Gesture是否会触发通知Accessibility Service的任何AccessibilityEvent？如果是，如果听力手势和表演手势恰好相同，则可能出现递归。那就是Listening Gesture可以向右滑动，触发一些事件。表演手势也可以说是向右滑动。现在，这也将触发相同的事件处理程序。
3）我们如何确定Performing Gesture成功执行？如果Performing Gesture发生在触摸和探索层之下，那么整个事情就具有重要意义。
非常感谢任何帮助。
答案 0 :(得分：0)
1）不，代表使用辅助功能的功能的用户执行手势不会最终被“听”到手势。 AccessibilityService实际上将手势发送到API，该API以与屏幕完全相同的方式计算屏幕触摸，从而完全绕开了屏幕。因此，辅助技术看不到这些事件。但是，如果您坚持引用，那么您当然可以自己从AccessibilityService调用这些手势的回调。因此，您执行的任何手势都不会触发触摸来探索手势。实际上，您可以通过触摸来探索手势来触发执行手势。
2）对我来说，这实际上是与问题1相同的问题。不，不是，因为问题1中的所有相同原因。
3）有两个答案。首先是'dispatchGesture'返回一个布尔值。当操作系统在调度手势时没有遇到技术问题时，此布尔值为true。例如，潜在的问题是：您尝试在屏幕外进行交互。这对你很愚蠢！大声笑。如果从此方法返回“ true”，则通常可以胜任并执行您的手势。在这一点上，我们可以确定手势是由用户自己实际执行手势来执行的。这与操作系统中的逻辑完全相同...如果您不相信我，请亲自检查AOSP：）
3B）确保一切正常的唯一方法是在屏幕上观看手势。