Como declarar as necessidades de visibilidade do pacote

Ao criar seu app, é importante considerar o conjunto de outros apps instalados no dispositivo que ele pretende acessar. Se o app for direcionado ao Android 11 (API de nível 30) ou versões mais recentes, o sistema deixará alguns apps visíveis automaticamente para o seu, mas ocultará outros por padrão. Este guia descreve como tornar esses outros apps visíveis para o seu.

Se o app for direcionado ao Android 11 ou versões mais recentes e precisar interagir com outros apps além dos que são automaticamente visíveis, adicione o elemento <queries> ao arquivo de manifesto do seu app. No elemento <queries>, especifique os outros apps pelo nome do pacote, pela assinatura da intent ou pela autoridade do provedor, conforme descrito nas seções a seguir.

Nomes de pacote específicos

Se você conhece o conjunto específico de apps que quer consultar ou com os quais quer interagir, como apps que se integram ao seu ou apps cujos serviços você usa, inclua os nomes dos pacotes deles em um conjunto de elementos <package> dentro do elemento <queries>:

<manifest package="com.example.game">
    <queries>
        <package android:name="com.example.store" />
        <package android:name="com.example.services" />
    </queries>
    ...
</manifest>

Comunicar-se com um app host em uma biblioteca

Se você desenvolver uma biblioteca Android, poderá declarar as necessidades de visibilidade do pacote adicionando um elemento <queries> ao arquivo de manifesto AAR. Esse elemento <queries> tem a mesma funcionalidade que o elemento pode declarar nos próprios manifestos.

Se a biblioteca envolver a comunicação com um app host, como o uso de um serviço vinculado, inclua um elemento <package> que especifique o nome do pacote do app host:

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

Ao incluir essa declaração, você pode verificar se o app host está instalado e interagir com ele, como chamando bindService(). O app de chamada que usa sua biblioteca fica automaticamente visível para o app host como resultado dessa interação.

Pacotes que correspondem a uma assinatura de filtro de intent

Seu app pode precisar consultar ou interagir com um conjunto de apps que atendem a uma finalidade específica, mas você pode não saber os nomes de pacotes específicos a serem incluídos. Nessa situação, você pode listar as assinaturas de filtro de intent no elemento <queries>. Seu app poderá descobrir apps que têm elementos <intent-filter> correspondentes.

O exemplo a seguir permite que seu app veja apps instalados compatíveis com o compartilhamento de imagens JPEG:

<manifest package="com.example.game">
    <queries>
        <intent>
            <action android:name="android.intent.action.SEND" />
            <data android:mimeType="image/jpeg" />
        </intent>
    </queries>
    ...
</manifest>

O elemento <intent> tem algumas restrições:

  • É necessário incluir exatamente um elemento <action>.
  • Não é possível usar os atributos path, pathPrefix, pathPattern ou port em um elemento <data>. O sistema se comporta como se o valor de cada atributo fosse o valor do caractere curinga genérico (*).
  • Não é possível usar o atributo mimeGroup de um elemento <data>.
  • Nos elementos <data> de um único elemento <intent>, é possível usar cada um dos seguintes atributos no máximo uma vez:

    • mimeType
    • scheme
    • host

    É possível distribuir esses atributos em vários elementos <data> ou usá-los em um único elemento <data>.

O elemento <intent> aceita o caractere curinga genérico (*) como o valor de alguns atributos:

  • O atributo name do elemento <action>.
  • O subtipo do atributo mimeType de um elemento <data> (image/*).
  • O tipo e subtipo do atributo mimeType de um elemento <data> (*/*).
  • O atributo scheme de um elemento <data>.
  • O atributo host de um elemento <data>.

A menos que especificado de outra forma na lista anterior, o sistema não é compatível com uma combinação de caracteres curinga e de texto, como prefix*.

Pacotes que usam uma autoridade específica

Nos casos em que é preciso consultar um provedor de conteúdo, mas você não sabe os nomes dos pacotes específicos, declare essa autoridade de provedor em um elemento <provider>, conforme demonstrado no snippet a seguir:

<manifest package="com.example.suite.enterprise">
    <queries>
        <provider android:authorities="com.example.settings.files" />
    </queries>
    ...
</manifest>

É possível declarar todas as autoridades do provedor em um único elemento <queries>. O formato depende do número de autoridades de provedor declaradas:

Elemento <provider> único
No elemento, declare uma lista de autoridades delimitada por ponto e vírgula.
Vários elementos <provider>
Em cada elemento , declare uma única autoridade ou uma lista de autoridades delimitada por ponto e vírgula.

Todos os apps (não recomendado)

Em casos raros, o app pode precisar consultar ou interagir com todos os apps instalados em um dispositivo, independentemente dos componentes que eles contenham. Para permitir que seu app veja todos os outros apps instalados, o sistema fornece a permissão QUERY_ALL_PACKAGES.

A lista a seguir fornece alguns exemplos de casos de uso em que a permissão QUERY_ALL_PACKAGES é apropriada para incluir:

  • Apps de acessibilidade
  • Navegadores
  • Apps de gerenciamento de dispositivos
  • Apps de segurança
  • Apps de antivírus

No entanto, na grande maioria dos casos, é possível atender aos casos de uso do seu app interagindo com o conjunto de apps visíveis automaticamente e declarando os outros apps que o seu precisa acessar no arquivo de manifesto. Para respeitar a privacidade do usuário, seu app precisa solicitar a menor quantidade de visibilidade do pacote necessária para que ele funcione.

Esta atualização de política do Google Play fornece diretrizes para apps que precisam da permissão QUERY_ALL_PACKAGES.