Este artículo se centra en cómo las aplicaciones de despertador deben responder a la adición del modo DB en Android 7.0.
Modo de inicio directo: Android 7.0 se ejecutará en un modo seguro de "inicio directo" cuando el dispositivo esté encendido pero el usuario no lo haya desbloqueado.
En pocas palabras, si no se realiza ningún procesamiento, la configuración del despertador no se puede utilizar cuando el teléfono está encendido y la pantalla está bloqueada (modo DB).
Para acceder al sitio web del desarrollador, consulte: Admite el modo de "arranque directo" | Desarrolladores de Android | Desarrolladores de Android
Método de respuesta:
1. Solicitud de ejecución en modo DB
De forma predeterminada, las aplicaciones no se ejecutan en el modo de inicio directo. Si su aplicación necesita realizar operaciones en modo DB, debe registrar los componentes de la aplicación que deben ejecutarse en este modo. Las aplicaciones se registran en el sistema marcando los componentes como compatibles con criptografía antes de que puedan ejecutarse en modo de inicio directo o acceder al almacenamiento criptográfico del dispositivo.
android:directBootAware="true"Cuando el dispositivo se reinicia, los componentes criptográficos pueden registrarse para recibir mensajes de transmisión ACTION_LOCKED_BOOT_COMPLETED del sistema. En este momento, el almacenamiento cifrado del dispositivo está disponible.
<action android:name="android.intent.action.LOCKED_BOOT_COMPLETED" />2. Recibir notificación de desbloqueo de usuario
Cuando el usuario desbloquea el dispositivo después de reiniciar, la aplicación puede pasar a acceder al almacén cifrado de credenciales y utilizar servicios regulares del sistema que dependen de las credenciales del usuario.
El proceso en primer plano que necesita ser notificado inmediatamente escucha el mensaje ACTION_USER_UNLOCKED.
<action android:name="android.intent.action.USER_UNLOCKED" />El proceso en segundo plano que realiza operaciones en notificaciones retrasadas escucha el mensaje ACTION_BOOT_COMPLETED.
<action android:name="android.intent.action.BOOT_COMPLETED" />También puede consultar directamente si el usuario ha desbloqueado el dispositivo llamando a userManager.isUserUnlocked().
Problemas encontrados por AppClock:
1. Al encender el teléfono, la alarma no sonó y se perdió. Después de analizar el registro, encontramos:
Cuando el usuario utiliza el teléfono móvil (la tapa está abierta y la pantalla está encendida). Cuando suena una alarma y el usuario sale de la interfaz de timbre a través de un botón sin configuración de código (por ejemplo, debido a una mala operación, etc.), la alarma se configurará en el estado perdido, el timbre se apagará y Se enviarán notificaciones.
if (AlarmSubLcd.isFlipOpen(mContext) == true && mIsScreenOn == true) {
missed();
}Método de procesamiento: registre el componente donde se encuentra este método en el manifiesto
android:showWhenLocked="true"Coloque este componente sobre la interfaz de la pantalla de bloqueo y regrese a la interfaz de desbloqueo.
2. En el modo DB, existe la probabilidad de que el despertador no suene cuando caduque (el despertador puede sonar después del desbloqueo, pero el despertador caducado se perderá)
Este problema me llevó dos días trabajar en emo. Por lo general, los errores probabilísticos son causados por subprocesos. Del análisis del registro, no sé quién cambió el estado de la instancia de alarma de incendio a falla, lo que provocó que la alarma no sonara en ese momento. Más tarde, descubrí en el registro de fallos que el widget del reloj fallaba en modo DB. En modo DB, no se puede llamar al método updateWidget().
Acercarse:
Verifique si el dispositivo se ha desbloqueado llamando a userManager.isUserUnlocked() y luego llame al método updateWidget() después de desbloquear el dispositivo.
UserManager mUserManager = context.getSystemService(UserManager.class);
if (mUserManager.isUserUnlocked()) {
UpdateWidget();
}