I wanted to try a tutorial for blocking calls for 2.2 on emulator. But MODIFY_PHONE_STATE gives me an error, saying that this is a system permission error in android manifest file.
Do I need modify phone state permission to block calls? If so, I am not sure how to remove system permission error.
<uses-permission android:name="android.permission.MODIFY_PHONE_STATE"></uses-permission>
If you are using eclipse,
goto Window -> Preferences -> Android -> Lint Error Checking.
There in CorrectNess section you will see ProtectedPermission in Id column, select it.
At the bottom of the window you will see its Severity to be Error(It is default value.) Change it to anything less sever than Error.
Hope it helps you.
Related
I ran into a bit of trouble with a project I'm working on. I'm building out the permission logic (prompting the user in runtime) do display the user on the map, but as a response I always get never_ask_again. If I check the apps permission settings then location is enabled there. This makes it hard to build out and test some of the logic. I've tried uninstalling the app and cleaning the project, nothing seems to help.
Is there a way how I could reset the permission settings for this app on my phone or what's the solution to this?
Thanks in advance!
I found a solution to this, this command seems to give me the desired result - adb shell pm clear com.appName
I am setting my targetSdkVersion to 23 and therefore I want to implement
"Requesting permissions at runtime". (see here)
Lint directly calls out if you forget to check the permission and
tells you the following:
Call requires permission which may be rejected by user: code should
explicitly check to see if permission is available (with
checkPermission) or explicitly handle a potential
`SecurityException'
This is quite nice and I want to analyze my code for any call that I may
have forgotten, but I can't find Lint option that I have to select
in my Inspection profile.
How is the inspection called?
Thanks!
First click on Hector the Inspector (the small icon of a man with a moustache at the very bottom-right of Android Studio). This will bring up an option to Configure inspections.
You should then type 'Permissions' into the searchbar, and ensure that "Constant and Resource Type Mismatches" is checked. After that, it's a simple case of running an inspection via Analyse > Inspect Code.
I'm preparing my app to target Android 6.0 Marshmallow.
When setting the target api to 23, the app immediately crashes upon launch. There is no useful information in the logcat output. (It gives a "Requested window does not exist" IllegalStateException, but still, nothing actually useful like class name or line number.)
This is fine (not really), I eventually narrowed it down to my launch activity where I get the user's device IMEI code (TelephonyManager.getDeviceId()). There needs to be a runtime permission request added. I understand this.
However, the app has something like 60 classes across numerous activities, so there is a lot of code to sort through. How can I possibly search through the code to find all of the cases where runtime permissions are required?
Surely Google must have thought of an easy way for developers to track down where the permission requests are required? I thought perhaps commenting out the permissions in the manifest would trigger a compile-time error where the permissions are used, or something of the sort, but nope.
My current method is by going through the app and when it crashes, do like the above with my launch activity and very slowly narrow down where it is. This is extremely inefficient and time-consuming. I'm tempted to just leave it at API 22 for now, but I know sooner or later this will have to be done.
Delete all AndroidManifest.xml permission.
Analyze -> Run Inspection by Name ->Constant and Resource Type Mismatches in Android Studio.
You can detect permission.
But this detection is not perfect...
Because this detects only method that contains this xmls files.
https://android.googlesource.com/platform/tools/adt/idea/+/master/android/annotations/android
https://android.googlesource.com/platform/tools/adt/idea/+/master/android/annotations/android/accounts/annotations.xml#118
What worked for me is this :
Analyze -> Run Inspection by Name -> Missing Permissions
I know it's a simple question but I can't find any answer. Well actually it's three related questions:
If my code requires a uses-permission manifest element, does Eclipse automatically add it to the manifest?
If Eclipse doesn't automatically add it, how do I know which permissions my app needs? Of course there is this list, but it's hard to go though this list checking if what my app does falls within each of these permissions.
If Eclipse doesn't automatically add the permission and I fail to do it, how will I find out? Will the app fail to install on the emulator? Will it install on the emulator but be force-closed when trying to access something it doesn't have permissions for? Or do I have to install the apk on a real device in order to find out?
If my code requires a uses-permission manifest element, does Eclipse automatically add it to the manifest?
No.
how do I know which permissions my app needs?
Generally, by reading the JavaDocs, which do a decent job of pointing out what permissions you need. Otherwise, you will find out in testing, when your app crashes with a SecurityException.
If Eclipse doesn't automatically add the permission and I fail to do it, how will I find out?
See above.
Will it install on the emulator but be force-closed when trying to access something it doesn't have permissions for?
Correct.
Eclipse will not add permissions automatically. However, if you try to use a feature that requires permission, you will be made aware of the missing permission. Here's an excerpt from android resource page on Permissions: Link
Often times a permission failure will result in a SecurityException
being thrown back to the application. However, this is not guaranteed
to occur everywhere. For example, the sendBroadcast(Intent) method
checks permissions as data is being delivered to each receiver, after
the method call has returned, so you will not receive an exception if
there are permission failures. In almost all cases, however, a
permission failure will be printed to the system log.
Your third question is answered by:
In almost all cases, however, a permission failure will be printed to
the system log.
Just in case you're wondering about what you would see in Logcat:
11-20 08:08:47.766: E/AndroidRuntime(9380):
java.lang.SecurityException: Need BLUETOOTH permission: Neither user
10111 nor current process has android.permission.BLUETOOTH.
Eclipse does not automatically add the uses-permission to your manifest. I once had forgot to add a permission and had my app fail when it got to that part of the code. I can't remember the exact error but it did mention that a permission was required to use the method I tried using and I believe that it told me what permission.
If you don't add one in then you will soon find out.
Is there a permission to acquire to clear logcat from the device? The following code is not working
ArrayList<String> commandLine = new ArrayList<String>();
commandLine.add("logcat");
commandLine.add("-c");
process = Runtime.getRuntime().exec(commandLine.toArray(new String[2]));
Is it event possible to clear logcat?
The only permission related to logs is:
<uses-permission android:name="android.permission.READ_LOGS" />
Try putting it to manifest. API says:
Allows an application to read the low-level system log files. Log entries can contain the user's private information, which is why this permission is 'dangerous'.
So it is definitelly required to read logs, however it is unclear whether it is helpful with clearing the logs.
There is no way for an app to clear logcat on the device. When you select the 'clear logcat' option in Eclipse/ADT you are not clearing it on the device.
If this changes or if I'm wrong then I hope someone will correct me - I'd be interested to know - but it is unlikely as they are moving Android in the opposite direction: as of JellyBean apps can no longer even read the logcat of other apps, let alone clearing it.