Mobility

Google steps up in the war against Android bloatware

With Marshmallow, Google ups the ante on permissions. But is it enough to prevent OEMs and carriers from adding bloatware to Android devices? Jack Wallen weighs in.

bloathero.jpg
Image: Jack Wallen

Before you get too excited, Google is not preventing OEMs and carriers from adding their wretched bloatware to Android devices. However, Android 6.0 Marshmallow will include a brand new permission system that allows the end user to determine what systems and data an app can access.

Until now, it has been unclear whether OEMs and carriers would be able to circumvent this new feature to abuse it and grant permissions to their bloatware. The text in the Marshmallow Compatibility Definition Document is very specific:

Permissions with a protection level of dangerous are runtime permissions. Applications with targetSdkVersion > 22 request them at runtime. Device implementations:

  • MUST show a dedicated interface for the user to decide whether to grant the requested runtime permissions and also provide an interface for the user to manage runtime permissions.
  • MUST have one and only one implementation of both user interfaces.
  • MUST NOT grant any runtime permissions to preinstalled apps unless: the user's consent can be obtained before the application uses it or the runtime permissions are associated with an intent pattern for which the preinstalled application is set as the default handler.

What this means is simple: While an OEM or carrier might be able to replace, say, a dialer with their own version and grant it permissions without user interaction, they cannot grant permissions to the bloatware for the user. The OEMs and carriers must provide an option for their bloatware that enables the user to enable/disable permissions for the app. This puts the onus on the end user to be responsible for granting or denying that app the necessary permissions.

Way to go, Google!

This is a very important step forward in preventing OEMs and carriers from adding bloatware to devices, which is a practice that needs to be curtailed completely. No, this doesn't empower the user to remove bloatware, but it does give them control over whether those pesky apps can do anything of significance. So if you "accidentally" run one of those apps, they won't get a chance to dive into and mine your data.

Less choice for the OEMs = more choice for users.

This also isn't a guarantee that OEMs and carriers won't find a loophole; they could always target a lower API and grant the necessary permissions — providing the app in question doesn't require an API 23 or higher. I hope Google can close that loophole and prevent further OEM shenanigans.

The end of rooting?

Imagine this scenario: You install an app that requires root permissions. When you first fire up that app, instead of the app checking for root, it could ask the user to give it the necessary permissions to run.

That scenario could cause a lot of trouble for end users and Google, so my guess is that the new Android permission system will not do away with the need to root a device.

I believe the permission system shipping with Marshmallow will go a long way to solve a number of issues. Hopefully, it will give end users the power to deny bloatware any functionality.

What do you think?

Is the new permission system enough, or should Google go further to prevent OEMs and carriers from adding bloatware? Let us know in the discussion.

Also see

About Jack Wallen

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website jackwallen.com.

Editor's Picks

Free Newsletters, In your Inbox