Android data permission denied

Почему при использовании adb мне отказывают в доступе к папке данных?

я подключился к моему живому устройству с помощью adb и следующих команд:

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

Как получить доступ root на моем телефоне?

13 ответов

есть две вещи, чтобы помнить, если вы хотите просмотреть все на вашем устройстве.

1. вам нужно иметь телефон с корневым доступом для того, чтобы просматривать папку данных на телефоне Android. Это означает, что у вас есть устройство разработчика (ADP1 или Иона из Google I / O) или вы нашли способ «укоренить» свой телефон каким-то другим способом.
2. вам нужно запустить ADB в корневом режиме, сделайте это, выполнив: adb root

начиная с уровня API 8 (Android 2.2), для отладочного приложения (тот, который был построен Android Studio все время, если сборка выпуска не была запрошена), вы можете использовать оболочку run-as команда для запуска команды или исполняемого файла в качестве конкретного пользователя / приложения или просто переключиться на UID вашего приложения, чтобы вы могли получить доступ к его данные.

список содержимого каталога yourapp:

переключиться на UID com.yourapp и запустите все дальнейшие команды, используя этот uid (пока вы не вызовете exit ):

Примечание 1: есть известная проблема С некоторыми телефонами HTC Desire. Из-за нестандартного владельца/разрешений , run-as команда не запускается на этих телефонах.

примечание 2.: как указано в комментариях @Avio: run-as имеет проблемы также с телефонами Samsung Galaxy S работает В CyanogenMod любой версии (от 7 до 10,1), потому что на этой платформе /data/data является символической ссылкой на /datadata . Один из способов решить проблему-заменить символическую ссылку на фактический каталог (к сожалению, для этого обычно Требуется root-доступ).

прежде чем мы начнем, у вас есть корни телефон? если нет, я настоятельно рекомендую вам сделать прыжок. 99% учебников, которые помогут вам сделать это, требуют, чтобы у вас был корневой телефон (я знаю, что b/c я потратил около часа на поиск способа сделать это без корневого телефона.. ничего не нашел..) также, если вы думаете об этом, ваш iPhone должен быть привязанным к этой же задаче. Так что это вполне разумно. Подробнее о укоренение в конце ответ.

из командной строки введите:

это приведет вас к вашей линии Android shell comand (вы должны увидеть что-то вроде этого: shell@android:/ $ сейчас типа:

это должно привести вас непосредственно к каталогу данных com.domain.yourapp :

если это не так (т. е. если вы получаете ошибку), то у вас, вероятно, нет корневого телефона, или вы не использовали свои привилегии пользователя root. Чтобы использовать права пользователя root, введите su в командной строке adb и посмотреть, что произойдет, если вы получите ошибку, то вы телефон не коренится. Если это не так, сначала укорените его, затем продолжите эти инструкции.

оттуда вы можете ввести ls и вы увидите все каталоги, включая dbs:

после этого вы можете использовать sqlite3 для просмотра dbase.. если вы не установили его (вы можете узнать это, введя sqlite3 если вам command not found тогда вам придется установить его. К установите sqlite, следуйте инструкциям здесь.

о укоренения: если вы никогда не укореняли свой телефон раньше, и вы беспокоитесь о том, что он завинчивает ваш телефон, я могу сказать вам с полной уверенностью, что беспокоиться не о чем. есть тонны быстрых и простых учебников по укоренению телефона для почти всех новых и старых моделей,и вы можете укоренить свой телефон, даже если у вас есть mac (я укоренил свой s3 с моим mac).

Источник

Android 10, «Permission denied» in a SD card #5320

Comments

Gnakkk commented May 20, 2020

Android 10 upgrade turned out to be such a bad idea because I lost the writing permission in my external SD card.

Is there a way to fix it?

The text was updated successfully, but these errors were encountered:

kcubeterm commented May 20, 2020 •

Can you provide device vendor name as well, because many custom rom devices , termux can access even write also, like in Redmi(miui)

RalfWerner commented May 20, 2020

I lost the writing permission in my external SD card.

creates two symlinks that allow writing and lists the content! At least one of the two paths is the sdcard but be careful — the paths are also disposed of with the termux deinstallation.
But, the google-file-App on Android 10 can edit termux data ( cp/mv — always with a new timestamp).

Gnakkk commented May 20, 2020

RalfWerner commented May 20, 2020 •

try $a from my example above behind /2 or instead. ls -la shows owner and group

xeffyr commented May 20, 2020

Full rw access to external storage was never supported.

Gnakkk commented May 21, 2020

@RalfWerner was right.
I’ve got it working now!

Thanks a million!

RalfWerner commented May 21, 2020 •

Full rw access to external storage was never supported.

@xeffyr This contradicts my experience with my Android 8/9 devices from different arch, on which all data allow r+w access and only restrictions due to fat-differences have to be considered.
With Q10/R11 that changes. Therefore I would not label the question as invalid. My real devices cannot be upgraded to Q10 and my 30Gb sdcard works simply like a USB stick, so I test with emulations.

I reread wiki and miss the changes that result in Q10 and R11 and targetSdkVersion 29/R ( *29.apk )
comes Aug 20 in less than 3 monthes. Here are some suggestions:

First, unlimited access from google-file to all termux data (including nl/ and packages u/ ). «App-private storage» does not apply to google, especially since the properties can be changed without termux-setup-storage ( tss ) in phone-setup.

/storage) are only allowed «one way» and _»x-file-access» not (fat differences).
Scripts can, however, be executed as the «input» of the interpreter (e.g. bash).

/sdcard exists on most devices and is a symlink with an unclear destination — often the real sdcard if it exists or internal storage. When formatting the sdcard, the folders (Android to Pictures) are created (different spellings) to which tss creates uniform symlinks. However, these folders are then multiple on one device and only the path /storage/*/* in termux is unique.

tss is not possible on R11 because the basic function am no longer works (@fornwall confirmed). I prefer debug to wiki-docu!

Reference to package limitation in external storage is missing in wiki. However, it can be used as ../ -backup if termux de/re-installed, does not use $a and the target device has the same arch.

At *29.apk , three different owner/group assignments have been set up on the sdcard on three different emulators. For termux all imaginable rw combinations and groups are included. google is allowed to do everything again and the $a path (@KangKazumi above) always belongs to termux — but unfortunately it is also disposed of with the app. Thanks to google (problem & solution) there is data recovery:)

Источник

Zheka’s blog

Sunday, February 16, 2014

Доступ к ресурсам Android приложения

Бывает так, что во время разработки, нужно заглянуть в приватные директории приложения. Как известно, доступ к ним закрыт, и при попытке, скажем, получить список файлов, имеем следующее:

Есть несколько решений данной проблемы.

Первое, что приходит на ум — получить root права. Недостатки очевидны. Ломать телефон из-за маленькой плюшки — варварство(да и телефон может быть не личный, а, например, корпоративный). Но имея root , получаем неограниченный доступ ко всем ресурсам системы.

run-as

В составе Android OS есть утилита run-as . По своей сути очень похожа на sudo — выполнение команд от имени приложения или говоря короче — делегирование прав:

Пара моментов которые нужно знать. Приложение должно быть собрано как debuggable и в нек. случаях нужно менять права на файлы/директории:

Из недостатков можно назвать лишь одно — нет возможности доступа к файлам приложений третьих лиц(установленных, например, с Play Market).

backup

Последний способ. Я его использовал до того, как познакомился с run-as . Android предоставляет возможность сделать копию приложения:

В текущей директории будет создан файл backup.dat ( [device id] можно узнать командой ‘adb devices’ ). Далее распаковываем *.dat файл:

Приведенная команда у меня работает только под Linux, под Mac OS я получаю сообщение об ошибке, мол openssl собран без поддержки zlib. Немного пошаманив, нашел решение, которое не требует пересборки openssl:

По сравнению с Linux вариантом, работет медленнее, но для меня не критично. После всех шагов, в текущей директории будет создана папка apps, содержащая все внутренности приложения.

До недавнего времени последний способ не имел недостатков. Т.е. была возможность получить доступ ко всем потрохам без каких-либо ограничений. Но начиная с версии Android 4.4 в AndroidMainifext.xml был добавлен флаг allowBackup:

Который гласит буквально следующее: если флаг установлен в значение false , то приложение никогда не будет иметь возможность сделать резервную копию или восстанновление из резервной копии, даже в случае резерного копирования всей системы(имеется ввиду средствами самой ОС). Поумолчанию флаг имеет значение true . Вот такие дела. Т.е. доспут к ресурсам своего приложения мы всегда будем иметь, а в остальном — как повезет.

Источник

Android runtime permissions. Почему, зачем и как

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

Хорошо, если вы устанавливаете приложение от какого-то известного разработчика, которому можете доверять. Но весьма подозрительно, если вы устанавливаете новый музыкальный плеер, а ему для работы требуется, например, получать ваше местоположение. Или, тем более, фонарик, требующий доступ к смс и звонкам.

Некоторые разработчики, чтобы уменьшить недоверие, добавляют в описание приложения на Google Play информацию о том, зачем нужно то или иное разрешение.

К шестой версии Android ситуация поменялась. Теперь разрешения нужно запрашивать в процессе работы. О том, как этой новой возможностью пользоваться и ее некоторых подводных камнях будет рассказано далее.

Общая информация

Подобно тому, как это происходит в iOS, при запросе появится системный диалог с запросом разрешения.

Отличие в том, что после нажатия на кнопку “Deny” разрешение не будет полностью запрещено для приложения, как это происходит у Apple. Его можно будет запросить повторно, но в этом случае появится опция “Never ask again”, после выбора которой “Deny” работает как “Don’t allow” в iOS.

Разрешения делятся на два типа (есть и другие, но они нас не интересуют):

• обычные (normal);
• опасные (dangerous).

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

Можно увидеть, что доступ к интернету не считается опасным. Все, кто использует рекламу в своих программах, могут вздохнуть с облегчением: отключить её, просто отобрав разрешение, не получится (все еще можно просто отключить интернет, но факт остается фактом).

Для того чтобы отозвать разрешение, которое было выдано ранее (или предоставить его, если вы выбрали “Never ask again”) нужно перейти в настройки приложения (Settings->Apps->*AppName*) в раздел Permissions и кликнуть по соответствующим переключателям. В этом меню также можно посмотреть все разрешения этой программы, выбрав пункт “All permissions” из контекстного меню. Еще есть возможность просматривать, каким приложениям выдано конкретное разрешение (и соответственно предоставить или отобрать его). Для этого в настройках в разделе Apps нужно кликнуть по меню с иконкой шестеренки и в открывшемся разделе выбрать App permissions. Далее, выбрав нужное разрешение, можно увидеть все приложения, которым оно нужно.

Взаимодействие с пользователем

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

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

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

Второй момент заключается в том, насколько ясно будет человеку, для чего нужно это разрешение. Зачем приложению для смс доступ к календарю? Наверное, для какой-то классной функции, которая облегчит перенос дат из сообщений в календарь и тому подобное. Но знаете об этом только вы, поэтому сначала нужно объяснить причину запроса и показать какие возможности даст доступ к этому разрешению. Это относится и к первичным и к вторичным разрешениям.

Еще раз кратко:

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

В случае, когда вам все-таки отказали, пояснение причины в следующий раз является обязательным. А если помимо отказа, пользователь попросил вас никогда не запрашивать данное разрешение, используя опцию “Never ask again”, но пытается использовать соответствующую функцию приложения, предложите ему перейти в настройки вашей программы и вручную включить необходимые разрешения. Это особенно важно, если разрешение критично для работы программы.

Логичным вопросом будет: а что же произойдет, если запустить ваше неадаптированное под runtime разрешения приложение на Android Marshmallow? Ответ зависит от того осмелились ли вы изменить targetSdk на 23 версию (compileSdk и buildTools нас в данном случае не интересуют). Если да, то у меня не лучшие новости для вас: очень вероятно, что вы получите SecurityException. Это не обязательно будет так, возможно где-то вы получите null вместо запрошенной информации, но вероятность далеко не нулевая. Если же вы используете targetSdk версии 22 и ниже, то все разрешения будут, как и прежде выданы приложению при установке, включая опасные. Это не отменяет того, что пользователь может отозвать любое из них после установки. При этом он получит предупреждение, что приложение не адаптировано под runtime разрешения и может работать некорректно. Насколько некорректно оно будет работать, полностью зависит от вас, то есть если вы проверяли возвращаемые значения на null или были готовы к нулю вместо вменяемого значения, то ничего страшного не произойдет: приложение просто не будет полноценно функционировать (что выглядит все же лучше чем падение из-за NullPointerException).

Но даже если у вас все хорошо с проверками и нет возможности заниматься внедрением новых возможностей, стоит перепроверить, все ли правильно работает, потому что иногда можно получить null не там, где его ожидаешь. Так, например, при использовании Environment.getExternalStorageDirectory() без наличия разрешения из группы Storage, мы получим File, но list() вернет нам заветный null. В документации такой исход описан, но для ситуации, когда File не является директорией. Так что проверка в любом случае лишней не будет.

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

В процессе отладки часто приходится включать/отключать разрешения. Заходить для этого каждый раз в настройки приложения не очень удобно. К счастью, это можно сделать с помощью adb:

И еще несколько полезных команд, смысл которых ясен из названия:

Перейдем к непосредственной реализации (предварительно не забудем обновить compileSdkVersion и targetSdkVersion до версии 23).

До момента, когда Marshmallow станет минимальной версией андроида для ваших приложений, еще далеко, поэтому нужно позаботиться об обратной совместимости. Конечно, можно делать проверки версии sdk, но зачем, если все реализовано за нас в support library v4 (ActivityCompat) и v13 (FragmentCompat). Если все же вам понадобятся оригинальные методы, то найти их не составит труда.

Во всех примерах используется ActivityCompat, так как они были сделаны для activity. Для fragment нужно использовать FragmentCompat. Если вы по какой-то причине не используете activity и fragment из support библиотек, то вам нужно реализовать интерфейс ActivityCompat.OnRequestPermissionsResultCallback или FragmentCompat.OnRequestPermissionsResultCallback соответственно.

Каждый раз, когда мы хотим использовать метод, требующий опасного разрешения, необходимо проверить есть ли оно у нас. Для этого используем метод ContextCompat.checkSelfPermission(Context context, String permission), который возвращает нам одно из int значений: PackageManager.PERMISSION_GRANTED в случае если разрешение есть или PackageManager.PERMISSION_DENIED если его нет. Именем разрешения является одна из констант класса Manifest.permission.

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

Стоит упомянуть, что если разрешения находятся в одной permission group, то запросить достаточно одно из них, так как все остальные элементы этой группы станут также доступны. Но так делать не нужно. Потому что в будущем состав групп может поменяться, поэтому при запросе разрешений не нужно делать предположений относительно того находятся ли они в одной группе или нет.

UPD будто в подтверждение предыдущего параграфа, начиная с Android 8.0 разрешения из одной permission group не выдаются сразу — каждое разрешение нужно запрашивать отдельно, но все разрешения из одной группы будут выданы автоматически, без участия пользователя при первом же их запросе.

UPD2 это же поведение было замечено на Android 7.0 — если часть разрешений из группы выдана (не могу сказать с уверенностью, имеет ли значение какие именно), то остальные будут выдаваться по запросу сразу же без показа диалога. Это может вызвать проблемы, если ваше приложение объясняет пользователю зачем ей нужно то или иное разрешение еще до его запроса. В реальной жизни такое редко когда может возникнуть (только при использовании adb комманд), но стоит учитывать это при отладке приложения.

Для запроса используется метод ActivityCompat.requestPermissions(Activity activity, String[] permissions, int requestCode). Массив permissions соответственно содержит названия разрешений, которые вы хотите запросить. Отсюда видно, что одновременно можно запрашивать несколько разрешений. requestCode — значение, по которому в дальнейшем можно будет определить, на какой запрос разрешения вам пришел ответ подобно тому как мы получаем результат от activity, используя startActivityForResult. Кстати, если посмотреть на код requestPermission, то обнаружится, что это всего лишь особая версия startActivityForResult.

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

Результат запроса разрешения следует обрабатывать в onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults). Параметры requestCode и permissions содержат данные, которые вы передавали при запросе разрешений. Основные данные здесь несет массив grantResults, в котором находится информация о том, получены разрешения или нет. Каждому i-му элементу permissions соответствует i-ый элемент из grantResults. Их возможные значения аналогичны результату checkSelfPermission.

Размер массива grantResults проверяется для того, чтобы удостовериться, что запрос разрешения не был прерван (в этом случае permissions и grantResults не будут содержать элементов). Такую ситуацию следует рассматривать не как запрет разрешения, а как отмену запроса на него.

Если вы ранее уже запрашивали разрешение, но пользователь отказался предоставить его, необходимо объяснить ему причину запроса. Этого не нужно делать, если причина, по которой вы запрашиваете разрешение, абсолютно ясна. Если же есть вероятность, что вопрос “А зачем приложению это нужно?” возникнет, то объяснить это крайне желательно. Для того чтобы узнать, нужно ли показывать объяснение есть метод shouldShowRequestPermissionRationale(@NonNull Activity activity, @NonNull String permission), который возвращает boolean. Само же объяснение можно реализовать, например, с помощью Snackbar с кнопкой действия, по клику на которой происходит запрос разрешения, или диалогового окна, если разрешение критично необходимо.

Never ask again

Одной из проблем может стать опция “Never ask again”, которая появляется при повторном запросе разрешения, после того как пользователь уже отказал ранее. Как видно из названия, при её выборе диалог запроса не будет больше появляться. shouldShowRequestPermissionRationale будет выдавать false, а в onRequestPermissionsResult будет получен результат PackageManager.PERMISSION_DENIED. И получим разрешение мы, только если включить его непосредственно через настройки приложения в разделе Permissions.

Что с этим можно сделать? В первую очередь, конечно, сообщить пользователю, что для выполнения действия нет нужных прав. Далее возможным действием может быть предложение перейти в настройки и предоставить это разрешение вручную. Не лучший вариант, но лучше чем ничего. Реализовать это можно вновь с использованием Snackbar с кнопкой действия.

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

В примере используются startActivityForResult и onActivityResult чтобы определить, что пользователь вернулся из activity настроек обратно в приложение и попробовать выполнить действие, которое нельзя было сделать без нужного разрешения. В методе showExtDirFilesCount нужно снова проверить есть ли разрешение для уверенности, что пользователь его все-таки выдал.

Здесь может возникнуть ситуация, которая не особенно мешает, если вы используете Snackbar для показа rationale, но портит UX, если вы решили использовать диалоги (причины этого решения мы не затрагиваем). А именно двойное появление rationale, до запроса разрешения и после него. Как это может произойти? У нас всего два метода, по которым мы можем судить о состоянии разрешения. Проблема в том, что до запроса разрешения ситуация, когда мы еще никогда не запрашивали это разрешение, и ситуация, когда пользователь ранее выбрал “Never ask again”, абсолютно одинаковы по значениям. А именно checkSeflPermission возвращает нам PERMISSION_DENIED, a shouldShowRequestPermissionRationale — false. Значит, показывать диалог для открытия настроек мы будем в onRequestPermissionsResult, где значение shouldShowRequestPermissionRationale точно будет разным для этих двух ситуаций. Все отлично? Не совсем. В этом callback’e никак нельзя определить была ли показана rationale или нет. Поэтому если вы показываете причину запроса, а далее пользователь просит больше его не спрашивать об этом разрешении, после нажатия на кнопку DENY он получит очередной rationale диалог, приглашающий его в настройки программы. Хорошие программы так себя не ведут.

Что делать в такой ситуации? В сети есть пара не очень красивых решений: одно из них — сохранять в SharedPreferences информацию о том имеется ли разрешение или нет, другое — хранить флаг о том была показана rationale или нет внутри класса. Первое решение не хорошо тем, что пока приложение не работает, пользователь может изменить настройки разрешений и информация в preferences будет неактуальной. Второй же способ не особо красивый.

Хорошим вариантом (на мой взгляд) будет завести два requestCode для каждого запроса, один для использования в rationale другой в остальных случаях. Этот способ так же не идеален и не особенно красив, но помогает придерживаться существующих методов, не внося ничего нового.

Intent

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

В качестве самого показательного примера чаще всего вспоминают камеру. Используйте стандартное приложение камеры (или другие приложения, умеющие это делать), если вам нужно всего лишь сделать фотографию без какой-то особой логики. В этом вам помогут Intent’ы (подробнее).

Таким образом, вы сможете избавиться от некоторых опасных разрешений и упростите работу с приложением.

Источник