Do Geofences rimane attivo in Android dopo il riavvio del dispositivo

Sto scrivendo un’applicazione che ha bisogno di usare il geofencing per quando qualcuno entra / esce da più siti nel corso della vita dell’applicazione che si sta installando.

La mia implementazione del geofencing (molto simile al secondo link qui sotto) funziona perfettamente quando installo l’applicazione, sia quando si sposta dentro / fuori i geofence e quando si usano le posizioni simulate per simularlo, fino al riavvio del dispositivo.

Al riavvio, nessuna delle posizioni fittizie, né effettivamente il movimento fisico dentro e fuori di un geofence, sembra triggersre l’evento e sparare l’intento in sospeso al mio ricevitore broadcast.

Ho esaminato i seguenti tre collegamenti e ho anche letto un bel po ‘del documento, ma non riesco a trovare una risposta definitiva a questo in qualsiasi punto in cui le geofenze registrate persistono o non persistono dopo un riavvio.

Questi sono i link che ho esaminato sullo stack overflow: i geofence Android sopravvivono a un riavvio?

Android Geofence alla fine smette di ricevere intenti di transizione

I Geofence Android rimangono attivi fino alla rimozione / scadenza o solo fino all’avvio di PendingIntent

Se qualcuno capisce la risposta a se si fermano dopo il riavvio del post, o ha un lavoro in giro se non lo fanno, sarebbe molto apprezzato! La mia ultima speranza al momento è creare un listener per BOOT_COMPLETED e registrarli nuovamente all’avvio ma id preferisce farlo solo se assolutamente necessario.

Grazie mille in anticipo!

Modifica: anche se non ho trovato una risposta definitiva (per iscritto), sono abbastanza sicuro di ciò che il signor TonyC ha pubblicato è corretto e ho optato per questa soluzione. Grazie mille TonyC!

Nel caso in cui qualcuno voglia vedere la soluzione che ho, ascolto l’azione di avvio completa all’avvio di un dispositivo, quindi registro nuovamente tutti i geofisici di cui ho bisogno.

Questo è nel manifest:

       

e quindi creare un ricevitore broadcast per esso che registrerà nuovamente i geofence all’avvio:

 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 } } 

Vale anche la pena notare che, se si è all’interno di un geofence all’avvio, questo in genere attiverà l’intento in sospeso del geofence una volta che il geofence sarà stato registrato.

Quindi, se ad esempio, il geofence avvia un’app, quindi quando si avvia un dispositivo che si trova nel geofence, aprirà anche l’app una volta che il ricevitore broadcast completo di avvio ha registrato il geofence, e i servizi di localizzazione hanno funzionato dove siamo.

Spero che sia di aiuto a qualcuno.

    Nella mia esperienza i geofences non sopravvivono al riavvio. Io uso un ricevitore BOOT_COMPLETED proprio come suggerisci tu. Funziona bene.

    I Geofences non sopravvivono a un riavvio. Ci sono altri casi in cui dovrai registrare nuovamente i geofences.

    Re-register geofences solo quando la documentazione richiesta richiama diverse situazioni oltre a BOOT_COMPLETED dove è necessario registrare nuovamente i tuoi geofences. È sfortunatamente vago e incompleto.

    Andiamo punto per punto prendendo in considerazione le nuove restrizioni di fondo imposte a partire da Android O:

    • Il dispositivo viene riavviato

    Questo può essere gestito aggiungendo quanto segue al filtro intent, poiché questi sono esentati dal divieto implicito di trasmissione :

      

    Quindi, assicurati di aggiungere la seguente authorization al manifest:

      

    Potresti voler catturare l’intento LOCKED_BOOT_COMPLETED più recente introdotto in Android N:

      

    Ma se lo fai, dovrai anche contrassegnare il tuo ricevitore con android:directBootAware=”true” . Questo introduce ramificazioni per la tua app . Vale a dire che tutti i dati basati su file a cui si accede devono essere eseguiti utilizzando l’archiviazione protetta dal dispositivo. Il lungo e breve è, se non è necessario essere avvisati quando il dispositivo viene avviato alla schermata di blocco, non utilizzare LOCKED_BOOT_COMPLETED.

    • L’app viene disinstallata e reinstallata

    Di nuovo, siamo fortunati perché puoi usare questo intento esplicito:

      
    • I dati dell’app vengono cancellati

    Questo è dove non ho idea. Esiste un ACTION_PACKAGE_DATA_CLEARED che è esente dal divieto di trasmissione implicito, ma verrà triggersto solo se i dati di un altro pacchetto vengono cancellati. Ho provato questo e posso confermare che non verrai richiamato quando i dati della tua app verranno cancellati.

    • I dati dei servizi di Google Play sono cancellati

    Questo può essere gestito aggiungendo quanto segue al tuo ricevitore:

          

    e quindi aggiungendo il seguente codice al metodo onReceive di 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 } } 
    • L’app ha ricevuto un avviso GEOFENCE_NOT_AVAILABLE

    Questo è il modo di Android di notificare all’utente tramite l’API di geofencing che i servizi di localizzazione non sono più disponibili e che è significato inviando un GeofencingEvent con un codice di errore e stato di GEOFENCE_NOT_AVAILABLE .

    Tuttavia, seguire semplicemente il vago consiglio della documentazione di geofencing porterebbe a credere che è ansible registrare nuovamente geofences a questo punto. Ciò sarebbe negativo in quanto i servizi di localizzazione sono probabilmente ancora disabilitati e ciò comporterebbe un maggior numero di GEOFENCE_NOT_AVAILABLE . Quello che serve è un hook per dire quando i servizi di localizzazione sono stati triggersti.

    Fino a Android O, registrando un BroadcastReceiver per android.location.MODE_CHANGED_ACTION ti darebbe questo hook. Su Android O e versioni successive, questo intento implicito è vietato e BroadcastReceiver non verrà più chiamato, quindi è necessario un altro hook.

    Per Android O e versioni successive, ho scoperto che l’utilizzo di JobScheduler in combinazione con JobInfo.Builder.addTriggerContentUri per monitorare le impostazioni. Sicurezza.LOCATION_PROVIDERS_ALLOWED URI funziona per questo scopo e avvierà anche l’app se non è attualmente in esecuzione per richiamare il tuo JobService. Questo approccio richiede API> = 24. Ho verificato che funzioni, anche con Android P DP5, quindi presumo che funzioni con l’API 28 quando viene distribuito Android P.

    Alcuni avvertimenti con l’approccio JobScheduler:

    1. La tua app potrebbe non essere notificata immediatamente, ma durante i miei test viene notificata entro pochi minuti.
    2. LOCATION_PROVIDERS_ALLOWED è deprecato e potrebbe essere rimosso in una versione futura di Android, ma non ho trovato una soluzione migliore.

    Quindi, se stai bene con una versione minApi di 24, puoi semplicemente usare JobScheduler / JobService per ottenere l’hook Settings.Secure.LOCATION_PROVIDERS_ALLOWED.

    Ma se non ti piace rinunciare al 10% della tua base di utenti ( KitKat, ti sto indicando! ) E hai bisogno di un minApi inferiore, avrai bisogno sia di un BroadcastReceiver che di un JobService.