Accessibility apps can intercept KeyEvents (hardware key presses), which is useful for doing something like remapping the hardware Bixby key on Samsung devices. Accessibility apps can turn off other apps, which is useful for battery saving apps like Greenify. LastPass used the API to create an Android password app before password apps were officially supported, which only happened in Android 8.0.
Google’s new policy of only allowing the accessibility API for accessibility purposes definitely seems to be new, as many of these apps are years old and have existed in the Play Store without issue. Google’s own developer documentation still claims it is fine to use the Accessibility APIs for non-accessibility purposes. For instance the “Building Accessibility Services” page suggests developers make apps for users “who may temporarily be unable to fully interact with a device.” The page even lists some non-accessibility examples for the accessibility API, like assisting “Users who are driving, taking care of a young child or attending a very loud party might need additional or alternative interface feedback.”
It’s understandable that Google would want to put a lid on the accessibility APIs in Android, but they already require a good amount of work from the user in order to enable. Android’s accessibility API requires special permissions that can’t be granted during runtime or requested programmatically by the app. Users must manually go into the accessibility options and enable accessibility features for the app, which requires tapping through a few warning pop ups.
Enabling this for a malicious app can, of course, wreak a lot of havoc, which is probably Google’s inspiration for cracking down on the accessibility API. Google’s sudden policy change seems like it will also reduce the functionality of myriad useful apps and could outright kill others. Some developers are attempting to come up with workarounds, but, for the most part, nothing on Android compares with the accessibility APIs.