Что делает разрешение QUERY_ALL_PACKAGES?
Android R Preview 1 представил новое разрешение под названием QUERY_ALL_PACKAGES . В документации к разрешению сказано следующее:
Разрешает запрос любого обычного приложения на устройстве, независимо от деклараций манифеста.
Кто-нибудь понял, что это на самом деле?
Я пробовал запустить на образе эмулятора следующее, и разрешение не повлияло ни на один из них:
- packageManager.queryIntentActivities(intent, 0)
- packageManager.getInstalledPackages(0)
2 ответа
Теперь, когда DP2 отсутствует, они рассмотрят это подробнее.
Пока я не тестировал пока этот аспект R DP2, похоже, ваше приложение теперь не может узнать, какие другие приложения установлены, на общих основаниях. Приведенный пример — queryIntentActivities() , но чтобы сделать это действительно работа, которая вам понадобится для серьезной лоботомии PackageManager . Вы можете добавить в белый список определенные пакеты и определенные структуры, чтобы попытаться обойтись этим в определенных случаях использования. И вот где загадочное разрешение QUERY_ALL_PACKAGES , увиденное в DP1, вступает в игру — это разрешение снимает эти новые ограничения. Учитывая «поиск в Google Play» чтобы предоставить рекомендации для приложений, которым требуется это разрешение, безопаснее всего предположить, что что, если вы попытаетесь его использовать, в конечном итоге вы будете забанены в Play Store из-за бот.
Итак, вы можете захотеть повторить свои эксперименты на DP2. Я планирую сделать то же самое в ближайшие недели.
Даже если добавлено разрешение QUERY_ALL_PACKAGES , вам все равно нужно добавить фильтр в свой AndroidManifest .
Например. для приложения запуска это может быть:
Источник
Android permission query all packages что это
Android R Preview 1 представил новое разрешение под названием QUERY_ALL_PACKAGES . В документации к разрешению сказано следующее:
Разрешает запрос любого обычного приложения на устройстве, независимо от деклараций манифеста.
Кто-нибудь понял, что это на самом деле?
Я пробовал запустить на изображении эмулятора следующее, и разрешение не повлияло ни на один из них:
- packageManager.queryIntentActivities(intent, 0)
- packageManager.getInstalledPackages(0)
Они покрывают это больше теперь, когда DP2 отсутствует.
Хотя я еще не тестировал этот аспект R DP2, похоже, что теперь ваше приложение не может узнать, какие еще приложения установлены, в целом. Приведенный пример queryIntentActivities() , но чтобы это действительно сработало, вам придется серьезно провести лоботомию PackageManager . Вы можете занести в белый список определенные пакеты и определенные структуры, чтобы попытаться обойтись этим в определенных случаях использования. И вот где загадочный QUERY_ALL_PACKAGES разрешение, видимое в DP1, вступает в игру — это разрешение снимает эти новые ограничения. Учитывая предостережение «ищите Google Play, чтобы предоставить рекомендации для приложений, которым требуется это разрешение», безопаснее всего предположить, что если вы попытаетесь его использовать, в конечном итоге вы будете забанены ботом в Play Store.
Итак, вы можете захотеть повторить свои эксперименты на DP2. Я планирую сделать то же самое в ближайшие недели.
Источник
Google ограничит Android-приложениям возможность видеть, какое ПО установлено на устройстве
Разработчики Android-приложений больше не смогут загружать в Google Play Store новые приложения с функцией QUERY_ALL_PACKAGES.
Компания Google объявила о намерении ограничить возможность Android-приложений видеть, какие еще приложения установлены на устройстве. Данный шаг призван усилить приватность и безопасность пользователей.
Обновление вступит в силу 5 мая 2021 года. Начиная с этой даты, разработчики Android-приложений больше не смогут загружать в Google Play Store новые приложения для Android 11 (уровень API 30) или более поздних версий, в которых присутствует функция QUERY_ALL_PACKAGES. Эта функция будет считаться «представляющей высокий риск или запрашивающей чувствительные разрешения», и использовать ее смогут только избранные приложения. Как сообщает Google, использовать функцию будет разрешено только приложениям для сканирования операций на устройстве, антивирусному ПО, браузерам и файловым менеджерам.
Решение ограничить приложения, которым будет разрешено использовать QUERY_ALL_PACKAGES, принималось очень долго. Даже если в Android-приложениях нет вредоносного кода, жадные до рекламы разработчики часто злоупотребляют разрешением видеть, какие приложения пользователи установили на свои устройства, и продают эту информацию рекламодателям, которые позже используют ее для показа таргетированной рекламы.
На презентации в рамках конференции MOBILEsoft 2020 группа исследователей сообщила, что из 14 300 исследованных ими Android-приложений более 4000 злоупотребляли различными API Android (так называемыми IAM) для получения списка локально установленных приложений. В то время функция QUERY_ALL_PACKAGES была выпущена как ответ на это злоупотребление, и в настоящее время Google ужесточает привязку к этому разрешению.
Источник
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. Далее, выбрав нужное разрешение, можно увидеть все приложения, которым оно нужно.
Второй момент заключается в том, насколько ясно будет человеку, для чего нужно это разрешение. Зачем приложению для смс доступ к календарю? Наверное, для какой-то классной функции, которая облегчит перенос дат из сообщений в календарь и тому подобное. Но знаете об этом только вы, поэтому сначала нужно объяснить причину запроса и показать какие возможности даст доступ к этому разрешению. Это относится и к первичным и к вторичным разрешениям.
|
|
Еще раз кратко:
- важные разрешения запрашиваем при запуске, вторичные — при первом использовании соответствующей функции;
- если понять, зачем нужно разрешение тяжело, предоставляем объяснение.
В случае, когда вам все-таки отказали, пояснение причины в следующий раз является обязательным. А если помимо отказа, пользователь попросил вас никогда не запрашивать данное разрешение, используя опцию “Never ask again”, но пытается использовать соответствующую функцию приложения, предложите ему перейти в настройки вашей программы и вручную включить необходимые разрешения. Это особенно важно, если разрешение критично для работы программы.
