Podczas tworzenia aplikacji warto wziąć pod uwagę inne aplikacje na urządzeniu, z którymi Twoja aplikacja musi wchodzić w interakcje. Jeśli Twoja aplikacja jest kierowana na Androida 11 (API na poziomie 30) lub nowszego, system automatycznie udostępnia jej niektóre aplikacje, ale domyślnie filtruje inne. Z tego przewodnika dowiesz się, jak sprawić, aby inne aplikacje były widoczne dla Twojej aplikacji.
Jeśli Twoja aplikacja jest przeznaczona na Androida 11 lub nowszego i musi wchodzić w interakcje z aplikacjami innymi niż te, które są automatycznie widoczne, dodaj element <queries>
do pliku manifestu aplikacji. W elemencie <queries>
określ inne aplikacje według nazwy pakietu, według podpisu intencji lub według uprawnień dostawcy, zgodnie z opisem w kolejnych sekcjach.
Określone nazwy pakietów
Jeśli znasz konkretne aplikacje, o które chcesz wysłać zapytanie lub z którymi chcesz wchodzić w interakcje, np. aplikacje zintegrowane z Twoją aplikacją lub aplikacje, z których usług korzystasz, umieść ich nazwy pakietów w zbiorze elementów <package>
w elemencie <queries>
:
<manifest package="com.example.game"> <queries> <package android:name="com.example.store" /> <package android:name="com.example.services" /> </queries> ... </manifest>
Komunikacja z aplikacją hosta w bibliotece
Jeśli tworzysz bibliotekę Androida, możesz zadeklarować swoje potrzeby w zakresie widoczności pakietu, dodając element <queries>
do pliku manifestu AAR. Ten element <queries>
ma taką samą funkcję jak element, który aplikacje mogą deklarować w swoich plikach manifestu.
Jeśli biblioteka komunikuje się z aplikacją hostującą, np. korzysta z usługi powiązanej, umieść element <package>
, który określa nazwę pakietu aplikacji hostującej:
<!-- Place inside the <queries> element. --> <package android:name=PACKAGE_NAME />
Dzięki temu możesz sprawdzić, czy aplikacja hosta jest zainstalowana, i wchodzić z nią w interakcje, np. wywołując funkcję bindService()
.
Aplikacja do połączeń, która korzysta z Twojej biblioteki, automatycznie staje się widoczna dla aplikacji hosta w wyniku tej interakcji.
Pakiety pasujące do podpisu filtra intencji
Aplikacja może potrzebować wysyłać zapytania do zestawu aplikacji, które służą konkretnemu celowi, lub wchodzić z nimi w interakcje, ale możesz nie znać konkretnych nazw pakietów, które należy uwzględnić. W takiej sytuacji możesz umieścić sygnatury filtra intencji w elemencie <queries>
. Aplikacja może wtedy wykrywać aplikacje, które mają pasujące elementy <intent-filter>
.
Poniższy przykład kodu pokazuje element <intent>
, który umożliwia aplikacji wyświetlanie innych zainstalowanych aplikacji obsługujących udostępnianie obrazów JPEG:
<manifest package="com.example.game"> <queries> <intent> <action android:name="android.intent.action.SEND" /> <data android:mimeType="image/jpeg" /> </intent> </queries> ... </manifest>
Element <intent>
ma kilka ograniczeń:
- Musisz uwzględnić dokładnie 1 element
<action>
. - Nie możesz używać atrybutów
path
,pathPrefix
,pathPattern
aniport
w elemencie<data>
. System zachowuje się tak, jakby wartość każdego atrybutu została ustawiona na ogólny znak wieloznaczny (*
). - Nie możesz używać atrybutu
mimeGroup
elementu<data>
. W elementach
<data>
pojedynczego elementu<intent>
możesz użyć każdego z tych atrybutów co najwyżej raz:mimeType
scheme
host
Możesz rozdzielić te atrybuty na kilka elementów
<data>
lub użyć ich w jednym elemencie<data>
.
Element <intent>
obsługuje ogólny symbol wieloznaczny (*
) jako wartość kilku atrybutów:
- Atrybut
name
elementu<action>
. - Podtyp atrybutu
mimeType
elementu<data>
(image/*
). - Typ i podtyp atrybutu
mimeType
elementu<data>
(*/*
). - Atrybut
scheme
elementu<data>
. - Atrybut
host
elementu<data>
.
O ile nie określono inaczej na poprzedniej liście, system nie obsługuje kombinacji tekstu i symboli wieloznacznych, np. prefix*
.
Pakiety, które korzystają z określonego organu
Jeśli chcesz wysłać zapytanie do dostawcy treści, ale nie znasz konkretnych nazw pakietów, możesz zadeklarować uprawnienia dostawcy w elemencie <provider>
, jak pokazano w tym fragmencie kodu:
<manifest package="com.example.suite.enterprise"> <queries> <provider android:authorities="com.example.settings.files" /> </queries> ... </manifest>
Uprawnienia dostawcy możesz zadeklarować w jednym elemencie <queries>
. W elemencie <queries>
możesz zadeklarować co najmniej 1 element <provider>
. Element może zawierać uprawnienia jednego dostawcy lub listę uprawnień dostawców rozdzieloną średnikami.<provider>
Wszystkie aplikacje (niezalecane)
W rzadkich przypadkach aplikacja może potrzebować wysyłać zapytania do wszystkich zainstalowanych na urządzeniu aplikacji lub wchodzić z nimi w interakcje niezależnie od tego, jakie zawierają komponenty. Aby umożliwić aplikacji wyświetlanie wszystkich innych zainstalowanych aplikacji, system udostępnia uprawnienie QUERY_ALL_PACKAGES
.
Oto przykłady zastosowań, w których warto uwzględnić uprawnienie QUERY_ALL_PACKAGES
:
- Aplikacje ułatwień dostępu
- Przeglądarki
- Aplikacje do zarządzania urządzeniami
- Aplikacje zabezpieczające
- Aplikacje antywirusowe
Zwykle jednak przypadki użycia aplikacji można zrealizować, korzystając z zestawu aplikacji, które są widoczne automatycznie , oraz deklarując w pliku manifestu inne aplikacje, do których Twoja aplikacja potrzebuje dostępu. Aby chronić prywatność użytkowników, aplikacja powinna prosić o najmniejszą ilość widoczności pakietu niezbędną do jej działania.
Ta aktualizacja zasad Google Play zawiera wytyczne dotyczące aplikacji, które wymagają uprawnienia QUERY_ALL_PACKAGES
.