www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
Google to remove Accessibility Services apps from the Play Store
By Thom Holwerda on 2017-11-13 23:39:35

Some of the most innovative applications on the Play Store are built on using APIs in ways that Google never intended. There are apps that can remap your volume keys to skip music tracks, record and play back touch inputs on webpages or games, and even provide alternative navigation keys so you can use your device’s entire screen. All of these examples that I’ve just mention rely on Android’s Accessibility APIs. But that may soon change, as the Google Play Store team is sending out emails to developers telling them that they can no longer implement Accessibility Services unless they follow Google’s guidelines.

Accessibility Services is an attack vector for malicious software, so in that light it makes sense. Of course, that doesn't make it any less frustrating that good, innovative software gets smothered like this. Luckily, this is Android, so the developers can always just distribute their applications outside of the Play Store through sideloading, but that's not exactly a secure solution for most people - and let's be honest, not being in the Play Store will be the death knell for most developers.

The real solution would be to provide APIs for things like this, but I doubt Google is going to invest any time, effort, and money into creating such APIs, since they seem more concerned with shoving useless digital assistants down our throats.

 Email a friend - Printer friendly - Related stories
.
Post a new comment
Read Comments: 1-10 -- 11-13
.
Seriously...
By leech on 2017-11-14 02:22:00
Digital assistants... why? There is seriously this massive push for these useless things. Even if I were the type of moron to talk to my phone, even when I try to see how far the tech has come, it still falls short.

Though I did tell Bixby the other day that it sucked, and it came back with some reply about trying to be nicer and coming back later when I was in a better mood.

Oh and it spelled the 'F-word' with a ph!'

Edited 2017-11-14 02:22 UTC
Permalink - Score: 1
.
Wonder what the real reasons are...
By gsyoungblood on 2017-11-14 06:46:31
I use the 1Password password manager. I also use the Notification History Pro app. And something else I forget at the moment. At some point all 3 required the accessibility features enabled for full functionality to work.

Now, given that the only way for that to happen requires manually going in and enabling those features for the apps -- the apps can't enable them itself -- it sure seems fishy that they are taking this step now. Something more is definitely going on here.

I'd even say it's going to DECREASE security in some situations.. I've used Notification History Pro to find alerts/messages/notificatio ns that popped up on the screen but then somehow mysteriously "auto closed" before I could see them. (I deleted the app that was doing that). I wouldn't have been able to do that without that tool, and as that uses the accessibility APIs to function, I suspect it's on the short list to be killed.

Of course Google won't issue refunds for apps they brick along the way by doing this either. I wonder what would happen if everyone who had apps disabled because of this took Google to small claims court. Sad thing is, most apps being under $10 i'm not even sure you'd be able to because I think there's a minimum damages amount.
Permalink - Score: 2
.
Comment by sj87
By sj87 on 2017-11-14 08:16:34
This is basically the death knell for modding Android without rooting, installing custom ROMs – and most importantly – without voiding warranty. The standard Android distribution is useless crap and most vendor-provided distros are either bloated or just plain horrible.

I myself am using All In One Gestures and System UI Tuner to make Android make a little sense and I guess both of these apps will be gone now.

Although, implementing custom gestures might still be allowed.

Edited 2017-11-14 08:20 UTC
Permalink - Score: 1
.
Thom, it is time to learn what an API is!
By avgalen on 2017-11-14 10:27:21
Quote from what you wrote:
> The real solution would be to provide APIs for things like this, but I doubt Google is going to invest any time, effort, and money into creating such APIs

Quote from the article that you literally put just a little bit above your quote
> All of these examples that I’ve just mention rely on Android’s Accessibility APIs.

I have noticed on many articles before that you keep pointing to API's as the solution to a problem even in cases where that doesn't make any sense. In this case it does make sense but these API's already exist and they are what developers are currently using. The problem is that they aren't using them for what they are supposed to be used for so technically you are probably (going to) violate the terms of service for the Play Store so Google is now announcing that your app is likely to get blocked.

I think it is perfectly fine to have these kind of tools outside of the store and only available from specialty stores (or sideloading) because as this quote from the comments shows you the tools that used these API's for good were used to block the tools that used these API's for bad
> I've used Notification History Pro to find alerts/messages/notificatio ns that popped up on the screen but then somehow mysteriously "auto closed" before I could see them. (I deleted the app that was doing that)

Of course it would be great if Google would move these API's so they are available for all apps in a secure way, but since many of these apps violate the "apps cannot interfere with other apps or the OS" rule for good reasons this is probably impossible.

Another option would be to work more closely with these app-developers so tools that are truly useful can get integrated into Android in a more secure way while being available to everyone. There are many reasons (bloat, update-tight-to-OS, licensing) why this would not be feasible.
Permalink - Score: 4
.
RE: Thom, it is time to learn what an API is!
By ahferroin7 on 2017-11-14 13:24:13
The real problem is defining what constitutes 'interfering with other apps or the OS'.

Greenify (which I personally use) is a great example of this, most developers would consider it to be interfering with their apps, but their apps running in the background unnecessarily (seriously, if you don't have notifications enabled, you don't need to have a background process, period) is what prompted its creation in the first place. It is interfering with the OS because it delays locking the phone, but that's the only way to do things just prior to the device going to sleep, so it's interference that's at least indirectly enforced by Google themselves (this would be a great place for an event API with some restriction on what could be done.

As things stand right now, Greenify is likely going to have to switch to installing as a device administrator (and thus be granted even more crap it doesn't really need), and even that may not be a workable alternative.
Permalink - Score: 4
.
RE[2]: Thom, it is time to learn what an API is!
By avgalen on 2017-11-14 21:45:55
I would be very unhappy if a "tombstoning" app would tombstone the background process from my podcast app that makes sure I have fresh things to listen to downloaded at night on Wifi instead of having nothing to listen to in the car.

The solution should be a "allow app to run in the background" privilige that can be enabled/disabled by the user through the OS-setting. A tool like greenify shouldn't be needed (since Androids 6 Doze) and shouldn't be able to control other apps like my podcasting app
Permalink - Score: 4
.
RE[3]: Thom, it is time to learn what an API is!
By ahferroin7 on 2017-11-15 12:35:17
Greenify doesn't try to control the whole system. You tell it what to keep from running in the background, and it only touches that stuff (and not even all of that stuff anymore, what with the 'cached only' background usage many apps are claiming (incorrectly in some cases) now), and even then it only does so when you tell it to, or you lock the device (and the last bit is half of why they need accessibility API's, the other half is UI automation to work around third-party apps not being allowed to terminate processes directly).

I agree that it shouldn't be needed, but the problem isn't Android as much as it is the developers who seem to think they need a background process all the time and offer no way to disable it. Most apps rely on Android to control notifications (they should have an option in the app itself), and have no option to control background content updates (like the example you give of a podcasting app). If you don't need either notifications or background updates, and aren't an application like BOINC (which is _supposed_ to run in the background), you don't need a persistent background process.

A classic example of this is my bank's mobile app. I've got notifications turned off (it actually has an option for this), and it by definition can't be doing any background updates other than what would be needed for notifications (which it shouldn't be doing, since notifications are off), so there is absolutely zero need for it to have a background process when the app isn't open.
Permalink - Score: 3
.
RE[4]: Thom, it is time to learn what an API is!
By avgalen on 2017-11-15 16:16:28
> Greenify doesn't try to control the whole system.
It sounds like greenify is an awesome powertool that serves you greatly

However, the problem isn't if greenify IS trying to control the whole system, the problem is that greenify CAN do that. Apps shouldn't have that possibility, especially not when they "abuse" accessibility for this.
Permalink - Score: 3
.
RE[5]: Thom, it is time to learn what an API is!
By ahferroin7 on 2017-11-15 16:31:04
No, the problem is the responsibility conferred by that permission, and Google's overreaction to a handful of apps abusing it. That level of control absolutely IS necessary for applications that provide accessibility services (imagine trying to write a screen reader without being able to access the data on-screen, or switch-input driver without being able to synthesize keystrokes and touch events). It's also functionally needed to provide things that the Android system lacks (input macros for example) or does a poor job of (keeping a handle on background resource usage to maximize battery life for example, which is largely what Greenify does).

Yes, things that request this permission should have some extra requirement for entry into the play store. Stifling unconventional usage spurred on by limitations in Android itself without providing an alternative though isn't a good approach, it just alienates people and encourages those of us who want (or possibly need) such things to learn to sideload apps, which just moves the security problem elsewhere (Most people aren't going to properly validate the authenticity of APK's they download, so it actually makes it a bigger security issue). It would be pretty easy for Google to extend this review to include useful things like what Greenify does (which they've nixed multiple ways before I might add), or UI automation tools, or input translation tools (think things that let you control the pointer with a keyboard, or provide input macros, etc) while still improving protection against the malware that abuses this (and most of that malware is liable to just punt to the device administrator privilege regardless, which has all the same issues).
Permalink - Score: 3
.
RE[4]: Thom, it is time to learn what an API is!
By zima on 2017-11-15 22:28:31
There's BOINC for Android?! Who ever thought of THAT to be a good idea? :P (power/battery usage)

PS. There is a good reason why banking app might want to run in the background - contactless payments via your phone instead of a card.
Permalink - Score: 3

Read Comments 1-10 -- 11-13

Post a new comment
Username

Password

Title

Your comment

If you do not have an account, please use a desktop browser to create one.
LEAVE SPACES around URLs to autoparse. No more than 8,000 characters are allowed. The only HTML/UBB tags allowed are bold & italics.
Submission of a comment on OSNews implies that you have acknowledged and fully agreed with THESE TERMS.
.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?