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 ukrywa niektóre aplikacje przed Twoją aplikacją, ale domyślnie filtruje 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> do 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ą za pomocą 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 sygnatury 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ą pasujące elementy <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 dostawcy lub listę oddzielonych średnikami danych o dostawcach.

Wszystkie aplikacje (niezalecane)

W rzadkich przypadkach aplikacja może potrzebować informacji z wszystkich zainstalowanych aplikacji na urządzeniu lub wchodzić z nimi w interakcję 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 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, nawiązując interakcję z zestawem 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.