Tech —

Android 6.0 Marshmallow, thoroughly reviewed

Marshmallow brings a lot of user-requested features but still has no update solution.

Permissions

App permissions popup, the permissions setting for Chrome, and the "Never ask again" checkbox that appears when an app asks for a permission a second time after being denied.

Updated apps, like Twitter and Google Camera, tell the user that they are broken because the user turned off a certain permission. Facebook hasn't updated, so it is broken and the user has no idea why.

A few more "This is broken because you denied a permission" messages from Google apps.

Press the gear on the "Apps" screen and you get the "Configure apps" screen. From here you can see a list of permissions by type, which makes blocking everything from a certain permission or taking an inventory of who-has-access-to-what easier.

"Draw over other apps" is a new permission too, but it gets a separate spot on the "Configure Apps" screen rather than being a permission in the permissions list. We're not sure why.

If you want to see a list of all the apps, press the overflow button and pick "show system." Denying permissions to these apps is probably a bad idea, though.

Warning messages for changing permissions with an old app and a system app.

One of the biggest additions to Android 6.0 is the new permissions system. Users can deny apps access to certain parts of the system, and apps that target the Marshmallow SDK will now ask for permissions on-demand, instead of in a big brick at install time.

Google has been experimenting with configurable app permissions since Android 4.3 through a hidden interface called "App Ops." App Ops worked a lot like the permission settings that are in Marshmallow now—it was a big checklist of permissions for each app. Google disabled App Ops shortly after it was discovered, saying that the system was never meant to be exposed to end users and that it would cause too many problems with existing apps. Disabling the wrong permission could cause an app to stop working or just crash outright. Users would never be notified when a permission was blocked, making it possible for a user to mess around with App Ops, break something, and not know why something was broken or how to fix it.

The difference between Android 4.3's App Ops and Android 6.0's permissions system is that developers and users both get informed of what is going on. Apps—even old apps—shouldn't crash because they were denied a permission. Apps that support Android M's permission system are notified and can react to a permission denial. In these new apps, the user gets more information to make a decision, and if something breaks, the user gets told why it is broken.

Apps that target the new SDK and are installed on a 6.0 device won't ask for any permissions at install time. That's right—the "install" button in the Play Store will actually install the app now. Apps can request permissions one-at-a-time in a system-provided pop-up, usually along the lines of, "Allow Chrome to access the Microphone? Allow/Deny." "Allow" counts as granting access forever, while "Deny" is a one-time rejection. The second time an app asks for a permission, a new checkbox will be added to the permission pop-up—"Never ask again"—which will make the denial permanent. Of course, permissions for any app can be changed at any time in the permissions settings.

As a side note, it's important to know the difference in Android between "targeting" an SDK and what that has to do with the minimum supported Android version an app will run on. The short answer is nothing. If an app targets the Marshmallow SDK, it doesn't mean it will only run on Marshmallow, it means that the app is aware of the new features and can use them. Apps have a "target SDK version" and a "min SDK version"—basically the newest and oldest Android versions that an app supports. Any competent app will gracefully degrade on older Android versions.

The permissions pop-ups can be displayed either at runtime or on-demand when an app needs a permission. When this happens is up to the developers, but Google recommends that developers request "critical" permissions at runtime and save permissions for "extra" features for an on-demand pop-up. For instance, Google Hangouts will request SMS access as soon as you start it up, but camera or location permission pop-ups would only happen when the users press their respective attachment buttons. These clearly inform the user of what the permission is for. Obviously a chat app wants to access your SMS, and it's requesting camera access because you pressed the camera button. If a permission's usage is less than obvious, developers are encouraged to "pitch" the user on why an app needs a permission in a "warm welcome" startup screen.

Informing users is a key part of this new permissions system. When a user denies a permission, the app is informed about it. Then if something isn't working, the app can put a message on the screen that says something like "Hey, this feature is broken now because you denied access to this permission." For instance, if you permanently block Twitter's access to your camera roll and try to attach a photo, the Twitter app will throw up a full-screen message that says, "It looks like you have turned off permissions to attach media." It then explains to the user what permissions it needs and even provides a handy link right to the app's settings so the user can turn the permission on. The UI for a message like this is up to the developer, and from what we can tell Google doesn't provide any recommendation on how to do it. We've seen everything from interstitials to toast messages to lower thirds.

Press on the gear in the upper right corner of the "Apps" screen and you'll get to the "Configure Apps" screen. From here you can view all apps that have access to a certain permission. For instance, if you wanted to block absolutely everything from accessing your location, you can do that. The "Configure Apps" screen will also show special permissions like "draw over other apps," which is used for things like Facebook Messenger's "Chat Heads."

Permission changes take place right away, and Android actually kills any background processing for an app if an existing permission is denied, the same way it would in a low memory situation. This prevents users from turning off an app permission while an app is using the permission, which could result in some odd behavior. Every app already has a plan in place to deal with a low-memory shut down, so this shouldn't cause any problems. Permissions are unique to each user, so if anyone out there is actually using Android's multi-user mode, one person granting a permission doesn't affect anyone else.

Pre-installed and OEM apps will be subject to the permissions system, too. Just like third-party apps, these will ask for permissions at run time. A few core system apps that are hidden under a "system apps" flag are accessible from the overview menu in a permissions list. This will surface things like Google Play Services and system components. Try to change the permissions for these apps and a warning will pop up saying that this is a bad idea. You're free to ignore the message and mess with whatever you want, though.

For some cases, developers don't actually need to request permissions for things that are covered by a system intent. For instance if an app just needs to take a one-time picture, a system intent can push the user out to the system camera app, and they can press a button to take a picture, which the app receives. This doesn't require a permission because the user is the one pressing the buttons. Contrast a one-time camera picture capture session to an app having background access to the entire camera roll, which would require a permission. The same goes for other system intents like selecting a contact or starting a call.

Old apps that don't target the Android M SDK will still show a big list of permissions at install time. The biggest change is that old apps that are denied a permission shouldn't crash like they did with Android 4.3's App Ops. Rather than block access outright, old apps are fed fake data that doesn't give away any user information. For an old app that has been denied access by the user, the user has zero contacts, their location isn't available, and there aren't any pictures—these are all valid error states that will result in a blank UI, instead of an outright crash to home screen.

The bad news is that if the user forgets that they have changed an old app's permissions, they won't be informed why an old app can't display their pictures. This makes messing with the permissions of an old app a risk, so Android shows a pop-up when trying to edit the permission of an unsupported app, warning the user that it could cause problems.

One of the bonuses of the new permissions system is that updates can always happen automatically now, even if an app is asking for more permissions. Previously, an app that asked for a new permission would have its update halted until a user tapped on the "new update" notification and approved the additional permission. Since app permissions aren't asked for at install time anymore, the app can just update, and any new permissions will be asked for when the user runs the app.

In Marshmallow, apps no longer get access to a device's Wi-Fi or Bluetooth MAC address by default. Since these were unique to every device, they could be used to identify and track users. Android 5.0 hides them behind the ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION permissions. To stop older apps from crashing when they try to query the MAC address, apps without one of the location permissions will get a fake MAC address. MAC addresses get hidden from external devices, too. When Android does a background Wi-Fi and Bluetooth scan, (for finding open networks or Eddystone Bluetooth beacons) the scan spoofs the MAC address and identifies as a randomized value.

Another change to the Android permission system is that every app automatically gets access to the Internet now, and users have no way of turning this off. Google's rationale is that because it is preventing apps from accessing user data, there is no reason to limit them from accessing the Internet. Apps also need Internet access to display non-Google ads (Google ads travel through Google Play Services), crash reporting, and analytics.

We'd imagine many users would still want to control what apps have access to the Internet, even if those apps supposedly don't have access to user data. This isn't only a matter of security and peace of mind, but locking down Internet access also lets users better manage their data cap. There is really no reason for a simple app like a flashlight or calculator to have access to the Internet, but under Android Marshmallow, they will.

We'd also like to see the permissions settings get a more obvious top-level section in the settings. Currently, they're buried in Settings -> Apps -> [app name] -> Permissions, which ensures no one will ever find it unless they know it is there. The permissions settings also don't display all the special access an app can have, which is a little confusing. The following special access settings sure feel like "permissions," but they aren't available from the permissions screen:

Draw over other apps: This permission does exactly what it says. It's used for floating apps like Facebook's Chat Heads. You won't find it in the permissions screen, though; this is in "Settings -> Apps -> Configure Apps (the gear button) -> Draw over other apps."

Accessibility: This lets apps "observe" your actions, read the screen, and have a bunch of other access to the system. It was intended for things like screen readers, but a lot of utility apps make use of it. Rather than live on the permissions screen, this one is under "Settings -> Accessibility."

Notification Access: This lets apps read all your notifications and is good for something like Android Wear. This won't be listed in app permissions though, it's off to "Settings -> Sound & notification -> App notifications."

Do Not Disturb Access: This is a new one. We would guess it lets apps change the "Do Not Disturb" settings on your phone. "Settings -> Sound & notification -> Do Not Disturb access."

Modify System Settings: This is another new access setting, and a surprising amount of apps have access to it. This is used to do things like read your current settings, turn on Wi-Fi, and change the screen brightness or volume. It's another permission that isn't in the permissions list. It's in "Settings -> Apps -> Configure Apps (the gear button) ->Modify system settings."

Device Administrators: This is usually for remote wipe apps. This one's in "Settings -> Security -> Device Administrators."

Tap and Pay: Only one app gets to be your default NFC payment app. This is in "Settings -> Tap & Pay."

This could be cleaned up. We'd like the permissions screen to be a single point for all the special access an app has, regardless of what small differences exist under the hood between the standard permissions listed on the "permissions" screen and these special access features. They're all just privacy controls after all, and merging them under one big "app access" dashboard would clean up the settings a bit.

Overall though, the new permissions system is a huge improvement over the all-or-nothing approach Android had previously taken to app permissions. Users can now provide informed consent to access their data, and app developers are kept in the loop about user decisions and can have a dialog with the user about why the app needs access to certain things. Even the rollout was handled well here. Thanks to the Android M Developer Preview, the permissions system has already been out for several months, so apps that aren't abandonware should be updated quickly.

Share this story

Ron Amadeo
Ron is the Reviews Editor at Ars Technica, where he specializes in Android OS and Google products. He is always on the hunt for a new gadget and loves to rip things apart to see how they work. Emailron@arstechnica.com//Twitter@RonAmadeo