Dichiarare le esigenze di visibilità dei pacchetti

Quando crei la tua app, è importante considerare le altre app sul dispositivo con cui deve interagire. Se la tua app ha come target Android 11 (livello API 30) o versioni successive, il sistema rende visibili automaticamente alcune app, ma per impostazione predefinita ne filtra altre. Questa guida descrive 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' <queries> elemento nel file manifest dell'app. All'interno dell'elemento <queries>, specifica le altre app per nome pacchetto, per firma dell'intent, o per autorità del provider, come descritto nelle seguenti sezioni.

Nomi pacchetto specifici

Se conosci le app specifiche che vuoi interrogare o con cui vuoi interagire, ad esempio le app che si integrano con la tua app o le app di cui utilizzi i servizi, includi i relativi nomi pacchetto in un insieme di <package> elementi 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 pacchetto dell'app host:

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

Includendo questa dichiarazione, puoi verificare se l'app host è installata e interagire con essa, ad esempio chiamando bindService(). L'app chiamante che utilizza la tua libreria diventa automaticamente visibile all'app host in seguito a questa interazione.

Pacchetti che corrispondono a una firma del filtro per intent

La tua app potrebbe dover interrogare o interagire con un insieme di app che hanno uno scopo specifico, ma potresti non conoscere i nomi pacchetto specifici da includere. In questa situazione, puoi elencare le firme dei filtri per intent nell'elemento <queries>. La tua app può quindi scoprire le app che hanno corrispondenti <intent-filter> elementi.

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, o port 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ù <data> elementi o utilizzare li in un singolo <data> elemento.

L'<intent> elemento supporta il carattere jolly generico (*) come valore per alcuni attributi:

• L'attributo name dell'elemento <action>.
• Il sottotipo dell'mimeType attributo di un <data> elemento (image/*).
• Il tipo e il sottotipo dell'mimeType attributo di un <data> elemento (*/*).
• 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 interrogare un content provider ma non conosci i nomi pacchetto specifici, puoi dichiarare l'autorità del provider in un <provider> elemento, 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 provider in un singolo <queries> elemento. All'interno dell'elemento <queries>, puoi dichiarare uno o più elementi <provider>. Un elemento <provider> può includere una singola autorità del provider o un elenco di autorità del provider separate da punto e virgola.

Tutte le app (non consigliato)

In rari casi, la tua app potrebbe dover interrogare o interagire con tutte le app installate su un dispositivo, indipendentemente dai componenti che contengono. Per consentire alla tua app di visualizzare tutte le altre app installate, il sistema fornisce l' autorizzazioneQUERY_ALL_PACKAGES.

Ecco alcuni esempi di casi d'uso in cui è appropriato includere l'autorizzazione QUERY_ALL_PACKAGES:

• App di accessibilità
• Browser
• App di gestione dei dispositivi
• App di sicurezza
• App antivirus

Tuttavia, in genere è possibile soddisfare i casi d'uso della tua 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 il suo funzionamento.

Questo aggiornamento delle norme di Google Play fornisce linee guida per le app che richiedono l'autorizzazione QUERY_ALL_PACKAGES.