My android app has nothing to do with phone calls, but I'm seeing that when I install a debug build on my test device it requires "Phone Calls: read phone state and identity" permissions. (I make no mention of this in AndroidManifest.xml).
I'd like to have the minimum possible permissions, and wondered if anyone knew how to get rid of this? I commented out the part where I was logging some stuff from Build.MODEL, Build.VERSION.*, etc. I also commented out the part where I was detecting the landscape/portrait orientation thinking that that might be the "phone state". But neither of those seemed to remove that permission required.
I found this bug report: http://code.google.com/p/android/issues/detail?id=4101 but it's marked working-as-intended with a note about permissions being correct from the market but not otherwise. Is this other people's experience? (I'd hate to have to publish to the market just to test that out.) Otherwise, does anyone know if there's an API I can avoid calling that will make it so my app doesn't need this permission?
Thanks!
(Answering my own question in case anyone else runs into this problem and searches for it.)
Digging around in PackageParser.java in the android source, I found out that the system will automatically assign
android.permission.WRITE_EXTERNAL_STORAGE and
android.permission.READ_PHONE_STATE
to any app that declares a targetSdk version of less than 4 (donut). There must be a compatibility reason for this, maybe apps targeting older versions could assume they had these permissions without declaring them explicitly. So, if you don't want these permissions added to your app implicitly, add a section like the following in AndroidManifest.xml
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="4" />
That is all.
Have fun, -Mike
Android 1.6 changelog: http://developer.android.com/sdk/android-1.6.html#api
WRITE_EXTERNAL_STORAGE: Allows an
application to write to external
storage. Applications using API Level
3 and lower will be implicitly granted
this permission (and this will be
visible to the user); Applications
using API Level 4 or higher must
explicitly request this permission.
But that is only one of them. For some reason the official change log is missing the info about READ_PHONE_STATE. The full story is cleared up here: http://blogs.zdnet.com/Burnette/?p=1369&page=3
New permissions. 1.6 programs must
explicitly request the
WRITE_EXTERNAL_STORAGE permission to
be able to modify the contents of the
SD card, and they must explicitly
request the READ_PHONE_STATE
permission to be able to be able to
retrieve phone state info. Apps
targeting earlier versions will always
request these permissions implicitly.
So as you can see, there is no way to publish an app targeted at 1.5 or earlier without requesting those permissions when installed on phones running 1.6 or higher.
Related
My app, already published on Google Play and currently targetting Android 12, is an alarm clock app. In the latest release, I have used the SCHEDULE_EXACT_ALARM permission and also handled checking and requesting this permission at runtime, as required.
Upon checking the behaviour change for Android 13, I found that there is a new permission USE_EXACT_ALARM which has very restrictive use cases as listed here. My app is an alarm clock app, and hence it qualifies to use this permission. (An advantage of using this permission is that the system automatically grants it, and it cannot be revoked by the user.)
I added this permission to the AndroidManifest.xml file and removed the SCHEDULE_EXACT_ALARM permission. However, Android Studio gives me a lint warning on the method alarmManager.setAlarmClock(...):
This is what the warning reads:
Setting Exact alarms with setAlarmClock requires the SCHEDULE_EXACT_ALARM permission or power exemption from user; it is intended for applications where the user knowingly schedules actions to happen at a precise time such as alarms, clocks, calendars, etc. Check out the javadoc on this permission to make sure your use case is valid.
The Android Developers website says that I have the option to declare either of the permissions based on my use case. However, Android lint tells me that I should declare SCHEDULE_EXACT_ALARM irrespective of whether I have already declared USE_EXACT_ALARM.
What should I do? Follow the website and suppress lint?
The answer's actually buried in the USE_EXACT_ALARM permission's documentation:
Apps need to target API Build.VERSION_CODES.TIRAMISU or above to be able to request this permission. Note that only one of USE_EXACT_ALARM or SCHEDULE_EXACT_ALARM should be requested on a device. If your app is already using SCHEDULE_EXACT_ALARM on older SDKs but need USE_EXACT_ALARM on SDK 33 and above, then SCHEDULE_EXACT_ALARM should be declared with a max-sdk attribute, like:
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"
android:maxSdkVersion="32" />
So it's kind of a conditional thing - if you're on 33+, then USE_EXACT_ALARM will be available, and the other one won't be requested at all.
I have an app that allows users to login using fingerprint authentication. The feature has been in production for a couple of months, but in the last day I started seeing many of these exceptions:
java.lang.SecurityException: Must have android.permission.USE_FINGERPRINT permission.: Neither user ##### nor current process has android.permission.USE_FINGERPRINT.
The crash occurs when I call fingerprintManager.isHardwareDetected() to check whether or not the device supports fingerprint authentication. I have the USE_FINGERPRINT permission declared in the manifest, so I don't know why the system would think that the process does not have this permission. This should not be something that I have to check at run time since USE_FINGERPRINT is a normal permission.
This has been working fine for months, and when it started crashing yesterday, we had been on a stable release for about a month. This problem sounds almost identical to this FingerprintManager.isHardwareDetected() throwing java.lang.SecurityException?. I am only seeing the crash on Oreo devices.
My current plan is to catch the Security Exception and proceed as if the device did not have the hardware, but my worry is that this might mean that no one is able to use the feature for login if this problem persists. Has anyone else had a recent issue with this exception? Or if not, does anyone have any ideas about why this might have just started happening all of a sudden like this? Thanks for the help!
Use the FingerprintManagerCompat instead, that was handling permissions correctly for me.
See:
https://developer.android.com/reference/android/support/v4/hardware/fingerprint/FingerprintManagerCompat
Additionally you might want to declare the permissions in your Android Manifest:
<!-- Fingerprint -->
<uses-permission-sdk-23 android:name="android.permission.USE_FINGERPRINT" />
Note that I used uses-permission-sdk-23, since I found that FingerprintManager doesn't work reliable in older versions of Android, I know there are some Samsung Galaxy devices with fingerprint reader, but before API 23 you were granting permissions at installation time; that depends more on your market. Try it and see if it makes a difference for your users.
See: https://developer.android.com/guide/topics/manifest/uses-permission-sdk-23-element
I found our apps runs even without asking permission like camera, location by setting the Target SDK 22 in API 24,25,26. Is it good to do that? Or we should make our app to ask permission to use Camera, Location of device?
I think it's better to check and ask permissions mainly because user can remove permissions manualy. In such case, your application could stop working. Handling permissions "in state of art" can avoid useless problems.
<uses-permission android:name="android.permission.CALL_PRIVILEGED"/>
I cannot grant this permission in the android manifest file as it shows the following
error:
Permissions with the protection level signature or signatureOrSystem are only granted to system apps. If an app is a regular non-system app, it will never be able to use these permissions.
So,what should i do now?
Permissions with the protection level signature or signatureOrSystem
are only granted to system apps. If an app is a regular non-system
app, it will never be able to use these permissions.
So,what should i do now?
If your app is expected to run on non-rooted devices, then you're simply doomed - you can do nothing, unless you have platform keys to sign your app with it.
Alternatively, you may narrow your audience to rooted devices only but that would allow you to do what you want incl. using features usually reserved for the platform or system apps ony.
Finally you may rethink your approach. Perhaps what you want to do can be achieved other way, w/o need of elevating app privileges.
For this "CALL_PRIVILEGED" permission , you will need a rooted device and the app must be installed as a system app only.
From the documentation (https://developer.android.com/reference/android/Manifest.permission.html#CALL_PRIVILEGED):
String CALL_PRIVILEGED
Allows an application to call any phone number, including emergency numbers,
without going through the Dialer user interface for the user to confirm the
call being placed.
Not for use by third-party applications.
So, the short answer is that you can't use it. What are you trying to accomplish?
I googled for an example source code for blocking calls and came across this EXAMPLE, But later I came to know that Google has updated their policy and
android.permission.MODIFY_PHONE_STATE
is an system level permission from android version 2.3, I have very important module placed on blocking a specific call.
How do I get a system level permission?
Please let me know if there is any way I can do this in my application. Its very important for the product and cannot be released without this functionality.
Please Help!
Thanks in advance
At least as of Android 5.0, MODIFY_PHONE_STATE has the following definition:
<permission android:name="android.permission.MODIFY_PHONE_STATE"
android:permissionGroup="android.permission-group.PHONE_CALLS"
android:protectionLevel="signature|system"
android:label="#string/permlab_modifyPhoneState"
android:description="#string/permdesc_modifyPhoneState" />
Your app can only hold this permission and use it to modify the phone state if it is signed by the firmware's signing key (the "your own custom ROM" scenario from Marcin's comment) or if your app is installed on the system partition. The latter can be accomplished by having your app pre-installed on the device (or having a rooted device user move your app to the system partition, as I understand it).