A word on Android permissions

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin

As you may know, this weekend we published the most significant update to Reverse Lookup ever. Unfortunately, it seems there has been some confusion about the permissions that the app requests, and Android permissions in general.

So please take a moment to read this blog post, and we’ll teach you a few important things to keep in mind when you are reviewing permissions –

1. Permission requests are not generated automatically.

Whenever we see or hear a discussion about Android permissions, it seems there are always people who assume that the permissions list presented during install is generated based on what the app tries to do.

This is actually false. The permissions that you are asked to approve during install are specifically requested by the developer. If the developer fails to request a needed permission, the app will simply crash when that code attempts to run.

With that being said, it’s generally bad practice for a developer to request unneeded permissions, but they can if they want. In some cases it’s difficult to avoid – some apps are written using third party frameworks that simply request everything(or at least more than what is needed). In this case, the developer may not be able to reduce the list to just what’s needed.

2. Don’t judge a permission by it’s group

When you install an Android app in the latest versions of the Play Store, you are shown a summarized list of permission groups. 

In the image below, it looks like we want access to your whole phone, and that’s understandably creepy. Calendar access? Photos? What?permission groups

But if you expand each section(image below), you can see the actual permissions we are asking for, and things start to make much more sense. You should do this for any app you install rather than just assuming it’s asking for complete access to each group.

expanded permissions

In the case of Reverse Lookup specifically, here’s what the permissions are actually used for:

  • Find Accounts – used when creating contacts so they can be attached to your Google account
  • Read Contacts – used so that we can omit people you already know from the main screen of the app
  • Modify Contacts – self explanatory – so the app can create a contact from found results if you choose that option
  • Read Call Log – used to generate the call list on the main screen – this permission wasn’t necessary in the past, but the method we used to query the call log has long been deprecated and has begun causing problems on some newer devices.
  • Directly dial phone numbers – The app contains a function to dial a number directly from the results screen
  • test access to protected storage/modify contents of USB storage – required by embedded Google maps to store temporary cache files on your SD card in order to improve performance
  • Read Phone Status – required for the ability to show a notification when receiving a phone call from an unknown number
  • Network access – needed to reach the call databases
  • View Network Connections – needed to check for internet connectivity

Recently removed permissions:

  • Location access – inadvertently requested in the past but was never used
  • Vibration – vibration functions were tested in some early test versions but never in a production release. Permission was left in until recently.

We know permissions are a scary issue for many users, and we always want to be as transparent as possible about the ones we use. We hope that this explanation has shined some light on how permissions work and specifically how and why we are using them.

If you have any further questions, as always, feel free to shoot us an email.

 

 

 

 

Follow Us!
Facebooktwittergoogle_plusFacebooktwittergoogle_plus