Quando crei la tua app, è importante considerare le altre app sul dispositivo con cui la tua app deve interagire. Se la tua app ha come target Android 11 (livello API 30) o versioni successive, il sistema rende alcune app visibili alla tua app automaticamente, ma filtra altre app per impostazione predefinita. Questa guida spiega come rendere visibili queste altre app alla tua app.
Se la tua app ha come target Android 11 o versioni successive e deve interagire
con app diverse da quelle visibili automaticamente, aggiungi l'elemento
<queries>
nel file manifest
della tua app. All'interno dell'elemento <queries>
, specifica le altre app in base al
nome del pacchetto, in base alla firma dell'intent
o in base all'autorità del provider, come descritto nelle sezioni
seguenti.
Nomi pacchetto specifici
Se conosci le app specifiche con cui vuoi eseguire query o interagire, ad esempio
app che si integrano con la tua app o app di cui utilizzi i servizi, includi i
nomi dei pacchetti in un insieme di elementi <package>
all'interno dell'elemento <queries>
:
<manifest package="com.example.game"> <queries> <package android:name="com.example.store" /> <package android:name="com.example.services" /> </queries> ... </manifest>
Comunicare con un'app host in una libreria
Se sviluppi una libreria Android, puoi dichiarare le tue esigenze di visibilità del pacchetto
aggiungendo un elemento <queries>
nel file manifest AAR. Questo elemento <queries>
ha la stessa
funzionalità dell'elemento che le app possono dichiarare nei propri manifest.
Se la tua libreria prevede la comunicazione con un'app host, ad esempio l'utilizzo di un servizio
associato, includi un elemento <package>
che
specifichi il nome del pacchetto dell'app host:
<!-- Place inside the <queries> element. --> <package android:name=PACKAGE_NAME />
Se includi questa dichiarazione, puoi verificare se l'app host è installata e
interagire con essa, ad esempio chiamando
bindService()
.
L'app di chiamata che utilizza la tua libreria diventa automaticamente
visibile all'app host in seguito a
questa interazione.
Pacchetti che corrispondono a una firma di filtro per intent
La tua app potrebbe dover eseguire query o interagire con un insieme di app che servono a
uno scopo particolare, ma potresti non conoscere i nomi dei pacchetti specifici da
includere. In questa situazione, puoi elencare
le firme dei filtri per intent nell'elemento
<queries>
. La tua app può quindi rilevare le app che hanno elementi <intent-filter>
corrispondenti.
Il seguente esempio di codice mostra un elemento <intent>
che consentirebbe all'app
di visualizzare altre app installate che supportano la condivisione di immagini JPEG:
<manifest package="com.example.game"> <queries> <intent> <action android:name="android.intent.action.SEND" /> <data android:mimeType="image/jpeg" /> </intent> </queries> ... </manifest>
L'elemento <intent>
presenta alcune limitazioni:
- Devi includere esattamente un elemento
<action>
. - Non puoi utilizzare gli attributi
path
,pathPrefix
,pathPattern
oport
in un elemento<data>
. Il sistema si comporta come se avessi impostato il valore di ogni attributo sul carattere jolly generico (*
). - Non puoi utilizzare l'attributo
mimeGroup
di un elemento<data>
. All'interno degli elementi
<data>
di un singolo elemento<intent>
, puoi utilizzare ciascuno dei seguenti attributi al massimo una volta:mimeType
scheme
host
Puoi distribuire questi attributi su più elementi
<data>
o utilizzarli in un singolo elemento<data>
.
L'elemento <intent>
supporta il carattere jolly generico (*
) come
valore per alcuni attributi:
- L'attributo
name
dell'elemento<action>
. - Il sottotipo dell'attributo
mimeType
di un elemento<data>
(image/*
). - Il tipo e il sottotipo dell'attributo
mimeType
di un elemento<data>
(*/*
). - L'attributo
scheme
di un elemento<data>
. - L'attributo
host
di un elemento<data>
.
Se non diversamente specificato nell'elenco precedente, il sistema non supporta una
combinazione di testo e caratteri jolly, ad esempio prefix*
.
Pacchetti che utilizzano un'autorità specifica
Se devi eseguire una query su un fornitore
di contenuti ma non conosci i nomi specifici dei pacchetti, puoi dichiarare l'autorità del fornitore in un elemento <provider>
, come mostrato nel seguente snippet:
<manifest package="com.example.suite.enterprise"> <queries> <provider android:authorities="com.example.settings.files" /> </queries> ... </manifest>
Puoi dichiarare le autorità del fornitore in un singolo elemento <queries>
. All'interno dell'elemento
<queries>
, puoi dichiarare uno o più elementi <provider>
. Un elemento
<provider>
può includere una singola autorità del fornitore o un
elenco di autorità del fornitore separate da punto e virgola.
Tutte le app (non consigliato)
In rari casi, la tua app potrebbe dover eseguire query o interagire con tutte le app installate
su un dispositivo, indipendentemente dai componenti che contengono. Per consentire alla tua app di
vedere tutte le altre app installate, il sistema fornisce l'autorizzazione
QUERY_ALL_PACKAGES
.
Alcuni esempi di casi d'uso in cui è opportuno includere l'autorizzazione
QUERY_ALL_PACKAGES
sono:
- App di accessibilità
- Browser
- App di gestione dei dispositivi
- App di sicurezza
- App antivirus
Tuttavia, di solito è possibile soddisfare i casi d'uso dell'app interagendo con l'insieme di app visibili automaticamente e dichiarando le altre app a cui la tua app deve accedere nel file manifest. Per rispettare la privacy degli utenti, la tua app deve richiedere la quantità minima di visibilità dei pacchetti necessaria per funzionare.
Questo aggiornamento delle norme di Google
Play
fornisce linee guida per le app che richiedono l'autorizzazione QUERY_ALL_PACKAGES
.