¿Las geocercas permanecen activas en Android después de reiniciar el dispositivo?

Estoy escribiendo una aplicación que necesita usar geofencing para cuando alguien ingresa / sale de varios sitios a lo largo de la vida de la aplicación que se está instalando.

Mi implementación de geofencing (muy similar al segundo enlace a continuación) funciona bien cuando instalo la aplicación por primera vez, tanto al moverme hacia adentro o hacia afuera de las geofences como al usar ubicaciones simuladas para simularlo, hasta que se reinicia el dispositivo.

Al reiniciar, ni las ubicaciones simuladas ni físicamente entrando y saliendo de una geocerca parecen desencadenar el evento y disparar el bash pendiente a mi receptor de difusión.

He examinado los siguientes tres enlaces y también he leído bastante sobre el documento, pero no puedo encontrar una respuesta definitiva a esto en ningún lugar que diga directamente que las geocercas registradas persisten o no persisten después de un reinicio.

Estos son los enlaces que revisé sobre el desbordamiento de stack: ¿Las geocercas de Android sobreviven a un reinicio?

Android Geofence finalmente deja de obtener intenciones de transición

¿Las Geofences de Android permanecen activas hasta que se eliminen / caduquen o solo hasta que se inicie mi PendingIntent?

Si alguien sabe la respuesta a si se quedan alrededor del reinicio de la publicación, o si no funciona, ¡sería muy apreciado! Mi última esperanza actualmente es crear un oyente para BOOT_COMPLETED y volver a registrarlos en el inicio, pero id solo lo hace si es absolutamente necesario.

¡Muchas gracias por adelantado!

Editar: Aunque no he encontrado una respuesta definitiva (por escrito), estoy bastante seguro de que lo que el Sr. TonyC publicó es correcto, y he optado por esa solución. Muchas gracias TonyC!

En caso de que alguien quiera ver la solución que tengo, escucho la acción de arranque completa cuando se inicia un dispositivo, y luego vuelvo a registrar todas las geocercas que necesito.

Esto está en el manifiesto:

       

y luego crea un receptor de difusión para él que volverá a registrar las geocercas en el arranque:

 package com.YOUR.PACKAGE.geofence; import android.app.PendingIntent.CanceledException; import android.content.Context; import android.content.Intent; import android.support.v4.content.WakefulBroadcastReceiver; import com.google.android.gms.common.ConnectionResult; import com.google.android.gms.common.GooglePlayServicesUtil; import com.google.android.gms.location.Geofence; public class BootCompleteReceiver extends WakefulBroadcastReceiver { private static final String TAG = "BootCompleteReceiver"; @Override public void onReceive(Context context, Intent intent) { //Do what you want/Register Geofences } } 

También vale la pena señalar que, si se encuentra dentro de una geocerca en el arranque, esto generalmente desencadenará la intención pendiente de la geofrontera una vez que se haya registrado la geocerca.

Entonces, si por ejemplo, la geocerca inicia una aplicación, entonces cuando arranque un dispositivo que está en la geocerca, también abrirá la aplicación una vez que el receptor de la transmisión de arranque completo haya registrado la geocerca, y los servicios de localización hayan funcionado donde usted son.

Espero que sea de ayuda para alguien.

En mi experiencia, las geofences no sobreviven al reinicio. Yo uso un receptor BOOT_COMPLETED tal como sugieres. Funciona bien.

Las geocercas no sobreviven a un reinicio. Hay otros casos en los que tendrá que volver a registrar geofences también.

Volver a registrar geofences solo cuando la documentación requerida indique varias situaciones además de BOOT_COMPLETED donde necesite volver a registrar sus geofences. Desafortunadamente es vago e incompleto.

Vayamos punto por punto teniendo en cuenta los nuevos límites de ejecución de fondo impuestos a partir de Android O:

  • El dispositivo se reinicia

Este se puede manejar agregando lo siguiente a su filtro de intención, ya que están exentos de la prohibición implícita de transmisión :

  

Luego, asegúrese de agregar el siguiente permiso a su manifiesto:

  

Es posible que desee capturar el nuevo bash LOCKED_BOOT_COMPLETED introducido en Android N:

  

Pero, si lo hace, también necesitará marcar su receptor con android:directBootAware=”true” . Esto introduce ramificaciones para su aplicación . A saber, cualquier información basada en archivos a la que acceda debe hacerse utilizando el almacenamiento protegido del dispositivo. En resumen, si no necesita que le avisemos cuando el dispositivo se inicie en la pantalla de locking, no use LOCKED_BOOT_COMPLETED.

  • La aplicación se desinstala y se vuelve a instalar

De nuevo, tenemos suerte aquí ya que puedes usar este bash explícito:

  
  • La información de la aplicación se borra

Aquí es donde no tengo idea. Hay un ACTION_PACKAGE_DATA_CLEARED que está exento de la prohibición implícita de emisión, pero solo se activará si se borran los datos de otro paquete. Intenté esto y puedo confirmar que no se te llamará cuando se borren los datos de tu propia aplicación.

  • Los datos de los servicios de Google Play se borran

Esto se puede manejar agregando lo siguiente a su receptor:

      

y luego agregue el siguiente código al método onReceive de su BroadcastReceiver:

 String action = intent.getAction(); if (TextUtils.equals(Intent.ACTION_PACKAGE_DATA_CLEARED, action)) { Uri uri = intent.getData(); if (uri.toString().equals("package:com.google.android.gms")) { // Code here to handle Google Play services data cleared } } 
  • La aplicación ha recibido una alerta GEOFENCE_NOT_AVAILABLE

Esta es la manera que tiene Android de notificarle a través de la API de geofencing que los servicios de ubicación ya no están disponibles y se significa enviando un GeofencingEvent con un código de estado y error de GEOFENCE_NOT_AVAILABLE .

Sin embargo, el simple hecho de seguir los vagos consejos de la documentación de geofencing lo llevaría a creer que puede volver a registrar geofences en este momento. Esto sería malo ya que los servicios de localización probablemente aún estén deshabilitados y al hacerlo se generarían más GEOFENCE_NOT_AVAILABLE s. Lo que se necesita es un gancho para saber cuándo se han cambiado los servicios de ubicación.

Hasta Android O, registrar un BroadcastReceiver para android.location.MODE_CHANGED_ACTION le daría este gancho. En Android O y más adelante, este bash implícito está prohibido y su BroadcastReceiver no se volverá a llamar más, por lo que se necesita otro enlace.

Para Android O y posterior, he encontrado que el uso de JobScheduler junto con JobInfo.Builder.addTriggerContentUri para monitorear el URI Settings.Secure.LOCATION_PROVIDERS_ALLOWED funciona para este propósito e incluso iniciará su aplicación si no se está ejecutando actualmente para invocar su JobService. Este enfoque requiere API> = 24. He verificado que esto funciona, incluso con Android P (API 28).

Algunas advertencias con el enfoque JobScheduler:

  1. Puede que su aplicación no se notifique de inmediato sobre el cambio, pero en mis pruebas, se notifica en unos minutos.
  2. LOCATION_PROVIDERS_ALLOWED está en desuso y podría eliminarse en una versión futura de Android.

Por lo tanto, si está de acuerdo con una versión minApi de 24, puede usar JobScheduler / JobService para obtener el gancho Settings.Secure.LOCATION_PROVIDERS_ALLOWED.

Pero, si no le gusta renunciar al 10% de su base de usuarios ( al momento de escribir esto, KitKat (API 19) obtiene el 9.1% de la base de usuarios activos de Android ) y necesita un minApi más bajo, necesitará tener un BroadcastReceiver y JobService.