It's not needed to add the app to the power-save exemption list, and it's probably a bad practice to encourage the user to do so for this kind of app.
However I noticed that on my device, even when granting the permission and using setExactAndAllowWhileIdle(), the alarm may still be delayed by a minute or two when the device is in sleep mode, but it's good enough.

Regarding the fact that you're also using AlarmManager to update the schedule data in the background: the recommended API to do this nowadays is Jetpack WorkManager. It allows to set constraints for the job (for example a network connection is required), a retry policy, and more.

from eventfahrplan.

Hi there, here are some quick answers:

1. In reality, SCHEDULE_EXACT_ALARM is a normal permission and not a runtime permission, so adding it to the manifest is enough to obtain it. However, obtaining the permission only does half of the job, as it only enables the "Alarms and Reminders" option panel in the system app settings. The second part of the job is to ask the user to go check the box in that panel, and as a shortcut you can launch the ACTION_REQUEST_SCHEDULE_EXACT_ALARM intent.
2. I didn't notice that issue, I receive RESULT_OK if the box is checked when returning to the app. Make sure you pass "package:${BuildConfig.APPLICATION_ID}" as uri data in your intent in addition to the action (assuming you use BuildConfig and are in your app module, otherwise you can also use context.packageName)
3. I'm afraid this screen will always be shown using the system language because the user is actually leaving your app to be redirected to a system settings screen.

from eventfahrplan.

2. Not sure what goes wrong here. I am using the following intent:

   val intent = Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM)
       .setData("package:${BuildConfig.APPLICATION_ID}".toUri())
   scheduleExactAlarmsPermissionRequestLauncher.launch(intent)

Functionality-wise everything works. So this can be fixed later, too. I now merge the branch.

Thank you again for bringing this up!

from eventfahrplan.

Thank you for reporting this issue and the effort of providing both the detailed analysis and the implementation reference!

It is indeed something that should be address as soon as possible (speaking of alarms ... smirk). I have seen the announcements before. I haven't come around to look into the topic for a while, though.

Power-save exemption

Apps targeting Build.VERSION_CODES#S or higher can schedule exact alarms only if they have the Manifest.permission#SCHEDULE_EXACT_ALARM permission or they are on the device's power-save exemption list. These apps can also start Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM to request this permission from the user.

Source: https://developer.android.com/reference/android/app/AlarmManager#canScheduleExactAlarms()

Do you think requesting to be on the "device's power-save exemption list" is also required to have alarms being fired on time? Also PowerManager#isIgnoringBatteryOptimizations is mentioned on the page.

Docs

Here is a few more links to the docs for later reference:

• Android 12 / behavior changes: Exact alarm permission
• Android 13 / behavior changes: New permission to use exact alarms
• Android 14 / behavior changes: Schedule exact alarms are denied by default

Notes

⚠️ At the moment the alarm manager is used to schedule session alarms and to load schedule data. The latter has to be separated from the change to use exact alarms is separated an uses AlarmManager#setInexactRepeating.

from eventfahrplan.

Looking into the topic I noticed a few questions / shortcomings:

1. Why can I not invoke permissionRequestLauncher.launch(SCHEDULE_EXACT_ALARM) like for POST_NOTIFICATIONS? And why is there no warning that it is wrong if I do anyway?
2. Once I granted the system permission screen with ACTION_REQUEST_SCHEDULE_EXACT_ALARM and resume my app the resultCode is RESULT_CANCELED and tell nothing about whether the permission was granted or not. Isn't that very inconvinient?
3. When I launch the system permission screen from an app running with a different language (e.g. German) than the system language (e.g. English) then the system permission screen is shown in the system language (e.g. English). That seems to be not very helpful for users.

@cbeyls Did you notice these too? Any other?

from eventfahrplan.

Maybe your issue is hardware-related? I tested my implementation on the emulator and on a Pixel 4a.
You can always test AlarmManager.canScheduleExactAlarms() instead when the activity result arrives.

from eventfahrplan.

I tested it on various devices and emulators - see: #614

Yes, I also check with canScheduleExactAlarms(), see:

from eventfahrplan.