UiAutomation vs AccessibilityService

In the doc's it say this about 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.

How exactly is UiAutomation different from a regular AccessibilityService, as it doesn't inherit from it in the source code.

public final class UiAutomation {
    private static final String LOG_TAG = UiAutomation.class.getSimpleName();
    // omitted the rest...

from UiAutomation vs AccessibilityService