Что такое App Permissions на Android и как его удалить

Как отключить разрешения

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

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

Откройте приложение «Настройки».
Коснитесь «Приложения» или «Диспетчер приложений» (хотя этот параметр может отличаться в зависимости от смартфона).
Оказавшись внутри, коснитесь «Настройки»> «Разрешения приложений» (если вы не можете найти эту опцию, возможно, вам придется нажать «Конфиденциальность и безопасность»> «Разрешения приложений».
Наконец, теперь вы можете коснуться любого разрешения. И вам нужно будет только активировать или деактивировать указанное разрешение. В случае появления в цвете это будет означать, что он активирован. Но если он неактивен, значит, он отключен.

Services

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

Такую функциональность нельзя реализовывать, просто запуская отдельный поток — это было бы для системы чёрным ящиком; в том числе, процесс был бы завершён при завершении всех activity, независимо от состояния таких фоновых операций. Вместо этого Android предлагает использовать ещё один вид компонентов — сервис.

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

Сервисы во многом похожи на activity: они тоже запускаются с помощью intent’ов и могут быть завершены системой при нехватке памяти.

Запущенные сервисы могут быть в трёх состояниях:

Background service — сервис, выполняющий фоновое действие, состояние которого не интересует пользователя (чаще всего, синхронизацию). Такие сервисы могут быть завершены при нехватке памяти с гораздо большей вероятностью. В старых версиях Android большое количество одновременно запущенных фоновых сервисов часто становилось причиной «тормозов»; начиная с версии 8.0 Oreo, Android серьёзно ограничивает использование фоновых сервисов, принудительно завершая их через несколько минут после того, как пользователь выходит из приложения.
Bound service — сервис, обрабатывающий входящее Binder-подключение. Такие сервисы предоставляют какую-то функциональность для других приложений или системы (например, и Google Play Services). В этом случае система может автоматически запускать сервис при подключении к нему клиентов и останавливать его при их отключении.

Рекомендуемый способ выполнять фоновые действия — использование , системного механизма планирования фоновой работы. JobScheduler позволяет приложению указать критерии запуска сервиса, такие как:

Доступность сети. Здесь приложение может указать, требуется ли этому сервису наличие сетевого подключения, и если да, то возможна ли работа в роуминге или при использовании лимитного (metered) подключения.
Подключение к источнику питания, что позволяет сервисам выполняться, не «сажая батарею».
Бездействие (idle), что позволяет сервисам выполняться, пока устройство не используется, не замедляя работу во время активного использования.
Обновления контента — например, появление новой фотографии.
Период и крайний срок запуска — например, очистка кэша может производиться ежедневно, а синхронизация событий в календаре — каждый час.

JobScheduler планирует выполнение (реализованное как вызов через Binder) зарегистрированных в нём сервисов в соответствии с указанными критериями. Поскольку JobScheduler — общесистемный механизм, он учитывает при планировке критерии зарегистрированных сервисов всех установленных приложений. Например, он может запускать сервисы по очереди, а не одновременно, чтобы предотвратить резкую нагрузку на устройство во время использования, и планировать периодическое выполнение нескольких сервисов небольшими группами (batch), чтобы предотвратить постоянное энергозатратное включение-выключение радиооборудования.

Workflow for requesting permissions

Before you declare and request runtime permissions in your app, evaluate
whether your app needs to do so. You can
fulfill many use cases in your app, such as taking photos, pausing media
playback, and displaying relevant ads, without needing to declare any
permissions.

If you conclude that your app needs to declare and request runtime permissions,
complete these steps:

In your app’s manifest file, declare the
permissions that your app might need to
request.
Design your app’s UX so that specific actions in your app are associated with
specific runtime permissions. Users should know which actions might require them
to grant permission for your app to access private user data.
to invoke the task or action in your app
that requires access to specific private user data. At that time, your app can
request the runtime permission that’s required for accessing that data.
that your app requires. If so, your app can access
the private user data. If not, continue to the next step.
You must check whether you have that permission every time you perform an
operation that requires that permission.
to the user,
explaining why your app needs the user to grant a particular runtime permission.
If the system determines that your app shouldn’t show a rationale, continue to
the next step directly, without showing a UI element.
If the system determines that your app should show a rationale, however,
present the rationale to the user in a UI element. This rationale should
clearly explain what data your app is trying to access, and what benefits
the app can provide to the user if they grant the runtime permission. After
the user acknowledges the rationale, continue to the next step.
that your app requires
in order to access the private user data. The system displays a runtime
permission prompt, such as the one shown on the .
Check the user’s response, whether they chose to grant or deny the runtime
permission.
If the user granted the permission to your app, you can access the private
user data. If the user denied the permission instead, so that it provides functionality to the user,
even without the information that’s protected by that permission.

Figure 1 illustrates the workflow and set of decisions associated with this
process:

Figure 1. Diagram that shows the workflow for declaring and
requesting runtime permissions on Android.

Special app access controls

There is actually a second section for Android 10 permissions. Let’s get you to the proper spot and then we’ll tell you how to use the menu.

Open Settings, navigate to Apps & notifications, and tap on the Advanced option to expand the menu.
Click on the Special app access option.
Select any category to view all of the apps with that special access. Unlike the regular Android 10 permissions section, this section only shows you apps with approved permission to use that feature. Thus, lists are a lot shorter and you may have categories with no apps listed.
Select the app you want to remove permissions for.
Tick the slider to the off position to remove the permission.

Определение Binder

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

Теперь, чтобы определить интерфейс, добавьте эти строки внизу класса:

MusicBinder вложен в другой класс и может получить доступ ко всем его методам. Он также может использовать все методы Binder. Внутри него вы создаете метод для получения контекста сервиса.

Создание самого уведомления

Пришло время создать само уведомление. Добавьте в NotificationHelper.kt следующее:

Вот что происходит в этом куске кода:

Если версия Android равна 8 или выше, система создает канал уведомления и возвращает Notification. К сожалению, библиотека поддержки для версий до Android 8 не предоставляет API каналов уведомлений. Подробнее об этой проблеме читайте в официальной документации на тему .
Возвращается Notification после вызова build() в конструкторе.

Уведомление может обновляться динамически. В этом случае мы будем обновлять текст, если пользователь закроет приложение во время работы службы.

Ниже getNotification() добавьте следующее:

Вот, что здесь происходит:

Мы обновляем текст в уведомлении, отображаемом в строке состояния, через notificationBuilder.
Затем говорим диспетчер уведомлений какое уведомление нужно обновить. Для этого мы используем уникальный NOTIFICATION_ID.

Наконец, давайте определим, что происходит, когда пользователь нажимает на уведомление. Добавьте это в начало NotificationHelper.kt:

Здесь вы выполняете ленивую инициализацию PendingIntent, которая запускает MainActivity, когда пользователь нажимает на уведомление.

Прекрасная работа! Уже очень многое было реализовано. Теперь пора запустить Foreground Service.

Удаление системных приложений с помощью специальных программ

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

Примером такой «чистящей» программы может стать популярный Titanium Backup. Хотя основная функция приложения – резервное копирование программ с настройками – становится в Android встроенной, программа ещё долго не потеряет актуальности.

Достоинство Titanium Backup – возможность не удалять сомнительные приложения сразу, а «заморозить» их. Если отсутствие той или иной программы скажется на работе других программ, вы всегда сможете её «разморозить». Если нет – можно смело удалять.

Ещё одна ценная черта этой программы – умение заменять исходные файлы сторонними. К примеру, если вы вместо стандартной программы-клавиатуры или телефонной книги хотите использовать альтернативную, вы сможете с помощью Titanium Backup сделать «переназначение».

Самое главное при установке Titanium Backup – убедиться, что в разделе для установки программ достаточно памяти. Иначе вам придётся либо удалять что-то нужное, либо следовать советам из предыдущего раздела.

Android 6

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

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

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

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

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

int permissionStatus = ContextCompat.checkSelfPermission(this, Manifest.permission.READ_CONTACTS);

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

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

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

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

int permissionStatus = ContextCompat.checkSelfPermission(this, Manifest.permission.READ_CONTACTS);if (permissionStatus == PackageManager.PERMISSION_GRANTED) { readContacts();} else { ActivityCompat.requestPermissions(this, new String[] {Manifest.permission.READ_CONTACTS}, REQUEST_CODE_PERMISSION_READ_CONTACTS);}

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

Обратите внимание, что для разрешений используется массив. Т.е

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

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

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

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

@Overridepublic void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) { switch (requestCode) { case REQUEST_CODE_PERMISSION_READ_CONTACTS: if (grantResults.length > 0 && grantResults == PackageManager.PERMISSION_GRANTED) { // permission granted readContacts(); } else { // permission denied } return; }}

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

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

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

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

Удалось выяснить

По мнению одного юзера, Permission Control — контроль разрешений для приложений. Данный компонент способен вызывать глюки, лаги, нестабильную работу телефона, увеличенный расход батареи. Для отключения необходимо перейти в настройки > безопасность, найти пункт App Permission > отключить.

Опасность отключенного приложения состоит в том, что все программы получат полные разрешения. Рекомендуется перед отключением просканировать смарт на наличие вирусов/троянов. Для проверки можно использовать антивирусы Касперского, Доктора Веба.

Приложение в списке установленных:

Также может быть ошибка:

permission control произошла ошибка

Можно попробовать данное приложение заморозить при помощи Titanium Backup. Удалять не стоит — могут быть проблемы. Приложение в Титаниуме:

При использовании штатного отключения может выскочить данное сообщение:

Apps will directly get permissions without your confirmation

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

Также после отключения могут быть проблемы с Play Market (скорее всего связаны с безопасностью).

Дополнительно удалось выяснить — за запуск сторонних приложений отвечает не только Phone Cleaner (необходим для энергосбережения), но и плагин Permission Control.

Если Permission Control заморозить Титаниумом тогда автостарт в настройках станет неактивным.

По непроверенной информации Permission Control это тоже самое что и Privacy Protect.

Чтобы приложение пермиссион вас больше не доставало, можно поставить галочку Больше не уведомлять.

Какие программы можно удалить с андроида, а какие удалять или отключать через Root небезопасно

Ненужные приложения на андроиде, список которых можно удалить без последствий:

все продукты Гугл вроде карт, браузера, иконок музыки, фильмов и фото, почтовый ящик, приложение оплаты и проч.;
аналогичные программы от «Самсунг»;
голосовые помощники;
облачные хранилища.

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

Далее представлены программы, которые вызывают сомнения у пользователей — удалять или нет:

Workspace. Одной из самых загадочных считают Workspace, что это за программа на андроид зависит от модели телефона. Оно либо выполняет функцию соединения некоторых программ с облачными сервисами, либо позволяет использовать гаджет в качестве ПУ. Удалять можно;
Perfdump. Второй по распространенности запрос — что это за программа на андроиде Perfdump. Утилита служит для отправления отчетов о работе системы производителю. Удалять можно, но лучше оставить;
Themes. Многих также интересует, что будет, если удалить темы оформления со смартфона. Логично, что придется устанавливать свои изображения. Можно удалить, но справедливости ради много места они не занимают и на работу ПО никак не влияют;
RCPcomponents. Приложение относится к протоколам безопасности KNOX, то есть оно системное. Встречается только на устройствах самсунг и его дочерних брендах. Удалять не рекомендуется;
Sts. Удаление данной утилиты будет крайне полезным. Она отвечает за то, чтобы рекламные баннеры Гугл алгоритм мог встроить в интерфейс мультимедиа;
PageBuddyNotiSvc. Пользователи долго не могли найти ответ на вопрос, что это PageBuddyNotiSvc в Android. Оказалось, что это строка с рекомендуемыми программами. Удалять можно;
AWAD. Программа для покупки авиабилетов. Удалять можно. Те, кто держит приложение на своем гаджете, могут рассчитывать на более выгодные цены;
com.android.providers.media. На вопрос что это — com android providers media Гугл дает однозначный ответ. Это системное приложение, отвечающее за построение списка приложений в профильных меню. Удалять нельзя;
Vpndialogs. Как понятно из первых трех букв, приложение отвечает за шифрование IP-протокола при подключении к Сети. Если анонимность в Сети не в приоритете, удалить можно;
Vcalendar. Календарь. Удаление на работу системы не повлияет;
Proxyhandler. Удаление повлияет на скорость поискового трафика. Деинсталляция не рекомендована;
Config updater. Файл отвечает за поступление на устройство обновлений. Удалять не рекомендуется;
Android Core Apps. Периодически утилита грузит центральный процессор. Отвечает за оптимизацию приложений. Удалять не рекомендуется;
Badgeprovider Android. Программа отвечает за функционирование почтовых и СМС сервисов. Удалять нельзя.

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

Как удалить вирус из Android

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

Однако, такой способ эффективнее не более чем в 30-40% случаев, ведь многие вирусы «сопротивляются» процедуре удаления.

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

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

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

зажмите кнопку включения/выключения смартфона и выберите «Отключить питание»;
держите зажатой кнопку до тех пор, пока не появится сообщение о переходе в безопасный режим;
подтвердите операцию;
просканируйте устройство с помощью антивируса;
при наличии прав суперпользователя можно запустить файловый менеджер и очистить системные папки от зловредного ПО;
когда все готово, перезагрузите смартфон и он будет работать уже в нормальном режиме и без вирусов.

В третьем случае вам придётся удалить вирус через компьютер. Для этого нужно подключить смартфон к компьютеру через USB-кабель и выбрать режим накопителя. После этого запустить проверку на вирусы через контекстное меню для обоих дисков: внутренней памяти телефона и SD-карты.

Как удалить не нужные предустановленные приложения?

Удаление стандартных программ без root прав, то есть вручную, осуществляется обычным способом. Выбираем «настройки», далее «приложения». Активируем требуемое, и нажимаем удалить.

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

Используем ES проводник.

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

После запуска проводника, перелистываем вправо либо нажимаем вверху окна, в зависимости от версии, для открытия меню. В нём необходимо найти и активировать «Root проводник», для получения прав на удаление предустановленных программ. Обычно он находится в разделе «средства».

Теперь возможно переходить к самой процедуре удаления. В системе Android предустановленные приложения находятся на внутренней памяти в папке «system/app». Выделяем касанием, требуемый файл и нажимаем удалить.

Более быстрый способ, это деинсталлировать файлы из раздела меню «системные». Он находится в начальном меню, закладка «APPS».

Используем СCleaner.

Инструкцию по установке и работе c CCleaner на Android мы уже публиковали. Для удаления предустановленных программ, запустите cleaner и войдите в главное меню. Нас интересует вкладка «системные». Выбираем её.

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

Удаляем предустановленные программы с помощью titanium backup.

В данном видео предлагаем вам наглядную инструкцию ещё одного способа удаления системных приложений на android.

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

Рождение проблемы

Проблема родилась сразу после Нового Года, когда я с сыном проверял возможности нового смартфона и качал на него разный хлам отовсюду. Первый признак болезни проявился в отказе обновляться по OTA, так как были изменены вирусами системные файлы. Болезнь девайса прогрессировала – при подключении к интернету стали загружаться сами по себе левые приложения, типа AliExpress, процессор от натуги стал перегреваться, а телефон зависать.

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

Типы разрешений для приложений в Android

Сами разрешения бывают двух типов, normal и dangerous. «Обычные» разрешения «безвредны» для пользователя, в то время как «опасные» могут получать доступ к личным данным и приватной информации человека. К dangerous разрешениям относятся, например, доступ к камере, смскам и файлам на телефоне.

Dangerous Permissions в Андроид

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

Разрешения до Android 6.0 Marshmallow

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

Android Install time permissions

Мы же с вами прекрасно знаем как часто люди вообще читают что их просят… Особенно если они и так хотят получить то, за чем пришли. По этому, начиная с Android 6.0 Google ввел контекстные, точечные разрешения.

Получение разрешений начиная с Android 6.0

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

Android runtime permissions

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

Сложно представить, например, приложение — камеру без доступа к камере.

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

Как уже обсудили, Google постоянно улучшает защиту приватности пользователей. Так в Android 11 запрос разрешений получил еще ряд изменений.

One-time permissions

Местоположение, камера и микрофон — самые опасные разрешения, так как содержат крайне конфиденциальные данные. Именно по этому, начиная с Android 11 вводятся one-time permissions. Если пользователь согласился на использование своих данных, то вы можете сделать это единожды. В следующий раз придется снова спрашивать.

Автоматический сброс разрешений

Если ваше приложение не используется в течение нескольких месяцев, то система может сбросить критичные для приватности разрешения. Придется их получать заново. Хорошая новость в том, что если вы и так используете best practices для получения runtime permissions, то для вас ничего особо поменяться не должно.

Запрет доступа по умолчанию

Обычно, когда мы спрашиваем пользователя разрешения у него есть 2 опции — принять и отклонить. Если получили отказ, то мы можем снова запросить доступ. В таких случаях появляется опция «отвали, больше не спрашивать». Начиная с Android 11, если пользователь несколько раз запретил доступ — это автоматически считается как выбор опции «больше не спрашивать».

Я согласен с гуглом. Приватность и безопасность пользователя должна быть на первом месте. А вы что думаете? Для нас это конечно подкидывает больше работы

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

УРОВЕНЬ ДОСТУПА PRIVILEGED

Privileged не самый высокий уровень доступа и позволяет использовать далеко не весь API Android. Однако в большинстве случаев он оказывается вполне достаточным, так как позволяет устанавливать и удалять приложения и пользователей (INSTALL_PACKAGES, DELETE_PACKAGES, MANAGE_USERS), управлять статусной строкой (STATUS_BAR), управлять некоторыми настройками питания (WRITE_SECURE_SETTINGS), читать и изменять настройки Wi-Fi (READ_WIFI_ CREDENTIAL, OVERRIDE_WIFI_CONFIG), отключать приложения и их компоненты (CHANGE_COMPONENT_ENABLED_STATE) и многое другое.

Чтобы приложение получило уровень доступа privileged, оно должно быть установлено в каталог /system/priv-app, а это значит — поставляться предустановленным в составе прошивки. Однако, имея root, мы можем поместить свое приложение в данный каталог с помощью двух функций:

Функцию runCommandWait я описывать не буду, она просто выполняет shell-команду и ждет ее завершения. Функция makeAppSystem, в свою очередь, принимает полное имя приложения (это то самое com.example.app, которое ты указываешь при создании нового проекта в Android Studio) и переносит его в /system/priv-app или /system/app, в зависимости от используемой версии Android.

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

до Android 4.4 (API Level: 20) каталога /system/priv-app не существовало и все системные приложения размещались в /system/app;
начиная с Android 5.0 (API Level: 21) пакеты с приложениями не просто складируются в /data/app и /system/priv-app, а размещаются внутри своих обособленных подкаталогов.

Как использовать этот код?

Очень просто: ты определяешь в Manifest.xml своего приложения все privileged-полномочия, которые ему нужны, не обращая внимания на ошибки IDE. Затем в самое начало кода приложения вставляешь вызов makeAppSystem с именем самого приложения в качестве аргумента, компилируешь и запускаешь. После запуска приложение перемещает само себя в /system/priv-app, перезагружает смартфон, и ему открываются все privileged API.

Список privileged-полномочий можно посмотреть в исходниках Android. Просто ищи по слову privileged. О том, как их использовать, — чуть позже.

УРОВЕНЬ ДОСТУПА DEVELOPMENT

В Android есть специальный уровень доступа development, отличие которого заключается в том, что приложения получают его не по факту размещения в /system/priv-app или использования цифровой подписи прошивки, а динамически. То есть система может дать такой уровень доступа любому приложению, а может и отозвать обратно

Но самое важное, что, имея права root, приложение может наделить себя таким уровнем доступа самостоятельно.
Чтобы это сделать, достаточно использовать примерно такой код:
В данном случае приложение appName получит полномочие WRITE_SECURE_ SETTINGS вне зависимости от того, где оно размещено и каким ключом подписано. Круто? Вне сомнения, однако WRITE_SECURE_SETTINGS — фактически единственное полезное полномочие с уровнем доступа development

Остальные четырнадцать — это полномочия для отладки и тестирования (чтение логов, дампы памяти и так далее).

Удаление системных приложений обычными методами

Самый простой способ удаления системных приложений – удалить их файлы. Как правило, они хранятся в основном разделе, в папке system/app. Их вспомогательные файлы могут храниться и в других папках, например:

data/data
data/dalvik-cache
system/lib

Чтобы удалять системные файлы, вам понадобится как минимум две вещи:

Рут-доступ. Как его получить – читайте подробную инструкцию на нашем сайте.
Файловый менеджер, умеющий работать с системными разделами. Традиционно рекомендуют приложение Root Explorer. Но и другие проводники ( к примеру, Total Commander или ES Проводник) тоже подходят.

Увлёкшись очищением памяти, помните: не стоит «с порога» удалять всё сомнительное. Зависимости между файлами не всегда очевидны. Впрочем, есть и исключения: если под именем ненужного приложения есть два файла с расширениями .apk и .odex, удалять всегда нужно оба.

Ни в коем случае нельзя удалять службы Google. А вот приложения (Maps, Gmail, Hangouts), если они вам не нужны, в принципе, можно и удалить.

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

App Permissions в Android – что это и как его использовать