Принятый ответ от mbaird ударяет гвоздь по голове. Предлагаемый метод onVisivilityChange()
, если он будет реализован, должен охватывать все вышеописанные случаи.
Тем временем это все еще является реальной проблемой для некоторых типов виджетов. Jom представил возможность регистрации для получения намерений ACTION_SCREEN_OFF / ACTION_SCREEN_ON. Это полезно, потому что полагаться на повторяющуюся тревогу без пробуждения недостаточно, поскольку другие службы вызывают пробуждения. Это сложно, потому что на такие действия нельзя подписаться через AndroidManifest.xml, а AppWidgetProvider не разрешено вызывать context.registerReceiver()
. Эти проблемы обсуждаются в нескольких других вопросах StackOverflow, включая Прослушивание ACTION_SCREEN_OFF , android.intent.action.SCREEN_ON не работает как фильтр намерений получателя и Android - как получить широковещательные намерения ACTION_SCREEN_ON / OFF? .
Мне удалось подписаться на намерения ACTION_SCREEN_OFF / ACTION_SCREEN_ON в виджете, создав вспомогательный экземпляр BroascastReceiver
и используя context.getApplicationContext().registerReceiver()
для его регистрации. Это может быть обманом и, по крайней мере, в некоторых последующих выпусках Android, может произойти сбой на этапе регистрации или, возможно, события просто не будут доставлены. Я написал код для обработки этих случаев, но пока он работает. К сожалению, конечно, это не удастся, если и когда приложение когда-либо будет убито.
Другая возможность состоит в использовании метода isHomeScreenShowing()
, как описано здесь , на который ссылается ответ xandy. Идеи, вероятно, можно было бы оптимизировать путем кэширования сгенерированного списка установленных CATEGORY_HOME
приложений и прослушивания трансляций ACTION_PACKAGE_ADDED / CHANGED / REMOVED для его обновления.
Моя стратегия:
- Старайтесь избегать вызова (через повторяющийся сигнал), когда его не видно.
- При вызове проверьте состояние экрана и другие индикаторы видимости, прежде чем делать что-нибудь дорогое.
- Только после этого вызывайте
IntentService
для обработки относительно дорогой работы, которая включает постоянное сетевое соединение. Это необходимо для мониторинга состояния удаленного сервиса в режиме реального времени.