Google cracks down on power-user apps that use Android’s accessibility API

Accessibility APIs offer powerful controls to apps, but Google says “no more.”

Ron Amadeo – Nov 13, 2017 4:20 pm | 125

Google is cracking down on apps that use Android’s accessibility API. Even though the APIs have been around for years without any kind of rules about usage, Google has now started telling developers that using the accessibility API for anything other than helping users with disabilities will result in a ban from the Play Store.

As first reported by XDA Developers, a number of app developers have received an e-mail from Google in regard to their accessibility app. According to the e-mail, Google’s new rules require that “Apps requesting accessibility services should only be used to help users with disabilities use Android devices and apps.” The e-mail says that developers “must explain to users how your app is using the ‘android.permission.BIND_ACCESSIBILITY_SERVICE‘ to help users with disabilities use Android devices and apps.” Google says that if developers don’t comply with the new policy within 30 days, their app will be removed from the Play Store.

Google’s new policy will hurt a large swath of power-user apps. Android accessibility APIs are meant for alternative input devices and alternative output methods, but they are also a powerful set of controls that have been co-opted by the Android tweaking community to give users more control over their devices. If you want to write a powerful Android app and don’t want to modify your phone for root access, tapping into the accessibility API is the next best thing.

With the accessibility API, apps can access lots of powerful commands that let them function a bit like a system-level app, and the legitimate, non-accessibility uses are almost endless. Through the API, an app can see all the other apps the user is running and take an action when a specific app launches. This is great for automation apps like Tasker, which allow users to write complicated “If, Then” statements that constantly run on the phone.

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.