App Restart in Android M (Marshmallow)
Android 6.0 (Marshmallow) introduced significant changes to the way apps handle permissions. One of the notable changes is the potential for an app to restart after a user modifies its permissions. This article dives into the reasons behind this behavior and provides insights into best practices for handling such scenarios.
Why Apps Restart
The app restart mechanism in Android M is triggered when an app requests a permission that it previously did not have and the user grants that permission. Here’s a breakdown:
- Runtime Permissions: Android M shifted towards runtime permissions, granting users more control over what data and features an app can access.
- Permission Grant: When an app needs a permission it doesn’t currently possess, it requests the permission. The user then grants or denies the request.
- Restart to Apply Changes: If the user grants a permission, the system restarts the app to apply the newly granted permissions. This ensures that the app can immediately access the resources it now has permission to use.
Understanding Permission Groups
Android M introduced permission groups, which categorize permissions based on their sensitivity. This categorization is essential in determining whether an app needs to restart when permissions change.
Permission Group | Restart Required? | Example Permissions |
---|---|---|
Dangerous Permissions | Yes |
|
Normal Permissions | No |
|
When an app is granted a dangerous permission, it typically needs to be restarted for the changes to take effect. Normal permissions usually don’t require a restart. However, if the app utilizes any specific system features linked to a normal permission, a restart might be necessary.
Code Example: Handling Permission Changes
@Override public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) { if (requestCode == MY_PERMISSIONS_REQUEST_READ_CONTACTS) { if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) { // Permission granted, proceed with the action // Example: Load contacts data // Restart the app if needed (for dangerous permissions) } else { // Permission denied, explain why it's needed // Show a message or disable relevant features } } }
In this example, the app checks for the result of a permission request (requestCode
). If the permission is granted, the app can proceed with its intended actions. If denied, the app should inform the user why the permission is necessary or disable features that rely on it.
Best Practices
- Handle Restart: If your app needs to restart after permission changes, gracefully handle the restart process. Save any essential data before restarting to avoid data loss.
- Inform Users: Communicate to users why a restart is needed and what benefits it brings, such as improved access to features.
- Minimize Restart: Avoid situations where frequent restarts are necessary. Use appropriate permissions and optimize your app’s logic to minimize restarts and improve the user experience.
Conclusion
Android M’s runtime permissions and the potential for app restarts have introduced challenges for developers. Understanding why these restarts occur and implementing best practices is crucial for building a seamless and user-friendly experience. By carefully handling permissions and anticipating potential restarts, developers can ensure that their apps function optimally while adhering to the principles of Android M’s permissions model.