Declarar as necessidades de visibilidade do pacote

Ao criar o app, é importante considerar os outros apps no dispositivo com que o app precisa interagir. Se o app for direcionado ao Android 11 (API de nível 30) ou versões mais recentes, o sistema vai deixar alguns apps visíveis automaticamente para o seu, mas vai 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 ficam 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 que quer interagir, como apps que se integram ao seu ou apps que oferecem serviços que 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 que os apps podem 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 conferir 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 vai poder descobrir apps que têm elementos <intent-filter> correspondentes.

O exemplo de código a seguir mostra um elemento <intent> que permite ao app ver outros apps instalados que oferecem suporte ao 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 oferece suporte a uma combinação de caracteres curinga e de texto, como prefix*.

Pacotes que usam uma autoridade específica

Se você precisar consultar um provedor de conteúdo, mas não souber os nomes dos pacotes específicos, declare a autoridade do provedor em um elemento <provider>, conforme mostrado neste snippet:

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

É possível declarar várias autoridades do provedor em um único elemento <queries>. No elemento <queries>, é possível declarar um ou mais elementos <provider>. Um elemento <provider> pode incluir uma única autoridade de provedor ou uma lista de autoridades do provedor delimitadas 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.

Veja abaixo alguns exemplos de casos de uso em que a permissão QUERY_ALL_PACKAGES é adequada para inclusão:

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

No entanto, geralmente é possível atender aos casos de uso do seu app interagindo com o conjunto de apps que ficam visíveis automaticamente e declarando outros apps que seu app 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.

Anterior
Saiba quais pacotes ficam visíveis automaticamente
Próxima
Atender aos casos de uso comuns