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.
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
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/notifications 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.
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
Quote from what you wrote:
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.
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.
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
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.
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.
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).
I think we agree on everything:
* Using accessibility requires a lot of extra scrutiny by the store and is very useful
* Abusing accessibility shouldn’t be needed, there should be proper ways to do this.
However, because I don’t have any app that needs this (I use W10M), I don’t mind if Google fixes this (the theoretical good thing) and you prefer for them to leave it the way it is (the practical good thing).
I am also afraid you would be correct about “Most people aren’t going to properly validate the authenticity of APK’s they download”. But I would say that those kind of people cannot be helped. If you are “brave” enough to download from outside the store, but “stupid” enough not to verify you cannot be helped by technology.
There’s BOINC for Android?! Who ever thought of THAT to be a good idea?
(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.
BOINC at least gives you good control of how it runs. There’s options to control what power sources it will run on (and it defaults to only running while charging), what network types it will sync data on, setting a minimum amount of battery power below which it won’t run (so you can set it to wait until the phone is charged before starting processing), and can even stop processing if the battery gets too hot. All in all, it’s probably got the best control of any app I’ve ever seen in terms of when it does things. It’s also pretty reasonable to use the rather significant spare processing power on most smartphones when they’re charging and you aren’t using them.
As far as the banking app, there quite literally is nothing that it needs to run in the background for if you turn off notifications, it doesn’t support transactions via NFC, it unconditionally reloads everything when you start it (so there’s no need to update the cache in the background). It’s quite literally either:
1. Lazy developers not terminating their background process during app termination.
or:
2. Stupid developers thinking that avoiding one fork()+exec() call during startup will provide some noticeable improvement in start-up times.
Did Google even fix the bug where giving or taking accessibility permission to an app it would just reset the MASTER pin/password used for the device ENCRYPTION to the default one [1]? No?
Did Google make this service resistant to active exploitation by malware [2] yet? No?
Burn it with fire then!
[1]: https://blog.g3rt.nl/android-lollipop-encryption-user-interface-flaw…
[2]: http://blog.trendmicro.com/trendlabs-security-intelligence/toast-ov…
Edited 2017-11-15 23:02 UTC