Команда adb shell run-as com.example.app возвращает ответ «run-as: package not debuggable», когда приложение собрано без флага отладки — система Android блокирует доступ к его приватным данным. Это штатный защитный механизм: run-as позволяет выполнять команды от имени приложения только в том случае, если разработчик явно разрешил отладку пакета.
Та же причина стоит за ошибкой INSTALL_FAILED_DEBUGGABLE при попытке установить release-сборку с отладочными параметрами и за отказом Android Studio присоединить отладчик к процессу. Ниже разберём, почему возникает эта ситуация, как проверить флаг debuggable в манифесте и какие варианты решения доступны разработчику и тестировщику.
Что означает ошибка «package not debuggable»
Утилита run-as в Android предназначена для запуска shell-команд в контексте конкретного приложения — с его UID и доступом к каталогу /data/data/имя_пакета. Это удобно для просмотра баз данных, shared preferences и файлов кеша без root-прав. Однако система разрешает такой доступ лишь для пакетов, у которых в манифесте установлен атрибут android:debuggable="true".
Если флаг отсутствует или равен false, команда завершается сообщением «package not debuggable». Это не сбой устройства и не проблема с ADB — это ожидаемое поведение, защищающее данные релизных приложений от несанкционированного чтения.
⚠️ Внимание: попытки обойти это ограничение на релизных сборках чужих приложений без root-прав технически не предусмотрены системой. Методы с изменением чужого APK нарушают его подпись и могут нарушать условия использования ПО.
Как проверить флаг debuggable в приложении
Первый диагностический шаг — убедиться, как собран APK. Если вы разработчик, откройте AndroidManifest.xml и проверьте элемент <application>: атрибут android:debuggable="true" должен присутствовать явно либо выставляться автоматически для debug-сборки. В Gradle-проектах debug-вариант обычно включает отладку по умолчанию, а release — нет.
Проверить уже установленное приложение можно через ADB. Команда выводит сведения о пакете, включая флаги:
adb shell dumpsys package com.example.app | grep -i flagsДополнительно полезно посмотреть, какая сборка установлена на устройстве — возможно, на смартфон попал release-вариант вместо debug. Сверьте имя пакета и вариант сборки в build.gradle вашего проекта.
Решение для разработчика: включить debuggable
Если приложение — ваше, исправление занимает несколько минут. Самый надёжный путь — собрать и установить debug-вариант проекта, в котором отладка включена по умолчанию.
- 🔧 Убедитесь, что в
build.gradleдля нужного build type не заданоdebuggable false. - 📦 Пересоберите проект командой
./gradlew assembleDebugили через меню Build → Build APK(s) в Android Studio. - 📲 Установите именно debug-сборку:
adb install app-debug.apk. - 🔍 Повторите
adb shell run-as ваш.пакет ls— доступ к файлам должен появиться.
☑️ Проверка перед запуском run-as
Обратите внимание на возможное расхождение: applicationId в Gradle может отличаться от имени пакета в манифесте, если заданы суффиксы вида applicationIdSuffix ".debug". В этом случае run-as нужно вызывать с полным итоговым именем пакета, например com.example.app.debug.
Ошибка при установке через adb install
Родственная ситуация — отказ установки с сообщением о debuggable при команде adb install или при запуске из Android Studio. Обычно это происходит, когда сборка содержит отладочные компоненты, но манифест собран как релизный, либо наоборот — когда инструменты ожидают отлаживаемый пакет, а получают release.
Порядок действий здесь простой: удалите предыдущую установку командой adb uninstall имя_пакета, очистите проект (./gradlew clean) и установите свежую debug-сборку. Конфликты подписей и смешанных вариантов после этого обычно исчезают.
| Ситуация | Вероятная причина | Действие |
|---|---|---|
| run-as: package not debuggable | Установлена release-сборка | Установить debug-вариант APK |
| run-as: unknown package | Неверное имя пакета или суффикс | Проверить applicationId и pm list packages |
| Отладчик не подключается | debuggable=false в манифесте | Включить debuggable для build type |
| INSTALL_FAILED при установке | Конфликт подписей старой и новой сборки | adb uninstall и чистая установка |
Что делать, если приложение чужое
Когда нужно получить доступ к данным стороннего приложения, ситуация принципиально иная. Без root-доступа система не даст читать приватные каталоги релизного пакета — это осознанное ограничение безопасности Android, а не недоразумение.
Легальные варианты ограничены: запросить у разработчика отладочную сборку, использовать официальные инструменты экспорта данных самого приложения, если они предусмотрены, или работать на устройстве с root-правами — с пониманием рисков для гарантии и безопасности. Инструкции по рутированию сильно зависят от модели устройства, поэтому универсального безопасного способа здесь нет.
⚠️ Внимание: переподпись чужого APK с добавлением флага debuggable меняет цифровую подпись приложения. Такая сборка не сможет обновляться поверх оригинала, а приложения с проверкой подписи могут отказаться работать.
Почему Android вообще ограничивает run-as
Каталог /data/data содержит токены авторизации, базы переписок и другие чувствительные данные. Если бы run-as работал с любым пакетом, любой подключённый по ADB компьютер мог бы извлекать эти данные без ведома пользователя. Флаг debuggable — компромисс: разработчик осознанно открывает доступ на этапе тестирования и закрывает его в релизе.
Типичные ошибки при диагностике
Часть проблем связана не с самим флагом, а с окружением. Проверьте, что устройство видно в выводе adb devices со статусом device, а не unauthorized — в последнем случае подтвердите диалог разрешения отладки на экране смартфона.
Ещё одна частая ситуация — несколько установленных вариантов приложения для разных пользователей или в рабочем профиле. Команда adb shell pm list packages --user 0 поможет убедиться, что пакет присутствует именно в нужном профиле. И наконец, после смены build type в Android Studio не забывайте выполнить Sync Project with Gradle Files, иначе сборка может использовать старую конфигурацию.
⚠️ Внимание: не публикуйте сборки с android:debuggable="true" в магазинах приложений. Google Play отклоняет отлаживаемые APK на этапе загрузки, а случайная публикация такого пакета открывает данные пользователей.
Часто задаваемые вопросы
Можно ли выполнить run-as для релизного приложения без root?
Нет. Доступ к приватным данным релизного пакета без root-прав система не предоставляет — это фундаментальное ограничение безопасности Android.
Почему debug-сборка всё равно выдаёт «not debuggable»?
Возможные причины: в build.gradle для debug-варианта явно задано debuggable false, на устройстве осталась старая release-установка, либо имя пакета отличается из-за applicationIdSuffix. Проверьте конфигурацию и переустановите приложение.
Чем run-as отличается от обычного adb shell?
Обычный adb shell работает от имени пользователя shell с ограниченными правами. Команда run-as пакет переключает контекст на UID конкретного приложения, открывая доступ к его каталогу данных — но только для отлаживаемых пакетов.
Опасно ли включать debuggable в своём приложении?
Для локальной разработки — нет, это стандартная практика. Опасность представляет только публикация отлаживаемой сборки: любой компьютер с ADB-доступом к устройству сможет читать данные приложения.
Как посмотреть файлы приложения без run-as?
Для debug-сборок в Android Studio есть Device Explorer (или Device File Explorer), который показывает файловую систему устройства в графическом интерфейсе и позволяет скачивать файлы из каталога приложения.