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> wskaż inne aplikacje według nazwy pakietu, podpisu intencji lub według urzędu dostawcy zgodnie z opisem w sekcjach poniżej.

Konkretne nazwy 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 Twoja biblioteka wymaga komunikacji z aplikacją hosta, na przykład korzystania z 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 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żesz 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ć jednocześnie każdego z tych atrybutów:

  • mimeType
  • scheme
  • host

  Możesz rozłożyć te atrybuty na wiele elementów <data> lub użyć ich w pojedynczym 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>

Możesz zadeklarować urzędy dostawcy 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. Ze względu na prywatność użytkownika aplikacja powinna prosić o najmniejszą widoczność pakietu, która jest niezbędna do działania.

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