Updates to User Data Access in Android Marshmallow
As Android Marshmallow is becoming widely available, it is important to take a look at some new updates regarding changes to how Marshmallow will handle user permissions and data. There are some major updates made in Marshmallow regarding user permissions and data which deviate from the other versions of the Android. This article highlights key considerations for user trust related to runtime permissions and hardware identifiers.
Permission Changes
In Marshmallow, the permissions have moved from install-time to runtime. This change has been made mandatory for SDK 23+. This means if an application is to be required to run on Marshmallow then it has to be updated, which is a major thing application developers and publishers have to keep in mind.
Runtime permissions means that the application can now request access to sensitive information in the context it will be used, which makes it possible to describe the need for that specific permission. Say bye-bye to long scary list of user permission requests.
Grouping of permissions now does not require user to understand the technical jargon and can make an informed decision. Allowing user to make a choice, it is possible for him to not grant a permission or even to revoke a previously granted permission. This generates the need to make permissions process thoughtful while handling API calls requiring permissions which may have been denied. Building the application to gracefully handle the failures so users can interact with rest of the application.
Changes to Identifier
Marshmallow has revoked access to some of the identifier data like Local WiFi and Bluetooth MAC addresses. For technical users, BluetoothAdapter.getDefaultAdapter().getAddress() and getMacAddress() method of a WifiInfo object will both return 02:00:00:00:00:00 hence onwards.
An alternative to this block is that Google Play Services will now provide Instance IDs to identify an instance of an application running on a device. This provides a dependable alternative to non-resettable, device-scoped hardware IDs used previously. These Instance IDs are scoped to an app instance and will not persist across a factory reset.
The Verdict
As a user it is good to be able to understand the permissions one is supposed to provide to an app plus being able to provide separate permissions makes it worthwhile since you get to pick and choose unlike previous way where you were supposed to provide all the permissions at one go during install time.
For developers and publishers of the applications, this means a great way to actually explain to user about why then need particular permission. But this comes with the great responsibility to make the permissions flow properly with the application and not make user feel insecure about providing certain permission. It’s always better to keep yourself in the shoes of users.
