¿Qué contexto recibe BroadcastReceivers al escuchar BOOT_COMPLETED?

AlarmManagers en Android pierden todas sus alarmas registradas cuando el teléfono pierde energía.

Utilizo el siguiente receptor de difusión para activar en el arranque de android:

public class AlarmBootReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) { Cursor alarmCursor = MainActivity.dbHelper.loadAlarms(); // Iterate through every stored alarm and set those alarms. // .... alarmCursor.close(); } } } 
  • Cuando onReceive del receptor de difusión se activa en el arranque del sistema, ¿qué parámetro de contexto se da al método? Tengo que saber el contexto, porque necesito el contexto para cancelar las alarmas establecidas en ese contexto.

  • Supongo que la llamada a MainActivity.dbHelper.loadAlarms () no es segura porque MainActivity no se inicializa en el arranque del sistema. ¿O es seguro porque dbhelper y loadAlarms () están todos inicializados y declarados estáticos?

Cuando onReceive del receptor de onReceive se activa en el arranque del sistema, ¿qué parámetro de contexto se da al método? Tengo que saber el contexto, porque necesito el contexto para cancelar las alarmas establecidas en ese contexto.

En este caso, obtendrás el Context aplicación global en onReceive() . Sin embargo, es irrelevante. No necesitas saberlo.

Para cancelar las alarmas más tarde, creará un PendingIntent y podrá usar cualquier Context que desee hacer. Las alarmas no están vinculadas a un Context específico, solo están vinculadas a una aplicación específica.

Supongo que la llamada a MainActivity.dbHelper.loadAlarms () no es segura porque MainActivity no se inicializa en el arranque del sistema. ¿O es seguro porque dbhelper y loadAlarms () están todos inicializados y declarados static ?

Si dbHelper es de hecho static e inicializado en la creación de instancia ( no en onCreate() ), entonces esta llamada está bien. En general, llamar a los métodos estáticos en las actividades es mal visto, ya que es fácil hacer algo estúpido suponiendo que la Activity se ha configurado correctamente. Sería mejor mover estos métodos estáticos a una clase general de utilidades, que no es una Activity y sólo contiene métodos static . Esto parecería menos sospechoso.

No importa qué tipo de Context recibe su BroadcastReceiver (en cualquier caso, su ApplicationContext ) porque: 1) Usted no debe usar un DBHelper que está asociado con una Activity . En su lugar, haga que sea Singleton y utilícelo en toda la aplicación. 2) Su AlarmManager debe configurarse utilizando un Service . Por lo tanto, su buena idea para llamar al servicio en su onReceive() y establecer las alarmas de ese servicio

  • ¿Por qué noftificaciones aparecen en la barra de notificación de Android por un tiempo, entonces desaparece
  • Widget no actualizado en el reinicio del lanzador
  • ¿Cómo puedo obtener los extras de Intent para un PendingIntent que ya está pendiente?
  • Incorrecto timestamp en las notificaciones futuras
  • Android: cómo obtener la ID de PendingIntent para cancelar la función pendingintent
  • Android - ¿Por qué utilizar intenciones pendientes para geofences
  • ¿Cómo puede detectar si su actividad está siendo onPaused debido a un PendingIntent que creó?
  • FLAG_CANCEL_CURRENT o FLAG_UPDATE_CURRENT
  • Android: ¿Cómo puedo acceder a un AsyncTask desde un PendingIntent creado por una notificación de barra de estado?
  • PendingIntent obtener requestCode
  • Ocultar la acción del teléfono abierta en el uso
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.