Zadeklaruj potrzeby związane z widocznością pakietu

Podczas tworzenia aplikacji należy wziąć pod uwagę inne aplikacje na urządzeniu, z którymi aplikacja musi się komunikować. Jeśli Twoja aplikacja jest kierowana na Androida 11 (poziom interfejsu API 30) lub nowszego, system automatycznie udostępnia niektóre aplikacje, ale domyślnie odfiltrowuje inne aplikacje. 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 interakcję z aplikacjami innymi niż te, które są widoczne automatycznie, dodaj element <queries> do pliku manifestu aplikacji. W elemencie <queries> określ inne aplikacje na podstawie nazwy pakietu, na podstawie sygnatury zamiaru lub na podstawie autoryzacji dostawcy, zgodnie z opisem w następnych sekcjach.

Nazwy konkretnych pakietów

Jeśli znasz aplikacje, do których chcesz wysłać zapytanie lub z którymi chcesz wchodzić w interakcję (np. aplikacje, które się integrują z Twoją aplikacją lub których usług używasz), podaj 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ę na Androida, możesz zadeklarować wymagania dotyczące widoczności pakietu, dodając element <queries> w pliku manifestu AAR. Element <queries> ma te same funkcje co element, który aplikacje mogą zadeklarować w swoich plikach manifestu.

Jeśli biblioteka wymaga komunikacji z aplikacją hosta, na przykład za pomocą uwią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 dodaniu tej deklaracji możesz sprawdzić, czy aplikacja hosta jest zainstalowana, i działać z nią, np. wywołując ją, korzystając z funkcji bindService(). Aplikacja wywołująca, która korzysta z Twojej biblioteki, automatycznie staje się widoczna dla aplikacji hosta w wyniku tej interakcji.

pakiety, które pasują do podpisu filtra intencji;

Aplikacja może potrzebować zapytań lub interakcji z zestawem aplikacji, które służą do określonego celu, ale nie znasz nazw pakietów, które należy uwzględnić. W takim przypadku możesz podać signatury filtra intencji w elemencie <queries>. Twoja aplikacja może wtedy wykrywać aplikacje, które mają zgodne elementy <intent-filter> <intent-filter>

Ten przykładowy kod 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 użyć dokładnie jednego elementu <action>.
  • W elemencie <data> nie można używać atrybutów path, pathPrefix, pathPattern ani port. 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 rozmieścić te atrybuty w wielu elementach <data> lub użyć ich w jednym elemencie <data>.

Element <intent> obsługuje ogólny symbol wieloznaczny (*) jako wartość dla 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 mieszania tekstu i symboli wieloznacznych, np. prefix*.

Pakiety, które korzystają z określonej instytucji wydającej certyfikaty cyfrowe

Jeśli chcesz wysłać zapytanie do dostawcy treści, ale nie znasz nazw konkretnych pakietów, możesz zadeklarować autorytet 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 pojedynczym elemencie <queries>. W elemencie <queries> możesz zadeklarować co najmniej 1 element <provider>. Element <provider> może zawierać dane dotyczące jednego organu wydającego certyfikat dostawcy lub listę oddzielonych średnikami danych o organach wydających certyfikat dostawcy.

Wszystkie aplikacje (niezalecane)

W rzadkich przypadkach aplikacja może potrzebować informacji z wszystkich zainstalowanych aplikacji na urządzeniu lub wchodzić z nimi we wzajemne interakcje, niezależnie od ich komponentów. Aby umożliwić aplikacji wyświetlanie wszystkich innych zainstalowanych aplikacji, system przyznaje jej uprawnienie QUERY_ALL_PACKAGES.

Oto kilka przykładów zastosowań, w których należy 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 , oraz deklarując inne aplikacje, do których aplikacja musi mieć dostęp w pliku manifestu. Aby zapewnić użytkownikom prywatność, aplikacja powinna prosić o najmniejszą widoczność pakietu, która jest niezbędna do jej działania.

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