Подтвердить что ты не робот

Лучшая архитектура для долгого обслуживания на Android

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

Бизнес-сценарий:

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

Пользовательский интерфейс приложения позволяет пользователю запускать/останавливать запись трека и просматривать дорожку в реальном времени на карте.

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

Вопрос:

После переменного времени, которое длится от 40 минут до полутора часов, служба записи убивается без предупреждения. Поскольку выходы BTT могут занять несколько часов, это приводит к неполному отслеживанию дорожек.

Дополнительная информация:

Служба запускается с START_STICKY и получает PARTIAL_WAKE_LOCK и работает в том же процессе, что и основной.

Новые местоположения приобретаются (и записываются) с заданной пользователем скоростью от 1 секунды до нескольких минут. Я знаю из документации по Android, что это ожидаемое поведение ОС для длительных служб.

Вопрос:

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

void fg() {
    Notification notification = new Notification(R.drawable.logstatus, 
                    "Logging On", System.currentTimeMillis());
    Intent notificationIntent = new Intent(this, LoggerActivity.class);
    PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, 
                    notificationIntent, 0);
    notification.setLatestEventInfo(this, "Logger","Logger Running",
                pendingIntent);
    startForeground(1, notification);   
}

а затем выйти из режима переднего плана при завершении ведения журнала:

stopForeground(true);