Why do so many applications require permission to read the phone state and identity?. Specifically:

Phone calls
   read phone state and identity

For example Quickpedia is a Wikipedia portal, but wants access to the phone. What is the explanation for this?

enter image description here

  • Its not really, for "yeah yeah, this app has this permission to send sms and ring a premium number behind your back" which is what people assume. @Christian's answer below has hit the nail on the head! It is legitimate in a lot of cases, and quite often, devs tend to forget about whittling down the permissions (perhaps a hold-over from the early days of development of an app).
    – t0mm13b
    Aug 14, 2012 at 18:47
  • 1
    @t0mm13b I don't think there's much of a demand for reduced permissions outside of techies and privacy geeks (self included). So if app makers just make it the norm to require the full suite of permissions, then consumers will assume lots of permissions are fine for any app. Government is not pressuring them to use minimum permissions, and so far the market is not pressuring them. I.e. there is little-to-no cost for apps to require lots of permissions.
    – user29020
    Jan 19, 2015 at 0:26

5 Answers 5


It allows the App to read a unique ID (a phone identifier named IMEI) that's associated with your phone.

It can therefore help with copy-protection or the attempt to track the number of users.

  • 3
    See this SO question about getting a unique ID of a phone, looks like the (currently) most reliable way for a developer to get a unique ID from a phone requires the Read Phone State permission stackoverflow.com/questions/2785485/…
    – GAThrawn
    Mar 7, 2011 at 15:08

There is another reason for this than the unique ID. I would guess that half of the apps don't access those values at all. The problem is that for a lower version up to Android 1.5 this permission does not exist. Everybody could access these values without requesting something.

Therefore if you create an app that is compatible with 1.5 this permission will automatically be added to emulate the lower security of Android 1.5 because of that you could ignore this permission in most of the times because it tends to be just a compatibility issue.

  • 2
    The same happens with SD card access. Jul 28, 2011 at 19:55
  • 2
    That's true – but doesn't explain why apps for 2.x and up want it so often.
    – Izzy
    Feb 7, 2014 at 21:18

The reason is that Android 1.5 and earlier did not require the application to specifically request those permissions and automatically granted them. Since Android 1.6, those permissions have to be specifically requested by the app. However, if you specify that your application can run on devices with Android 1.5 and less, then that permission is added to the application by default and the market shows that permission as being requested by the application.

So in summary, the application may not actually be accessing your "phone state and identity" but if the developer specified that his/her application can run on devices with 1.5 or less then that permission will be shown.


This question has been bothering me quite some time. So now, finally, I decided to get to the bottom of the issue.

The Playstore has an app named permission.READ_PHONE_STATE, which requests READ_PHONE_STATE as the only permission, and does nothing else than printing out all data it can access with or without using it. I've installed that on my LG Optimus 4X, being rooted on stock Android 4.0.3, and revoked the permission using LBE. Results where pretty interesting, as the following screenshots show:

Screenshot 1 Screenshot 2 Screenshot 3
Information gathered by the app permission.READ_PHONE_STATE (click images for larger variants)

As you can easily see, even some information the dev though inaccessible without the permission, was freely accessible: my mailbox number (remark: Yes, it's the correct one; with my provider that's the shortcut when dialing from your own device, so I can freely display it ;) At the end of the first screenshot you see:

  • CALL_STATE_IDLE. So no phone call incoming, outgoing, or in progress. No app needs this permission to "background" itself on incoming calls.

It's even possible to see whether mobile data are active (DATA_DISCONNECTED; I was on WiFi when taking the screenshots, as you can see in the notification bar), which country you're in, your provider (including some technical data on him), whether you're having a SIM card, or if you're in roaming.

The only things not accessible hence are identifying data: IMEI, SIMID, IMSI, and your own phone number.

Conclusion: This permission is only needed for identification purposes, nothing else.

Why do so many apps need it then?

  • For the ad modules, most likely1
  • Because the dev thought he needs it (as pointed out by some answers here)2
  • Because the app in question is designed to (also) run on Android 1.5 and below (easy to find out, as that's listed on Google Play).

Likelihoods in exactly this order, IMHO.

1 Note by Dan's post on chat:

Google Play policy now forbids apps from getting your IMEI to identify you for advertising purposes. All the ad libraries have been updated now to use the Google-Play-Services-provided "advertising ID", so any that still use the IMEI for this purpose should be reported to Google.

As it's hard for the user to tell what the app is using the IMEI for, you should ask the developer to explain first.

2 Another developer just pointed me to a subtle difference: while the permission is not needed to read the current call status (as I've pointed out), it might be needed to register a listener in order to be notified on changes of the call status (see: Detecting incoming and outgoing phone calls on Android). While there seem to be means of handling this automatically when the system calls onPause, that might not always be suitable: think of your alarm clock. You might not want to have that automatically stopped on an incoming call – especially not when your profile is set to ringer volume "muted".

3 Again a correction from Dan: You only get the default extra permission if your app's "target" version is 1.5. If you target a later version but your min version is 1.5, you don't get the permission added automatically.


  1. Interesting that there's an open issue (21504) to divide READ_PHONE_STATE in what's needed to a) detect incoming calls and related (telephony), and a second permission for the identification details (IMEI, IMSI, etc). Opened 11/2011, still not worked on. Star it if interested :)
  2. And yes, there's a way to achieve the same (detecting incoming calls) without the READ_PHONE_STATE permission, as e.g. pointed out by Arno Welzel. As an incoming phone call would trigger the ringer, that event could be used with onAudioFocusChange(), which does not require any special permission: if triggered by that, the app could check the CallState (again, without any special permission required) to see whether there's an incoming call.
  • I think you need to remove the part where you say no app needs this permission to background on incoming calls. You already make this point in footnote 2, but it's contradictory. See also developer.android.com/reference/android/telephony/…
    – Mikel
    May 18, 2014 at 17:33
  • @Mikel You're partially right. Using this permission is the "easiest" way to accomplish the task, but it's not the only one. It can be done without, as some developer pointed out (was it on chat? Unfortunately, I've lost the link). As with many things, using Google's APIs makes some things much easier to accomplish (while it also binds your app to the Google eco system). I'm not a developer, so I cannot tell how much more work the other way would mean.
    – Izzy
    May 18, 2014 at 17:53
  • I'm not an Android dev yet either, and I agree it sounds like some use cases are covered by onPause(). Just saying that "No app needs this permission" sounds wrong to me. It sounds more like "some apps may need this permission", e.g. if they run in the background. Also note that receiving the broadcast intent must surely be more efficient than repeatedly polling the phone state.
    – Mikel
    May 18, 2014 at 18:02
  • @Mikel See my update. And yes, "no need at all" might be a bit exaggerated. Maybe in 0.5% of all current requests, it might indeed be needed, with no alternative available #D And yes again: onPause() was what we discussed on chat for that! But using onAudioFocusChange() might be less overhead even (the little polling then might be ignorable).
    – Izzy
    May 18, 2014 at 18:06

Many ad publishers use this permission to get the Phone ID for all sorts of tracking purposes. There are other ways to get a unique ID, but unfortunately they are buggy in older Android versions (the story is more complicated, see e.g. https://stackoverflow.com/questions/2785485/is-there-a-unique-android-device-id or http://android-developers.blogspot.com/2011/03/identifying-app-installations.html for a more complete story).

So if the app uses advertisements, there is a fair chance that the app itself does not actually need the READ_PHONE_STATE permission, only the ad provider does.

  • 1
    That's IMHO the main issue behind it all! Well figured.
    – Izzy
    Feb 7, 2014 at 21:21

You must log in to answer this question.