AccessibilityServices, Play Store Bans, and API Design
TL;DR: When designing an API, keep features with privacy and security ramifications separate from other features, such that both you and developers using the API have a very clear sense of what is and is not sensitive.
Many of you may have heard about Google’s threats to remove apps from the
Play Store that have an
AccessibilityService that is not primarily for
accessibility. Many outlets reported on this, including
and Ars Technica.
According to the purported emails, Google is stating that if your
app has requested the
you must explain to users how your app is using the
android.permission.BIND_ACCESSIBILITY_SERVICEto help users with disabilities use Android devices and apps
Later, the email states that you should remove the app if “the permission is being used for something other than helping users with disabilities use Android devices and apps”.
On the one hand, I completely understand the rationale for instituting this sort of ban. Accessibility APIs have been a privacy and security problem for some time, even if many people are only recently noticing it. It is easier for Google to whitelist various apps that have legitimate need to use those APIs than it is to root out all malicious uses.
However, whenever you see bath water being thrown out, look for an associated baby.
In Android 8.0, Google added fingerprint gesture support. While relatively few devices have hardware support for this, it effectively turns the fingerprint sensor into a tiny trackpad. At present, you can detect swipes in the four cardinal directions (up, down, left, right), and you can take some action based upon this via a registered callback.
However, they put fingerprint gesture support in
AccessibilityService. Hence, only apps that request the
BIND_ACCESSIBILITY_SERVICE permission can find out about fingerprint gestures.
It is unclear why Google thinks that fingerprint gestures are primarily for
users who need assistive technologies. After all, trackpads are fairly commonplace
elsewhere, used by people with a wide range of abilities. Google even supports
trackpads with Android apps on Chromebooks, without requiring the app to have
Moreover, by putting fingerprint gestures into the accessibility APIs,
not only would app developers need to fuss with an
and not only would enabling that service trigger all sorts of privacy and security
warnings to the user, but with the new Play Store policy, any app seeking
fingerprint gestures needs to be for users with disabilities, period.
While the ban is aiming to defend users against unnecessary privacy and security challenges, there is nothing in today’s fingerprint gesture API that is sensitive, and it’s unclear what they could add in the future that would be sensitive. Even if the gestures somehow get integrated with actual fingerprint scans, there’s a separate API for fingerprint scans, not tied into accessibility.
So we get a new general-purpose feature, and courtesy of an engineering choice (where the API resides) and a policy choice (ban on unnecessary use of accessibility APIs), most developers cannot use that feature.
This brings me back to the TL;DR from the outset. Keep APIs with privacy and security ramifications separate from other APIs. Make it very obvious to all parties what portions of your API may put users at risk. Conversely, don’t attach normal APIs onto an API set that is sensitive just because it’s easier or, in the absence of those privacy and security ramifications, it might make sense. Bright lines help everybody understand what is and is not safe. And, in the future, should bans like this one be required, it is simpler to only affect those misusing the sensitive APIs if the sensitive APIs are clearly separated out from the remaining APIs.
In this case, given that accessibility APIs are going to have privacy and security
ramifications indefinitely, IMHO the better approach would have been to have fingerprint
gestures be somewhere else. For example, they could be just simple
sources, not significantly different than how trackpads work elsewhere. Even
if there are technical reasons for keeping fingerprint gestures out of the regular
input framework, there could be a
FingerprintGestureManager system service
or some such that provided this ability, independent of the accessibility APIs.
It’s not out of the question that this could be addressed in the timeframe
of Android P (Peppermint? Pistachio? Pomegranate?), should Google
choose to do so. Only time will tell if we can put this baby back into some
After all, you have to be very careful with some babies.
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!