Can somebody summarize the drawbacks to setting the targetSdkVersion to 22 to avoid handling runtime permissions?
After reading the Google docs on this and a few other Stack Overflow posts, the only downside I can find is that a user could grant permission at install time, then go into their OS settings and revoke that specific permission for that specific app, and then run the app again. However from a few of the examples I found this is not difficult at all to deal with in code.
Is this really the only drawback to using targetSdkVersion 22 to force permissions at install time? Will things stay this way for years into the future?
Also, if for example I use these settings in my build.gradle file:
compileSdkVersion 24
buildToolsVersion "24.0.1"
minSdkVersion 19
targetSdkVersion 22
Can I still access API 23 & 24 features in an app or am I limited to 22 and earlier?
Before somebody responds with "It is best practice to not do this and to request permissions at runtime as needed as recommended by Google", yes, of course I'm aware of this. And yes, I'm also aware of some examples out there that attempt to provide boiler plate code to for ask for runtime permissions such as:
https://github.com/googlesamples/easypermissions
However there are at least two situations I can think of where it would be very advantageous to request permissions at install time and not install the app if the permissions are not granted:
1) Suppose half way through the work week the person I report to asks "Can you throw together a proof of concept Android app for the Friday meeting that does XYZ to show some visitors we are having that day?" If I have to throw together a quick alpha version of an app and I only have a few days to do it, and it will take that long to put together the basic functionality, and the app will require, say, 4 permissions, it would be much better to demand all permissions at install time for the alpha version so I have the time to spend on the app functionality. Then if I get the go ahead, as I move the app to beta and then to final, to change permission requests to one by one at run time as needed.
2) Some apps absolutely need certain permissions to be of any use. For example, if I'm writing an OpenCV app that takes images from the camera and then does something based on what is or is not in the images, it would be preferable to not let such an app be installed to begin with if the user is not willing to grant camera permission.
I really wish Google had left it in as an option to request/require permissions at install time, and also offer the option to request permissions at runtime. Has there been any negative developer feedback regarding the decision to be able to ask for permissions at runtime only? Is it possible that Google may allow permission requests at install time or run time in a future version, in which case I could simply use the targetSdkVersion 22 option in the interim?
No. For example, unless your
targetSdkVersion
is 24 or higher, Android 7.0+ device users will get a "this app may not support split-screen"Toast
when trying to use your app in split-screen mode.Also, with respect to runtime permissions, bear in mind that a
targetSdkVersion
of 22 or lower means that the user will be prompted for all your requested permissions at install time. You appear view this as a positive. Prospective users may disagree. Given a choice between App A which requests all sorts of permissions at install time and App B that does not, users will tend to choose App B, absent strong reasons to go with App A. Over time, as Android 6.0+ rolls out to more and more users, apps that request permissions at install time will be viewed as unmaintained or poorly written, as users will expect not to have to agree to permissions up front.No.
Yes, though some may behave differently due to your
targetSdkVersion
.Anything is possible. In general, Google does not discuss future plans like this.
As stated in https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html
So we'll have to target the latest SDK version soon.