1

Я наткнулся на проблему с получением сообщений 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, если мое приложение находится на переднем плане или просто в фоновом режиме (пока активность все еще существует).

сценарий ошибки

  1. Пользователь запускает приложение
  2. пользователь открывает управление Android задачи
  3. Пользователя пойло/удаляет приложение из диспетчера задач (извещение: услуга приложения по-прежнему работает в фоном. Все, что делает мое приложение в фоновом режиме, прекрасно работает, и постоянное уведомление о приложении все еще доступно)
  4. Уведомление GCM push будет отправлено на устройство/приложение.
  5. 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 сообщение для процесс: ............. ....

Неужели кто-то другой столкнулся с проблемой и нашел решение? :-) Или мое понимание не так?

Спасибо!

+0

Да. У меня тоже был такой же крах. Я просто спросил здесь. http://stackoverflow.com/questions/32291478/exception-when-sending-broadcast-to-componentinfo Предполагаю, что многие люди пользуются услугами. Интересно, как их толчок работает ... – user1165560

+0

Я предполагаю, что они используют одно из упомянутых обходных решений. Обратите внимание, что если вы воспользуетесь предлагаемым обходным путем в своем упомянутом сообщении, у вас будет небольшой побочный эффект: если вы откроете свой диспетчер задач и отмахнетесь от своего приложения, диспетчер задач закроется. – mheymel

ответ

1

Эта проблема по-прежнему будет возникать с новым предлагаемым способом Google (с использованием GcmReceiver (com.google.android.gms.gcm.GcmReceiver) и GcmListenerService). Общая проблема, похоже, коррелирует с этим bug. Возможно, упомянутые обходные пути полезны кому-то.

+0

Я пробовал обходной путь в первом комментарии. Это работает для меня. Спасибо за Вашу информацию! – user1165560

+0

да, он работает вообще. Обратите внимание на побочный эффект, о котором я упомянул в комментарии выше (закрытие диспетчера задач). Вы нашли обходное решение для этого? – mheymel

+0

Я заметил побочный эффект. Я не нашел обходного пути для этого :-( – user1165560

 Смежные вопросы

  • Нет связанных вопросов^_^