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.
Related
I was wondering, is it possible to access what the INTERNET permissions grants, without actually requesting that permission?
Environment: rooted Android phone from API 15 (Android 4.0.3) to the newest one at the time of the answer and app as system app with privileged permissions. No signature permissions, but supposed I have them too. Just ANY way.
I'm asking this not to do some stupid stuff (hopefully no one that reads this will do, if there are any positive answers). Asking because I'm making an assistant app which is supposed to control the entire phone if needed, and requests many permissions. If the INTERNET one is not one of them, if I publish it on some store, people could be relaxed about privacy, since I can't send anything out - or can I still...?
If I can, I'll just let them know there's no way to be sure I won't steal their privacy except by trust (I guess? Or there's some other way I didn't think of?). If there's no way, well, done. Easy. Just don't include it and it's fine about privacy (would have to think about ads, but that's something else - reduced and full version or something).
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.
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 want to enable android.permissions.STATUS_BAR in my app. Is it possible to do so, given that I am targeting possibly non-rooted phones?
From what I understand, android.persmissions.STATUS_BAR is a System persmission and can't be used.
In android terms it falls under signatureOrSystem permission. The meaning is (taken from Android Manifest DOCS)...
A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The "signatureOrSystem" permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.
Have a look at the following links as well. They might help you find a workaround...
How to disable statusbar in android
Why are these permissions being refused?
Preventing status bar expansion
Starting Android 4.1 gettings android log requires ROOT permission, so now it's impossible to
ask users to send log using apps like LogCollector, which just get android log and send it to email. Android log can be viewed using ddms app from Android SDK but it's not good to ask users install Android SDK.
So, how to get android log from the users for Android 4.1 without rooting?
You can get your own app's log without permission now. You can not read other apps' logs at all, permission or not.
This is somewhat documented here. Just refer to Diane Hackborn's response:
The change is that third party applications can no longer get the read
logs permission, however every app can read the logs containing only
the lines they have written, without needing any permission.
Keep in mind that access to the logs has never been part of the SDK,
and is still not part of the SDK. If you are relying on it then, even
after this change, you run the risk of breaking in the future. (And
that is partly why this got lost for documentation, it is not part of
the SDK, so there isn't really a place to document it, in fact
documenting it would kind-of make it a part of the SDK which we don't
want. :p)
There are quite a few handy libraries out there that send the Crash Reports across to you.
ACRA
Zubhium How it works
Bug Sense
Acra is open source and free. Zubhium and Bug Sense have have a limited functionality Free Version.
All being said, these are good ONLY for your own application. Everything else that does not belong to you, is basically, off limits.
I am not sure if this could / would work, but see the Source for Cyanogenmod. There might be something of use and interesting there.