Develop Reference

Android permission SCHEDULE_EXACT_ALARM required with USE_EXACT_ALARM for alarm app?

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.

Since Android 6.0 listening to the PhoneStateListener.LISTEN_DATA_CONNECTION_STATE changes seems to no longer require READ_PHONE_STATE permission

I'm applying Android 6.0 runtime permissions into an app which listens to carrier data connection state changes. I first tried to just remove the READ_PHONE_STATE from the manifest to check where the app requires the permission. To my surprise the app didn't crash at all.
After this I've tried the same installation on two pre 6.0 devices which did actually crash on it. To me it seems like Android 6.0 does no longer require the permission. Is there any way to confirm this?
The line below is the one on which the pre 6.0 devices crashes:
tm(TelephonyManager).listen(this, PhoneStateListener.LISTEN_DATA_CONNECTION_STATE);

Is there any way to confirm this?
Yes, this commit removes the request of READ_PHONE_STATE when register the event type LISTEN_CALL_STATE, LISTEN_DATA_ACTIVITY and LISTEN_DATA_CONNECTION_STATE:
Do not enforce PHONE_STATE_PERMISSION to register listener PHONE_STATE_PERMISSION should not be required to register to the following event types:
- PhoneStateListener.LISTEN_CALL_STATE
- PhoneStateListener.LISTEN_DATA_ACTIVITY
- PhoneStateListener.LISTEN_DATA_CONNECTION_STATE
In case of LISTEN_CALL_STATE, an empty string should be passed instead of incomingNumber, when caller has no PHONE_STATE_PERMISSION.
Bug: 21588537 Change-Id: I5b6d0308924f7e4cd13a983b8e0c9b3a5bbb119b
The documentation on developer.android.com was updated and correctly shows that the permission are not required.
If your code doesn't need the permission READ_PHONE_STATE for other reason apart from LISTEN_DATA_CONNECTION_STATE you can change your AndroidManifest.xml adding maxSdkVersion to the uses-permission:
<uses-permission android:name="android.permission.READ_PHONE_STATE" android:maxSdkVersion="22" />

There is no special permission listed for PhoneStateListener.LISTEN_DATA_CONNECTION_STATE in the official android documentation.
http://developer.android.com/reference/android/telephony/PhoneStateListener.html#LISTEN_DATA_CONNECTION_STATE

How to use Android permissions and make them optional for devices that do not have that feature

I have an app that plays audio. I recently added the permission:
android.permission.READ_PHONE_STATE
so I could tell when a call was coming in so I could mute the audio during the call. I also added the permission:
android.permission.CALL_PHONE
So the user could press a icon to call a phone number. These were minor changes and really don't affect how most people use the app. After I published it I now have users who have tablets that don't have phone capability that they can not download the update and new users who have tablets do not see it in the play store anymore.
I read several posts about using this in the manifest instead of the permissions:
<uses-feature android:name="android.hardware.telephony" android:required="false">
But when I try to test the app on the device I get this error:
Caused by: java.lang.SecurityException: Neither user 10022 nor current process has android.permission.READ_PHONE_STATE.
Does anyone have any suggestions on how I can add these minor features to the app without alienating all of the non-phone users?

I read several posts about using this in the manifest instead of the permissions
You use <uses-feature> in addition to the permissions, not instead of the permissions.
Quoting the documentation:
For any of the permissions below, you can disable filtering based on the implied feature by explicitly declaring the implied feature explicitly, in a element, with an android:required="false" attribute.
So, add back your permissions. Then, use PackageManager and hasSystemFeature() at runtime, to see whether the device has android.hardware.telephony, so you can react as needed.

As #CommonsWare suggested use the following code to check if the device has telephony features available using the PackageManager
PackageManager pm = getBaseContext().getPackageManager();
pm.hasSystemFeature(PackageManager.FEATURE_TELEPHONY);

Android App reports "not installed" due to permission error

On a tablet I installed a apk develloped in Eclipse under Ubuntu. The App works on the AVD and is already installed on a phone and working.
The installation of the apk gives no error, however when starting the App it gives a "not installed" toast message.
In the aLogCat output I see a Permission denial message of the Launcher for WRITE_EXTERNAL_STORAGE. Note that the USB connection is not connected when I started the App.
Furthermore I noticed the following line in aLogCat and I noted that the "-1" was added to the package name.
New package installed in /data/app/com.company.AppName-1.apk
In the manifest the lines
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-sdk android:minSdkVersion="8" android:targetSdkVersion="15" />
are in the manifest block and
<android:permission="android.permission.WRITE_EXTERNAL_STORAGE">
in the application block.
Why is this working on a Android 2.3 phone and in a Android 4.0.3 AVD, but not on a Android 4.0.3 tablet?
Platform info: Eclipse 3.7.2, Tablet: Yarvik TAB461EUK; Installed with "ES File Explorer"

Try removing the permission from the application block. I dont know for sure but from personal experience ICS do not support permission attribute in application block which has already been defined in the main block. It inherits from the main block. Please tell if that solves the problem.
I dont know why it works on the AVD, may be because AVD do not have any external storage.

Related documentation:
http://developer.android.com/guide/topics/manifest/manifest-intro.html describes the permission element only for the main manifest block (now)
Changes per version states:
HONEYCOMB: When an application requires a permission to access one of its components (activity, receiver, service, provider), this permission is no longer enforced when the application wants to access its own component. This means it can require a permission on a component that it does not itself hold and still access that component.
Activity states:
The name of a permission that clients must have to launch the activity or otherwise get it to respond to an intent. If a caller of startActivity() or startActivityForResult() has not been granted the specified permission, its intent will not be delivered to the activity.
If this attribute is not set, the permission set by the element's permission attribute applies to the activity. If neither attribute is set, the activity is not protected by a permission.
Not very clear to me

Android permissions: Phone Calls: read phone state and identity

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.