There are a lot of moving parts to all of our favorite applications. You might not think about this when scrolling through your timeline on Twitter or watching videos on YouTube, but the amount of stuff going on behind the scenes to make all of these apps work the way they're supposed to is actually pretty incredible.
Certain apps like LastPass, Tasker, and Clipboard Actions tap into Android's Accessibility Services to allow for deeper features that otherwise couldn't exist, but Google recently announced that applications using them without directly benefiting those with disabilities could be removed from the Play Store.
Accessibility Services are an interesting tool, and to get a better idea of what exactly is taking place here, we need to take a closer look.
What are Accessibility Services?
Accessibility Services are found within Android and allow phones and tablets to be easier to use by those with disabilities. When you go to the Accessibility settings page on your Android device, you'll see an array of controls that Google has enabled by default. Some of the items here include the likes of tapping items on your screen to have your device read them out to you, spoken feedback that reads aloud all of your actions, increasing the size of items on the display, etc.
As expected, the general theme here is to make Android easier and simpler to use for people that need some extra assistance.
In addition to the services that are built into Android by default, developers can tap into Accessibility Services with their own apps to create new features that take advantage of them. On the Android Developers site, Accessibility Services are described as follows:
Why some apps use them
Although the main goal of Accessibility Services is to allow developers to create tools targeted at individuals with disabilities, we've seen a number of apps over the years that have tapped into this resource to create expanded features that can technically benefit everyone.
For example, LastPass's App Fill reveals an overlay on top of whatever screen or other app you're on so you can easily add username and password information without having to open up the full LastPass application. Clipboard Actions also taps into Accessibility Services so you can more easily manage links you've copied and take action on them without having to be in the full Clipboard Actions app.
This is a method that developers have been using for quite some time now, and while it technically works, it does create for vulnerabilities that Google doesn't like to see.
Google's reasoning for the new limitations
As great as Accessibility Services can be when used legitimately, it's also possible for the service to be used maliciously. Apps that use Accessibility Services open up greater security threats than ones that don't, and this leaves devices at risk for attacks.
Shortly after Google announced the decision to limit applications that can use Accessibility Services, it was discovered that the change was likely connected to a "toast overlay" attack that had been discovered by security firm TrendMicro. Essentially, the toast overlay attack allows malicious apps to display images and buttons over what should really be shown in order to steal personal information or completely lock users out of their device.
Apps using this toast overlay attack have since been removed from the Play Store and a patch with the September Security Bulletin resolves the vulnerability, but this is just one example of how an app tapping into Accessibility Services can cause serious damage.
The future is APIs
Apps that are using Accessibility Services to help the disabled in legitimate ways will continue to exist, but for those that aren't targeted at this specific demographic, Google has a solution – APIs. In the example of LastPass, the new Autofill API with Android Oreo allows LastPass to offer similar functionality to its Auto Fill feature without having to use Accessibility Services.
This does mean that users need to be running newer versions of Android to access all of the features of some of their favorite titles, but at the end of the day, your functionality is remaining while also cutting down on possible security risks.
We understand the annoyance that some users have towards this change, but when looking at it from Google's perspective, it's a move that just makes sense. Accessibility Services were never intended to be used for a large portion of the ways that certain devs are tapping into them, and it's something that Google needs to crack down on.
At the end of the day, once apps get updated to support Google's numerous APIs, we'll get similar features with greater protection from attacks. What more could you ask for?
I use RoboForm that makes use of accessibility and I enjoy the functionality. Nevertheless, I applaud Google for making this move.
This was a great article. I had read about Google doing this in another article, but I didn't really understand what the big deal was. Thanks for breaking it down for us plebes. My only question now is what is an API?
Application Programming Interface. These are used by programmers mainly. Simply speaking, it's a one-line code which can be used to do a certain task without knowing how the line of code is actually working.
It's like calling a plumber to fix your faulty tap. You don't know how he is going to fix the tap but all you know is that he IS going to fix the tap.
The Accessibilty API is also used by disabled people to customise their phones, and despite what the propaganda says, this clampdown threatens the apps that we use. Google is putting its own interests first and disabled people like me will suffer. ... ... unless someone at Google develops compassion instead of algorithms
"What more could you ask for?" How about Google stop finding ways to turn Android into something as useless as iOS? Or how about asking Google to tighten the control over what apps get published on the Play Store? We all know Updates on Android are a sh*tshow. With this sort of reaction what Google achieves is nothing more than royally f*cking people who actually heavily rely on things like LastPass. Because the majority of those people will very likely not have a phone with Oreo or the new API's. And won't get it. There's no reason, for example, for someone with an Xperia Z3 that's fully functional to swap phones if they don't need to. But the Z3 was left on Marshmallow because of Google. The Z5 will be left on Nougat. Why should people be forced to change from phones that are fully functional just because Google decides to screw them over? What can be done? Well, LastPass can provide the apk for separate sideloading or use an alternative store to the Play Store. If Google tries to prevent that too, well, as a consumer, the message I get is: Android is slowly losing any advantage over iOS. Might as well just switch to an iPhone.
How is Sony not updating their phones to newer versions of Android the fault of Google? Google doesn't build Sony's phones, and it's not their responsibility or charge to force OEMs to do upgrades. If Google tried to force OEMs to upgrade, they'd be sued by every OEM and the government for meddling in other companies business practices. Place the blame where it belongs. Sony decided not to update the Z3 and Z5 to the latest versions of Android. Google provides the basic OS. It's up to Sony to use it. If Sony decided it wasn't worth it to them, that's on Sony, not Google.
Actually you're dead wrong.
Sony didn't update the Z3 to 7.0 because Google - no one else - decided to exclude phones with the snapdragon 801 from certification by changing the CTS and demanding support for Vulkan or OpenGL ES 3.1. The 801 had OpenGL ES 3.0. That's why Sony dropped the phone and didn't update it before the 2 year of updates expired. So yeah, we CAN blame Google. Also, OEMs don't have legal basis to sue Google if they demanded the phones to be updated. Google only had to make that a requirement for Play Store certification instead of demanding a bunch of bloatware to be pre-installed. So, again, Google's fault.
"At the end of the day, once apps get updated to support Google's numerous APIs, we'll get similar features with greater protection from attacks." This is misleading. Many features that apps use Accessibility Services for don't have a comparable API they can be replaced with. For example, Button Mapper and AutoInput can't use anything other than Accessibility Services for what they do.
"At the end of the day" doesn't quite cut it for me. Google is cutting off accessibility now. In two years time if I decide to upgrade my phone maybe, but probably not an equivalent API will be available. It's like your car manufacturer saying 'we didn't intend you to use your cigarette lighter socket to charge your phone, so we're disabling it in all cars". But don't worry guys we have a new charge socket in our 2018 models. For those of us using apps like tasker this will ruin our android experience. I am also not sure how they can determine if a person with disabilities benefits? Just like the cigarette lighter socket, accessibility has been used for years for other uses. Google has waited until an entire eco system has built up around the API then they cut it off? Good security choice bad implementation.
Hi I have Parkinson's Disease. This is a personal attack on my quality of life. The problem here is that Google forgets that disabled people use apps like Tasker and the AutoApps plugins to customise their phone to meet individual special needs. It's cruel that they sing their own praises on accessibility, yet deal with the disabled via automated soulless emails or a wall of silence. All this needs is to approve Tasker and the AutoApps.
Wrote some requests related to this issue here:
Please consider starring them and optionally write your insights there
"once apps get updated to support Google's numerous APIs" what a load of bunk. The auto fill API is currently available on 0.3% of Android phones. A year from now it will likely be available on less than 20%.
Get the best of Android Central in in your inbox, every day!
Thank you for signing up to Android Central. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.