IssueTracker

we are having a look at the issue you reported, will update this issue with more information as it becomes available.

Yes this one is really annoying as users will think that the app want to access contacts while it just want to enumerate accounts. A possible workaround is to preemptvely explain at runtime to the user that the GET_ACCOUNTS permission will ask for 'accessing contact' but this is really convoluted and confusing and just plain unnecessary. That's the biggest issue with the permission categories descriptions: they may not match the underlying individual permission asked.

There is no plan to break out GET_ACCOUNTS in its own component in the Android M. However, this may be considered for future releases.

Sorry, but this is broken behavior. I think many apps require GET_ACCOUNTS for all kinds of reasons while having nothing to do with contacts at all.

We have plenty of apps that need this permission and don't do anything with contacts. Now we need to explain to users why these apps won't work without "Contacts" permissions. This will increase our support costs and may reduce user satisfaction, just because of Google's ignorance ...

This is definitely not "working as intended", in terms of runtime permissions philosophy. Guys, I know this needs SDK level bump but I think that - taking into account that this has serious consequences when it comes to the end-user experience - this is worth it and it's better to do this sooner than later.

For getting "your own" accounts, you can do that:

<uses-permission android:name="android.permission.GET_ACCOUNTS" android:maxSdkVersion="22"/>

on Android > 22 you don't need the permission (as long as you just need accounts from your own account type)

This works also for:
AUTHENTICATE_ACCOUNTS, MANAGE_ACCOUNTS and USE_CREDENTIALS

@8 Not all apps need to create their own accounts. Sometimes they need some kind of identification (like the payload for purchases), and this one is the only thing that doesn't change for the same user.

@10 I wasn't argumenting against it, just saying that this is an option for those who only handle "own accounts"

@11 Oh ok. Thank you .

Couldn't agree more with above.  Getting a user's accounts can be used for identifying the user and has nothing to do with Contacts.  Many of Google's own services require getting the user's google account to authenticate with apis.

GET_ACCOUNTS permission got deprecated in N Preview 1:

"GET_ACCOUNTS (Deprecated)
The GET_ACCOUNTS permission is now deprecated. The system ignores this permission for apps that target Android N."

Does it mean that there will be no possibility to obtain accounts of the other apps on Android >=N? :(

Prepared simple test application targeting N and apparently there is no difference in behavior comparing to M (tested against Nexus 9, N Preview 1).

@15 Well maybe they didn't change it yet.

Please move it out of the contacts group. It makes my app like a spy but actually I am just trying to get a quick user ID.

I have no idea how they will handle it, especially that now it's a part of Contacts category in Marshmallow.
It should have never been there.

[Comment deleted]

[Comment deleted]

[Comment deleted]

BILLION DOLLAR COMPANY and fucked up documentation.

Sadly, the only solution for now is to keep on targeting SDK version 22
And it's very, very sad to be forced to do so…

@23

Or you can explain to your users beforeand (popup dialog) what you need this permission for, and that it has nothing to do with 'accessing contacts'.
A bit cumbersome but better than nothing.

Variant: explain what you need this permission for only if the user deny the permission, with the ability to request it again.

My comments are not being published for very long time. After i upload a comment i get a message " thank you for your comments. It will be published after it is scrutinised by moniters" But it is never published  what is the reason? Is it to do with permission? How does one give permission to NDTV?

Debug otg camera.

Hi doe's anyone find workaround for this?
Request read contacts permission is unacceptable for me. and the workaround suggested here didn't worked for me.
Thanks

I am not able to login with Google in Android 6.0 if there GET_ACCOUNTS permission is not granted.
For Lollipop & below it is working fine. Why google login require this permission.

[Comment deleted]

READ_CONTACTS and GET_ACCOUNTS should definitely be different permissions. It is not acceptable to give user the impression that we are spying on her contacts when all we need is her ID.

I notice most/all of these comments are from developers, so I wanted to give my input as a user. Even though I understand all this, and know how it works, I still hesitate and sometimes refuse when an app asks for a permission seemingly unrelated to what it actually needs, such as in this case. I think this is beyond ridiculous to have been set up this way, and it should have NEVER made it out the door. Google keeps doing stupid stuff like this and turning people off, and I really wish they would get their act together. The real problem here is the use of the permissions groups. It is a major security issue that granting just ONE permission in a group grants the ENTIRE group, and an even bigger security issue that because of this, not only is the security provided actually pretty pathetic, but it MAKES THE USER THINK THERE IS A MUCH HIGHER LEVEL OF SECURITY THAN ACTUALLY EXISTS. Shame on Google for this.

I'm more knowledgeable than most regular (non-dev) users about this stuff, and I pay attention to permissions more than most. But as I said, even understanding these limitations, I still don't like to grant permission to my contacts when an app doesn't need that permission. As a user, the best advice I can give is to be as transparent as possible. Some of my pet peeves are related to lack of transparency: new permissions with no explanation given (especially when they're snuck in), updates with no 'What's new' section or without updating it, questionable permission requests. So hopefully those devs that read this will start changing their ways, and maybe even get a trend going. I'd suggest listing all permissions requested and their purpose (descriptive, in English, not one or two word BS or technical jargon) in the app description (ideally) or a link to a website with that information, and an explanation in 'What's new' every time a new permission is added. It's too bad Google refuses to take the initiative and require these things, but, then again, they're one of the worst offenders.

Why is this issue closed?!  This is still a pretty pressing and sever permissioning problem.

-_-

Wow...as an end user, this is appalling... Whey do I need to give a "Notes" application access to my Contacts?  OOoohh... because it needs access to my IMAP account login to grab the notes from my IMAP server...  Therefore it needs access to my Contacts... genius...so clear.

Yeah that's just plain idiotic.  

And to any Google dev that thinks that the App Dev should just post a note letting me know why they need that permission... THEN WHY HAVE PERMISSIONS AT ALL....  "Gee... this app dev needs access to my Contacts for a completely unrelated reason than to spy on my contact list and spam everyone... gee ok...sure I'll just take their word that they won't do anything shitty to my contacts... here have full permission."  

Seriously?  And closed won't fix...   Thats some seriously stupid "security" thinking.

Apps which access google sheets and drive apis need GET_ACCOUNT permissions as per google api docs, but from end user point of view, they are scared to share phone contacts with app just because of this bug.
I think it's better to fix or provide workaround for this issue.

Why is this marked fixed?!  I think this is still not fixed.

Google is not respecting data privacy laws in Germany with this choice. I am very disappointed. May have to move back to apple after all. - End User

Shame that Google does not take this seriously. end user with a little bit more knowledge

Please consider a better way to handle this issue. As an end user, it makes me disallowed this permission in many apps. As a developer, I need to abandon AccountManager since GET_ACCOUNT is required, and my users will not grant this permission. Writing a prompt msg before asking the contact permission to explain the reason is bad, you should not expect a normal user can understand the relationship between getting a user account and the contact list.

Combining the GET_ACCOUNT and contact permission maybe logical in technical points of view, and easy to implement. However, as a product and part of the user experience, it doesn't perform well and clear to the end users.

Google should consider a better way to deal with this permission, maybe just prompt a different message.

Marking this issue as fixed is very disappointing, maybe this issue is not easy to fix or change, but at least, Google should show the attitude that they are trying to improve both users and developers' experience.

I have the very same issue and I am receiving lots of bad reviews from people that thinks my app is spying them and from people that are not able to login because they refuse the permission and blame my app login mechanism.
Pretty much 90% of 1* reviews that I have received are caused by this issue that IS NOT FIXED.

You don't need this permission anymore on Oreo to enumerate accounts, so it is sort of fixed there.

To Google, how many users denied app permission just because of that misleading message? Who in charge should be getting fired.

My app same like other comments, give 1 star and probably uninstall just because of that misleading message. Who in charge should be getting fired.

Have any of the developers wanting (well, more like demanding this) submitted a patch? (Hint, hint!)

This issue is sort of resolved. Since SDK Level 26 (Oreo) GET_ACCOUNTS is no longer relevant. Account visibility is no longer determined on the basis of a permission but on a per account basis. So either the app which manages the account has to grant visibility to your app or your app has to request it from the user.

See https://developer.android.com/reference/android/accounts/AccountManager#getAccountsByType(java.lang.String) and https://developer.android.com/reference/android/accounts/AccountManager.html#newChooseAccountIntent(android.accounts.Account,%20java.util.List%3Candroid.accounts.Account%3E,%20java.lang.String[],%20java.lang.String,%20java.lang.String,%20java.lang.String[],%20android.os.Bundle).

@44 Interesting. Is there a sample for this?

Yeah, I'm an end user with Android development experience, and this is broken. I'm here through the same mechanism as other users: Turning off "read contacts" permission by default for everything, only to discover that there's actually a bunch of nonsequitor permissions misleadingly rolled up with it. I like the "push a fix" post, but it's clear he doesn't know what Android's development is like, where at-google-dot-com people push code to fortify their monopoly to the exclusion of all other code. And since code is just, well, codified business logic, this tight control is necessarily also to the exclusion of all other ideas. It's a monoculture that sorely lacks in diversity. Though not all is lost, for I do find a great sense of schadenfreude in all instances of project members silently wontfix-ing braindead issues and subsequently ignoring all other posts. Or at least ignoring all the posts they don't delete.