UiAutomation 与 AccessibilityService
UiAutomation vs AccessibilityService
在 doc's 中它说的是关于 UiAutomation
Class for interacting with the device's UI by simulation user actions
and introspection of the screen content. It relies on the platform
accessibility APIs to introspect the screen and to perform some
actions on the remote view tree. It also allows injecting of arbitrary
raw input events simulating user interaction with keyboards and touch
devices. One can think of a UiAutomation as a special type of
AccessibilityService which does not provide hooks for the service life
cycle and exposes other APIs that are useful for UI test automation.
The APIs exposed by this class are low-level to maximize flexibility
when developing UI test automation tools and libraries. Generally, a
UiAutomation client should be using a higher-level library or
implement high-level functions. For example, performing a tap on the
screen requires construction and injecting of a touch down and up
events which have to be delivered to the system by a call to
injectInputEvent(android.view.InputEvent, boolean).
The APIs exposed by this class operate across applications enabling a
client to write tests that cover use cases spanning over multiple
applications. For example, going to the settings application to change
a setting and then interacting with another application whose behavior
depends on that setting.
UiAutomation 与常规 AccessibilityService 有何不同，因为它在 source code.
中不继承它
public final class UiAutomation {
private static final String LOG_TAG = UiAutomation.class.getSimpleName();
// omitted the rest...
无障碍服务：
should only be used to assist users with disabilities in using Android
devices and apps. They run in the background and receive [...] AccessibilityEvents [...]. Such events denote some
state transition in the user interface, for example, the focus has
changed, a button has been clicked, etc. Such a service can optionally
request the capability for querying the content of the active window.
这是一个强大的工具，基本上可以让您访问 phone 上发生的所有事情，因此用户需要在 phone 设置（通常在 Accessibility/Installed服务）。
UiAutomation:
嗯，你基本上引用了问题中的描述，但这里有更详细的描述：
在某种程度上，UiAutomation 充当修饰的 AccessibilityService (decorator design pattern)。您可以阅读方法 getServiceInfo 和 setServiceInfo 的源代码来验证它，它们在内部使用连接的服务对应项（快速查看导入）。
这是一个添加了一些功能的包装器，例如，它允许您导航视图层次结构等，而无需在每次首次 [=37] 设置中启用辅助功能服务 phone =] 仪器化测试。这是借助 android.app.Instumentation class 和其他测试框架组件实现的。系统可以安全地授予所需的权限，因为检测 can only be started through adb or from within a System App.
这不是真正的 AccessibilityService（甚至不是真正的服务），但可能是为了简单起见并引起对底层环境的注意。
在 doc's 中它说的是关于 UiAutomation
Class for interacting with the device's UI by simulation user actions and introspection of the screen content. It relies on the platform accessibility APIs to introspect the screen and to perform some actions on the remote view tree. It also allows injecting of arbitrary raw input events simulating user interaction with keyboards and touch devices. One can think of a UiAutomation as a special type of AccessibilityService which does not provide hooks for the service life cycle and exposes other APIs that are useful for UI test automation.
The APIs exposed by this class are low-level to maximize flexibility when developing UI test automation tools and libraries. Generally, a UiAutomation client should be using a higher-level library or implement high-level functions. For example, performing a tap on the screen requires construction and injecting of a touch down and up events which have to be delivered to the system by a call to injectInputEvent(android.view.InputEvent, boolean).
The APIs exposed by this class operate across applications enabling a client to write tests that cover use cases spanning over multiple applications. For example, going to the settings application to change a setting and then interacting with another application whose behavior depends on that setting.
UiAutomation 与常规 AccessibilityService 有何不同，因为它在 source code.
public final class UiAutomation {
private static final String LOG_TAG = UiAutomation.class.getSimpleName();
// omitted the rest...
无障碍服务：
should only be used to assist users with disabilities in using Android devices and apps. They run in the background and receive [...] AccessibilityEvents [...]. Such events denote some state transition in the user interface, for example, the focus has changed, a button has been clicked, etc. Such a service can optionally request the capability for querying the content of the active window.
这是一个强大的工具，基本上可以让您访问 phone 上发生的所有事情，因此用户需要在 phone 设置（通常在 Accessibility/Installed服务）。
UiAutomation:
嗯，你基本上引用了问题中的描述，但这里有更详细的描述：
在某种程度上，UiAutomation 充当修饰的 AccessibilityService (decorator design pattern)。您可以阅读方法 getServiceInfo 和 setServiceInfo 的源代码来验证它，它们在内部使用连接的服务对应项（快速查看导入）。
这是一个添加了一些功能的包装器，例如，它允许您导航视图层次结构等，而无需在每次首次 [=37] 设置中启用辅助功能服务 phone =] 仪器化测试。这是借助 android.app.Instumentation class 和其他测试框架组件实现的。系统可以安全地授予所需的权限，因为检测 can only be started through adb or from within a System App.
这不是真正的 AccessibilityService（甚至不是真正的服务），但可能是为了简单起见并引起对底层环境的注意。