This question already has answers here:
How to grant MODIFY_PHONE_STATE permission for apps ran on Gingerbread
(5 answers)
Closed 10 years ago.
How to resolve this issue android.permission.MODIFY_PHONE_STATE. when i'm trying to answer my call this error should occurred.
The problem you're having was introduced in Android 2.3 (Gingerbread). Any code you have that requires MODIFY_PHONE_STATE will work all the way up to (and including) Android 2.2, but will break for Android 2.3+.
A change was checked in by David Brown that limits the use of the MODIFY_PHONE_STATE permission to system apps. System apps are either
Pre-installed into a system folder on the ROM
Compiled by a manufacturer using their security certificate
There was an issue opened for this, but Google killed it. They did this on purpose, not by accident, and clearly have no intention of reversing it.
I suspect you're trying to use a hidden API like ITelephony. I am - and I got burned by this. The Android team's justification is that it was hidden and you shouldn't have been using it anyways. My personal belief is that there was no security risk (it needed a permission) so just leave it in place until they finish building a proper public Telephony API.
You are not having this permission in the app manifest
Add permission in the manifest android.permission.MODIFY_PHONE_STATE
If the problem still remains please follow the stackoverflow internal link.
Related
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.
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 am pretty new in Android Studio. I am trying to add a permission:
<uses-permission android:name="android.permission.CONTROL_LOCATION_UPDATES"/>
The problem I am facing is that apparently my app is NON system app. I read about the differences between system and NON system apps. However I didn't get to any solution.
My question is: How to sign an app by platform signature? Can anyone explain that please? And maybe explain why do I need to do that?
I know that my question might look very silly, but as I mentioned, I just started to use Android Studio so I am pretty new in all that and I need some help with silly things like this one.
My question is: How to sign an app by platform signature?
Build your own custom Android ROM. You will sign that platform, and you can then sign your app with the same signing key. Of course, you will only get this permission when your app is running on devices that, in turn, are running your custom ROM.
And maybe explain why do I need to do that?
Because you are trying to use a signature-level permission to control the OS. Approximately 1 in 50,000 Android developers need to do this, and usually only in conjunction with creating their own custom Android ROM.
IOW, to quote the documentation for this permission: "Not for use by third-party applications".
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is there any way to ask permission programmatically?
as my app requires the permission<uses-permission android:name="android.permission.CALL_PHONE" />
most of my users aren't happy cause on installation there's a text "paid services" (or sth) because in my app I have to make calls.
Afaik there IS a solution to NOT write permissions in the manifest, but ask for them as they are used.
How can I achieve this?
You cannot change permissions of existing app, but you may create two different apps, one with CALL_PHONE permission, and another one without it. And let the people decide which one they want to install.
Although I'm one of the developers who would like to see some hybrid permission system in place, there is no solution as of today, at least according to the docs.
Android has no mechanism for granting permissions dynamically (at run-time) because it complicates the user experience to the detriment of security.
Source