PermissionX 1.5 is available for Android special permissions

preface

Good morning everyone. Speaking of PermissionX, I haven’t updated this framework in a while. One is that I don’t have as much spare time to write open source projects as I did in the past, and two is that the main functionality of PermissionX is fairly stable and doesn’t require frequent changes.

PermissionX does not support special permission requests on Android. Yes, PermissionX is essentially just a wrapper around the Android runtime permission API to simplify runtime permission requests. These special permissions are not part of the Android runtime permissions, so PermissionX does not support them either.

But special permissions are a part of what we developers are likely to deal with on a regular basis. They’re not hard to write, but they feel like a chore every time we write them. So after careful consideration, I’ve decided to include a few of the more common special permissions that PermissionX supports. In this article, we’ll take a look at the differences between using PermissionX and not using PermissionX for these common special permissions.

In fact, Android’s permissions mechanism has undergone long iterations. Before 6.0, Google designed the permissions mechanism relatively simple, your application needs to use what permissions, just need to declare in the Androidmanifest.xml file can be.

But starting with OS 6.0, Android introduced runtime permissions. Android roughly classifies common permissions into common permissions, dangerous permissions, and special permissions.

Ordinary permissions are those that do not directly threaten the user’s security or privacy. As in the past, these permissions are declared in the Androidmanifest.xml file and do not require any special processing.

Dangerous permissions are those that may compromise user privacy or affect device security, such as obtaining device contact information and locating devices. This part of the permission needs to be applied through the code, and the user must manually agree to obtain authorization. The PermissionX library primarily handles requests for such permissions.

Special permissions are even rarer, and Google believes that such permissions are more sensitive than dangerous permissions, so you can’t just ask the user to manually grant permission. Instead, you need to ask the user to go to a special Settings page to manually authorize an application to use this permission.

However, compared with dangerous permissions, there is no fixed application method for special permissions. Each special permission may be written in a different way, which makes applying for special permissions more complicated than applying for dangerous permissions.

Starting with version 1.5.0, PermissionX has support for several of the most commonly used special permissions. As mentioned earlier, there is no set way to apply for special permissions, so PermissionX is designed to support these special permissions one by one. If you find that you need to apply for a special permission that is not yet supported by PermissionX, you can also request it from me and I will consider adding it in a future release.

In the past, we usually publish open source libraries on JCenter, but I believe you have already known that JCenter is going to be discontinued. For details, please refer to my article on the event of jCenter being discontinued.

Currently, JCenter is on the verge of semi-obsolete. although open source libraries can still be downloaded from JCenter, it is no longer possible to release new open source libraries to JCenter. The download service will also be shut down after February 1.

So, if we want to publish open source libraries in the future, we will have to publish them to other repositories. For example, Google now recommends that we use Maven Central.

As a result, starting with version 1.5.0, PermissionX will also publish libraries to Maven Center. The previous version was not worth the migration, so I didn’t want to do the migration again. Versions prior to 1.5.0 will remain available for download on JCenter until February 1 next year.

For more information on how to publish your libraries to MavenCentral, see Bye JCenter and publish your open source libraries to MavenCentral.

Android special permissions

What are the special permissions in Android?

To be honest, I don’t know much about that. The special permission I know is basically because I need to use it, and then I find that this permission is neither ordinary permission nor dangerous permission. I have to apply for it in a more special way, and then I realize that it is a special permission.

As a result, PermissionX 1.5.0’s support for special permissions is limited to a few of the most common ones THAT I know of and have received feedback from users.

A total of the following three:

1. Floating window
2. Change the setting
3. Managing external Storage

Next, I will introduce these three special permissions in more detail.

Floating window

The hover window feature is used a lot in many applications because it comes in handy when you may have some content that needs to be displayed above others.

Of course, you don’t need to apply for permission to implement the hover window function inside your own app, but if you want your hover window to sit on top of other apps, you will have to.

The hover window permission is called SYSTEM_ALERT_WINDOW. If you check the documentation for this permission, you will find that this permission is requested in a special way:

According to the documentation, starting with Android 6.0, Before using the SYSTEM_ALERT_WINDOW permission, issue an Intent with the action settings. ACTION_MANAGE_OVERLAY_PERMISSION to initiate manual authorization. In addition, you can use the Settings.Candrawoverlays () API to determine whether or not the user has authorized lays.

Therefore, to apply for suspension window permission, it is natural to write the following code:

if (Build.VERSION.SDK_INT >= 23) {
    if (Settings.canDrawOverlays(context)) {
        showFloatView()
    } else {
        val intent = Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION)
        startActivity(intent)
    }
} else {
    showFloatView()
}

Copy the code

It doesn’t look complicated.

True, but the main trouble with it is that it is requested in a way that deviates from normal run-time permission requests, so you have to write separate permission request logic for it.

The goal of PermissionX is to weaken this separate permission request logic, reduce the need for differentiated code, and strive to use the same SET of apis to request specific permissions.

If you’re already familiar with PermissionX, you’ll be familiar with the following code:

PermissionX.init(activity) .permissions(Manifest.permission.SYSTEM_ALERT_WINDOW) .onExplainRequestReason { scope, DeniedList - > val message = "PermissionX need you agree to the following permissions can be normal use" scope. ShowRequestReasonDialog (deniedList, the message, "Allow", Request {allGranted, grantedList, deniedList -> if (allGranted) {toasts. MakeText (activity, "All permissions have been granted ", Toast.length_short).show()} else {toast.maketext (activity, "You rejected the following permissions: $deniedList", toast.length_short).show()}}Copy the code

As you can see, this is the normal use of standard PermissionX, but here we are using it to request the hover window permission. That is, even special permissions can be handled in a normal way in PermissionX.

Also don’t forget that all requested permissions must be registered in androidmanifest.xml:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.permissionx.app">
    
    <uses-permission android: />

</manifest>

Copy the code

So what does it look like? Let’s take a look:

As you can see, PermissionX also comes with a permission prompt that kindly informs the user that we need the hover window permission and directs the user to manually open it.

Change the setting

Now that we know how to request hover window permissions, we can quickly go over how to request change Settings permissions, because they are used exactly the same way.

The permission to change the Settings is called WRITE_SETTINGS, and if we look at its documentation, we’ll see that it’s exactly the same as the hover window:

In Android 6.0, you need to issue an Intent with the action settings. ACTION_MANAGE_WRITE_SETTINGS for manual authorization before using the WRITE_SETTINGS permission. We can then use the settings.system.canwrite () API to determine whether the user is authorized.

So, if you are applying for this permission manually, I believe you already know how to write.

How do you write PermissionX? This is of course easier, just need to apply for permission to replace, other parts are not used to modify:

PermissionX.init(activity)
    .permissions(Manifest.permission.WRITE_SETTINGS)
    ...

Copy the code

Of course, don’t forget to register permissions in androidmanifest.xml:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.permissionx.app">
    
    <uses-permission android: />

</manifest>

Copy the code

Run it and the effect will look like the picture below:

Managing external Storage

Managing external storage permissions is also a special permission that allows your App to read and write to the entire SD card.

Some friends may ask, THE SD card is not to be able to read and write globally? Why do I need to apply for this permission again?

You may not have read about Scoped Storage on Android 11. Since Android 11, Android has forced Scoped Storage to be enabled, and all apps no longer have access to the SD card globally.

For more on Scoped Storage, check out my article on new Android 11 features.

But what if some applications just want to read and write to the SD card globally (say, a file browser)?

Don’t worry, Google still gave us a solution, which is to ask for managed external storage permission.

This permission was added in Android 11 for this particular scenario.

So how to apply for this permission? Let’s take a look at the documentation:

It can be roughly divided into several steps:

First, declare MANAGE_EXTERNAL_STORAGE permission in androidmanifest.xml.

Second, issue an Intent with action settings. ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION to direct the user to manual authorization.

Third, call Environment. IsExternalStorageManager () to determine whether the user has been authorized.

I won’t show you the traditional way of requesting permissions, but PermissionX is still pretty much the same. Just note that since the MANAGE_EXTERNAL_STORAGE permission is new to Android 11, we should only request this permission on Android 11 or later, as shown below:

if (Build.VERSION.SDK_INT >= 30) {
    PermissionX.init(this)
        .permissions(Manifest.permission.MANAGE_EXTERNAL_STORAGE)
        ...
}

Copy the code

The permissions in androidmanifest.xml are as follows:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.permissionx.app">
    
    <uses-permission android: />

</manifest>

Copy the code

Run the program, the effect is as follows:

This gives us global access to read and write SD cards.

PermissionX is also particularly handy because it can apply for multiple permissions at once. If we want to apply for both hover window and modify Settings, we can simply write:

PermissionX.init(activity)
    .permissions(Manifest.permission.SYSTEM_ALERT_WINDOW, Manifest.permission.WRITE_SETTINGS)
    ...

Copy the code

The operating effect is shown in the figure below:

Of course, you can also apply for special permissions together with normal runtime permissions, which PermissionX also supports. PermissionX will only call back to the developer once all permissions have been requested.

PermissionX < span style = “box-sizing: border-box; color: RGB (51, 51, 51); line-height: 22px; font-size: 14px! Important; word-break: inherit! Important;”

Dependencies mavenCentral repositories {Google () ()} {implementation 'com. Guolindev. Permissionx: permissionx: 1.5.0'}Copy the code

Note that you must now use the Mavan Central repository instead of JCenter.

If you are interested in the PermissionX source code, you can visit the PermissionX project home page:

Github.com/guolindev/P…