First, you take the mallow…
Then you put the mallow on your Android.
The Sandlot? Anyone? We digress. Here, we’re talking Android Marshmallow, and—courtesy of Chaotic Moon Android dev Carlos Vega—we’re going to get technical…
With the increased concerns surrounding security, companies are proactively increasing their efforts to safeguard consumers’ data and protect their privacy. And as more and more consumers have shifted away from computers largely in favor of smartphones and tablets, a big focus has been placed on giving consumers the ability to limit what data their mobile applications are allowed access to. For quite some time, Apple has provided the capability for iPhone and iPad users to allow or deny apps to access contacts, photos or location data. Android users, on the other hand, have been forced to accept an app’s required permissions at installation time, since Google provided no way of revoking those permissions post-installation.
With the release of Android Marshmallow at this year’s Google I/O, support for runtime permissions was officially announced, and Android users will finally be allowed to safely install an app without giving upfront consent of personal information. This has various implications from both a development and a design standpoint. Before developers rush to update their app to account for their new permissions model, they must fully understand the implications of such a migration. Here, we break down the major gotchas to aid in the decision-making process.
The first step in analyzing the scope of work for your specific app is to determine which permissions you are using that are impacted by the new model. Google has categorized all Android permissions into two major groups: Normal and Dangerous permissions. If your app only uses normal permissions, then no changes are needed in your code. If your app uses any permissions categorized as “dangerous”–such as Camera, Contacts or Location–then certain code refactoring is required. Even access to external disk storage is categorized as a dangerous permission. It’s likely your app makes use of Google Play Services and other third-party libraries, so you must also be aware of any permissions that might be required by such components.
Once you have determined that your app requires changes, the next step is determining which user interaction flow best serves your users. You want to give users control over how your app uses their information, but you also do not want to annoy them by needlessly asking for too many permission requests ahead of time. Both security and user experience are key. With this in mind, during app startup (i.e. first usage), you should only ask for permissions that are absolutely needed for basic app operation. However, if it isn’t clear to the user why such permissions might be needed, you should provide the user some context in the form of a warm-up screen or dialogue that explains why that permission is needed. For all other permissions, you should ask the user on an as-needed basis. For example, if the user presses a camera button to share a picture, it’s best to ask for the permission at that moment in time.
So should you update your app right away to target Marshmallow and the new permissions model? It all depends. If you support a legacy app that, for example, still employs ActionBarSherlock or is targeting an SDK older than Lollipop, then some major refactoring might be needed before you can even consider implementing runtime permissions. Either way, you should treat this work with urgency. Even without targeting the latest SDK, Marshmallow users will be able to manually disable permissions, which might result in your app misbehaving.
If you were already targeting Lollipop, then the path to implementing runtime permissions is much clearer. You will still have to do some refactoring, but the adjustments should not be large enough to justify depriving Marshmallow users of this new feature. It’s important to remember that there are other neat Marshmallow features, such as the fingerprint API. If your app requires some sort of authentication, this can provide another layer of security for your app without requiring users to type passwords.