Runtime permissions are essential to ensure that your apps get the required permissions to function, on android 6+ devices, however, it seems like some top developers (gameloft, ea games) do not find the need to implement runtime permissions, and they are rather happy on target SDK 22. So my questions are:
Why do I need take the pain of adding run-time permissions, when I can be stay on api 22. This would also save some lines of code.
Is it possible to upgrade from target SDK 22 to target SDK 23 once the app has been published? If I plan to stay on SDK 22 for now. It seems like downgrading is not possible. " Keep in mind that once you publish an APK targeting API level 23 or higher, you won't be able to submit an update targeting API level 22 or lower on any channel. "
Why do I need take the pain of adding run-time permissions, when I can be stay on api 22
Your "I can be stay on api 22" assumption may not hold up well over time. For example, the user will be told that your app is not compatible with multi-window.
Also, users see that the app is not supporting runtime permissions right away at install time, as they are prompted with the classic install-time permission dialog. Users, over time, will start to think that apps that show that dialog are out of date and not being maintained, and so they may not bother installing your app.
Also, certain third-party libraries that you may want to use may insist upon a higher targetSdkVersion.
So, while technically you can have any targetSdkVersion you want, there are costs.
This would also save some lines of code.
Not necessarily. The user can still revoke these permissions from within Settings, and so you may need more error-handling code than before.
Is it possible to upgrade from target SDK 22 to target SDK 23 once the app has been published?
In general, yes.
Related
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?
Is this really the only drawback to using targetSdkVersion 22 to force permissions at install time?
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.
Will things stay this way for years into the future?
No.
Can I still access API 23 & 24 features in an app
Yes, though some may behave differently due to your targetSdkVersion.
Is it possible that Google may allow permission requests at install time or run time in a future version
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
In the second half of 2018, Play will require that new apps and app updates target a recent Android API level. This will be required for new apps in August 2018, and for updates to existing apps in November 2018. This is to ensure apps are built on the latest APIs optimized for security and performance.
So we'll have to target the latest SDK version soon.
I know that if you set target sdk to 23 you now need to ask the users for "dangerous" permissions at runtime like was responded here:
Android 6.0 Permission Error
But some permissions are listed as "normal" and they are required when the app is installed. Is it possible to somehow mark some of the "dangerous" requirements that we have in our manifest to act as "normal" (to require them on install and not at runtime) because without some of them the app cannot actually function properly. Just rewriting everything to ask permissions at runtime is not really an option at the moment, but we will probably do that in the future.
No. There is no way to do what u want.
If you don't have the time to develop it now, you should target SDK 19 (permissions were introduced on Lollipop 21)
edit:
my bad, you should target API 22, as permissions were introduced on API 23. But still, target a lower API is the best option until you have time to properly develop the permission model.
Is it possible to somehow mark some of the "dangerous" requirements that we have in our manifest to act as "normal" ?
No it is not possibile.
The only way to avoid managing the runtime permissions is to use target 22.
But pay attention.
The users can revoke permissions from any app at any time, even if the app targets a lower API level
According to Android M Changes page, there is a new platform changes for Android 6.0. and they saying that
If you have previously published an app for Android, be aware that these changes in the platform affect your app.
So if my app is previously released before Android M release, and my app targeting API 21
1- Does this new changes will affect it?
2-Does i have to update my code to follow this new changes to be compatible with Android Mand raise the API Level to be 23?
** take in consideration in Android developer they says
If the API level of the platform is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect.
Does this forward compatibility is applied to the Android M changes or not?
** i know this is a foolish version and i am daft man but please i need a help.
Does this new changes will affect it?
Some will. For example, while all of your permissions that you request in the manifest will be granted at install time (as they used to), the user can go in and deny them to your app in Settings. However, usually, all this will do is block access to data from your app, in ways that you should be handling already. For example, you might ask for READ_CONTACTS and query ContactsContract, but you should be handling the case where the user has no contacts. On Android 6.0, you might get no contacts in response to your query because the user denied your app access to contacts.
Does i have to update my code to follow this new changes to be compatible with Android Mand raise the API Level to be 23?
Generally speaking, no. Older Android apps usually work fine on Android 6.0.
However, eventually, there will be something that you want to have that requires targetSdkVersion of 23 or higher, in which case you will need to take other changes into account, such as the runtime permissions. And, you will need to test your app on Android 6.0, to see if Android 6.0's changes trigger bugs in your code.
I'm wanting to clarify on the key changes of marsh mallow 6.0.
Are there any changes that we need to be aware of as developers, as opposed to user only or OS features that do not affect development.
If so how do we manage these changes? example do we need to disable a feature, will it cause application crashes or it will open the setting page and asking for enabling the feature for that application.
I was so confused about how the recent changes affect developers, I was looking for some clarity.
As far as I can see there's no need to enable or disable features, the developer needs to be mindful of what target sdk they are developing in when creating or updating apps.
The biggest change to developers in the latest upgrade is Runtime Permissions.
Taken from:
Everything every Android Developer must know about new Android's Runtime Permission
Although Android is being keep developed but the latest update to Android M is totally different since there is some major change that would change everything like new Runtime Permission. Surprisingly it is not much talked about in Android Developer community even though it is extremely important and may cause some big trouble in the near future.
.../...
You might already feel like there is some cold wind blowing through your arms ... If you are an Android Developer, you will suddenly know that programming logic is totally changed. You cannot just call a function to do the job like previous but you have to check for the permission for every single feature or your application will just simply crash !
Correct. I would not spoil you that it is easy. Although it is a great thing for user but it is truly nightmare for us developer. We have to take coding to the next level or it will surely have a problem in both short-term and long-term.
Anyway this new Runtime Permission will work like described only when we set the application's targetSdkVersion to 23 which mean it is declared that application has already been tested on API Level 23. And this feature will work only on Android 6.0 Marshmallow. The same app will run with same old behavior on pre-Marshmallow device.
This means user permissions are not being requested at install time, but at runtime. This is done using a permission request, and can be saved by the user for one run of the app, or as a default 'always'. This permission can always be revoked in the device settings.
As the api is backward compatible, any devices running with apps of targer sdk < 23 will still be ok.
However these same apps will not run on android devices >= 6.0 with a target sdk of 23 if the runtime permissions are not implemented and the user failing to give permission needs to be managed to stop apps from crashing.
The only manisfest permissions that will require runtime permission requests are those that are deemed as a dangerous permission level, so accessing personal information, camera, etc.
Permissions are grouped and once a permission is given for one item of a group, permission is then granted for the remaining permissions of the group.
For more detail Sytem - Permissions.
I have an app in the market that is targeting Android SDK 23 at the moment.
My problem is that with the release of Android 6, users have to accept dangerous permissions at runtime. I have got my first crash regarding this and I want to solve it fast before it gets serious.
I want to do it correctly as Android recommend asking the user at runtime to accept the permission and if not, hide the feature and stuff. But that takes time and will be done in the future. :)
But, would be for now changing the targetSdkVersion to 22 be a valid solution? What would that mean for users with Android 6 that have already installed the app?
I hope my quiestion is clear, thanks a lot!
If an app targets the Marshmallow SDK, it means that the app is aware of the new features and can use them
I think that if you're not handling the permissions as Android 6 is supposed target it one API lower because this is the compatibility of you're app
Btw it is recommended to ask the critical permissions on the start of the app and the minor when needed.
Hope that I helped.