Push уведомления в Android. Грабли, костыли и велосипеды

[zo_oz]

Результаты были в районе 20-25% расхода заряда за 8-9 часов.

Это не нормально. Как вообще можно принять после таких тестов такое решение? 3%/час при спящем телефоне? Конечно, все зависит от объема аккумулятора, но это же просто издевательство над людьми…

[gang018]

Данные я привел с учетом работы других приложений. Постараюсь собрать более детальную статистику конкретно по нашему приложению

[kekekeks]

Издевательство над людьми — выпускать устройства с не работающими нормально Push-уведомлениями.

[jvIlya]

Есть такой экран Settings->Battery->History details
Интересно глянуть его с вашим приложением и без него. Особенно строчку с awake.

Я думаю, если приложение все ночь будит устройство каждые 5 минут (проснуться+слазить в интернет), то батарейка должна заметно садится.

[gang018]

Нашел этот пункт. Сегодня обязательно попробую провести тест и отписаться по результатам

[forceLain]

Необходимо в пределах 30-60 секунд оповестить пользователя о некотором действии

В конечном счете было принято решение о том, чтобы держать свое соединение с сервером в связке с GCM.

Надо было сразу с этого начинать. И убрать GCM.

Нам это уведомление не нужно, поэтому мы воспользовались следующим велосипедом… запустить одновременно с первым сервисом второй… затем убить второй сервис.

Жесть конечно. А потом все плюются от качества ПО в маркете…

[bejibx]

Согласен, жесть, но во многих ситуациях иначе никак. Знаете ли вы, например, что поддержка карт памяти появилась в Android SDK только в API 4.4 (KitKat)? Все приложения, поддерживающие более ранние версии операционки используют хаки и костыли чтобы понять по какому пути смонтирована карта памяти, ведь каждый вендор монтирует куда ему вздумается. Как у разработчика, у тебя есть выбор: либо писать хаки и костыли и потом страдать от последствий ради того, чтобы предоставить пользователю функционал, который он хочет, либо мягко послать его в пеший эротический тур, сославшись на «извините, злой Google не даёт нам так делать». Во втором случае, вам, мягко говоря, не поверят, ведь всегда найдётся кто-то, кто не постесняется накидать хаков и костылей ради функционала и тогда пользователи справедливо возразят — «Но у Васьки то работает». И после этого попробуйте втолковать людям что так делать нехорошо. Sad but true.

[forceLain]

Для того, что бы периодически опрашивать сервер не нужно городить будильники из AlarmManager. Нужен SyncAdapter. Но в вашем случае, как мне кажется, вместо постоянного периодического опроса сервера лучше подойдет сервис и long polling в нём.

[BupycNet]

Кстати. Интересно можно ли сделать соединение с сокетом, чтобы телефон спал (мало потреблял) но и мог принять через сокет данные?

[bejibx]

Только вместе с WakeLock'ом, а это автоматически означает работающий на-полную процессор. Более того, на некоторых устройствах нужно (кто бы сомневался) использовать грязнейший хак, описанный тут — Reception of UDP packets in sleep mode.

[Xcam]

И именно там нашли ответ на вопрос — начиная с 19 API lvl (Kitkat) абсолютно все «будильники» в системе стали разовыми. Вывод — всегда читайте документацию.

в документации нашел только такие строки

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whose {@code targetSdkVersion} is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.

Т.е. повторяющиеся будильники есть, но они не гарантируют вам точного времени срабатывания до секунды. Это связано с экономией батареи — погрешность дает системе возможность отправить Intent в тот момент, когда телефон активен и не потребуется его специально для вашего приложения будить. Возможно я что-то не нашел?

[Alexey_Bespaly]

начиная с 19 API lvl (Kitkat) абсолютно все «будильники» в системе стали разовыми.

Да где же такое написано?

Документация:

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whose targetSdkVersion is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.

Да они не точные, но и батарейку не сажают. Вам наверное не подойдут. Но вводить в заблуждение тоже не стоит.

[h0tkey]

Я, вероятно, что-то упустил, но для достижения latency уведомлений в 30-60 секунд вам пришлось и «будильник» с таким же периодом запускать? Если да, то подозреваю, что устройства в сон уходить почти не будут, потому что это, ЕМНИП, не мгновенный процесс, сон многоуровневый и наступает постепенно.

[BupycNet]

Странно, что автор сразу такое не нагуглил.
stackoverflow.com/questions/13534732/how-to-make-the-android-device-hold-a-tcp-connection-to-internet-without-wake-lo
Судя по всему можно таки сделать постоянное TCP соединение и усыпить девайс. Причём потом разбудить его приходом пакета.

[Bo_bda]

а вы уверены, что у вас система не вырубит инет сама тем более с введением новых систем сна в 6.0? хотя если мне не изменяет память, то она вообще сейчас может убить все если не ставить специальные флаги.

Если не прав, поправьте.

[BupycNet]

Я тут не сильно специалист. Сам не знал, что такое может вообще работать. Но технически — если у нас например есть процесс и он не убит, и есть например 3G-4G сеть, или Wifi в режиме «не выключать в режиме сна» то вполне все должно работать.
Ну в крайнем случае — можно эти флаги и использовать.

[bejibx]

Для меня данная информация выглядит сомнительно. Не указаны ни версии Android ни конкретные модели устройств на которых это заработало. В противовес могу привести несколько ссылок на stackoverflow, где утверждается обратное:

1. Android and SO_KEEPALIVE — will a sleeping device still send keepalive segments?
2. Android: Listen to packet data when Android in sleep mode
3. ServerSocket in android not accepting while on SLEEP MODE [screen off]
4. Android socket gets killed imidiatelly after screen goes blank
5. Android, keeping socket/wireless connection while screen off

Скорее всего, как обычно, поведение очень сильно зависит от конкретного устройства и версии ОС. Для меня невозможность получить данные от сокета в режиме сна без WakeLock'а выглядит абсолютно логично — процессор в режиме сна просто прекращает обработку процесса вашего приложения, а без доступного процессорного времени как понять что на сокет что-то прилетело?

[BupycNet]

Мне что то подсказывает, что проблема может решиться api для приложений связанное с администратором устройства.
Вообще тот же gcm ведь по сути вроде как держит соединение и в wakelock может принимать пуши. Что мешает сделать тоже самое?
Вообще проблема для меня едкая — сам хочу в PushAll сделать резервный сервис. У нас уже есть веб сокет как резерв помогает тем, кто с компа заходит с закрытыми портами (сокет проксируется через nginx на обычном порту)
Вполне можно опционально подключать, если GCM отвалился.

[bejibx]

Вообще тот же gcm ведь по сути вроде как держит соединение и в wakelock может принимать пуши. Что мешает сделать тоже самое?

Не путайте сторонние приложения, системные приложения и системные компоненты, для всех разные условия. GSM — это системный компонент, он вполне может работать в обход ограничений API, потому что сам является его частью.

Мне что то подсказывает, что проблема может решиться api для приложений связанное с администратором устройства.

Не факт. В любом случае тут всё упирается в необходимость запросить у пользователя разрешение на администрирование устройства для вашего приложения. С большой долей вероятности пользователь просто удалит приложение за такую наглость.

[BupycNet]

Зависит от направленности. Например если описать пользователю например статистику, что с его телефоном неполадки и многие оповещения не доходят — то он вполне сможет сделать выбор — включить эту функцию или остаться как есть.

[bejibx]

Проблема «Администратора устройства» в том, что этот режим даёт приложению кучу полномочий сразу, без возможности выборочной отмены. Получается вы выводите пользователю эту статистику и просите его разрешить админку. Он думает — «Почему бы и нет?», открывается системное окно и там написано, что приложение получит возможность «удалять данные устройства», «запрещать использование камеры»,… «увести жену», «забрать кота» и вот на этом шаге у многих может возникнуть недоверие. Я бы точно не стал давать приложению такие полномочия только ради уведомлений, разве что это приложение написано мной лично.