When our apps want to do something that has the potential to cause harm to a user's device or perhaps the user's privacy, Android requires us to deal with it in a specific way, usually by having our app ask permission from the user before we do certain things.
With the introduction of Android Marshmallow at the end of 2015, the way that we had to handle things changed—but only for the new Marshmallow devices.
The current situation, therefore, is that we need to deal with two possible situations: Marshmallow and pre-Marshmallow.
Before Marshmallow, if we wanted our app to do something that could potentially cause harm, such as connect to the Internet (our next app will do this), get a GPS location, take pictures, access the address book, and much more, we needed to add a line of code to the AndroidManifest.xml file.
Then, when users install our app from Google Play, a little pop-up warning appears letting them know exactly what potentially harmful operations our app wants to do. Users have to agree that they trust our app or the installation would be aborted.
How this works is outlined in the next steps:
- We want to add the potentially harmful feature x.
- We add a permission for the feature x to
AndroidManifest.xml. - The user downloads the app from Google Play and is warned that our app uses the feature x.
- The user decides whether to let our app use the feature x. If the user does, the app is installed; if the user doesn't, it is not.
Marshmallow does not ask for permissions at the time the app is installed. It asks for permissions when the specific feature that requires the permission is about to be used. This can be considered a good thing or a bad thing for the user, depending on your opinion.
One potential upside is that users can install an app with, for example, two permissions: the permission to access their address book and the permission to make phone calls. This hypothetical example might be an address book app that lets the users add contacts and tap a contact to call them.
With Marshmallow, users will be able to grant a permission to one of the features, for example, access to the address book to allow them to manage their contacts. They could decline the permission to allow the app to make phone calls and be confident that the app will never be responsible for a big phone bill. With the pre-Marshmallow permissions, it is all or nothing.
One downside is that users will more easily install apps that contain features they might not approve of, and not realize until they have wasted some time and potentially missed the 15-minute refund window that Google Play offers. However, I am sure that Google only had user security in mind when they devised this system.
What this means to us as developers is that we will need to not only add permissions to the AndroidManifest.xml file for pre-Marshmallow devices, but we will also need to add code in all the right places to handle the Marshmallow permissions at runtime.
The situation is further complicated by the fact that Marshmallow considers some permissions as dangerous and others as normal. This will add significant complexity to our code.
It was considered very carefully before starting this book that the amount of coverage that would be necessary to use Marshmallow runtime permissions in the projects of this book would cloud the other learning objectives and provide little immediate benefit to readers who are developers or to our future users. This is especially true as it is unlikely that Marshmallow ownership will reach even 10 percent market share before a new edition of this book is required. In addition to this, there is a very simple workaround to make all our apps compatible with Marshmallow and pre-Marshmallow permissions, and we will see this when we build our first app with a dangerous permission in Chapter 21, Navigation Drawer and Where It's Snap.
Now that we have considered permissions, let's build our widget demo app that requires the android.permission.INTERNET permission. This is considered a normal permission, so it doesn't require any special handling for Marshmallow devices.