Я согласен с ответом, предложенным @rds.
Имейте в виду, что CONNECTIVITY_ACTION устарело на уровне API 28.
Если у вас есть требование, чтобы состояние Wi-Fi (подключение / отключение) было обнаружено, несмотря на то, что приложение было убито, и вы хотите настроить таргетинг на последнюю версию, тогда у вас нет особого выбора.
Вам нужно использовать connectivityManager.registerNetworkCallback(networkRequest, networkCallback)
Вопрос в том, что вы не можете использовать BroadcastReceiver, так как же тогда?
Вы можете использовать JobScheduler или лучше WorkManager (периодический запрос). Почему Periodic, потому что если это OneTimeRequest, то он сможет запускаться только один раз и продолжать прослушивание, пока ваше приложение находится на переднем плане.
В документации говорится:
Обратные вызовы будут продолжать вызываться до тех пор, пока приложение не выйдет или не будет вызвана ссылка #unregisterNetworkCallback (NetworkCallback)}.
После того, как приложение будет убито или удалено из списка последних приложений, networkCallback не сможет его прослушивать.
Итак, вам нужны такие периодические задания, чтобы приложение постоянно слушало. Какой должна быть продолжительность? Это зависит от вас и зависит от конкретного случая.
Я знаю, что это немного некрасиво, но так оно и есть. Одна из проблем может заключаться в том, что если устройство пользователя находится в режиме ожидания или приложение находится в состоянии ожидания, ваша работа может быть отложена.
targetSdkVersionдо N или более поздней версии?