GCM/FCM: non ricezione di eventi, callback di intenzione broadcast: risultato = ANNULLATO

Question

Ci sono discussioni su questo errore, ma sembra che tutti finiscano con le risposte sullo "stato di stop" (delle app).

Sto vedendo qualcosa di diverso.

Ho due campioni push cloud, uno è l'esempio GCM ufficiale e l'altro è un progetto FCM che ha seguito il tutorial e sono entrambi interessati.

Entrambi sono installati su un Samsung S6 con 6.0.1, il dispositivo è collegato (senza Doze) e connesso a WiFi.

Di volta in volta, l'invio di messaggi push a uno il campione GCM o per l'applicazione FCM inizia a fallire con questi nella logcat:

07-17 14: 37: 38,851 W/GCM-DMM (29459): callback intento broadcast: risultato = CANCELED forIntent {act = com.google.android.c2dm.intent.RECEIVE flg = 0x10000000 pkg = gcm.play.android.samples.com.gcmquickstart (ha extra)}

07-17 14: 38: 25.231 W/GCM-DMM (29459): callback di intenzione broadcast: risultato = CANCELED forIntent {act = com.google.android.c2dm.intent.RECEIVE flg = 0x10000000 pkg = firebasetest.example.kman .firebasetest (ha extra)}

L'avvio dell'interfaccia utente di ciascuna app farà passare nuovamente i messaggi push (a quell'app), ma i vecchi (che hanno prodotto gli errori) non verranno restituiti.

Ora, non ho forzato l'arresto di nessuna delle app. Uno di questi l'ho usato solo 15 minuti fa. Il dispositivo non è andato in stop (lo schermo era acceso ed è stato collegato tutto il tempo).

Quindi la spiegazione "forza interrotta" non si applica qui, la modalità Doze non si applica qui.

Inoltre, parlando di "force stopped", ho eseguito diversi test, eseguendo quindi deliberatamente chiudendo l'app (GCM o FCM) dalla "lista delle app recenti", verificando che il processo fosse stato ucciso (tramite il logcat) e quindi (GCM o FCM) i messaggi push sarebbero passati bene.

Quindi deve essere qualcos'altro (non "forza arrestata" o modalità Doze) e questo qualcos'altro sta causando l'inaffidabilità dei messaggi push, che vanifica lo scopo.

Qualche idea su come rintracciare questo in basso, per prevenire/evitare questa improvvisa rottura della consegna di messaggi push?

manifesta del campione GCM:

https://github.com/googlesamples/google-services/blob/master/android/gcm/app/src/main/AndroidManifest.xml

manifesta del test di FCM:

`` `xml

<application 
    android:allowBackup="true" 
    android:icon="@mipmap/ic_launcher" 
    android:label="@string/app_name" 
    android:supportsRtl="true" 
    android:theme="@style/AppTheme"> 
    <activity android:name=".MainActivity"> 
     <intent-filter> 
      <action android:name="android.intent.action.MAIN" /> 

      <category android:name="android.intent.category.LAUNCHER" /> 
     </intent-filter> 
    </activity> 

    <service android:name=".MyFirebaseMessagingService"> 
     <intent-filter> 
      <action android:name="com.google.firebase.MESSAGING_EVENT" /> 
     </intent-filter> 
    </service> 


    <service android:name=".MyFirebaseInstanceIDService"> 
     <intent-filter> 
      <action android:name="com.google.firebase.INSTANCE_ID_EVENT" /> 
     </intent-filter> 
    </service> 
</application> 

` ``

Answer 1

La mia conclusione è :

Questo è causato da Android Studio.

Quando hai finito di lavorare su un progetto per la giornata e esci da AS, ti chiede se l'app (in fase di debug) debba essere chiusa.

Indipendentemente da ciò che si seleziona qui, AS interromperà sempre l'app e la metterà in uno stato "fermato" - non solo GCM, anche gli allarmi smetteranno di sparare.

Vedo che accada tutto il tempo, e ho preso l'abitudine di riavviare l'app me stesso e fare qualcosa lì così non dice "fermato" e non mi sorprende ("cosa è successo") il giorno dopo .

Pensavo di aver presentato un bug per questo, ma non riesco a trovarlo ora. Se qualcuno è interessato, sentitevi liberi ...