Zadeklaruj potrzeby związane z widocznością pakietu

Podczas tworzenia aplikacji należy wziąć pod uwagę inne aplikacje na urządzeniu, z którymi Twoja aplikacja musi wchodzić w interakcje. Jeśli aplikacja jest kierowana na Androida 11 (API na poziomie 30) lub nowszego, system automatycznie udostępnia jej niektóre aplikacje, ale domyślnie odfiltrowuje inne. Z tego przewodnika dowiesz się, jak sprawić, aby te inne aplikacje były widoczne dla Twojej aplikacji.

Jeśli Twoja aplikacja jest kierowana na Androida 11 lub nowszego i musi wchodzić w interakcje z aplikacjami innymi niż te, które są widoczne automatycznie, dodaj element <queries> w pliku manifestu aplikacji. W elemencie <queries> określ inne aplikacje według nazwy pakietu, według podpisu intencji lub według urzędu dostawcy, jak opisano w sekcjach poniżej.

Konkretne nazwy pakietów

Jeśli znasz konkretne aplikacje, do których chcesz wysyłać zapytania lub z którymi chcesz wchodzić w interakcje, np. aplikacje, które integrują się z Twoją aplikacją, lub aplikacje, z których usług korzystasz, umieść ich nazwy pakietów w zbiorze elementów <package> wewnątrz elementu <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ę na Androida, możesz zadeklarować potrzeby dotyczące widoczności pakietu, dodając element <queries> w pliku manifestu AAR. Ten element <queries> ma taką samą funkcjonalność jak element, który aplikacje mogą deklarować we własnych plikach manifestu.

Jeśli biblioteka wymaga komunikacji z aplikacją hosta, np. przy użyciu powiązanej usługi, dodaj element <package>, który określa nazwę pakietu aplikacji hosta:

<!-- Place inside the <queries> element. -->
<package android:name=PACKAGE_NAME />

Dzięki tej deklaracji możesz sprawdzić, czy aplikacja hosta jest zainstalowana, i wejść z nią w interakcję, np. wywołując bindService(). W wyniku tej interakcji aplikacja do dzwonienia, która używa Twojej biblioteki, automatycznie staje się widoczna dla aplikacji hosta.

Pakiety pasujące do podpisu filtra intencji

Może się zdarzyć, że Twoja aplikacja będzie musiała wysłać zapytanie do zestawu aplikacji, które służą do określonego celu, lub wejść z nimi w interakcję, ale nie będziesz znać konkretnych nazw pakietów, które należy uwzględnić. W takiej sytuacji możesz podać podpisy filtrów intencji w elemencie <queries>. Aplikacja może wtedy wykrywać aplikacje z pasującymi elementami <intent-filter>.

Poniższy przykładowy kod pokazuje element <intent>, który umożliwia aplikacji wyświetlanie innych aplikacji instalowanych 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 podać dokładnie 1 element <action>.
  • W elemencie <data> nie możesz używać atrybutów path, pathPrefix, pathPattern ani port. System zachowuje się tak, jakby wartość każdego atrybutu była ustawiona na ogólny symbol 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 maksymalnie raz:

    • mimeType
    • scheme
    • host

    Możesz rozdzielić te atrybuty między 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 na poprzedniej liście nie określono inaczej, system nie obsługuje kombinacji tekstu i symboli wieloznacznych, takich jak prefix*.

Pakiety, które korzystają z określonego urzędu

Jeśli chcesz wysłać zapytanie do mechanizmu dostarczania 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>

Możesz zadeklarować urzędy dostawcy w jednym elemencie <queries>. W elemencie <queries> możesz zadeklarować co najmniej 1 element <provider>. Element <provider> może zawierać pojedynczy urząd dostawcy lub rozdzielaną średnikami listę urzędów dostawców.

Wszystkie aplikacje (niezalecane)

W rzadkich przypadkach aplikacja może potrzebować wysyłać zapytania do wszystkich aplikacji instalowanych na urządzeniu lub wchodzić z nimi w interakcje, niezależnie od zawartych w nich komponentów. Aby umożliwić aplikacji wyświetlanie wszystkich innych zainstalowanych aplikacji, system udostępnia uprawnienie QUERY_ALL_PACKAGES.

Oto kilka przykładów przypadków użycia, w których uprawnienie QUERY_ALL_PACKAGES jest odpowiednie:

  • 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ą automatycznie widoczne , 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 najmniejszy zakres widoczności pakietów niezbędny do jej działania.

Ta aktualizacja zasad Google Play zawiera wytyczne dotyczące aplikacji, które wymagają uprawnienia QUERY_ALL_PACKAGES.

Wstecz
Know which packages are visible automatically
Dalej
Fulfill common use cases