Jobservice android после закрытия приложения
Я запускаю сервис из своей основной активности Android следующим образом:
Когда я закрываю страницу активности, вытаскивая ее из списка последних приложений, служба перестает работать и перезапускается через некоторое время. Я не могу использовать постоянные службы с уведомлениями из-за требований к моему приложению. Как я могу заставить службу НЕ перезапускать или выключать и просто продолжать работу при выходе из приложения?
@kiran Проблема, с которой я сталкиваюсь, заключается в том, что служба перезапускается после закрытия действия. Я ищу способ, чтобы служба работала постоянно (без перезапуска после завершения активности). Я чувствую, что мы не можем этого достичь. На низких ресурсах ваш сервис будет убит. Лучшее, на что мы могли надеяться - это перезагрузка. А на 4.4+, swipe kill даже не перезапустит сервис. Пожалуйста, прочитайте эту ветку Подумайте, действительно ли вам нужен сервис, работающий буквально все время: это плохо сказывается на энергопотреблении и потреблении памяти.Наконец, после всех исследований, которые я сделал, я понял, что лучший выбор для долгого обслуживания - startForeground() , потому что он сделанные для этого, и система действительно эффективно работает с вашим сервисом.
@Bam Бэм, у меня есть именно эта проблема. Тем не менее, мой сервис - это приоритетный сервис, и он все еще убивается, когда моя деятельность закрывается. Я изменил свой аргумент инициализации намерения из контекста getApplicationContext () на getBaseContext (), и это решило проблему. я могу использовать getBaseContext () в pendingIntent? вместо использования notificationManager.notify(intent.getIntExtra("notification_Id", 0), builder.build()); я должен использовать startForeground(intent.getIntExtra("notification_Id, 0), builder.build()); Я использую NotificationCompat.Builderсделайте так, чтобы вы обменивались данными в своем "Мастере"
то ваша служба будет запущена в другом процессе с именем ServiceProcess
если вы хотите, чтобы ваша служба никогда не умирала:
onStartCommand() вернуться START_STICKY
создать службу Deamon
startForeground(), есть способ запуститьForeground без уведомления, google it
Скорее всего, начинать в onDestroy будет считаться борьбой с системой Android, что является плохой практикой. На самом деле служба перестает работать, когда я закрываю или закрываю приложение (а затем служба перезапускается). Я не хочу, чтобы служба приостанавливалась / останавливалась при выходе из приложения / закрытии приложения; Я хочу, чтобы это продолжалось. Я считаю, что решение связано с запуском службы в отдельном процессе, но я не совсем уверен.Службы иногда довольно сложны.
Когда вы запускаете службу из какого-либо действия (или вашего процесса), служба, по сути, работает в одном процессе.
цитата из примечаний разработчика
Большая путаница в отношении класса Service фактически вращается вокруг того, что это не так:
Служба не является отдельным процессом. Сам объект службы не подразумевает, что он работает в своем собственном процессе; если не указано иное, он работает в том же процессе, что и приложение, в котором оно входит.
Служба не является нитью. Это не значит, что нужно выполнять работу основного потока (чтобы избежать ошибок, связанных с ошибками приложения).
Итак, что это означает, если пользователь удалит приложение из последних задач, он удалит ваш процесс (включая все ваши действия и т.д.). Теперь давайте рассмотрим три сценария.
Сначала, где служба не имеет уведомления переднего плана.
В этом случае ваш процесс будет убит вместе с вашим сервисом.
Второй, где служба имеет уведомление переднего плана
В этом случае служба не будет убита, и ни один из них не будет выполняться
Третий сценарий Если служба не имеет уведомления переднего плана, она все равно может работать, если приложение закрыто. Мы можем сделать это, запустив службу в другом процессе. (Тем не менее, я слышал, что некоторые люди говорят, что это может не сработать, вам нужно попробовать сами)
вы можете создать службу в отдельном процессе, включив атрибут ниже в вашем манифесте.
Android: процесс = ": yourService"
android: process = "yourService" имя процесса должно начинаться с нижнего регистра.
цитата из примечаний разработчика
Если имя, присвоенное этому атрибуту, начинается с двоеточия (':'), новый процесс, частный для приложения, создается, когда это необходимо, и служба запускается в этом процессе. Если имя процесса начинается с символа с нижним регистром, служба будет выполняться в глобальном процессе этого имени при условии, что у него есть разрешение на это. Это позволяет компонентам в разных приложениях совместно использовать процесс, уменьшая использование ресурсов.
вот что я собрал, если кто-то эксперт, пожалуйста, исправьте меня, если я ошибаюсь:)
Я запускаю службу из своего основного Android-действия следующим образом:
Когда я закрываю страницу активности, вытаскивая ее из списка недавних приложений, служба перестает работать и перезапускается через некоторое время. Я не могу использовать постоянные службы с уведомлениями из-за требований моего приложения. Как я могу сделать так, чтобы служба НЕ перезапускалась или не завершалась, а просто продолжала работать при выходе из приложения?
Наконец, после всех исследований, которые я провел, я пришел к выводу, что лучший выбор для долго работающей службы - это startForeground() , потому что он создан для этого, и система действительно хорошо справляется с вашими услугами.
Просто переопределите метод onDestroy в своем первом видимом действии, например, после заставки у вас есть домашняя страница, а при перенаправлении с заставки на домашнюю страницу вы уже закончили заставку. так что поставьте уничтожить на главной странице. и остановите обслуживание этим методом.
Будет проще запустить службу намерений. Услуга по созданию потока в приложении, но он все еще находится в приложении.
Объявите это в своем манифесте. Дайте собственное имя вашему процессу и сделайте этот процесс изолированным и экспортированным.
Почему SyncAdapter? Ответ: Потому что раньше вы запускали службу, используя контекст вашего приложения. поэтому всякий раз, когда процесс вашего приложения будет убит (когда вы удалите его из диспетчера задач или ОС, убейте его из-за нехватки ресурсов), в это время ваша служба также будет удалена. SyncAdapter не будет работать в потоке приложения . поэтому, если вы вызовете внутри него . служба больше не будет удалена . если вы не напишите код для ее удаления.
Почему бы не использовать IntentService?
IntentService открывает новый поток отдельно от основного потока и работает там, поэтому закрытие приложения не повлияет на него.
Вы должны добавить этот код в свой класс Service, чтобы он обрабатывал случай, когда ваш процесс убивается.
Использование одного и того же процесса для службы и действия и START_STICKY или START_REDELIVER_INTENT в службе - это единственный способ перезапустить службу при перезапуске приложения, что происходит, например, когда пользователь закрывает приложение, но также и тогда, когда система решает закрыть в целях оптимизации. Вы НЕ МОЖЕТЕ иметь услугу, которая будет работать постоянно и без перебоев. Это сделано намеренно, смартфоны не предназначены для выполнения непрерывных процессов в течение длительного периода времени. Это связано с тем, что время автономной работы является наивысшим приоритетом. Вам необходимо спроектировать свою службу таким образом, чтобы ее можно было остановить в любой момент.
Попробуйте это, он будет поддерживать работу службы в фоновом режиме.
BackServices.class
В MainActivity onCreate опустите эту строку кода
Теперь служба будет работать в фоновом режиме.
Основная проблема заключается в том, что невозможно запустить службу при закрытии приложения, ОС Android ( в некоторых ОС ) отключит службу для оптимизации ресурсов. Если вы не можете перезапустить службу, вызовите диспетчер сигналов тревоги. Чтобы запустить приемник таким образом, вот весь код, этот код будет поддерживать вашу службу.
IN Main Activity запускает диспетчер аварийных сигналов таким образом,
Это вызовет получателя, а получатель,
И этот будильник принимает вызовы один раз, когда приложение Android открывается и когда приложение закрывается.
Услуги иногда бывают довольно сложными.
Когда вы запускаете службу из действия (или вашего процесса), служба, по сути, находится в том же процессе.
Цитата из заметок разработчика
Большая часть путаницы в отношении класса Service на самом деле вращается вокруг того, чем он не является:
Сервис - это не отдельный процесс. Сам по себе объект Service не означает, что он работает в собственном процессе; если не указано иное, он выполняется в том же процессе, что и приложение, частью которого оно является.
Сервис это не нить. Это не средство само по себе выполнять работу из основного потока (во избежание ошибок Application Not Responding).
Итак, это означает, что если пользователь убирает приложение от недавних задач, он удаляет ваш процесс (включая все ваши действия и т. Д.). Теперь давайте рассмотрим три сценария.
Это может вам помочь. Я могу ошибаться, но мне кажется, что это связано с возвратом START_STICKY в вашем методе onStartCommand() . Вы можете избежать повторного вызова службы, вернув вместо нее START_NOT_STICKY .
Сделать так, чтобы вы служили вот так в вашем Mainifest
Тогда ваша служба будет работать в другом процессе с именем ServiceProcess
Если вы хотите, чтобы ваша служба никогда не умирала:
onStartCommand () return START_STICKY
onDestroy () -> начать себя
создать сервис Deamon
jin -> создать собственный процесс Deamon, вы можете найти несколько проектов с открытым исходным кодом на github
startForeground (), есть способ startForeground без уведомления, погуглите
В этом руководстве описано, как спланировать фоновую работу с помощью API планировщика заданий Android, который доступен на устройствах Android под управлением ОС Android 5.0 (уровень API 21) и более поздних версий.
Обзор
Один из лучших способов поддерживать хорошую отзывчивость приложения Android — выполнять сложную или длительную работу в фоновом режиме. При этом важно, чтобы фоновая работа не влияла негативно на взаимодействие пользователя с устройством.
Например, фоновое задание может опрашивать веб-сайт каждые три или четыре минуты, чтобы получать изменения в определенном наборе данных. Это кажется пустяком, но это может повлиять на время работы аккумулятора. Приложение будет раз за разом выводить устройство из спящего режима, повышать уровень энергопотребления ЦП, включать беспроводную связь, выполнять сетевые запросы и обрабатывать результаты. Все усложняется тем, что устройство не будет немедленно выключаться и возвращаться в режим ожидания с низким энергопотреблением. Плохо спланированная фоновая работа может привести к тому, что устройство самопроизвольно и без необходимости будет переходить в режим повышенного энергопотребления. На первый взгляд безобидное действие (опрос веб-сайта) довольно быстро сделает устройство непригодным для использования.
Android предоставляет приведенные ниже API для выполнения работы в фоновом режиме, но их недостаточно для интеллектуального планирования заданий.
- Службы намерения . Службы намерения отлично подходят для выполнения работы, но они не позволяют планировать ее.
- AlarmManager . Эти API помогают только планировать работу по расписанию, но не позволяют фактически выполнять работу. Кроме того, AlarmManager поддерживает только ограничения на основе времени, то есть создает оповещение в определенное время или по истечении определенного времени.
- Широковещательные приемники . Приложение Android может настроить широковещательные приемники для выполнения работы в ответ на события или намерения уровня системы. При этом широковещательные приемники не позволяют управлять временем выполнения заданий. Кроме того, изменения в операционной системе Android в будущем ограничат возможность выполнять широковещательные приемники, а также типы работы, на которую они могут реагировать.
Существуют два ключевых аспекта эффективного выполнения фоновой работы (иногда называемой фоновым заданием или просто заданием):
- Рациональное планирование работы. Если приложение выполняет работу в фоновом режиме, оно должно делать это рационально. В идеале приложение не должно требовать выполнения задания. Вместо этого оно должно указать условия, при которых задание может быть выполнено, а затем запланировать в операционной системе задание, которое выполнит нужную работу при выполнении этих условий. Это позволяет Android самостоятельно управлять заданием, повышая эффективность устройства. Например, сетевые запросы могут собираться в пакет и выполняться одновременно, чтобы оптимизировать затраты на работу с сетью.
- Инкапсуляция работы. Код для выполнения фоновой работы должен быть инкапсулирован в отдельный компонент, который может работать независимо от пользовательского интерфейса и который будет сравнительно просто повторно запланировать, если по какой-либо причине работу не удастся выполнить.
Планировщик заданий Android — это платформа, встроенная в операционную систему Android, которая предоставляет гибкий API для удобного планирования фоновой работы. Планировщик заданий Android состоит из следующих типов:
- системная служба Android.App.Job.JobScheduler , которая используется для планирования, выполнения и (при необходимости) отмены заданий от имени приложения Android;
- абстрактный класс Android.App.Job.JobService , который должен быть дополнен логикой для выполнения в фоновом задании. Это означает, что JobService отвечает за асинхронное выполнение работы;
- объект Android.App.Job.JobInfo , который содержит критерии, используемые Android при выборе времени для запуска задания.
Чтобы запланировать работу с помощью диспетчера заданий Android, приложение Xamarin.Android должно инкапсулировать код в классе, который расширяет класс JobService . JobService содержит три метода жизненного цикла, которые могут быть вызваны в течение времени существования задания.
bool OnStartJob(JobParameters parameters) — этот метод вызывается из JobScheduler для выполнения работы в основном потоке приложения. Именно JobService отвечает за асинхронное выполнение работы и возвращает true , если еще осталась невыполненная работа, и false по завершении этой работы.
Когда JobScheduler вызывает этот метод, он запрашивает и сохраняет блокировку в режиме бодрствования для Android на время выполнения задания. По завершении задания JobService должен сообщить об этом в JobScheduler , вызвав метод JobFinished (см. далее).
JobFinished(JobParameters, bool needsReschedule) — этот метод должен вызываться из JobService , чтобы сообщить JobScheduler о завершении работы. Если JobFinished не вызывается, JobScheduler не удалит блокировку в режиме бодрствования, что приведет к быстрой разрядке аккумулятора.
bool OnStopJob(JobParameters parameters) – вызывается, если задание прерывается Android. Он должен возвращать true , если нужно запланировать задание повторно в соответствии с критериями повтора (подробнее описано ниже).
Есть возможность указать ограничения или триггеры, которые будут контролировать время выполнения задания. Например, можно ограничить задание так, чтобы оно выполнялось только во время зарядки устройства, или запускать задание при съемке фото.
В этом руководство подробно описано, как реализовать класс JobService и запланировать его выполнение в JobScheduler .
Требования
Для планировщика заданий Android требуется Android с уровнем API 21 (Android 5.0) или более поздней версии.
Использование планировщика заданий Android
Использование API JobScheduler для Android состоит из трех этапов:
- Реализуйте тип JobService и включите в него нужную работу.
- Используйте объект JobInfo.Builder , чтобы создать объект JobInfo , который будет содержать критерии, по которым JobScheduler выполнит задание.
- Отправьте это задание с помощью JobScheduler.Schedule .
Реализация JobService
Вся работа, выполняемая планировщиком заданий Android, должна быть выполнена в типе, расширяющем абстрактный класс Android.App.Job.JobService . Создание JobService очень похоже на создание Service на платформе Android.
- Расширьте класс JobService .
- Включите в подкласс ServiceAttribute и задайте параметру Name строковое значение, которое состоит из имени пакета и имени класса (см. следующий пример).
- Для свойства Permission элемента ServiceAttribute укажите строковое значение android.permission.BIND_JOB_SERVICE .
- Переопределите метод OnStartJob , добавив код для выполнения работы. Android будет вызывать этот метод в основном потоке приложения, чтобы выполнить задание. Если работа требует больше времени, чем несколько миллисекунд, ее нужно выполнять в отдельном потоке, чтобы избежать блокировки приложения.
- По завершении работы JobService должен вызвать метод JobFinished . С помощью этого метода JobService сообщает JobScheduler о том, что работа выполнена. Отсутствие вызова JobFinished приведет к тому, что JobService сохранит уже ненужные требования к устройству и сократит время его автономной работы.
- Мы также рекомендуем переопределить метод OnStopJob . Этот метод вызывается Android, если нужно остановить задание до его выполнения, что позволяет JobService корректно освободить ресурсы. Этот метод должен возвращать true , если нужно заново запланировать задание, или false , если повторное выполнение не требуется.
Следующий код является примером простейшего JobService для приложения, использующего TPL для асинхронного выполнения некоторой работы.
Создание JobInfo для планирования задания
Приложения Xamarin.Android не создают экземпляр JobService напрямую, а вместо этого передают объект JobInfo в JobScheduler . JobScheduler создаст экземпляр запрошенного объекта JobService , чтобы запланировать и запустить JobService в соответствии с метаданными в JobInfo . Объект JobInfo должен содержать следующие сведения:
- JobId — значение int , которое используется в JobScheduler для идентификации задания. Повторное использование этого значения приведет к обновлению существующего задания. Это значение должно быть уникальным для каждого приложения.
- JobService — этот параметр представляет собой ComponentName , который явным образом определяет тип, который JobScheduler должен использовать для выполнения задания.
Этот метод расширения демонстрирует создание JobInfo.Builder в Android с помощью объекта Context , например действия:
У планировщика заданий Android есть мощная возможность управлять временем выполнения или условиями, при которых может выполняться задание. В следующей таблице описаны некоторые методы JobInfo.Builder , которые позволяют приложению влиять на выполнение задания.
| Метод | Описание |
|---|---|
| SetMinimumLatency | Указывает задержку (в миллисекундах), которая должна соблюдаться перед выполнением задания. |
| SetOverridingDeadline | Объявляет, что задание должно быть завершено до истечения указанного времени (в миллисекундах). |
| SetRequiredNetworkType | Указывает требования к сетевому подключению для выполнения задания. |
| SetRequiresBatteryNotLow | Задание может выполняться, только если устройство не отображает пользователю предупреждение о низком уровне заряда. |
| SetRequiresCharging | Задание может выполняться только во время зарядки аккумулятора. |
| SetDeviceIdle | Задание запускается только во время работы устройства. |
| SetPeriodic | Задание должно выполняться регулярно. |
| SetPersisted | Задание должно сохраняться даже после перезагрузки устройства. |
SetBackoffCriteria предоставляет некоторые рекомендации о том, как долго JobScheduler будет ожидать перед повторной попыткой выполнить задание. Критерий откладывания разделяется на две части: задержка в миллисекундах (по умолчанию 30 секунд) и используемый тип откладывания (иногда называется политикой откладывания или политикой повтора). В перечислении Android.App.Job.BackoffPolicy инкапсулируются две политики:
- BackoffPolicy.Exponential — политика экспоненциальной задержки экспоненциально повышает значение начальной задержки после каждой неудачной попытки. После первой неудачной попытки библиотека выдерживает паузу, длительность которой определяется заданным начальным периодом (например, 30 секунд), а затем повторно назначает задание. При второй неудаче библиотека будет ожидать не менее 60 секунд перед попыткой повторного запуска. После третьей неудачной попытки библиотека будет ждать 120 секунд и т. д. Это значение по умолчанию.
- BackoffPolicy.Linear — эта стратегия использует линейную задержку, то есть выполнение задания каждый раз повторно назначается через заданный интервал (до тех пор, пока оно не будет выполнено). Линейная задержка лучше всего подходит для работы, которая должна быть выполнена как можно скорее, или при наличии проблем, которые быстро исчезают сами по себе.
Дополнительные сведения о создании объекта JobInfo см. в документации Google по классу JobInfo.Builder .
Передача параметров в задание через JobInfo
Параметры передаются в задание путем создания PersistableBundle , который передается вместе с методом Job.Builder.SetExtras .
Доступ к PersistableBundle осуществляется из свойства Android.App.Job.JobParameters.Extras метода OnStartJob класса JobService .
Планирование задания
Чтобы запланировать задание, приложение Xamarin.Android получает ссылку на системную службу JobScheduler и вызывает метод JobScheduler.Schedule для объекта JobInfo , который был создан на предыдущем шаге. JobScheduler.Schedule немедленно возвращает одно из двух целочисленных значений:
- JobScheduler.ResultSuccess — если задание было успешно запланировано;
- JobScheduler.ResultSuccess — если задание не удалось запланировать. Обычно это связано с конфликтом параметров JobInfo .
Следующий код содержит пример планирования задания и уведомления пользователя о результатах попытки планирования:
Отмена задания
Можно отменить все запланированные задания или только одно задание, используя метод JobsScheduler.CancelAll() или метод JobScheduler.Cancel(jobId) .
Сводка
В этом руководстве описано, как использовать планировщик заданий Android для рационального выполнения работы в фоновом режиме. Мы изучили, как инкапсулировать в JobService работу, которую необходимо выполнить, и как с помощью JobScheduler запланировать эту работу, указывая критерии в JobTrigger и способ обработки ошибок в RetryStrategy .
Я запускаю службу из моей основной деятельности Android следующим образом:
когда я закрываю страницу активности, проводя ее из списка последних приложений, служба перестает работать и перезапускается через некоторое время. Я не могу использовать постоянные службы с уведомлениями из-за моих требований к приложению. Как я могу заставить службу не перезапускаться или выключаться и просто продолжать работать при выходе из приложения?
наконец, после всех исследований я сделал, я приходя к пониманию, что лучший выбор для длительного обслуживания является startForeground() , потому что это сделано для этого, и система на самом деле хорошо справляется с вашим сервисом.
этой может помочь вам. Я могу ошибаться, но мне кажется, что это связано с возвращением START_STICKY в своем onStartCommand() метод. Вы можете избежать повторного вызова службы, вернувшись START_NOT_STICKY вместо.
сделать вам обслуживание, как это в вашем Манифеста
тогда ваша служба будет работать на другом процессе с именем ServiceProcess
Если вы хотите, чтобы ваш сервис никогда не умирал:
onStartCommand () возвращает START_STICKY
создать службу Deamon
jin - > создайте собственный процесс Deamon, вы можете найти некоторые проекты с открытым исходным кодом на GitHub
startForeground (), есть способ startForeground без уведомления, google it
услуги иногда довольно сложны.
когда вы запускаете службу из действия (или вашего процесса), служба по существу находится в том же процессе.
цитирование из примечаний разработчика
большая путаница в классе обслуживания фактически вращается вокруг того, что это не так:
служба не является отдельным процессом. Сам объект сервиса не означает, что он работает в своем собственном процессе; если не указано иное, он работает в том же процессе, что и приложение, частью которого он является.
сервис не поток. Это не само по себе средство для работы с основным потоком (чтобы избежать ошибок, не отвечающих приложению).
Итак, что это означает, если пользователь удаляет приложение от последних задач, он удалит ваш процесс(это включает в себя все ваши действия и т. д.). Теперь рассмотрим три сценария.
первый где служба нет уведомления переднем плане.
в этом случае ваш процесс будет убит вместе с вашим сервисом.
второй где служба и уведомление переднего плана
в этом случае служба не убита и не является процессом
третий сценарий Если служба не имеет уведомления переднего плана, она может продолжать работать, если приложение закрыто. Мы можем сделать это путем запуска услуги в другом процессе. (Тем не менее, я слышал, что некоторые люди говорят, что это может не сработать. оставил вам попробовать его самостоятельно)
вы можете создать службу в отдельном процессе, включив атрибут ниже в вашем манифесте.
android: process=": yourService"
android: process= "yourService" имя процесса должно начинаться с нижнего случай.
цитирование из заметок разработчика
Если имя, присвоенное этому атрибуту, начинается с двоеточия ( ' :'), новый процесс, закрытый для приложения, создается, когда это необходимо, и служба запускается в этом процессе. Если имя процесса начинается с строчные символ, служба будет работать в глобальном процессе с этим именем, при условии, что у нее есть разрешение на это. Это позволяет компонентам в различных приложениях совместно использовать процесс, сокращение использования ресурсов.
это то, что я собрал, если кто знаток, пожалуйста, поправьте меня, если я ошибаюсь :)
попробуйте это, он будет держать службу работает в фоновом режиме.
BackServices.класс!--7-->
в своем MainActivity onCreate брось эту строку кода
Теперь служба будет работать в фоновом режиме.
основная проблема в неспособности запустить службу, когда приложение закрыто, Android OS (в некоторых ОС) убьет службу для оптимизации ресурсов, если вы не можете перезапустить службу,то вызовите сигнализацию,чтобы запустить приемник, как это, вот весь код, этот код будет поддерживать службу ur.
в основной Activty запустить сигнализацию ясли таким образом,
это вызовет reciver и reciver есть
и это alaram reciver звонки один раз, когда android приложение открыто и когда приложение закрыто.Так что служба такая,
Почему SyncAdapter? Ans: потому что ранее вы использовали для запуска службы, используя контекст приложения. поэтому всякий раз, когда ваш процесс приложения убивают (когда u удалить его из Диспетчера задач или ОС убить его из-за нехватки ресурсов ) в это время ваш сервис также будет удален. SyncAdapter не будет работать в потоке приложений.. поэтому, если вы позвоните внутри него.. сервис больше не будет удален.. если вы не напишете код для его удаления.
использование одного и того же процесса для службы и активности и START_STICKY или START_REDELIVER_INTENT в службе-единственный способ перезапустить службу при перезапуске приложения, что происходит, например, когда пользователь закрывает приложение, но также и когда система решает закрыть его по причинам оптимизации. Вы не можете иметь службу, которая будет работать постоянно без перерыва. Это по дизайну, смартфоны не предназначены для запуска непрерывных процессов для длительное время. Это связано с тем, что срок службы батареи является наивысшим приоритетом. Вам нужно разработать свой сервис, чтобы он обрабатывал остановку в любой момент.
Почему бы не использовать IntentService?
IntentService открывает новый поток отдельно от основного потока и работает там, таким образом, закрытие приложения не повлияет на него
объявите это в своем манифесте. Дайте пользовательское имя вашему процессу и сделайте этот процесс изолированным и экспортированным .
вы должны добавить этот код в свой класс обслуживания, чтобы он обрабатывал случай, когда ваш процесс убивается
запуск службы intent будет проще. Служба создания потока в приложении, но она все еще находится в приложении.
просто переопределите метод onDestroy в первом видимом действии, например, после всплеска у вас есть домашняя страница, и при перенаправлении с всплеска на домашнюю страницу вы уже закончили всплеск. поэтому поставьте на destroy на домашней странице. и остановите обслуживание в этом методе.
Читайте также: