Что такое android permission query

Permissions: query() method

The Permissions.query() method of the Permissions interface returns the state of a user permission on the global scope.

Syntax

query(permissionDescriptor) 

Parameters

An object that sets options for the query operation consisting of a comma-separated list of name-value pairs. The available options are:

The name of the API whose permissions you want to query. Each browser supports a different set of values. You’ll find Firefox values there, Chromium values there, and WebKit values there.

(Push only, not supported in Firefox — see the Browser Support section below) Indicates whether you want to show a notification for every message or be able to send silent push notifications. The default is false .

Indicates whether you need and/or receive system exclusive messages. The default is false .

Note: As of Firefox 44, the permissions for Notifications and Push have been merged. If permission is granted (e.g. by the user, in the relevant permissions dialog), navigator.permissions.query() will return true for both notifications and push .

Note: The persistent-storage permission allows an origin to use a persistent box (i.e., persistent storage) for its storage, as per the Storage API.

Return value

A Promise that resolves to a PermissionStatus object.

Exceptions

Exception	Explanation
TypeError	Retrieving the PermissionDescriptor information failed in some way, or the permission doesn’t exist or is currently unsupported (e.g. midi , or push with userVisibleOnly ).

Examples

.permissions.query( name: "geolocation" >).then((result) =>  if (result.state === "granted")  showLocalNewsWithGeolocation(); > else if (result.state === "prompt")  showButtonToEnableLocalNews(); > // Don't do anything if the permission was denied. >); 

Specifications

Specification
Permissions # dom-permissions-query

Browser compatibility

BCD tables only load in the browser

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

This page was last modified on Apr 7, 2023 by MDN contributors.

Your blueprint for a better internet.

What does QUERY_ALL_PACKAGES permission do?

Android R Preview 1 introduced a new permission called QUERY_ALL_PACKAGES . The documentation for the permission says the following:

Allows query of any normal app on the device, regardless of manifest declarations.

• packageManager.queryIntentActivities(intent, 0)
• packageManager.getInstalledPackages(0)

asked Mar 14, 2020 at 4:19
41k 37 37 gold badges 180 180 silver badges 220 220 bronze badges

can you please elabroate wheere you have put this Query and this of ACTION_CAPTURE, DO you have idea for SENDTO, SEND TO MULTIPLE?

Jan 12, 2021 at 5:47
Yes, it really does not work, I’m also having problems with that.
May 25, 2022 at 5:44

4 Answers 4

Even when permission QUERY_ALL_PACKAGES is added, you still need to add filter to your AndroidManifest .

E.g. for the launcher app it might be:

answered Mar 8, 2021 at 7:52
905 1 1 gold badge 8 8 silver badges 9 9 bronze badges
Docs about intent filters developer.android.com/training/basics/intents/…
Mar 8, 2021 at 7:58

Thanks, this is easier to follow than the accepted answer. If you add more detail about what the permission does and what you need to put in the element, then I’ll make this the accepted answer.

Mar 8, 2021 at 9:28

We only need to query the packageName of the calling component through the Android PackageManager and not access the app itself. So for this also do we have to add the queries in the manifest? Thanks in advance.

Apr 26, 2021 at 10:52

I think you should be using instead of the way google uses android.googlesource.com/platform/packages/apps/Bluetooth/+/… means you are declaring / overriding a new permisison and may cause an installation error with DUPLCAITE_PERMISSION on devices lower than Android11 if other apps put this same permssion. implies you are using a predefined system permission

Oct 28, 2021 at 6:31

you should use instead of , which means you are requesting that permission while the latter means you are defining the permission (as of android S, this permission is not discouraged)

Apr 15, 2022 at 10:21

They cover this more now that DP2 is out.

While I haven’t tested this aspect of R DP2 yet, it appears that your app now can’t find out what other apps are installed, on a general basis. The cited example is queryIntentActivities() , but to make this really work you would need to seriously lobotomize PackageManager . You can whitelist certain packages and certain structures to try to get by this for certain use cases. And, this is where the mysterious QUERY_ALL_PACKAGES permission seen in DP1 comes into play — this permission removes these new restrictions. Given the «look for Google Play to provide guidelines for apps that need this permission» caveat, it is safest to assume that if you try using it, eventually you will be banned from the Play Store by a bot.

So, you might want to re-try your experiments on DP2. I plan to do the same in the coming weeks.

answered Mar 19, 2020 at 23:39
CommonsWare CommonsWare
990k 191 191 gold badges 2399 2399 silver badges 2511 2511 bronze badges

Thanks! I’ve accepted this answer since it links to the official documentation, which had enough info for me to get it working. After updating to DP2, my calls to queryIntentActivities() only returned a few apps. I added the element to the manifest to declare the intents that I was passing to queryIntentActivities() , and then queryIntentActivities() started returning all the relevant apps again.

Mar 21, 2020 at 0:16

I’m curious about something. On applications that require all apps listing (such as a home launcher app, or a utility app that does stuff to other apps depending on user’s input) is adding the permission considered dangerous? Or, does this affect the call PackageManager.getInstalledApplications() ? If it does affect, what should we do to fetch installed applications without adding the permission then?

Apr 1, 2020 at 11:47

@FurkanYurdakul: They have language in the docs that suggests that requesting QUERY_ALL_PACKAGES will need to be approved (probably via a form) to be able to distribute your app on the Play Store. Launchers should have few(er) problems, as you can use the element to whitelist the ability to query for HOME / LAUNCHER activities. I have not done a complete test for what is and is not affected in PackageManager , but my guess is that getInstalledApplications() will be affected.

Apr 1, 2020 at 11:59

@Sam even I also checked on Android 11 beta, still, all packages list is coming from above APIs. Didn’t see any impact as mentioned in the android 11 change doc.

Permissions в Android: как не допустить ошибок при разработке

Всем привет! На связи Юрий Шабалин, ведущий архитектор Swordfish Security и генеральный директор Стингрей Технолоджиз. Эта статья написана в соавторстве с Android-разработчиком Веселиной Зацепиной (@VeselinaZatsepina). В материале мы поговорим про один из ключевых механизмов в Android, а именно про разрешения. Разберем, что это такое, как с ними работать, а главное, какие ошибки могут возникнуть и как их не допустить. Будет интересно, поехали!

Введение

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

Разрешения защищают доступ к:

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

А чтобы узнать, что из себя представляют разрешения на более низком уровне, в самом Android, достаточно покопаться в исходниках.

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

На этой же основе построены и разрешения. В файле frameworks/base/data/etc/platform.xml имена разрешений, которые есть в Android, сопоставлены с наименованиями групп в Linux.

Если пойти чуть глубже и посмотреть, что представляют из себя группы и как они работают внутри системы, то в файле system/core/include/private/android_filesystem_config.h можно увидеть сопоставление групп с их числовыми идентификаторами:

. #define AID_ROOT 0 /* traditional unix root user */ #define AID_SYSTEM 1000 /* system server */ #define AID_RADIO 1001 /* telephony subsystem, RIL */ #define AID_BLUETOOTH 1002 /* bluetooth subsystem */ #define AID_CAMERA 1006 /* camera devices */ . static const struct android_id_info android_ids[] = < < "root", AID_ROOT, >, < "system", AID_SYSTEM, >, < "radio", AID_RADIO, >, < "bluetooth", AID_BLUETOOTH, >, < "camera", AID_CAMERA, >, . 

И на самом деле, когда приложение запрашивает какие-то привилегии в системе, используя механизм разрешений, всё, что происходит под капотом – это добавление пользователя в определенную группу. Соответственно, когда приложение пробует воспользоваться, например камерой, на уровне системы происходит проверка присутствия клиента в нужной группе. Всё гениальное просто и отлично работает!

Общие положения Android-разрешений

Вернемся на уровень выше и рассмотрим типы разрешений:

1. Install-time permissions – предоставляются автоматически при установке приложения. Разрешения во время загрузки дают приложению неполный доступ к данным или позволяют ему выполнять ограниченные действия, которые минимально влияют на систему или другие программные продукты. Android включает в себя несколько install-time permissions: normal permissions и signature permissions, которые отличаются уровнем защиты (normal и signature);

1. Runtime permissions (dangerous permissions) – требуют, чтобы приложение запросило разрешение во время выполнения. Предоставляет продукту дополнительный доступ к данным с ограниченными правами или разрешает ему выполнять некоторые действия, которые существенно влияют на систему и другие приложения. Этим permissions система присваивает dangerous уровень защиты;

1. Special permissions – соответствуют конкретным операциям приложения. Только Android-платформа и OEM (оригинальный производитель оборудования) могут определять специальные разрешения в тех случаях, когда хотят защитить доступ к особенно мощным действиям, таким как отрисовка поверх других приложений. Этим разрешениям система присваивает appop уровень защиты. В отличие от runtime permissions, здесь пользователь должен предоставить специальные разрешения на странице «Доступ к специальному приложению» в системных настройках. Приложения могут отправлять туда пользователей с помощью Intent, который приостанавливает ПО и запускает соответствующую страницу настроек для данного специального разрешения. После того как пользователь вернется в приложение, оно может проверить, предоставлено ли разрешение в функции onResume() .

Группы разрешений

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

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

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

Это встроенное разрешение, которое имеет уровень защиты (protectionLevel) – dangerous. При установке приложения с данным разрешением Android ОС спросит пользователя о том, хочет ли он предоставить доступ к данным своих контактов.

Разработчики могут создать свои разрешения. Для этого их нужно прописать в файле AndroidManifest.xml:

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

И тогда при установке приложения ОС Android спросит пользователя, давать ли доступ приложению к камере или нет.

Уровни разрешений

1. normal – пользователь не знает, что приложение запрашивает доступ к этому ресурсу, потому что права предоставляются автоматически при установке;
2. dangerous – этот уровень требует, чтобы пользователь подтвердил, может ли приложение получить доступ к определенному ресурсу;
3. signature – приложение, использующее этот уровень разрешений, должно быть подписано тем же сертификатом, что и продукт, объявивший его. Это не позволяет злоумышленнику прописать с этим разрешением в файле AndroidManifest.xml, потому что Android не даст установить приложение;
4. Есть несколько других уровней, таких как system, installer, privileged, appop и т. д., которые используются системными приложениями. Их следует рассматривать как уровень signature с точки зрения злоумышленника, т. е. разрешения, использующие этот уровень защиты, не могут быть объявлены в .

Некоторые разрешения, такие как CAMERA, позволяют вашему приложению получать доступ к аппаратным частям, которые есть только у некоторых устройств Android. Если ваше приложение объявляет одно из этих hardware-associated permissions, подумайте, сможет ли оно работать на устройстве, не имеющем этого оборудования. В большинстве случаев оборудование является необязательным, поэтому лучше и назвать его таковым, задав для android:required значение false в объявлении , как показано в следующем фрагменте кода из файла AndroidManifest.xml:

Если вы не установите для android:required значение false в объявлении , Android предположит, что для запуска вашего приложения требуется аппаратное обеспечение. Система запретит некоторым устройствам устанавливать ваше приложение.

Рекомендации при работе с разрешениями

1. При объявлении «своих» (кастомных) разрешений не забывайте об уровне защиты. Если мы объявим свое разрешение не укажем protectionLevel, то по умолчанию оно примет уровень normal и его можно будет спокойно использовать. Аналогичную ошибку допустили разработчики встроенного приложения Samsung, это привело к тому, что другие приложения на телефоне могли читать историю звонков, SMS-сообщения и т. д.
2. Будьте внимательны при работе с разрешениями, если у вас есть «экосистема» приложений. Предположим, ваша экосистема состоит из двух продуктов: My Cool Cam и My Cool Reader. Первый для чтения использует функциональные возможности второго.

Манифест приложения камеры:

Манифест приложения для чтения:

На первый взгляд может показаться, что всё хорошо и безопасно, поскольку только приложения из экосистемы могут получить доступ к конфиденциальной информации, хранящейся в AllUserNotesContentProvider . Но что произойдет, если на устройстве жертвы установлено только приложение для чтения? В этом случае система Android ничего не будет знать об объявлении разрешений com.mycoolcam.USE_COOL_CAMERA , и поэтому уровень по умолчанию будет помечен как обычный.

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

1. Избегайте опечаток в названии разрешений.

Разрешение для com.mycoolcam.USE_COOL_CAMERA будет иметь protectionLevel = signature , а для com.mycoolcam.USE_COOL_CAM – значение normal. Это позволяет любому приложению прописать в манифесте разрешения на использование с помощью com.mycoolcam.USE_COOL_CAM , что, в свою очередь, предоставит доступ к действию CoolCamActivity .

1. Избегайте опечаток в названии атрибутов.

В приведенном выше примере вместо атрибута android:permission (который устанавливает уровень доступа к компоненту), указано android:uses-permission . Это значит, что компонент не имеет уровня защиты, поэтому любое стороннее приложение сможет получить к нему доступ.

1. «Защищайте» используемые разрешения.
   Файл AndroidManifest.xml:

 public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder)

В этом случае для доступа к uri ContactsContract.CommonDataKinds.Phone требуется разрешение android.permission.READ_CONTACTS . Однако для доступа к content: //com.exampleapp.contacts не запрашиваются никакие права.

Защищайте свои Content Providers.
Используйте атрибут android:permission тега , чтобы ограничить доступ других приложений к данным в ContentProvider. В отличие от остальных компонентов, для ContentProvider можно установить два отдельных атрибута разрешений: android:readPermission (ограничивает права сторонних приложений на чтение данных) и android:writePermission (доступ на запись). Обратите внимание, если провайдер защищен разрешениями и на чтение, и на запись, наличие только разрешения на запись не позволит приложению читать данные.

Разрешения проверяются при первом обращении к ContentProvider и в тот момент, когда приложение выполняет операции с данными. Если запрашивающее приложение не имеет разрешения, возникает исключение SecurityException. Использование ContentResolver.query() требует разрешения на чтение; применение ContentResolver.insert() , ContentResolver.update() или ContentResolver.delete() требует разрешения на запись. Во всех этих случаях отсутствие необходимого permission приводит к SecurityException.

6.1. Предоставляйте доступ на основе каждого URI.

Система предоставляет нам дополнительный детальный контроль, как другие приложения могут получить доступ к ContentProvider вашего приложения. В частности, ContentProvider может защитить себя с помощью разрешений на чтение и запись, при этом позволяя своим прямым клиентам совместно использовать определенные URI с другими приложениями. Чтобы заявить о поддержке вашим продуктом этой модели, применяйте атрибут android:grantUriPermissions или элемент . Последний позволяет совместно использовать определенные пути.

Также возможно предоставлять разрешения для каждого URI. Для этого необходимо при запуске Activity или возврате результата в Activity установить флаг Intent.FLAG_GRANT_READ_URI_PERMISSION или Intent.FLAG_GRANT_WRITE_URI_PERMISSION (или оба этих флага). Это даст другим приложениям разрешения на чтение, запись или чтение и запись для определенного URI, включенного в Intent).

       // соответствует любой последовательности от нуля до набора символов.

В случае с «bad» ContentProvider разрешит доступ ко всем своим данным.

1. Избегайте определения пользовательских разрешений в пространстве имен «android.permission».
   Определение кастомного разрешения в пространстве имен android.permission может привести к неожиданному поведению, если более новая версия Android добавит разрешение с тем же именем. Для кастомных permissions рекомендуется использовать пространство имен, специфичное для приложения.
2. Проверяйте опечатки в значениях атрибутов android:permission.

  android:permission="TODO" > android:permission="[TODO]" >

1. Явным образом предоставляйте другому приложению разрешение на доступ к компоненту приложения через уровень защиты signature|knownSigner.

1. Будьте внимательны с разрешениями, которые запрашивают сторонние библиотеки в вашем проекте. При подключении внешней библиотеки, вы также наследуете ее требования к разрешениям. Помните о разрешениях, которые нужны для каждой зависимости, и о том, для чего они используются. В Android Studio, при просмотре файла AndroidManifest.xml, снизу есть вкладка Merged Manifest. В ней – итоговый файл манифеста с учетом всех подключенных библиотек и т. д. То есть в этом файле отображаются все разрешения, запрашиваемые сторонними библиотеками, а также их компоненты.

Заключение

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

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

Спасибо за внимание, с вами были Юрий Шабалин и Веселина Зацепина!

app_utils 0.0.6

Application plugin which provides utility functions for Android and iOS.

App Utils #

An application plugin that offers utility functions designed for use on both the Android and iOS platforms.

Installation #

Android #

In the Android context, you have the option to either declare the QUERY_ALL_PACKAGES permission (providing a wider scope of visibility for app packages) or specify packages within the

Note: Using QUERY_ALL_PACKAGES permission could result in the potential rejection of your app on the Play Store if your app lacks essential core functionalities that necessitate a broader package visibility. For instance, applications like antivirus software that require broader visibility to scan all apps on the device. If your app does not inherently demand QUERY_ALL_PACKAGES permission as a core functionality, it is recommended to explore the option of using the queries tag instead.

iOS #

In Ios, for opening the target app from your app, you need to provide the URL scheme of the target app.

In your deployment target is greater than or equal to 9 then also need to update another app information in your Info.plist.

LSApplicationQueriesSchemes whatsapp // url scheme 

List of supported functions #

Function	Description
launchApp (Android and iOS)	Initiates the launch of the specified application using the provided package name on Android and the URLScheme on iOS.
getInstalledApps (Android)	Returns a list of the installed applications on your Android device.
canLaunchApp (Android & iOS)	Verifies the application’s launch feasibility.
getCurrentDeviceInfo (Android and iOS)	Returns current device information.
getCurrentAppInfo (Android and iOS)	Returns information about your application.
readLaunchedData (Android and iOS)	Allows reading sender application data. On Android, it gathers data from the activity intent, whereas on iOS, it acquires data from the URL Scheme.
openDeviceSettings (Android and iOS)	Initiates access to the settings page within your application. — For Android, it offers diverse settings choices. — However, in iOS, owing to Apple’s limitations, it exclusively provides access to the primary settings page. For more information, please visit here.

Upcoming features #

Features #

1. requestDeviceAuth �� — Unleash your device’s potential with a touch! Open the device unlock screen on both Android and iOS platforms.
2. playAudio �� — Immerse yourself in a world of sound. Seamlessly play audio on your device with just a tap.
3. openDeviceSensor �� — Get closer to the magic of your device. Experience the power of open device sensors like never before.

Explore these exciting functionalities and bring a new dimension to your app’s capabilities!

Contributors #

A big shoutout to the following amazing contributors who have helped shape and improve this project:

Join our ranks by contributing to this project! Every line of code makes a difference. ��

Bugs or Requests #

If the code genie escapes its lamp and causes trouble, just give a shout by opening an issue. Got a brainwave for a cool feature? Toss the idea into a GitHub ticket, and I’ll whip out my magnifying glass ��. And hey, pull requests? They’re like virtual high-fives! ��