我正在为Android编写无障碍服务,旨在为身体残疾的人提供不同的控制设备的选择,例如使用开关、扫描、头部追踪和其他方法。
目前,我们使用无障碍API(Accessibility API)来执行应用程序界面上的实际操作,基本上是使用AccessibilityNodeInfo.performAction()方法。这在大多数情况下都很好用,但我们发现一些重要的限制:
- 大多数键盘(IME)根本不起作用。我们只在Lollipop(API 22)上成功使用了Google键盘,并不得不使用AccessibilityService.getWindows()。对于低版本的API,我们不得不开发一个特殊的键盘(毫无疑问不是最佳解决方案)。 - 大多数游戏不可访问。它们没有导出AccessibilityNodeInfo树。 - 网页导航不现实(没有滚动等问题)。
一个解决方案是使用不同的API来执行操作,看起来android.app.UiAutomation会适合这个目的。根据文档,“它还允许注入模拟键盘和触摸设备用户交互的任意原始输入事件”,这正是我想要的;尽管我知道UiAutomation旨在用于测试(也许不适合生产质量代码),并且可能在不同的设备上表现不同。我也明白,如果任何应用程序都可以使用此类API,它可能成为安全漏洞。但是,鉴于AccessibilityNodeInfo.performAction()提供了类似的“权限”,允许辅助功能服务使用UiAutomation似乎是合理的。
因此,在我的辅助功能服务中,我尝试了以下操作:
目前,我们使用无障碍API(Accessibility API)来执行应用程序界面上的实际操作,基本上是使用AccessibilityNodeInfo.performAction()方法。这在大多数情况下都很好用,但我们发现一些重要的限制:
- 大多数键盘(IME)根本不起作用。我们只在Lollipop(API 22)上成功使用了Google键盘,并不得不使用AccessibilityService.getWindows()。对于低版本的API,我们不得不开发一个特殊的键盘(毫无疑问不是最佳解决方案)。 - 大多数游戏不可访问。它们没有导出AccessibilityNodeInfo树。 - 网页导航不现实(没有滚动等问题)。
一个解决方案是使用不同的API来执行操作,看起来android.app.UiAutomation会适合这个目的。根据文档,“它还允许注入模拟键盘和触摸设备用户交互的任意原始输入事件”,这正是我想要的;尽管我知道UiAutomation旨在用于测试(也许不适合生产质量代码),并且可能在不同的设备上表现不同。我也明白,如果任何应用程序都可以使用此类API,它可能成为安全漏洞。但是,鉴于AccessibilityNodeInfo.performAction()提供了类似的“权限”,允许辅助功能服务使用UiAutomation似乎是合理的。
因此,在我的辅助功能服务中,我尝试了以下操作:
Instrumentation i = new Instrumentation();
UiAutomation automation = i.getUiAutomation();
但是getUiAutomation()总是返回null。
在无障碍服务中有没有使用UiAutomation(或类似API)的选项?
顺便说一句:对我们来说,root设备不是一个选择,因此我们无法通过屏幕驱动程序注入事件。
UiAutomation
在所有设备和所有应用程序上的行为都是相同的。除此之外,你还假设UiAutomation
是为生产使用而设计的,而不是其声明的用途(“开发UI测试自动化工具和库”)。据我所知,这在仪器测试之外是不可用的。 - CommonsWare