Остановка Activity Recognition PendingIntent была вызвана посреди ночи

мое приложение периодически собирает данные об обнаруженной активности Activity Recognition. Я реализовал его точно так, как описано в документации , но с интервалом в одну минуту .

пока пользователь вошел в систему - приложение зарегистрировано с помощью PendingIntent для получения обновлений из процесса google play..

пожалуйста, не читайте мне лекции об использовании батареи, сети и проблемах с производительностью, возникающих из-за ежеминутных обновлений запросов, если только это не имеет никакого отношения к моей проблеме:

проблема: на некоторых устройствах (в Nexus 5 такое бывает чаще всего) часов в 5-6 среди ночи - IntentService перестал звонить.

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

моему приложению важно знать, какова текущая активность каждую минуту, даже если она остается неизменной или бездействует в течение длительного времени.

мой вопрос:

  • как я могу узнать, вызвано ли прекращение периодического распознавания активности из-за значительного датчика движения или по какой-либо другой причине?
  • есть ли способ каким-то образом заставить процесс Google play выполнять обновления активности, не останавливая его на время, которое он считает не нужным?

comment
Здравствуйте, у вас есть какое-либо лучшее решение для того же, что и мое приложение, которое также должно хранить данные о каждой активности в нашем бэкэнде. можете ли вы помочь мне с лучшим решением   -  person Vishal Thakkar    schedule 15.03.2019


Ответы (1)


Согласно ActivityRecognitionClient.requestActivityUpdates:

В целях экономии заряда батареи отчеты об активности могут прекращаться, если устройство находится в состоянии «НЕПОДВИЖНО» в течение длительного периода времени. Он возобновится, как только устройство снова переместится. Это происходит только на устройствах, поддерживающих оборудование Sensor.TYPE_SIGNIFICANT_MOTION.

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

Если вы напрямую инициируете действия, основанные на вызове IntentService (плохая идея, поскольку другие приложения могут вызвать его очень быстрое срабатывание), а не только на изменениях в активности, вам следует отделить эти действия и вместо этого установить будильник или активировать адаптер периодической синхронизации для любого необходимого вам интервала времени, считывая текущее значение из последней полученной вами активности.

person ianhanniballake    schedule 12.06.2014
comment
Спасибо за быстрый ответ. в обновлении распознавания активности IntentService все, что я делаю, это сохраняю DetectedActivity в базе данных SQLite. Я не понял, что вы говорите о развязке. отделить что к чему? - person Tal Kanel; 12.06.2014
comment
Итак, если вы уже сохраняете активность, вы всегда знаете последнюю активность (активность с самой высокой отметкой времени), так в чем проблема? Для разделения я имел в виду, запускали ли вы сетевые запросы или что-то более тяжелое. - person ianhanniballake; 12.06.2014
comment
Мне нужно постоянно записывать поминутные данные. запись = хранить в базе данных и время от времени синхронизировать с моим сервером. поэтому, если он остановился на 4-5 часов, это не подходит для моих нужд... - person Tal Kanel; 12.06.2014
comment
Верно, но вам уже не гарантированы поминутные данные — если другое приложение запрашивает обновления каждую секунду, то вам также будут перезванивать с той же скоростью, а не только раз в минуту. - person ianhanniballake; 12.06.2014
comment
Если вам нужно строго хранить данные каждую минуту, делайте это, даже если вы ничего не получаете от службы активности Google. Вам просто нужно сохранить последнее значение, полученное от Google, и отправлять его снова и снова. Однако вы получите много избыточных данных. - person Jose L Ugia; 22.06.2014