Zadeklaruj potrzeby związane z widocznością pakietu

Podczas tworzenia aplikacji ważne jest, aby 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 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ą widoczne automatycznie, 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 wymaga komunikacji z aplikacją hostującą, np. korzystania 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 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żą do określonego celu, 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 ani port 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 A <provider> może zawierać uprawnienia jednego dostawcy lub listę uprawnień dostawców rozdzieloną średnikami.

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 można zrealizować przypadki użycia aplikacji, korzystając z zestawu aplikacji, które są widoczne automatycznie , i 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.