Pro Android with Kotlin

111
CHAPTER 7: Permissions
val backFromSettingPerm = 6183 // any suitable constant
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
val activity = this
if (!Settings.System.canWrite(activity)) {
// This is just a suggestion: present a special
// dialog to the user telling about the special
// permission. Important is the Activity start
AlertDialog dialog =
new AlertDialog.Builder(activity)
.setTitle(...)
.setMessage(...)
.setPositiveButton("OK", { dialog, id ->
val intent = Intent(
Settings.ACTION_MANAGE_WRITE_SETTINGS)
intent.data = Uri.parse("package:" +
getPackageName())
activity.startActivityForResult(intent,
backFromSettingPerm)
}).setNegativeButton("Cancel",
{ dialog, id ->
// ...
})
.create();
dialog.show();
systemWillAsk = true;
}
} else {
// do as with any other permissions...
}
Once done with that intent, the callback method onActivityResult() can be used to 
continue with the GUI flow.
override
protected fun onActivityResult(requestCode:Int,
resultCode:Int, data:Intent) {
if ((requestCode and 0xFFFF) == backFromSettingPerm) {
if (resultCode == Activity.RESULT_OK) {
// act accordingly...
}
}
}
For the SYSTEM_ALERT_WINDOW permission, you have to follow the same approach, but use 
ACTION_MANAGE_OVERLAY_PERMISSION instead for creating the content.
Note For this special SYSTEM_ALERT_WINDOW permission, the Google Play store will 
automatically grant the permission if the app gets installed from the Google Play store and the API 
level is 23 or higher. For local development and testing, you have to use the intent as described.

---

112
CHAPTER 7: Permissions
Feature Requirements and Permissions
In Chapter 
2
 we saw that by virtue of the  element inside AndroidManifest.
xml you can specify which features your app will use. This information is important for the 
Google Play store to find out on which devices your app can run after published. However, 
there is another important aspect to take into account if you specify this requirement: which 
permissions will be implied by such requirements, and how will they be handled depending 
on the API level in use?
Feature constants and API levels do not necessarily strictly relate to each other. For 
example, the android.hardware.bluetooth feature was added in API level 8, but the 
corresponding Bluetooth API was added in API level 5. Because of this, some apps were 
able to use the API before they had the ability to declare that they require the API using the 
 declaration. To remedy this discrepancy, Google Play assumes that certain 
hardware-related permissions indicate that the underlying hardware features are required 
by default. For instance, applications that use Bluetooth must request the BLUETOOTH 
permission in a  element, and for apps targeting older API levels, Google 
Play assumes that the permission declaration implies that the underlying android.hardware.
bluetooth feature is required by the application. Table 
7-2
lists the permissions that imply 
such feature requirements.
Note that the  declarations take precedence over features implied by the 
permissions in Table 
7-2
. For any of these permissions, you can disable filtering based on 
the implied feature by explicitly declaring the implied feature in a  element, 
with an android:required=”false” attribute. For example, to disable any filtering based on 
the CAMERA permission, you would add this to the manifest file:
android:required="false" />