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.
Related
I am wondering if that if I only test this application in this version of API, will it work still the same as API versions above? If it doesn't, what's a good way to develop an application? Create it 1 by 1 for each API?
I heard from my friend that he developed his app in KitKat but when he tested it in Marshmallow, some features are not working right.
My friend also met a problem similar to your friend's. His app runs well in kitkat but when he use Lollipop, the camera cannot work. There is nothing absolute, you can only test your app on as many devices as possible.
For some deprecated methods, you should keep an eye on them to make sure they can still work on higher sdk levels.
Something even more annoying is that some manufactures change the API so that they can customize the OS deeper such as Xiaomi MIUI.
There is no such guarantee. You should pay attention every time a new major android version is released as it might affect your app, even if you're targetting a lower api level.
For example, Android O will limit background execution, even if you don't target api level 26. See: https://developer.android.com/preview/behavior-changes.html#atap
Things are changing since every android update and here are a few of the many things which one should keep in mind while developing an application:
Runtime permissions are a major change in Marshmallow and onwards. Gone are the days when developers could add whatsoever permissions. Runtime permissions prompts the user to grant a permission to run a specific feature in the application and the user has an option of denying it. In case you haven't checked if your app has been granted the required permissions before conducting an operation you will get a security exception.
Permission groups has been added. Each group has a set of permissions and one should check in which group your required permission falls before prompting for it.
Location services API has also undergone some changes. As per the old API the user would be taken to the settings page in order to turn on the location services. This has changed and now the user can be prompted to turn on the location services using the new API. Check documentation for more details.
Android O limits the number of background tasks which can be executed. So as a developer you have to be wise about which task is being executed in which thread.
App signing process has also changed significantly especially for application supporting marshmallow and above.
These are just a few of the things which one may keep in mind while developing an application. Also look out for deprecated api's.
I am getting very conflicting information regarding the use of android.permission.READ_LOGS Android permission. Firstly, the Android Documentation website does not specify the protection level of this permission. It is neither classified as normal, nor dangerous. They do specify the following:
"Not for use by third-party applications, because Log entries can
contain the user's private information."
Some websites say not to use it for the same privacy concerns.
However I have some issue with that:
When I tested this permission in my app on Android 7.1.1 (Nexus 5X) and Android 4.4.2 (old Samsung 8" tablet), neither of them prompted me that the app required this permission. Both said that the app requested "no special permissions". This only happens if the permission is deemed "normal", in which case it is automatically granted.
Secondly, using this permission, I can only view logs from logcat pertaining to my app, which does not log any personal information. Hence, I don't violate any privacy either. I thought this permission may allow me to see other app's logs, causing privacy issues.
So, if this is the case, then is it deemed safe to use this permission in a production version of the app? It would help me a lot in debugging strange bugs users face if they can send me a logcat by the press of a button.
EDIT: Ok, now I am quite confused. It appears that I don't need to explicitly specify this permission in the manifest either.
Is READ_LOGS a normal or dangerous Android permission?
Neither. As of Android 7.1, it is signature|privileged|development. That basically means that apps signed as part of the firmware build or installed on the privileged partition can hold the permission, but nothing else can.
the Android Documentation website does not specify the protection level of this permission
Correct. READ_LOGS is still in the SDK, for backwards-compatibility reasons, but ordinary apps have not been able to hold it since Android 4.1, which came out five years ago.
This only happens if the permission is deemed "normal", in which case it is automatically granted.
No.
I thought this permission may allow me to see other app's logs, causing privacy issues.
It did, on Android 4.0 and earlier.
then is it deemed safe to use this permission in a production version of the app?
Well, bear in mind that there has never been a documented and supported way for apps to access LogCat contents. Most likely, you're using one of the script-kiddie solutions that have been posted, such as running the logcat command and capturing its output. So, it is entirely possible that there are devices, now or in the future, that will not support your particular approach towards accessing LogCat. So, the permission is not your problem; the lack of a supported API for LogCat access is your problem.
Personally, I'd use a logging library to log the content to both a file and to LogCat, using the file for whatever your app needs it for.
So I have this app that I made before the Android M came out, the app has permissions such as Camera(using custom camera within the app) Write & Read from external storage and System Alert permission I installed the app to my phone which has android 6.0 and the app was able to run normally and without any restrictions. I was able to use the camera, save files into sdcard & show a custom view using the WindowManager API.
please take a note that the target SDK for the app is android lollipop.
my question: is this even possible? the OS let apps that has target SDK smaller than M to run perfectly without asking for permissions? and if this is actually the default behaviour that android developers implement?
P.S: the identified question is not really applicable for my question. and i don't see any similarity between them at all.
Yes, it is possible. But that can give you a big problem. If the user deactivates some permission your app simple crushes because the permission is no longer available. The OS ask the user "This app was developed for a previous android version. disabling this permission can cause unexpected closing of the app" (ore some thing similar). In conclusion this is the normal behaviour because the android version that you are using to compile your app is before permissions needed to be confirmed by the user.
https://inthecheesefactory.com/blog/things-you-need-to-know-about-android-m-permission-developer-edition/en
this link explains all you need to now about your question .
Yes, if your app has targetSdkVersion below 23, it will work on M and above without asking any permissions (they will be asked during installation).
But if user will revoke any permission himself, app will crash. It was made by Google to get backwards compatibility with old applications that does not support new Permissions API.
You can read more about it here.
Here is quote from that page:
If the device is running Android 5.1 or lower, or your app's target
SDK is 22 or lower: If you list a dangerous permission in your
manifest, the user has to grant the permission when they install the
app; if they do not grant the permission, the system does not install
the app at all.
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.
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.