Programa alarmas exactas rechazadas de forma predeterminada

Las alarmas exactas están diseñadas para notificaciones destinadas a usuarios o para acciones que deben realizarse en un momento preciso.

SCHEDULE_EXACT_ALARM, el permiso que se introdujo en Android 12 para que las apps programen alarmas exactas, ya no se otorgará, de forma previa, a las apps instaladas más recientemente que se orienten a Android 13 y versiones posteriores (se establecerá como rechazado de forma predeterminada). Si el usuario transfiere datos de la app a un dispositivo que ejecuta Android 14 mediante una operación de copia de seguridad y restablecimiento, se rechazará el permiso de todos modos. Si una app existente ya tiene este permiso, se otorgará de forma previa cuando el dispositivo se actualice a Android 14.

Se requiere el permiso SCHEDULE_EXACT_ALARM para iniciar alarmas exactas mediante las siguientes APIs; de lo contrario, se arrojará SecurityException:

Aún se aplican las prácticas recomendadas actuales para el permiso SCHEDULE_EXACT_ALARM, incluidas las siguientes:

Apps afectadas

Si un dispositivo ejecuta Android 14 o versiones posteriores, este cambio afectará a una app instalada recientemente que tenga las siguientes características:

  • Se orienta a Android 13 (nivel de API 33) o versiones posteriores.
  • Declara el permiso SCHEDULE_EXACT_ALARM en el manifiesto.
  • No se encuentra dentro de una situación de exención u otorgamiento previo.
  • No es una app de calendario ni de alarma.

Las apps de calendario y alarma deben declarar USE_EXACT_ALARM

Las apps de calendario o alarma deben enviar recordatorios del calendario, alarmas de activación y alertas cuando la app ya no se ejecute. Estas apps pueden solicitar el permiso normal USE_EXACT_ALARM. Se otorgará el permiso USE_EXACT_ALARM durante la instalación, y las apps que tengan este permiso podrán programar alarmas exactas, al igual que las apps con el permiso SCHEDULE_EXACT_ALARM.

Casos de uso que podrían no exigir alarmas exactas

Como ahora el permiso SCHEDULE_EXACT_ALARM se rechaza de forma predeterminada, y el proceso de concesión de permisos requiere pasos adicionales de los usuarios, se recomienda que los desarrolladores evalúen sus casos de uso y determinen si las alarmas exactas tienen sentido para sus casos de uso.

En la siguiente lista, se muestran los flujos de trabajo comunes que pueden no requerir una alarma exacta:

Programa tareas repetidas durante el ciclo de vida de tu app
El método set() es útil si la tarea debe tener en cuenta las restricciones en tiempo real, por ejemplo, sonar a las 2:00 p.m. mañana o en 30 minutos. De lo contrario, se recomienda usar los métodos postAtTime() o postDelayed() en su lugar.
Tarea en segundo plano programada, por ejemplo, actualizar la app y subir registros
WorkManager proporciona una forma de programar tareas periódicas sujetas a horarios específicos. Puedes proporcionar un intervalo de repetición y flexInterval (mínimo de 15 minutos) para definir el tiempo de ejecución detallado de la tarea.
Se necesita que una alarma suene en un horario aproximado mientras el sistema esté inactivo
Usa una alarma inexacta. Específicamente, llama a setAndAllowWhileIdle().
Acción especificada por el usuario que debe ocurrir después de un tiempo específico
Usa una alarma inexacta. Específicamente, llama a set().
Acción especificada por el usuario que puede ocurrir dentro de un período
Usa una alarma inexacta. Específicamente, llama a setWindow(). Ten en cuenta que la duración mínima permitida es de 10 minutos.

Pasos de migración para seguir usando alarmas exactas

Como mínimo, las apps deben comprobar si tienen permiso para programar alarmas exactas. Si las apps no tienen el permiso, deberán invocar un intent para solicitarselo al usuario.

Es lo mismo que el flujo de trabajo estándar para solicitar un permiso especial:

  1. Las apps deben llamar a AlarmManager.canScheduleExactAlarms() para confirmar que tiene el permiso correcto.

  2. Si la app no tiene el permiso, invoca un intent que incluya ACTION_REQUEST_SCHEDULE_EXACT_ALARM, junto con el nombre del paquete, para solicitarles a los usuarios que otorguen el permiso.

    Verifica la decisión del usuario en el método onResume() de tu app.

  3. Detecta las transmisiones de AlarmManager.ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED que se envían si el usuario otorga el permiso.

  4. Si el usuario le otorgó el permiso a tu app, esta puede establecer alarmas exactas. En cambio, si el usuario rechazó el permiso, deberás hacer una degradación elegante de la experiencia en la app para que siga proporcionando funcionalidad, sin la información protegida por ese permiso.

En el siguiente fragmento de código, se muestra cómo verificar el permiso SCHEDULE_EXACT_ALARM:

val alarmManager: AlarmManager = context.getSystemService<AlarmManager>()!!
when {
   // If permission is granted, proceed with scheduling exact alarms.
   alarmManager.canScheduleExactAlarms() -> {
       alarmManager.setExact(...)
   }
   else -> {
       // Ask users to go to exact alarm page in system settings.
       startActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))
   }
}

Código de muestra para verificar el permiso y controlar las decisiones del usuario en onResume():

override fun onResume() {
   …  
   if (alarmManager.canScheduleExactAlarms()) {
       // Set exact alarms.
       alarmManager.setExact(...)
   }
   else {
       // Permission not yet approved. Display user notice and revert to a fallback  
       // approach.
       alarmManager.setWindow(...)
   }
}

Haz una degradación elegante de la denegación del permiso

Algunos usuarios se negarán a otorgar el permiso. En esta situación, recomendamos que las apps hagan una degradación elegante de la experiencia y todavía intenten proporcionar la mejor experiencia del usuario de resguardo posible mediante la identificación de sus casos de uso.

Exenciones

Los siguientes tipos de apps siempre pueden llamar a los métodos setExact() o setExactAndAllowWhileIdle():

  • Apps firmadas con el certificado de la plataforma
  • Apps con privilegios
  • Apps que se encuentran en la lista de entidades permitidas de la batería (si tu app cumple con los requisitos, puedes solicitarla mediante la acción de intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).

Otorgamientos previos

  • A los titulares de la función SYSTEM_WELLBEING, se les otorgará SCHEDULE_EXACT_ALARM de forma previa.

Lineamientos para las pruebas

Para probar este cambio, inhabilita el permiso Alarmas y recordatorios para tu app desde la página de Acceso especial de apps en la configuración del sistema (Configuración > Apps > Acceso especial de apps > Alarmas y recordatorios), y observa el comportamiento de tu app.