Android 6.0 Marshmallow technically is all of a week old. (Less so if you count the date of the code drop, I suppose.) But it's been in developer preview status for months, and developers have been able to submit apps that use the new API level (and thus the new permissions) for a little while now.
So if you're running Marshmallow on a Nexus phone (and you really should be), you'll start running into the new permissions scheme as apps are updated. One of my first instances of this was with Twitter. (And kudos to Twitter for being one of the early ones.)
How Twitter does it ...
Consider this screenshot, which you'll see when you open up Twitter for the first time. Twitter would like to use my current location to customize my experience. OK, why not. I like my location, and I like better experiences. I'll allow it.
Then the new permission in Marshmallow kicks in. Do I want to give Twitter access to the thing I said I wanted to give it access to? Yes, I do. Which is why I hit OK the first time.
The thing is, Twitter's first dialog box doesn't actually have anything to do with actually allowing the permission for my location. It just triggers the system dialog. But it is worded a little more friendly than the Android permission dialog.
Twitter: "Twitter would like to user your current location to customize your experience."
Android: "Allow Twitter to access this device's location?"
Two permission-like questions that ask the same question — but only one actually allows anything.
The former tells me what it wants to do — and more importantly why it wants to do it. The latter is mostly the same sort of simple-but-vague permission-speak we've come to loathe from Android. And it sort of needs to be, I suppose. But that's where the app requesting the permission — that first dialog box from Twitter — becomes even more important. Instead of immediately giving me the "Don't allow/OK" option, Twitter should take another sentence to tell me what's next. "Twitter would like to user your current location to customize your experience. If you're cool with that, click 'allow' on the next screen." Or something to that effect. Then you've got better context for the permission request, and the user is prepared for what's coming up — and it's not so repetitive.
That's two hard stops on the user, and that's tough. But it's a one-time pain point. And it's worth it, I think, to get us to pay a little more attention to the dangerous (that's the technical term) permissions apps may require. On the other hand, iconography and context may mean you don't need to tell me that you're about to ask permission for the camera, since I just tapped the camera icon.
Here's how Google puts it:
In some circumstances, you might want to help the user understand why your app needs a permission. For example, if a user launches a photography app, the user probably won't be surprised that the app asks for permission to use the camera, but the user might not understand why the app wants access to the user's location or contacts. Before you request a permission, you should consider providing an explanation to the user. Keep in mind that you don't want to overwhelm the user with explanations; if you provide too many explanations, the user might find the app frustrating and remove it.
How Facebook does it ...
Let's take a look at how Facebook — another app that's already updated for the new permissions.
Ahhhh, the rare double permission request. This is what you get from Facebook when you hit the camera icon for a new status update. OK, I cheated a little — you get this double notification if you deny the storage permission the first time, when it's trying to populate the thumbnails of what's in your gallery. But it's nicely done. Facebook tells you what it wants, and why it wants it.
And then you get to repeat yourself again. Yes, I'd like Facebook to have permission to ask my phone to do something.
But, again, it's that first "Allow" button I have a problem with. It doesn't actually allow anything other than the system dialog to ask you the exact same thing again. And you only have to do it once.
How Hangouts does it ...
Here's one more example, this time in Google Hangouts. Hitting the camera or gallery icons within a conversation will only trigger the system dialog. There's no superfluous request ahead of the actual one that grants the permissions. (And, again, I'd argue that that's fine. When I tap a camera icon, getting a request for the camera permission already has context.)
Where I think Google really did a nice job was with this first-run explainer for the contacts permission, which flat-out is necessary for the app to work at all. First it says why it needs access to your contacts. Hitting "Next" then presents the system permission request. That it says "Next" and not "Allow" is what's really important there. One flows into the other. You obviously don't want to do every permission request full-screen like this. But for something important enough to be presented at first run, it's very nicely done.
The switch to runtime permissions is a big one, and important. But they may be a small learning process.
I'm admittedly making a bit of a mountain out of a molehill here. You only have to go through this the first time for an app. But permissions are important. (And I think the switch to runtime permissions is a good one.) An explanation of permissions is good. Even the double-stop can be overlooked in the name of making you look before you leap. Explain the permission to the user, just don't make them think they've already allowed it once, only to make them actually do it a step later in the system request. I just don't like repeating myself is all.
And as always, you're free to revoke permissions whenever you want. If you do so, the app will ask your permission again the next time you try to use that functionality.
Point is, we as users have something new to get used to here. But so, too, do app developers.
Update: For a more technical listen of all this — and, by the way, confirmation that the way Facebook and Twitter are doing things isn't quite ideal — check out Episode 33 of the Android Developers Backstage podcast.