Site navigation

Social networks

Contact us

The Impact of Android Marshmallow on Runtime Permissions

by WeezLabs Senior Android developer  Gleb Mozheiko


Since Android M was officially announced, the internet has been abuzz with step-by-step guidelines and detailed instructions of moving to the new permission schemes. Android M departs from previous builds, and these changes in Android must be understood thoroughly. The most interesting facet is how end users actually deal with it - what can the user block, and how will this change potentially impact ad/monitoring services in the cases of fetching, controlling, monitoring user engagement activity occurring on the device.

Ins and outs

First of all, the impact will fall somewhere between "no visible effect" to "supportable" in context of ad/monitor services. To be truly sure, we’ve spent some time checking the Android SDK and several popular ad/monitoring platforms (Google Analytics, Flurry, InMobi, AdMob, Smaato, HockeyApp and TestFairy).

Let's examine the nuances in cases of supportable impact. The new Marshmallow permission grant scheme impacts apps only in case of access to:

  • user's calendar
  • camera
  • contacts
  • location
  • recording audio
  • call permissions (make a call OR read IMEI OR read user's phone number OR something else related to phone call function)
  • body sensors (usually data from wearables, such as heart rate)
  • SMS (send, read)
  • external storage (any access to any file/folder except ones located here: SDCARD//:Android/data/data/your_app_package).

All other permissions become granted straight out of the box (from the user’s point of view) and they are called normal permissions. In this case, normal actually stands for permissions which have no great risk to the user's privacy or security. For example, users would reasonably want to know whether an app can read their contact information, so they need to grant this permission explicitly. By contrast, there's generally no problem with allowing an app to send a push notification, so that permission is designated as normal.

From a developer’s point of view, nothing changed in the case of normal permissions – one still needs to declare necessary permissions in the AndroidManifest. The most important feature is that the system doesn’t prompt the user to grant normal permissions, and users cannot revoke these permissions. Thus, if the app was designed to have internet or fingerprint permissions, those will appear regardless. The entire list of normal permission is located here:

Users will worry less with the decreased number of required permissions. Before asking a necessary permission, you can fully describe why this permission is so important for the app and thereby win the user’s trust.

Now, back to the ad / monitor platforms: the aforementioned platforms may call from the list of abnormal permissions:

  • Flurry may ask for location.
  • Smaato may ask for location, read phone state, writing in external storage, access to calendar.
  • InMobi may ask for location, read phone state, writing in external storage, access to calendar and audio record (all of them are needed only for Interactive Rich Media Ads).
  • Google Analytics won't ask for anything.
  • AdMob won't ask for anything.
  • HockeyApp and TestFairy also won’t ask for anything.

As you can see, there is only one "bad" limitation, which is the request to get access to location that helps to use geo-fencing. The iOS platform has coped with those kinds of grant permission flows for a long time, showing that the scheme works well.

Gleb Mozheiko



Not just another web and mobile apps development company!

WeezLabs is about dreaming big and helping our clients reach their full potential.



1848 Lincoln Blvd, Suite #100,
Santa Monica, CA 90404



Call us 310.776.6234 or complete the form below.