Uccidere app <my service> (pid 1724) perché provider <il mio provider> è in process di morire <la mia app>

Un provider viene implementato in applicazioni e aggiornamenti delle applicazioni fornendo i dati fornitori e viene triggersto un servizio remoto che richiede al provider di recuperare i valori memorizzati. L'applicazione è chiusa dopo qualche tempo, ma il servizio continua ad accedere al provider di contenuti. Ad alcuni punti viene riportto il seguente errore logcat e il servizio remoto si è arrestato.

"Uccidere app (pid 1724) perché il provider sta nel process di morire"

  • errore adb in eclipse android
  • Sostituire il button Home per un'applicazione per la sostituzione dell'auto
  • Le lattine Android consentono controlli con gradle
  • google map - runtimeexception - errore che infligge frammento di class
  • Come simulare Android che uccide il mio process
  • L'errore di Gradle dopo aver incluso facebook sdk
  • Ho provato google per questo errore e non sono riuscito a trovare informazioni sul perché questo errore si verifica.

    UPDATE: in uno dei contesti di posti restituiti da getApplicationContext viene utilizzato invece di Servizio per get contentresolver per interrogare il provider di contenuti. Causa qualche problema?

    4 Solutions collect form web for “Uccidere app <my service> (pid 1724) perché provider <il mio provider> è in process di morire <la mia app>”

    Hmm, fortuna, nessuna risposta finora. Ho capito cosa ha causato il crash la scorsa settimana! Credo che dovrei condividere quello qui.

    Il provider P è definito nell'applicazione A che ha un servizio S1 che distriggers il pacchetto e uccide il pacchetto per qualche motivo. Ora c'è un'altra applicazione B che dispone di servizio S2 e utilizza il provider P. Ad un certo punto, il servizio S1 distriggers alcuni componenti dell'applicazione Un pacchetto e uccide il process, che rende il fornitore di trovare tutti i processi connessi e uccide quei da uno, questo rende il process in cui l'applicazione B sta eseguendo a morire con l'errore "Uccidere app perché il provider è in process di morte.

    Spostare il fornitore in una nuova applicazione ha risolto il problema in modo che esso funziona nel proprio process risolto il problema.

    Il seguente post del forum sembra rilevante. https://groups.google.com/forum/?fromgroups#!topic/android-developers/7aOLy1DXdhQ

    Sembra che se esiste un process "A" che gestisce un provider di contenuto e un process "B" con un cursore (o ContentObserver) a tale fornitore di contenuti e proceda "A" per causa, ad esempio, di una disinstallazione di "A" 's pacchetto.

    provare questa soluzione:

     Context ctx = context.createPackageContext("package of the provider", Context.CONTEXT_IGNORE_SECURITY); cursor = ctx.getContentResolver().query(uri, null, null, null, null); // do something with cursor 

    E non ha riavviato il process principale quando il pacchetto viene disinstallato, che fornisce il provider …

    TL; DR

    Utilizza ContentProviderClient instabile.

    Ecco la spiegazione di un altro autore: https://stackoverflow.com/a/33562256/87383

    LUNGA LETTURA

    Di fronte allo stesso problema e risolto (soluzione alternativa) il modo seguente:

    Prima di tutto dovresti comprendere la differenza tra ContentResolver.registerContentObserver e ContentResolver.query

    Così, ContentResolver.registerContentObserver collega semplicemente l'istanza ContentObserver locale con ContentService . Viene raggiunto creando un "bridge" utilizzando l' istanza di class ContentObserver.Transport (che è fondamentalmente un legante) e passandolo al ContentService . Vedere ContentObserver.getContentObserver ()

    Perché è importnte? Poiché questi osservatori non sono gestiti (registrati) da ActivityManagerService .

    Quindi, cosa è speciale sul metodo ContentResolver.query ? Per rispondere a questa domanda dobbiamo guardare a ContentProviderClient . Poiché le query effettive vengono eseguite tramite le istanze di ContentProviderClient responsabili di contattare ContentProvider remoto.

    E ci sono due "tipi" di ContentProviderClient – stabili e instabili . I clienti instabili vengono gestiti dalla tua applicazione. Ma stabile è gestito da Android per te, quindi quando l'applicazione viene arrestata, ActivityManager sa che è il momento di uccidere tutti i client .

    Consulta questo commit per ulteriori dettagli sui client del provider di contenuti instabili: https://android.googlesource.com/platform/frameworks/base/+/6ae8d1821822296df0606c9cd1c46708cc21cb58

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.