Опасные разрешения приложений: почему полный запрет ломает смартфон

Навигация перестаёт запускаться, синхронизация зависает, а мессенджер начинает повторять один и тот же запрос. Android при этом продолжает работать. Ломается конкретное приложение или его отдельные функции — и довольно часто по вине разработчика, а не системы.

Я смотрю на разрешения по последствиям. Что приложение делает после отказа? Продолжает работать или ложится, как сломанный навигатор? Вот здесь и начинается настоящая мобильная безопасность.

Как Android раздаёт доступ к данным

В Android есть два базовых механизма выдачи разрешений. Обычные права выдаются автоматически при установке. Опасные, или runtime permissions, запрашиваются у пользователя во время работы приложения.

К обычным относятся, например, доступ в интернет и статус подключения к сети. Система не показывает отдельный диалог: приложение устанавливается, доступ к сети уже разрешён. Диалог «разрешить интернет?» выглядит перебором — примерно как спрашивать разрешение открыть дверь в квартиру, где вы уже живёте.

Опасные разрешения связаны с приватными данными и критическими ресурсами:

Например, сканеру штрихкодов нужна камера. Голосовому помощнику — микрофон. Навигатору — точная геолокация. Контакты нужны приложению для обмена сообщениями, хотя некоторые мессенджеры умеют работать и без доступа к адресной книге.

Сам факт запроса ещё ни о чём не говорит. Вопрос в контексте. Фонарик, который просит доступ к журналу звонков, выглядит подозрительно. Сканер документов, которому нужна камера, — вполне нормально. SMS для подтверждения банковской операции может быть необходим конкретному приложению, поэтому механически запрещать его так же рискованно, как доверять.

От Android 6.0 до «Больше не спрашивать»

Модель runtime permissions появилась в Android 6.0 Marshmallow в 2015 году. До неё приложение обычно получало набор прав при установке. Пользователь видел список мелким шрифтом и нажимал одну кнопку. Согласие было формальным, но разработчикам было удобно.

Android 6.0 перенёс опасные разрешения в момент, когда они действительно нужны. Появились сценарии вроде «разрешить камеру для сканирования?» или «предоставить доступ к геолокации для навигации?». Это уже похоже на нормальный диалог с пользователем.

В Android 11 появились разовые разрешения — «только в этот раз». Подход удобен для отдельных действий: камера нужна на один проход сканирования, микрофон — для записи короткого голосового сообщения. Приложение не должно получать постоянный доступ к данным ради одной кнопки.

Но у механики есть злая особенность. Два последовательных отказа система трактует как «Больше не спрашивать». После этого Android перестаёт показывать стандартный диалог запроса. Приложение больше не может самостоятельно вывести окно с кнопками «Разрешить» и «Запретить». Оно может отправить пользователя в системные настройки.

На практике это выглядит так:

1. Приложение просит доступ.

2. Пользователь отказывает.

3. Приложение снова просит при следующем запуске или при попытке выполнить функцию.

4. Второй отказ превращается в постоянный запрет.

5. Дальше доступ придётся включать вручную.

Разрешение всегда можно вернуть через настройки приложения. Поэтому «Больше не спрашивать» — блокировка, а не приговор. Просто система перестаёт помогать невнимательному разработчику.

В Android 11 также появился автосброс. Если приложение несколько месяцев подряд не использовали, Android может отозвать ранее выданные доступы к конфиденциальным данным. Программа остаётся установленной, но при следующем запуске снова попросит разрешение.

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

Почему приложение «падает», хотя Android живой

Архитектурные рекомендации Android требуют от разработчика корректно обрабатывать отказ. На техническом языке это называется graceful degradation, то есть плавное снижение функциональности.

Правильное поведение выглядит так:

• карта показывает сохранённые маршруты, но не строит маршрут по текущему местоположению;
• мессенджер открывает переписку, но не подтягивает новые контакты;
• приложение для заметок работает без доступа к памяти, если конкретная функция позволяет;
• камера сообщает, что доступ к камере запрещён, вместо вылета;
• сервис синхронизации приостанавливает работу, а не перезапускает запрос в бесконечном цикле.

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

Проблема начинается, когда разработчик assumes: «пользователь наверняка разрешит». Код проверяет разрешение, получает отказ, но продолжает обращаться к данным или объекту, которого уже нет. На выходе получается сбой. Приложение падает при запуске либо зацикливается на собственном экране запроса.

Типичный сценарий выглядит так. Пользователь отказывает в доступе к контактам. Приложение должно показать сообщение: «Разрешите доступ, чтобы найти нужного человека». Вместо этого оно отправляет пользователя в настройки. После возвращения экран с запросом появляется снова. Затем приложение опять открывает настройки. Системный диалог может больше не появляться, но самодельная карусель приложения продолжает крутиться.

Есть ещё один сбойный вариант: обязательная функция инициализируется раньше, чем пользователь принимает решение. Например, камера или геолокационный модуль запускается при старте, хотя нужны только после нажатия кнопки. Отказ приходит слишком поздно, чтобы обработать его корректно.

Отказ должен гасить конкретную функцию. Если вылетает всё приложение, разработчик забыл про отказ; Android тут ни при чём.

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

Как запрещать доступ без катастрофы

Единого списка разрешений, которые нельзя давать никогда, нет. Камера сканеру нужна, микрофон — голосовым сообщениям, SMS — некоторым сервисам подтверждения. Я бы оценивал каждое разрешение по задаче приложения и по тому, какие данные оно обещает использовать.

Обычно запрос выглядит логично, если разрешение связано с основной функцией:

• камера у сканера, фотографа или приложения для распознавания документов;
• микрофон у голосового помощника, диктофона или мессенджера с голосовыми вызовами;
• точная геолокация у навигатора или трекера;
• контакты у приложения, которое ищет людей по адресной книге.

Запрос выглядит лишним, когда приложение лезет в данные, которые никак не участвуют в его работе. Фонарик с доступом к контактам и SMS вызывает вопросы. Редактор фотографий, требующий журнала звонков, выглядит ещё страннее. Приложение для фонариков может технически использовать камеру, но контакты и история звонков к делу отношения не имеют.

Мой рабочий порядок выглядит так:

1. Начинаю с новых и малоизвестных приложений. Смотрю, что установлено, какие разрешения выданы и какие функции приложение заявляет. Установка из привычного магазина снижает риск, но не отменяет проверку.

2. Отказываюсь по одному разрешению. Массовый запрет превращает нормальную программу в нервный комок. По одному праву проще понять, какая функция сломалась.

3. Перезапускаю приложение и выполняю нужное действие. Камера действительно открывается? Голосовое сообщение записывается? Навигация видит текущую точку? Если функция не работает, возвращаю только необходимое право.

4. Проверяю геолокацию отдельно от фонового доступа. Фоновая геолокация означает, что координаты продолжают поступать, когда приложение свёрнуто или экран выключен. Постоянный доступ нужен навигатору во время маршрута, геозонам и некоторым трекерам. Бытовым приложениям он часто не требуется.

5. Не трогаю обычные разрешения без причины. Доступ в интернет выдаётся автоматически и не сопровождается диалогом. Если приложение работает, лезть в эту строку в настройках бессмысленно.

6. Учитываю автосброс. Приложение, которым давно не пользовались, может снова попросить доступ. Это защитный механизм, а не попытка оператора или разработчика вытрясти ещё немного данных.

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

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

Специальные права: настоящий запасной вход в смартфон

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

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

Это огромная мощность. Поэтому злоупотребление выглядит убедительно: вредоносная программа выдаёт себя за помощник, читает экран, перехватывает нажатия и действует от имени пользователя.

Право на оверлей позволяет приложению рисовать поверх других окон. Само по себе оно используется легитимно: плавающая клавиатура, панель перевода, ненавязчивый музыкальный плеер. В сочетании со специальными возможностями оно открывает схему атаки, известную как tapjacking: злоумышленник рисует поверх настоящего окна кнопку, а пользователь нажимает её, не замечая подмены.

Отдельный риск — программа, которая получила слишком широкое разрешение под безобидным предлогом. Приложение-«оптимизатор» может требовать специальные возможности для очистки памяти. А лаунчер — для расширенных жестов. До выдачи права стоит спросить, зачем именно оно требуется. Если объяснение начинается с «для удобства», этого недостаточно.

Проверять такие доступы нужно вручную:

1. Откройте настройки специального доступа.

2. Просмотрите приложения с включёнными специальными возможностями.

3. Отключите те, которыми вы не пользуетесь или которые вам незнакомы.

4. Проверьте приложения с правом отображения поверх других окон.

5. Оставьте доступ только там, где он нужен для конкретной функции.

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

Особые права — запасной вход в смартфон. Обычный диалог разрешений о нём почти не рассказывает.

Полный запрет опасных прав — грубый и часто бессмысленный ход. Он отключает камеру у сканера, микрофон у диктофона и геолокацию у навигатора, а затем демонстрирует ошибки разработчика. Разумная стратегия проще: разрешайте необходимое, отказывайте лишнее, проверяйте специальные доступы и возвращайте конкретное право, если отказ действительно сломал нужную функцию. Смартфон от этого не сломается. Приложение — вполне может.