Клиент для libnotify под Android

XMPP сервер на десктопе, XMPP клиент на смартфоне. Задача сводится к отправке уведомлений по XMPP. По крайней мере под Андроид ничего писать не надо.

XMPP сервер на десктопе, XMPP клиент на смартфоне

Мне тоже это кажется рабочим вариантом. Но код писать всё равно надо будет, чтобы реализовать кастомные уведомления, например, «долгая вибрация», «короткая вибрация», «мигание LEDом», «текст» и произвольная комбинация этих штук...

Ну, тогда во избежание велосипедизма стоит глянуть вот этот проект: http://projectmaxs.org/homepage/

Кастомные уведомления можно реализовать модулем к нему, без необходимости изобретать транспорт, аутентификацию и т.д.

Нет, это немного оверхед - допустим дома я сижу за одним компьютером, на работе - за другим, мне на обоих поднимать jabber-сервера? Или держать сервер на vps для отправки 10 уведомлений в сутки? Вариант поднять сервер на андроиде, конечно, возможен, но так же не кажется мне очень выгодным.

А, да, pushbullet и аналоги не рассматриваю по причине того что все это должно работать в локальной сети, без выхода в интернеты.

Тогда придется писать свой сервис на яве, который будет работать в фоне и жрать батарею, потому как экономный push работать не будет.

А пуши нельзя слать внутри локальной сети?

Нет, это Google API, только с их серверов

Не понимаю я ваших проблем. Сделайте простенькое приложение, которое будет по HTTP опрашивать сервер каждые 5 минут.

Не ставьте на него wake-lock, и тогда оно не будет жрать батарейку. Телефон всё равно периодически просыпается чтобы принять пуши с серверов, проверить почту и отправить в телеметрию - приложение просто вклинится в этот участок.

Вообще, столько слов было сказано про мифическое выжирание батарейки, и как оно сразу одолевает незадачливых новичков. Я за 5 лет программирования под Андроид ни разу не видел ничего подобного - а приложения-поллеры у меня имеются.

Раз в пять минут будет очень редко. Грубо говоря я хочу получать нотификации из IM (не будем о том что я могу им пользоваться на мобильном девайсе). очевидно что чем раньше я получу информацию о событии, тем лучше. Мои опасения - если я поставлю очень маленький промежуток между оповещениями (скажем, 10 секунд), то девайс просто не будет засыпать. А ставить минуту и больше я тоже не могу по понятным соображениям.

Вообще, столько слов было сказано про мифическое выжирание батарейки, и как оно сразу одолевает незадачливых новичков. Я за 5 лет программирования под Андроид ни разу не видел ничего подобного - а приложения-поллеры у меня имеются.

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

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

Разумные опасения. А что если увеличивать интервал? Скажем, если за 10 секунд ничего не пришло, в следующий раз опрашивать через 12 или 15? Ну и так далее, по нарастающей.

Засыпание телефона вообще тёмная лошадка, и я тоже не уверен, уснёт он или нет. Но по спеке в отсутствие wake-lock приложений он должен засыпать после выключения экрана - безотносительно того, есть ли работающие сервисы или нет.

девайс просто не будет засыпать

Но ведь те самые «энергосберегающие» пуш-нотификации - это то же самое TCP-соединение, только к OS-вендору, и одно на все приложения вместе, разве не так? Если так, и если для вас важнее всего оперативность получение оповещений по одному (или _ещё_ одному) каналу связи, то не вижу принципиальной разницы, используется ли пуш, или обыкновенное TCP-соединение уровня приложения, и от влезания в более глубокие дебри ничего принципиально не меняется.

Да, увеличение интервала проверок планируется (двух типов - в случае отсутствия сообщений и в случае недоступности хоста, который должен слать оповещения; во втором случае предельный интервал будет больше). Ну и что-то для сброса на минимальный интервал тоже.

Не знаю, может если соединение не разрывается и есть возможность как-то «замониторить» события то это позволяет девайсу «уснуть глубже» чем в случае абстрактных «GET-запросов раз в 5 секунд».

Я не такие соединения имел в виду, а постоянные. Как у XMPP или SIP-клиентов (имеется в виду via TCP или via TLS). Такие соединения будут большую часть времени висеть в системном вызове типа select()/poll(). Я думаю, это достаточно экономно. И я думаю, примерно так же (с доп. фичей, аналогичной XMPP stream resumption) вендорские пуши и реализуются.

KDE Connect