Команда adb shell pm grant com.example.app android.permission.WRITE_SECURE_SETTINGS возвращает Exception occurred while executing 'grant' — и разрешение приложению не выдаётся. Эта ошибка появляется в окне терминала при попытке выдать приложению системное разрешение через ADB, и её текст почти ничего не объясняет: ниже обычно идёт лишь java.lang.SecurityException или IllegalArgumentException с коротким пояснением. Именно эта вторая строка — ключ к диагностике, поэтому первым делом стоит прочитать вывод целиком, а не только заголовок исключения.
Проблема характерна для сценариев, когда пользователь настраивает приложения вроде Tasker, Shizuku, App Ops, Brevent или утилиты управления жестами и автоматизации. Все они требуют разрешений, которые нельзя выдать через стандартный диалог Android, — только через ADB или root. В этой статье разберём, почему команда pm grant завершается исключением, как определить конкретную причину и какие способы решения безопасны.
Что означает эта ошибка
Сообщение Exception occurred while executing 'grant' — это обёртка: менеджер пакетов (PackageManager) отклонил команду и вернул исключение. Само по себе оно не говорит о поломке устройства — это штатная реакция системы на некорректный или запрещённый запрос. Реальная причина всегда указана в строке ниже, после типа исключения.
Типичные варианты второй строки:
- 🔒
SecurityException: grantRuntimePermission: Neither user ... nor current process has android.permission.GRANT_RUNTIME_PERMISSIONS— ADB-сессия не имеет полномочий, чаще всего из-за ограничений прошивки. - 📦
IllegalArgumentException: Unknown package: com.example.app— пакет с таким именем не установлен на устройстве. - 🚫
SecurityException: Permission ... is not a changeable permission type— это разрешение нельзя выдать черезpm grantв принципе. - 👤
Unknown permissionили упоминание пользователя — разрешение не существует либо не запрошено приложением в манифесте.
Обратите внимание: без второй строки диагностика превращается в гадание. Если терминал обрезает вывод, выполните команду повторно и скопируйте текст полностью — это сэкономит время на всех следующих шагах.
Проверка имени пакета и установки приложения
Самая частая и самая простая причина — опечатка в имени пакета или отсутствие приложения на устройстве. Имя пакета (com.example.app) — это не название из магазина, а внутренний идентификатор, и он должен совпадать символ в символ, включая регистр.
Чтобы проверить, установлено ли приложение и как точно называется его пакет, выполните:
adb shell pm list packages | findstr "часть_имени"
На Linux или macOS вместо findstr используется grep. Команда выведет строки вида package:com.example.app — скопируйте имя оттуда, не перепечатывая вручную. Если приложение в списке отсутствует, его нужно сначала установить, причём на того пользователя, для которого выдаётся разрешение.
- 🔍 Убедитесь, что приложение установлено именно на основном пользователе, а не в рабочем профиле или втором пространстве.
- ✍️ Скопируйте имя пакета из вывода
pm list packages, а не из названия в Play Market. - 🧩 Проверьте, не установлено ли несколько версий приложения (например, обычная и клонированная).
- 🔄 При сомнениях переустановите приложение и повторите команду.
Проверка самого разрешения
Вторая по частоте причина — попытка выдать разрешение, которое приложение не запрашивало или которое вообще нельзя выдать командой pm grant. Через эту команду можно выдавать только runtime-разрешения (опасные разрешения, которые в обычном случае запрашиваются диалогом) и некоторые специальные — при условии, что они объявлены в манифесте приложения.
Если разрешение не прописано в манифесте приложения, система ответит ошибкой Unknown permission или проигнорирует запрос. Проверить, какие разрешения запрашивает установленное приложение, можно так:
adb shell dumpsys package com.example.app | findstr "permission"
В выводе ищите раздел requested permissions — выдать через grant можно только то, что там перечислено. Если нужного разрешения в списке нет, команда pm grant бессильна: это ограничение самого приложения, и исправить его может только разработчик.
Отдельный случай — разрешения с пометкой not changeable. Часть системных разрешений (например, подписочные, signature-level) выдаётся только приложениям, подписанным ключом прошивки. Никакая команда ADB без root не обойдёт это ограничение, и попытки приведут к тому же исключению.
Ограничения прошивки и производителя
На ряде устройств — это отмечают владельцы аппаратов Xiaomi с MIUI, а также некоторых прошивок других производителей — выдача разрешений через ADB дополнительно ограничена. Система может требовать включённых опций в режиме разработчика, без которых pm grant завершается SecurityException даже при правильном синтаксисе.
Что стоит проверить в настройках для разработчиков (названия пунктов могут отличаться в зависимости от версии прошивки — сверяйтесь с документацией вашего устройства):
- 🛠️ Включена ли сама отладка по USB — без неё ADB-команды не выполняются вовсе.
- 🔓 На MIUI — пункт вроде «Отладка по USB (настройки безопасности)»: без него команды, меняющие разрешения и настройки, блокируются. Для его активации может требоваться вход в аккаунт и SIM-карта.
- ⏱️ Не истёк ли период авторизации отладки — на некоторых прошивках разрешения отладки отзываются автоматически.
- 💻 Подтверждён ли компьютер на устройстве: при подключении должен был появиться запрос «Разрешить отладку?» с отпечатком ключа.
⚠️ Внимание: включение расширенных опций отладки снижает защиту устройства — через ADB с компьютера можно будет менять системные настройки. После завершения настройки приложений отладку по USB имеет смысл отключить, особенно если устройством пользуются вне дома.
Проверить, видит ли компьютер устройство и авторизовано ли оно, помогает команда adb devices. В выводе напротив серийного номера должно стоять device, а не unauthorized или пустая строка. Статус unauthorized означает, что на экране смартфона не подтверждён запрос на отладку — отзовите авторизации в настройках разработчика и подключите кабель заново.
Почему на Xiaomi ошибка возникает чаще
В MIUI/HyperOS выдача разрешений через ADB дополнительно защищена. Даже при включённой отладке по USB команды, изменяющие разрешения и настройки, могут блокироваться, пока не активирован отдельный пункт «Отладка по USB (настройки безопасности)» в меню разработчика. На части прошивок для его включения требуется авторизованный Mi-аккаунт и активная SIM-карта. Точное название и наличие пункта зависят от версии прошивки.
Пошаговая диагностика и исправление
Если собрать всё вместе, порядок действий выглядит так: от простых проверок — к более глубоким. Не пропускайте шаги, даже если уверены в правильности команды: опечатки в длинных именах разрешений встречаются постоянно.
☑️ Диагностика ошибки grant
Базовый синтаксис команды для справки:
adb shell pm grant ИМЯ_ПАКЕТА ИМЯ_РАЗРЕШЕНИЯ
Если устройств несколько, добавьте указание цели: adb -s СЕРИЙНИК shell pm grant .... А при работе со вторым пользователем или рабочим профилем может понадобиться флаг --user с идентификатором пользователя — узнать список пользователей можно командой adb shell pm list users. Разрешение, выданное основному пользователю, не распространяется на копию приложения в другом профиле, и это тоже типичный источник путаницы.
После успешного выполнения команда не выводит ничего — молчание терминала означает успех. Проверить результат можно повторным запросом dumpsys package: в разделе granted permissions приложения нужное разрешение должно быть помечено как выданное (granted=true).
| Строка в выводе ошибки | Вероятная причина | Что делать |
|---|---|---|
| Unknown package | Приложение не установлено или опечатка в имени | Проверить через pm list packages |
| Unknown permission | Разрешение не запрошено приложением или опечатка | Сверить с dumpsys package |
| Not a changeable permission type | Разрешение нельзя выдать через pm grant | Способа без root нет |
| SecurityException (GRANT_RUNTIME_PERMISSIONS) | Ограничение прошивки, отладка безопасности выключена | Проверить опции разработчика |
| Нет упоминания пакета, ошибка соединения | Проблема с ADB-подключением | Проверить adb devices, кабель, драйверы |
Когда стандартные методы не помогают
Бывают ситуации, когда все проверки пройдены, синтаксис верный, а ошибка остаётся. Здесь важно не переходить сразу к рискованным действиям, а сузить круг причин.
Во-первых, попробуйте перезапустить ADB-сервер: команды adb kill-server и затем adb start-server сбрасывают зависшие сессии. Во-вторых, проверьте актуальность самих инструментов — устаревшая версия Android SDK Platform-Tools иногда конфликтует с новыми версиями Android на устройстве. Скачивать Platform-Tools следует только с официального сайта для разработчиков Android.
⚠️ Внимание: не используйте сторонние «ADB-инсталляторы» и модифицированные утилиты из неофициальных источников — они могут содержать вредоносный код, а ADB-доступ даёт им широкие возможности на компьютере и устройстве.
Если разрешение относится к подписочным (signature-level), единственные легальные пути — root-доступ с соответствующими инструментами или приложение, подписанное ключом производителя. Оба варианта выходят за рамки обычной настройки: root снимает устройство с гарантии и ослабляет безопасность, поэтому взвесьте, действительно ли нужна функция, ради которой выдаётся разрешение. Часто приложение предлагает альтернативный режим работы с урезанными возможностями, но без специальных разрешений.
Часто задаваемые вопросы
Ошибка возникает, хотя раньше та же команда работала. Почему?
Возможные причины: обновление прошивки изменило политику разрешений, отладка по USB была автоматически отключена системой, приложение обновилось и изменило манифест, либо истекла авторизация компьютера. Начните с adb devices и проверки опций разработчика.
Можно ли выдать разрешение без компьютера?
Частично — да. Приложения на базе Shizuku позволяют выдавать отдельные разрешения локально, но сам Shizuku после каждой перезагрузки требует активации либо через ADB, либо через беспроводную отладку (на Android 11 и новее). Полностью без ADB на не-root устройстве обойтись нельзя.
Что значит «Permission is not a changeable permission type»?
Это разрешение, которое система не позволяет выдавать командой pm grant в принципе — обычно оно подписочное или системное. Такие разрешения получают только системные приложения или приложения, подписанные ключом производителя. На устройстве без root обойти ограничение нельзя.
Опасно ли выдавать WRITE_SECURE_SETTINGS приложению?
Это разрешение позволяет приложению менять системные настройки, включая некоторые параметры безопасности. Выдавайте его только проверенным приложениям, функциональность которых вам понятна, и отзывайте командой adb shell pm revoke, если приложение больше не используется.
Как отозвать разрешение, выданное через ADB?
Командой adb shell pm revoke ИМЯ_ПАКЕТА ИМЯ_РАЗРЕШЕНИЯ — синтаксис аналогичен grant. Удаление приложения также автоматически отзывает все выданные ему разрешения.