Zadeklaruj potrzeby związane z widocznością pakietu

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 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 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.