Android obb permission denied

03.jpg (240.03 KB, Downloads: 7)

2021-02-10 00:53:15 Upload

04.jpg (193.23 KB, Downloads: 9)

2021-02-10 00:53:15 Upload

05.jpg (273.45 KB, Downloads: 9)

2021-02-10 00:53:15 Upload

Все готово. Можем спокойной записывать, копировать, создавать файлы и папки.

06.jpg (181.42 KB, Downloads: 8)

2021-02-10 00:53:15 Upload

Надеюсь будет полезно тем, кто столкнулся с такой проблемой!

Источник

Как установить кэш в /obb и /data на Android 11 без Root

В новой версии Android Google не только внедрила новые полезные фичи, но и внесла некоторые изменения в файловую систему. Если быть точным, «корпорация добра» запретила сторонним приложениям выполнять действия с папками /Android/obb и /Android/data — файловые менеджеры выдают ошибку: «Не удалось создать папку… Android/obb. Permission denied. Не удалось создать… Android/obb. No such file or directory. Файлы не были извлечены».

По словам команды разработчиков, они пошли на этот шаг ради безопасности. Но вместе с этим теперь нельзя устанавливать сторонние приложения, требующие кэша. После установки Android 11, я первым же делом решил изучить этот вопрос и попытался обойти ограничение. На данный момент я нашёл только один метод, не требующий Root-права, — использование adb (Android Debug Bridge). Сразу отмечу, что для этого способа обязательно наличие ПК.

Содержание

Подготовка

Для начала необходимо на смартфоне зайти в «Настройки», затем в раздел «Для разработчиков» и включить в нём «Отладку по USB». Если у вас нет пункта «Для разработчиков», сперва придётся зайти в раздел «О телефоне», найти там «Номер сборки» и тапнуть по нему несколько раз, пока не появится надпись «Вы стали разработчиком».

Следующим шагом станет скачивание adb на ПК. Для этого необходимо зайти на официальный сайт и загрузить софт для своей платформы, после чего распаковать полученный ZIP-архив в удобном месте (если у вас Windows, для упрощения рекомендую переместить извлечённую папку в корень диска C).

Как скопировать кеш в Android/obb или Android/data на Android 11

Итак, всё настроено и смартфон подключен к ПК. Если у вас Windows, первым делом нужно открыть «Командную строку» от имени администратора. Сделать это можно, набрав в поиске системы «cmd» и выбрав соответствующий пункт.

Далее необходимо прописать следующую команду: cd . Например, если, как я советовал выше, папка находится в корне диска C, команда будет выглядеть следующим образом: cd C:/platform-tools. Как только вы окажетесь в нужной директории, можно прописать команду adb devices. Если всё сделано верно, в консоли отобразится подключённое устройство. В случае, если появится надпись unauthorized, необходимо со смартфона подтвердить вход в режим отладки на данном компьютере (скорее всего, это окно появится сразу же, как смартфон будет подключен к ПК).

Для владельцев компьютеров на macOS действия почти аналогичные. После загрузки и распаковки инструментов, необходимо открыть терминал, перейти в директорию с файлами (по дефолту это будет папка Downloads) командой cd и прописать ./adb devices. По сути, отличие от Windows лишь в том, что каждый раз вместо adb надо писать ./adb.

Переходим непосредственно к загрузке файлов. Команда, которая для этого потребуется, строится по следующему шаблону: adb push . Для владельцев macOS-устройств всё то же самое, но с ./ в самом начале команды. Важное замечание касательно второго пути (на смартфоне): он выглядит как sdcard/android/obb или sdcard/android/data.

Примечательно, что adb не умеет отправлять на устройство целые папки, поэтому для этого придётся заранее создать папку, и уже в неё кидать файл(ы). Создаётся папка командой: adb shell mkdir .

В качестве примера я рассмотрю процесс переноса кэша для игры GRIS. Изначально он поставляется в папке com.devolver.grispaid, поэтому сначала я создам директорию на смартфоне командой adb shell mkdir sdcard/android/obb/com.devolver.grispaid.

Создав папку, я использую команду, о которой я рассказывал ранее: adb push C:/com.devolver.grispaid/main.25.com.devolver.grispaid.obb sdcard/android/obb/com.devolver.grispaid

Как удалить кеш из Android/obb или Android/data на Android 11

Для удаления файлов необходимо прописать следующую команду: adb shell rm -f . Если же необходимо удалить директорию со всем содержимым внутри, пригодится следующая команда: adb shell rm -rf .

Вывод

Google, несомненно, усложнила доступ к папкам data и obb, но всё же работать с этими директориями можно, пускай и с помощью дополнительных инструментов. Если вы знаете другие методы обхода данных ограничений в Android 11, делитесь ими в комментариях.

Источник

Как обойти ограничения Android 11?

В одиннадцатой итерации операционной системы от компании Google, предназначенной для смартфонов и планшетов, ставка делалась на безопасность пользовательских данных и стабильность в работе. Как обойти ограничения Android 11? Надобность в этом возникает для установки софта и мобильных игр из сторонних источников.

Действительно, речь идёт о директории Android-data и Android-obb. В последней зачастую располагается кэш ПО, выкачиваемый отдельно при первом запуске клиента. Если вы пользуетесь отличными от Play Market ресурсами, придётся как-то разблокировать скрытые папки. Простая попытка зайти через «Проводник» успехом не увенчается, как и распаковка ZIP-файла с кэшем по указанному пути.

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

Как убрать ограничения Android 11 на obb папку?

Просто установите из официального магазина приложений любой сторонний файловый менеджер. Например, всенародный Total Commander. Фича работает в Xiaomi с MIUI 12, да и на других смартфонах должна поддерживаться.

После этого стандартным способом пройдите в Android-obb и вставьте кэш с интересующей вас видеоигрой. Или иной контент, перемещаемый в ранее сокрытую папочку.

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

Источник

Android permissions

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

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

Полный список существующих разрешений можно посмотреть здесь. Характеристика Protection level подскажет насколько опасно это разрешение. А здесь можно сразу просмотреть весь список normal разрешений.

Если приложению необходимо получить какое-либо разрешение, то оно должно быть указано в AndroidManifest.xml, в корневом теге . Тег разрешения — .

Вот пример манифеста с разрешениями:

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

В этом материале мы подробно рассмотрим, как происходит это подтверждение.

До Android 6

До выхода Android 6 все было просто и легко. Когда пользователь устанавливал приложение с манифестом, который мы рассмотрели чуть выше, то он видел такой экран:

Система показывает разрешения, которые были прописаны в манифесте. Сначала те, которые могут быть опасными с точки зрения приватности (отправка смс, доступ к камере/местоположению/контактам), а затем — обычные (интернет, bluetooth).

Таким образом пользователь видит, на что претендует приложение, и может примерно понять все ли в порядке. Если, например, приложение калькулятор при установке просит у вас доступ к контактам и смс, то скорее всего, что-то не так с этим приложением и оно может быть опасным для ваших данных.

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

Если же в манифесте не указать разрешение READ_CONTACTS, то его не будет и в списке тех разрешений, которые подтверждает пользователь. Соответственно, система не предоставит этому приложению доступ к контактам. И при попытке получить список контактов, будет ошибка:
java.lang.SecurityException: Permission Denial: opening provider com.android.providers.contacts.ContactsProvider2

Android 6

С выходом Android 6 механизм подтверждения поменялся. Теперь при установке приложения пользователь больше не видит списка запрашиваемых разрешений. Приложение автоматически получает все требуемые normal разрешения, а dangerous разрешения необходимо будет программно запрашивать в процессе работы приложения.

Т.е. теперь недостаточно просто указать в манифесте, что вам нужен, например, доступ к контактам. Когда вы в коде попытаетесь запросить список контактов, то получите ошибку SecurityException: Permission Denial. Потому что вы явно не запрашивали это разрешение, и пользователь его не подтверждал.

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

Давайте посмотрим, как это выглядит на практике.

Проверка текущего статуса разрешения выполняется методом checkSelfPermission

На вход метод требует Context и название разрешения. Он вернет константу PackageManager.PERMISSION_GRANTED (если разрешение есть) или PackageManager.PERMISSION_DENIED (если разрешения нет).

Если разрешение есть, значит мы ранее его уже запрашивали, и пользователь подтвердил его. Можем получать список контактов, система даст нам доступ.

Если разрешения нет, то нам надо его запросить. Это выполняется методом requestPermissions. Схема его работы похожа на метод startActivityForResult. Мы вызываем метод, передаем ему данные и request code, а ответ потом получаем в определенном onResult методе.

Добавим запрос разрешения к уже имеющейся проверке.

Проверяем разрешение READ_CONTACTS. Если оно есть, то читаем контакты. Иначе запрашиваем разрешение READ_CONTACTS методом requestPermissions. На вход метод требует Activity, список требуемых разрешений, и request code. Обратите внимание, что для разрешений используется массив. Т.е. вы можете запросить сразу несколько разрешений.

После вызова метода requestPermissions система покажет следующий диалог

Здесь будет отображено разрешение, которое мы запросили методом requestPermissions. Пользователь может либо подтвердить его (ALLOW), либо отказать (DENY). Если будет запрошено сразу несколько разрешений, то на каждое из них будет показан отдельный диалог. И пользователь может какие-то разрешения подтвердить, а какие-то нет.

Решение пользователя мы получим в методе onRequestPermissionsResult

Проверяем, что requestСode тот же, что мы указывали в requestPermissions. В массиве permissions придут название разрешений, которые мы запрашивали. В массиве grantResults придут ответы пользователя на запросы разрешений.

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

В итоге схема получения разрешения состоит из трех действий:
— проверка текущего состояния разрешения
— запрос на получение разрешения, если оно еще не было получено
— обработка ответа на запрос

Далее поговорим про некоторые дополнительные возможности, нюансы и прочие мелочи.

Манифест

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

Всегда проверяйте разрешение

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

Don’t ask again

Когда вы первый раз делаете запрос на какое-либо разрешение, пользователь может отказать. При последующих запросах этого же разрешения, в диалоге появится чекбокс Don’t ask again

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

Объяснение для пользователя

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

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

Есть метод shouldShowRequestPermissionRationale, который может быть полезен в данной ситуации. Передаете ему название разрешения, а он вам в виде boolean ответит, надо ли показывать объяснение для пользователя.

Т.е. вы сначала проверяете наличие разрешения. Если его нет, то вызываете shouldShowRequestPermissionRationale, чтобы решить, надо ли показывать объяснение пользователю. Если не надо, то делаете запрос разрешения. А если надо, то показываете ваш диалог с объяснением, а после этого диалога делаете запрос разрешения.

Алгоритм работы метода shouldShowRequestPermissionRationale прост.

Если вы еще ни разу не запрашивали это разрешение, то он вернет false. Т.е. перед первым запросом разрешения ничего объяснять не надо.

Если вы ранее уже запрашивали это разрешение и пользователь отказал, то метод вернет true. Т.е. пользователь не понимает, почему он должен давать это разрешение, и надо ему это объяснить.

Если пользователь ставил галку Don’t ask again, то метод вернет false. Запрос полномочий все равно не будет выполнен. Объяснять что-то не имеет смысла.

Разумеется, вы можете показывать дополнительную информацию согласно вашим правилам и не использовать метод shouldShowRequestPermissionRationale.

Группы

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

Например, разрешения READ_CONTACTS и WRITE_CONTACTS принадлежат группе CONTACTS. И если пользователь уже подтверждал разрешение на READ_CONTACTS, то при проверке WRITE_CONTACTS вы получите PERMISSION_GRANTED.

Android 6 и targetSdkVersion 23

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

Новая схема будет работать, если версия Android >= 6 И targetSdkVersion >= 23.

В остальных случаях, т.е. когда targetSdkVersion

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник

Вам также может понравиться

Как деактивировать режим наушников на смартфоне с Android?

Когда к мобильному устройству присоединены наушники

Обзор игры Джелли-Джу для Android

В последние годы популярность мобильных игр резко возросла

Лучшие шахматные приложения для iOS и Android

Нынешний читерский скандал в шахматном мире сейчас

Что хотят увидеть пользователи от Android 5.0 Key Lime Pie

ОС Google Android развивается, и по всему видимому