How Permission Can Be Checked at Runtime Without Throwing Securityexception

How permission can be checked at runtime without throwing SecurityException?

You can use Context.checkCallingorSelfPermission() function for this. Here is an example:

private boolean checkWriteExternalPermission()
{
    String permission = android.Manifest.permission.WRITE_EXTERNAL_STORAGE;
    int res = getContext().checkCallingOrSelfPermission(permission);
    return (res == PackageManager.PERMISSION_GRANTED);            
}

Runtime permissions in capsulated objects - how to handle properly?

The permission is granted for the whole app, not for individual objects.

If you get the permission for your app once, you don't need to request it again and again.

In your case you can check and request the necessary permissions before writing to a file or even before the creation of your object.

The best practice is to request the permissions in the context just before using the features which require the permissions.

Check my library for handling permissions easily. Just get a reference of context and you can request permissions from anywhere.

https://github.com/nabinbhandari/Android-Permissions

checking if FOREGROUND_SERVICE permission is granted allways returns false

This is failing because you probably run it on device with API < 28. This method field works only on API 28 and up. If you write as you should Manifest.permission.FOREGROUND_SERVICE instead of plain string, Android Studio will warn you.

what exception would be appropriate to throw when an android permission is missing?

Based on @Selvin's comment I let android throw the exception - I got :

09-20 17:13:39.115: E/AndroidRuntime(1688): java.lang.SecurityException: Requires READ_PHONE_STATE: Neither user 10064 nor current process has android.permission.READ_PHONE_STATE.

So it indeed appears that android uses java.lang.SecurityException - and to be consistent with android I'll have to use this

how to check whether a permission is denied by user in android

Right now, android asks for the user to accept all the permissions an app asks for in the manifest on installation. In the upcoming M release, android will switch over to the iOS style of permissions with an "on needed" basis. (For certain permissions. See @Commonsware's comment for more details) Meaning whenever the user tries to use a feature that requires permission it will ask them to accept or deny. If they hit deny I imagine there will be an sdk positive and negative response button interface to implement.

As for right now in your dilemma, if the user rejects permissions they won't be able to use your app period.

Android permission doesn't work even if I have declared it

_{(the following is extracted from a blog post of mine about this)}

The big reason for not getting your permission nowadays is because
your project has a targetSdkVersion of 23 or higher, and the permission
that you are requesting is "dangerous". In Android 6.0, this includes:

• ACCEPT_HANDOVER
• ACCESS_BACKGROUND_LOCATION
• ACCESS_MEDIA_LOCATION
• ACTIVITY_RECOGNITION
• ANSWER_PHONE_CALLS
• ACCESS_COARSE_LOCATION
• ACCESS_FINE_LOCATION
• ADD_VOICEMAIL
• BODY_SENSORS
• CALL_PHONE
• CAMERA
• GET_ACCOUNTS
• PROCESS_OUTGOING_CALLS
• READ_CALENDAR
• READ_CALL_LOG
• READ_CELL_BROADCASTS
• READ_CONTACTS
• READ_EXTERNAL_STORAGE
• READ_PHONE_STATE
• READ_SMS
• RECEIVE_MMS
• RECEIVE_SMS
• RECEIVE_WAP_PUSH
• RECORD_AUDIO
• SEND_SMS
• USE_SIP
• WRITE_CALENDAR
• WRITE_CALL_LOG
• WRITE_CONTACTS
• WRITE_EXTERNAL_STORAGE

For these permissions, not only does your targetSdkVersion 23+ app
need to have the <uses-permission> element(s), but you also have
to ask for those permissions at runtime from the user on Android 6.0+
devices, using methods like checkSelfPermission() and
requestPermissions().

As a temporary workaround, drop your targetSdkVersion below 23.

However, eventually, you will have some reason to want your
targetSdkVersion to be 23 or higher. At that time, you will need
to adjust your app to use the new runtime permission system.
The Android documentation has
a page dedicated to this topic.

Requesting Android run-time permissions using try and catch

Some thoughts on unchecked exceptions: https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

Recalling that SecurityException is a runtime exception, I emphasize this part:

Runtime exceptions represent problems that are the result of a programming problem, (...)

So I understand that requesting permission after a thrown SecurityException means that the program has a problem of not checking whether the app has some specific permission before calling an operation. I particularly avoid developing problematic programs.

Nonetheless, both codes will work the same.

---

Related Topics