Eu me deparei com um problema ao receber mensagens do GCM se meu aplicativo for executado em segundo plano (Serviço). No meu cenário, não recebo a mensagem do GCM (observe que não se trata de como receber o GCM em geral, comoaqui) e o ActivityManager mata o aplicativo. Então, me pergunto se tenho um mal-entendido conceitual ou se é um problema geral.

fundo

Eu tenho um aplicativo Android que é executado em primeiro plano (Atividade) e em segundo plano (Serviço). O aplicativo é anexado a uma notificação persistente para garantir que o aplicativo continue sendo executado, mesmo que o usuário abra o Android TaskManager e roube o aplicativo. O aplicativo usa um WakefulBroadcastReceiver e um IntentService para receber e processar mensagens do GCM (ambos são registrados no arquivo de manifesto e todas as permissões são definidas). Pelo que entendi, esse era o padrão sugerido pelo Google para processar mensagens do GCM. Soluções semelhantes podem ser vistasaqui ouaqui mas, se necessário, também posso adicionar exemplos de código. Sei que o Google alterou o fluxo do Android BroadcastReceiver com a API 3.1 (por exemplo,aqui) Em geral, sou capaz de receber e processar mensagens do GCM se meu aplicativo estiver em primeiro plano ou simplesmente em segundo plano (enquanto a atividade ainda existir).

Cenário de erro

Usuário inicia o aplicativoUsuário abre o gerenciador de tarefas do AndroidO usuário desliza / remove o aplicativo do gerenciador de tarefas (aviso: o serviço do aplicativo ainda está sendo executado em segundo plano. Tudo o que meu aplicativo faz em segundo plano funciona bem e a notificação persistente do aplicativo ainda está disponível)A notificação por push do GCM será enviada para o dispositivo / aplicativo.Meu WakefulBroadcastReceiver não recebe a notificação por push. Também em alguns dispositivos, o aplicativo morre (a notificação persistente também será removida). No meu dispositivo de teste, notei o seguinte log do logcat enquanto a notificação persistente permanece, mas meu aplicativo parecia não estar mais sendo executado (não há mais entradas de log do aplicativo no logcat):07-20 12:46:36.930: I/GCM(1071): GCM message foo.bar.blub 0:14373891986... 07-20 12:46:36.940: I/ActivityManager(750): Killing 23750:foo.bar.blub/... (adj 0): remove task Há algumas informações disponíveis, que um aplicativo não pode processar mensagens do GCM se o aplicativo foi forçado a sair (por exemplo,aqui ouesta) mas este não é o meu caso. Meu aplicativo é executado em segundo plano, apenas a atividade é removida. Quando o cenário de erro ocorre, nenhum rastreamento de pilha adicional de exceção do meu aplicativo está disponível. Não vejo uma razão pela qual não recebo a mensagem do GCM ou mesmo porque o aplicativo foi morto.

O mesmo erro ocorre se eu registrar o WakefulBroadcastReceiver no serviço anexado à notificação persistente.

Informação adicional

O Google anunciou umanova maneira processar mensagens do GCM e incentivar os usuários a mudar. Por algumas razões, não posso mudar para uma nova maneira. Devido a isso, não verifiquei a nova maneira sugerida.

EDIT: AdicionalInformações de log enquanto muda para oGcmReceiver:

08-06 18: 33: 01.670: I / GCM (3360): mensagem GCM foo.bar.blub 0: 1438878778919403% 9002042af9fd7ecd 08-06 18: 33: 01.695: I / ActivityManager (815): matando 4296: foo.bar .blub / u0a216 (adj 0): remover tarefa ... 08-06 18: 33: 01.909: W / BroadcastQueue (815): Exceção ao enviar transmissão para ComponentInfo {foo.bar.blub / com.google.android.gms .gcm.GcmReceiver} 08-06 18: 33: 01.909: W / BroadcastQueue (815): android.os.DeadObjectException 08-06 18: 33: 01.909: W / BroadcastQueue (815): em android.os.BinderProxy.transactNative (Método nativo) 08-06 18: 33: 01.909: W / BroadcastQueue (815): em android.os.BinderProxy.transact (Binder.java:496) 08-06 18: 33: 01.909: W / BroadcastQueue (815) : at android.app.ApplicationThreadProxy.scheduleReceiver (ApplicationThreadNative.java:861) 08-06 18: 33: 01.909: W / BroadcastQueue (815): em com.android.server.am.BroadcastQueue.processCurBroadcastLocked (BroadcastQueue.java:245) ) 08-06 18: 33: 01.909: W / BroadcastQueue (815): em com.android.server.am.BroadcastQueue.processNextBroadcast (BroadcastQueue.java: 898) 08-06 18: 33: 01.909: W / BroadcastQueue (815): em com.android.server.am.BroadcastQueue $ BroadcastHandler.handleMessage (BroadcastQueue.java:149) 08-06 18: 33: 01.909: W / BroadcastQueue (815): em android.os.Handler.dispatchMessage (Handler.java:102) 08-06 18: 33: 01.909: W / BroadcastQueue (815): em android.os.Looper.loop (Looper.java:135 ) 08-06 18: 33: 01.909: W / BroadcastQueue (815): no android.os.HandlerThread.run (HandlerThread.java:61) 08-06 18: 33: 01.909: W / BroadcastQueue (815): no com .android.server.ServiceThread.run (ServiceThread.java:46) 08-06 18: 33: 01.909: W / libprocessgroup (815): falha ao abrir /acct/uid_10216/pid_4296/cgroup.procs: nenhum arquivo ou diretório 08-06 18: 33: 01.910: W / ActivityManager (815): agendando a reinicialização do serviço com falha foo.bar.blub / .service.BubbleService em 1000ms 08-06 18: 33: 01.958: W / ActivityManager (815): Spurious morte para ProcessRecord {26174c48 4412: foo.bar.blub / u0a216}, curProc para 4296: null 08-06 18: 33: 03.253: W / ctxmgr (28358): [PowerConnectionState] Obteve o mesmo valor que seja para conexão de energia (estado do plugue: 2 BatteryLevel: 0,66) 08-06 18: 33: 08.277: W / ctxmgr (28358): [PowerConnectionState] Obteve o mesmo valor de antes da conexão de energia (estado do plugue: 2 BatteryLevel: 0,66)

08-06 18: 33: 01.909: W / libprocessgroup (815): falha ao abrir /acct/uid_10216/pid_4296/cgroup.procs: esse arquivo ou diretório não existe 08-06 18: 33: 01.910: W / ActivityManager (815) : Planejando a reinicialização do serviço com falha foo.bar.blub / .service.BubbleService em 1000ms 08-06 18: 33: 01.957: I / art (4412): Ativação tardia -Xcheck: jni 08-06 18: 33: 01.958: I / ActivityManager (815): inicie o proc 4412: foo.bar.blub / u0a216 para transmissão foo.bar.blub / com.google.android.gms.gcm.GcmReceiver 08-06 18: 33: 01.958: W / ActivityManager ( 815): Morte espúria para ProcessRecord {26174c48 4412: foo.bar.blub / u0a216}, curProc para 4296: null 08-06 18: 33: 01.992: I / art (4412): o depurador não está mais ativo 08-06 18 : 33: 02.024: I / GcmDataIntentService (4412): Enviar mensagem para processar: .................

Alguém encontrou o problema e encontrou uma solução? :-) Ou meu entendimento está errado?

Obrigado!