Можно ли сохранить приложение Tizen живым без остановки

Question

Недавно я начал разрабатывать для Tizen OS. Мое приложение создано только для носимых и только для конкретного устройства, которое является Samsung Gear Sport (Tizen 3.0 на борту). Основная цель этого приложения состоит в сборе полных данных датчика в течение длительного периода времени. Меня интересуют частота сердечных сокращений и датчики движения в целом (гироскоп и акселерометр). Затем эти данные будут отправлены на облачный сервер и проанализированы. В настоящее время я рассматриваю WEB-приложение, потому что до сих пор я не нашел доказательств того, что в WEB API отсутствует то, что существует в нативном API.

Но есть одно ограничение в Tizen OS, которое я пока не могу преодолеть. Мое приложение усыпляется через некоторое время (около 10 минут). Крайне важно, чтобы это приложение работало в фоновом режиме в течение длительного времени (до 10 часов). Чтобы достичь этого, я попробовал следующие подходы:

• Обычное приложение Tizen с background-category: данные, предоставленные этим подходом, все еще слишком фрагментированы, например, я получил 15-минутные дыры, где вообще не было никаких данных. Иногда были дыры даже дольше 30 минут.
• API Tizen Alarms: аварийные сигналы выполняли свою работу в случае сохранения приложения в рабочем состоянии, но с каждым аварийным сигналом приложение выводилось на передний план, и это неприемлемое решение. Существует возможность автоматического отключения приложения (с помощью управления приложением), но оно не имеет обратного вызова, поэтому все тревоги должны быть запланированы заранее.
• Флаг CPU_AWAKE заставлял систему показывать всплывающее окно "это приложение использует слишком много энергии", и, если не ответить в течение 10 минут или около того, система все равно убьет мое приложение.
• Веб-работники - это только ради аргумента, веб-работники усыпляют вместе с приложением
• Запись данных: я надеялся на что-то похожее на Apple Health Kit, но вместо этого я получил что-то, что совсем не работает для HRM. Как-то это работает для PRESSURE Датчик. Tizen позволяет начать запись для HRM но ничего не записывается после - NotFoundError: Failed to read recorded data, Любой другой датчик дает TypeMismatchError,
• Приложение веб-службы - для этого требуется сертификация на уровне партнера в компании Samsung, также на него влияют фоновые ограничения, как упоминается в документации.
• Наблюдайте за приближением лица с установленным в настройках устройства флагом "держать всегда включенным". Это решение было лучшим, которое я пробовал. Приложение Watch Face просыпается каждую минуту, чтобы изменить время, а также получает данные датчика. К сожалению, после дополнительных испытаний выяснилось, что в записанных данных было несколько дыр.

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

А теперь вопрос: возможно ли сохранить приложение в течение 10+ часов без остановки?

Answer 1

Если вы нацелены на нативный API-интерфейс Service Service 3.0, получите следующее:

device_power_request_lock(POWER_LOCK_CPU, 0);
sensor_listener_set_option(listener,  SENSOR_OPTION_ALWAYS_ON);
sensor_listener_set_attribute_int(listener, SENSOR_ATTRIBUTE_PAUSE_POLICY, SENSOR_PAUSE_NONE);

И не забудьте установить категорию фона (датчик + местоположение, если необходимо) в манифесте, потому что в противном случае Tizen убьет ваше приложение через ~ 10 минут.

Конечно, вряд ли все это должным образом задокументировано...

Answer 2

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

• WEB-приложение, написанное на JS, которое было приложением для циферблата
• Собственное приложение службы (без пользовательского интерфейса), написанное на C

Все приложения были ориентированы на Tizen API 2.3.1. Это важная часть, потому что было много проблем с 3.0 API, таких как неожиданные убийства приложений операционной системой или "чрезмерное использование батареи", которые иногда также приводили к уничтожению моего приложения. Забавная вещь в Tizen OS состоит в том, что, когда оно убивает приложение с циферблатом из-за чрезмерного использования ресурсов, главный экран часов просто черный. К сожалению, ориентация на API 2.3.1 привела к невозможности использования нескольких API, добавленных после этой версии.

Следующая вещь, которую я использовал, была device_power_request_lock(POWER_LOCK_CPU, 0); во всех родных сервисных приложениях. Я считаю, что использование более старого API (2.3.1 вместо 3.0) позволило приложению работать намного дольше, не будучи уничтоженным системой. Я думаю, что это недостаток в этой версии ОС Tizen, которую я использовал.

В веб-приложении, которое я использовал ScreenStateChangeListener и события timetick, чтобы проверить, запущено ли приложение-служба. Если нет -> это было запущено WEB-приложением. Для связи между сервисом и циферблатом я использовал API слушателя предпочтений. Наблюдение за лицом Веб-приложение отвечало за проверку того, какая служба работает, и какую службу необходимо активировать или запустить.

В итоге я использовал 4 собственных сервисных приложения, упакованных вместе с веб-приложением. Каждое служебное приложение имело свою цель, такую ​​как файловая система, сеть, мониторинг и т. Д. Многопоточные служебные приложения было очень сложно поддерживать, и они часто зависали по неизвестной причине.