Я наткнулся на проблему с получением сообщений GCM, если мое приложение работает в фоновом режиме (служба). В моем сценарии я не получаю сообщение GCM (обратите внимание, что это не о том, как получить GCM вообще, как here), а ActivityManager убивает приложение. Поэтому я задаюсь вопросом, есть ли у меня концептуальное недоразумение или если это общая проблема.Уведомление GCM push для фонового приложения вызывает сбой
фон
У меня есть Android-приложение, которое работает на переднем плане (активность) и фона (Service). Приложение прилагается к постоянному уведомлению, чтобы убедиться, что приложение продолжает работать, даже если пользователь открывает Android TaskManager и удаляет приложение. Приложение использует WakefulBroadcastReceiver и IntentService для приема и обработки сообщений GCM (оба они зарегистрированы в файле манифеста и установлены все разрешения). Насколько я понимаю, это предлагаемая модель Google для обработки сообщений GCM. Аналогичные решения можно увидеть here или here, но при необходимости я могу добавить примеры кода. Я знаю, что Google изменил поток Android BroadcastReceiver с API 3.1 (например, here). В общем, я могу получать и обрабатывать сообщения GCM, если мое приложение находится на переднем плане или просто в фоновом режиме (пока активность все еще существует).
сценарий ошибки
- Пользователь запускает приложение
- пользователь открывает управление Android задачи
- Пользователя пойло/удаляет приложение из диспетчера задач (извещение: услуга приложения по-прежнему работает в фоном. Все, что делает мое приложение в фоновом режиме, прекрасно работает, и постоянное уведомление о приложении все еще доступно)
- Уведомление GCM push будет отправлено на устройство/приложение.
- My WakefulBroadcastReceiver не получает push-уведомление. Также на некоторых устройствах приложение умирает (постоянное уведомление также будет удалено). На моем тестовом устройстве я заметил следующий log из logcat, в то время как постоянное уведомление остается, но мое приложение, похоже, больше не работает (никаких дополнительных записей в журнале приложения в 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
Имеется некоторая информация о том, что приложение не может обрабатывать сообщения GCM, если приложение было принудительно завершено (например, here или this), но это не мое дело. Мое приложение работает в фоновом режиме, только действие удаляется. При возникновении сценария ошибки нет дополнительных стеков стека приложений, доступных в моем приложении. Я не вижу причины, по которой я не получаю сообщение GCM или даже почему приложение будет убито.
Такая же ошибка возникает, если я зарегистрирую WakefulBroadcastReceiver в службе, прикрепленной к постоянному уведомлению.
Дополнительная информация
Google объявил new way для обработки сообщений GCM и рекомендует пользователям изменять. По некоторым причинам я не могу переключиться на короткий путь к новому. Из-за этого я не подтвердил новый предложенный способ.
РЕДАКТИРОВАТЬ: Дополнительный Лог-Информация при переключении на GcmReceiver
:
08-06 18: 33: 01,670 I/ГКМ (3360): ГКМ сообщение foo.bar.blub 0 : 1438878778919403% 9002042af9fd7ecd 08-06 18: 33: 01.695: I/ActivityManager (815): Killing 4296: foo.bar.blub/u0a216 (adj 0): удалить задачу ... 08-06 18: 33: 01.909 : W/BroadcastQueue (815): Исключение при отправке широковещательной рассылки на 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): at android.os.BinderProxy.transactNative (Родной метод) 08-06 18: 33: 01.909: W/BroadcastQueue (815): at 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): at com.android.server.am.BroadcastQueue.processCurBroadcastLocked (BroadcastQueue.java:245) 08-06 18: 33: 01.909: W/BroadcastQueue (815): at com.android.server.am.BroadcastQueue.processNextBr oadcast (BroadcastQueue.java:898) 08-06 18: 33: 01.909: W/BroadcastQueue (815): at com.android.server.am.BroadcastQueue $ BroadcastHandler.handleMessage (BroadcastQueue.java:149) 08- 06 18: 33: 01.909: W/BroadcastQueue (815): at android.os.Handler.dispatchMessage (Handler.java:102) 08-06 18: 33: 01.909: W/BroadcastQueue (815): at android .os.Looper.loop (Looper.java:135) 08-06 18: 33: 01.909: W/BroadcastQueue (815): at android.os.HandlerThread.run (HandlerThread.java:61) 08-06 18: 33: 01.909: W/BroadcastQueue (815): at com.android.server.ServiceThread.run (ServiceThread.java:46) 08-06 18: 33: 01.909: W/libprocessgroup (815): не удалось открыть /acct/uid_10216/pid_4296/cgroup.procs: Нет такого файла или каталога 08-06 18: 33: 01.910: W/ActivityManager (815): Планирование перезапуска аварийного отказа service foo.bar.blub/.service.BubbleService в 1000 мс 08-06 18: 33: 01.958: W/ActivityManager (815): ложная смерть для ProcessRecord {26174c48 4412: foo.bar.blub/u0a216}, curProc для 4296: null 08-06 18:33: 03.253: W/ctxmgr (28358): [PowerConnectionState] Получил то же значение, что и раньше, для подключения к электросети (Состояние штепселя: 2 BatteryLevel: 0,66) 08-06 18: 33: 08.277: W/ctxmgr (28358): [PowerConnectionState] То же значение, что и раньше, для подключения к электросети (Состояние штекера: 2 BatteryLevel: 0,66)
08-06 18: 33: 01.909: W/libprocessgroup (815): не удалось открыть /acct/uid_10216/pid_4296/cgroup.procs: Нет такого файла или каталога 08-06 18: 33: 01.910: W/ActivityManager (815): перезапуск планирования с разбивкой сервис foo.bar.blub/.service.BubbleService в 1000ms 08-06 18: 33: 01.957: I/art (4412): Late-enable -Xcheck: jni 08-06 18: 33: 01.958: I/ActivityManager (815): Запустить proc 4412: foo.bar.blub/u0a216 для широковещательной передачи foo.bar.blub/com.google.android.gms.gcm.GcmReceiver 08-06 18: 33: 01.958: W/ActivityManager (815): ложная смерть для ProcessRecord {26174c48 4412: foo.bar.blub/u0a216}, curProc для 4296: null 08-06 18:33:01.992: I/art (4412): Отладчик больше не активен 08-06 18: 33: 02.024: I/GcmDataIntentService (4412): Push сообщение для процесс: ............. ....
Неужели кто-то другой столкнулся с проблемой и нашел решение? :-) Или мое понимание не так?
Спасибо!
Да. У меня тоже был такой же крах. Я просто спросил здесь. http://stackoverflow.com/questions/32291478/exception-when-sending-broadcast-to-componentinfo Предполагаю, что многие люди пользуются услугами. Интересно, как их толчок работает ... – user1165560
Я предполагаю, что они используют одно из упомянутых обходных решений. Обратите внимание, что если вы воспользуетесь предлагаемым обходным путем в своем упомянутом сообщении, у вас будет небольшой побочный эффект: если вы откроете свой диспетчер задач и отмахнетесь от своего приложения, диспетчер задач закроется. – mheymel