Журнал освещенности
Датчик света участвует в регулировке яркости, смене режима экрана и ряде фоновых сценариев. Следы обращения к нему видны не через один общий список, а через сочетание признаков. Я проверяю разделы разрешений, записи системных событий и поведение программ в покое. Такая связка раскрывает, кто считывает показания по делу, а кто запускает лишний опрос.
Первый признак связан с правами, хотя прямого пункта для сенсора в меню может не быть. Часть программ получает сведения через общий доступ к данным устройства или через службы, связанные с движением и состоянием экрана. Я открываю карточку каждой подозрительной утилиты и смотрю, какие разрешения выданы, какие сняты, какие восстановились после обновления. Если приложению для заметок или калькулятору открыт путь к служебным данным, появляется повод для отдельной проверки, а при схожих признаках полезно также проверить доступ к журналу использования Bluetooth, а для примера того, как меняется подача сервиса, можно посмотреть Project makeover.
Системные записи
Дальше я перехожу к журналам событий. В них важны не названия строк, а повторяемый рисунок: пробуждение процесса, запрос к сенсору, короткая серия чтений, завершение. Если такие циклы идут при заблокированном экране и без действий владельца, фоновая активность выходит за рамки явной задачи. Отдельно смотрю, совпадает ли обращение с изменением яркости. При штатной работе цепочка выглядит связно, без лишних запусков стороннего процесса.
Еще один слой проверки дает расход заряда. Датчик света сам по себе не создает крупную нагрузку, зато постоянный опрос тянет за собой пробуждения, работу службы и обращения к памяти. Я сопоставляю всплески расхода с периодами без использования устройства. Если в эти промежутки одна и та же ппрограмма держит активность, а экран не менял режим, подозрение усиливается. Такой признак не доказывает сбор напрямую, но сужает круг поиска.
Практические различия
Штатный сценарий легко отличить по привязке к функции. Читалка реагирует на смену освещения во время открытой книги, камера подстраивает экран перед съемкой, оболочка меняет яркость после выхода на свет. Лишний сбор выглядит иначе: процесс оживает в фоне, не показывает результат на экране и не связан с текущим действием владельца. Еще один маркер — сохранение активности после запрета смежных разрешений. Значит, источник данных проходит через другой канал.
Отдельную ошибку создает доверие к названию программы. Безобидное описание в магазине не говорит о фактическом поведении после установки. Я сверяю имя пакета, дату обновления и набор служб, которые запускаются вместе с ним. Подмена нередко прячется в утилитах с простым назначением: фонарик, блокнот, сканер кодов. Для таких задач чтение света выглядит спорно, если на экране нет функции автоподстройки.
Еще одна ловушка связана с разовой проверкой. Краткий просмотр раздела батареи или разрешений не показывает скрытый сбор, который включается при смене состояния экрана, при запуске зарядки или при переходе в сон. Я наблюдаю устройство в разных режимах и отмечаю, какой процесс просыпается первым. Потом отключаю подозрительную программу и повторяю цикл. Если рисунок событий исчезает, связь подтверждается без догадок.
При разборе доступа приложений к журналу использования датчика освещенности я избегаю двух крайностей. Первая ошибка — считать опасным всякое чтение сенсора. Вторая — доверять системе без сверки следов. Точный результат появляется, когда права, журнальные записи, расход заряда и сценарий работы складываются в одну картину. Если хотя бы один элемент выпадает, проверку продолжают до ясной причины.