GET_ACCOUNTS permission while using GCM - Why is this needed?

android push-notification google-cloud-messaging

42,030

Solution 1

It uses an existing connection for Google services. For pre-3.0 devices, this requires users to set up their Google account on their mobile devices. A Google account is not a requirement on devices running Android 4.0.4 or higher.

SO this is the reason for requirement of the permission

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

to read Google account.

Solution 2

The GET_ACCOUNTS permission is no longer needed for GCM to work. It used to be required for registration to GCM, but a recent Play Services update stopped using the Google account even on Froyo and Gingerbread. If you are registering to GCM with Play Services (i.e. With GoogleCloudMessaging.register), you no longer need this permission on any Android version. If you are using the deprecated library (GCMRegistrar.register), you still need a Google Account on pre 4.0.4 version, which requires that permission.

Source (posted on android-gcm Google Group by a Google developer) :

Some background:

Froyo and Gingerbread registration is implemented in GoogleServicesFramework, using the Google account for registration. This has resulted in a lot of auth errors for people where the account was not in a good state.

Starting with ICS, GCM doesn't depend or uses the Google account - you can use it before you add an account or without any accounts.

The "Play Services" update is implementing the new scheme on all devices - but it seems a small number of devices have problems with this, we're investigating - but the numbers are far lower than those with the old scheme.

Solution 3

As everyone else here has said, GET_ACCOUNT is needed for android devices lower than 4.0.4.

If you are like me and have installed a library that automatically adds this permission but you do not need it to, you can tell the AndroidManifest to remove the permission by adding the permission with the tools:node="remove" attribute.

In your AndroidManifest.xml file, make sure the xmlns:tools attribute it defined in your manifest tag and then add the permission with remove set:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          xmlns:tools="http://schemas.android.com/tools"
          ...>

  ...

  <uses-permission android:name="android.permission.GET_ACCOUNTS" tools:node="remove" />

  ...

</manifest>

Word of warning that this never actually works for me but I know it has worked for others. If you can see what I might be doing wrong or have any more info about it, please comment!

*Edit: There is a bug report open to get this feature working: https://bugzilla.xamarin.com/show_bug.cgi?id=48153

Solution 4

when you use

compile 'com.google.android.gms:play-services:7.5.0' add the build.gradle file means GET_ACCOUNT permission added automatically.

forexample if developer have to use only admob in project means only specify this permission in build.gradle file compile 'com.google.android.gms:play-services-ads:7.5.0' if have any another clarification see this link https://developers.google.com/android/guides/setup

Solution 5

I don't think this is actually the case. I tested it on a freshly factory reset Gingerbread device with a new Gmail account and I could receive GCM messages just fine without that permission. So the documentation is WRONG.

View more solutions

42,030

Vamsi Challa

Updated on July 09, 2022

Comments

Vamsi Challa almost 2 years

I have an app, with Push notifications implemented.

I want to understand the reason why we need "GET_ACCOUNTS"(android.permission.GET_ACCOUNTS), while implementing GCM? Some users are raising concerns with this permission. I have used this permission in the manifest as it was given in the official site here.

How safe is this permission? and if I remove this, from my manifest, will the push notifications work?
- 323go over 10 years
  
  Have you tried push notifications without GET_ACCOUNTS permission? It seems that it'd be faster to try it than to ask and wait for a reply. Once you know, please post your results as answer.
- Brinda K over 10 years
  
  GET_ACCOUNT is to verify if user synced Google account in mobile, and generate the key value for each user(each Google account). This is required if the device is running a version lower than Android 4.0.4.
- Vamsi Challa over 10 years
  
  Okie.. is there any other way of doing this, other than keeping this in manifest?
- markostamcar over 10 years
  
  For me it works without that permission just fine on any OS.
Vamsi Challa over 10 years

Okie.. is there any other way of doing this, without giving this in manifest?
CommonsWare over 10 years

@VamsiChalla: All permissions must be in the manifest. However, if your android:minSdkVersion is set to 14 or higher, I would interpret the documentation as meaning that you would not need this permission.
Pankaj Kumar over 10 years

No. This task is to be done by Google Services, your application can not varify. And other thing is that when you want to read Accounts in Android, this permission will be required. SO at last you have to add this permission. Although you can add some description about this permission in your info page of application, to be clear with user.
Android Developer over 10 years

Without using get_accounts permission for below android version 4.0.4, the notifications doesnot received or it will crash the app?
Will Calderwood over 9 years

Please read the answer from Eran. This permission is no longer required on any device. Eran's answer is now the correct one.
efeyc about 8 years

@CommonsWare why 14 or higher? Shouldn't it be 16 or higher if we are talking about 4.0.4+
efeyc about 8 years

@CommonsWare, ok you are right, I thought version 15 is only 4.0.3, then I realized it is both 4.0.3 - 4.0.4
Devesh almost 7 years

Seems to be old post but it was not working for me either. So what I did was after reading the android documentation added this additional property in the user persmission android:maxSdkVersion="SOME NUMBER OF API THAT YOU DO NOT SUPPORT" along with the tools:node="remove". It worked for.
hvaughan3 almost 7 years

@Devesh Nice thanks for the extra info. I also edited my post and added the bug report for this feature.