Guia para desenvolvedores

Os recursos empresariais do Android oferecem às organizações uma plataforma de mobilidade Android segura, flexível e unificada, combinando dispositivos, aplicativos e gerenciamento. Por padrão, os apps Android são compatíveis com os recursos empresariais do Android. No entanto, existem outros recursos que você pode usar para que seu app funcione melhor em dispositivos Android gerenciados:

  • Compatibilidade do perfil de trabalho: modifique seu app Android para que ele funcione melhor em um dispositivo gerenciado.
  • Configurações gerenciadas: modifique seu app para permitir que os administradores de TI especifiquem configurações personalizadas para os apps.
  • Dispositivos dedicados: otimize seu app para que ele possa ser implantado em um dispositivo Android como um quiosque.
  • Logon único (SSO): simplifique o processo de login para usuários que fazem login em diferentes apps em dispositivos Android gerenciados.

Pré-requisitos

  1. Você criou um app Android.
  2. Você já pode modificar o app para que ele funcione melhor para organizações.
  3. Versão mínima: Android 5.0 Lollipop versão recomendada: Android 6.0 Marshmallow e mais recentes.

Observação: os recursos empresariais do Android são integrados à maioria dos dispositivos com Android 5.0. No entanto, o Android 6.0 e versões mais recentes oferecem outros recursos, especialmente no que diz respeito a dispositivos dedicados.

Perfis de trabalho

Você pode gerenciar os aplicativos e os dados da empresa de um usuário usando um perfil de trabalho. Um perfil de trabalho é um perfil corporativo gerenciado associado à conta de usuário principal em um dispositivo Android. Um perfil de trabalho isola apps e dados de trabalho com segurança dos apps e dados pessoais. Esse perfil de trabalho está em um contêiner separado do perfil pessoal, controlado pelo usuário. Esses perfis separados permitem que as organizações gerenciem os dados corporativos importantes, mas deixam todo o restante no dispositivo do usuário sob controle dele. Para uma análise mais detalhada sobre as práticas recomendadas, consulte o guia Perfis de trabalho. Confira abaixo uma visão geral dessas práticas recomendadas.

Principais recursos de um perfil de trabalho

  • Perfil separado e seguro
  • Google Play gerenciado para distribuição de apps
  • Candidaturas de trabalho separadas com selo
  • Recursos de gerenciamento somente de perfil controlados por um administrador

Benefícios do perfil de trabalho no Android 5.0 e em versões mais recentes

  • Criptografia de dispositivo completo
  • Um pacote de app Android (APK) para os dois perfis quando há um perfil pessoal e um de trabalho no dispositivo
  • O Controlador de política de dispositivo (DPC) é limitado ao perfil de trabalho.
  • Administração de dispositivos pela classe DevicePolicyManager

Considerações para perfis de trabalho

Impedir que intents falhem entre perfis

É difícil saber quais intents podem cruzar entre perfis e quais estão bloqueadas. A única maneira de ter certeza é testando. Antes que seu app inicie uma atividade, é necessário verificar se a solicitação foi resolvida chamando Intent.resolveActivity().

  • Se retornar null, a solicitação não será resolvida.
  • Se retornar algo, ele mostra que a intent é resolvida e que é seguro enviá-la.

Observação: para ver instruções detalhadas de teste, consulte Evitar intents com falha.

Compartilhar arquivos entre perfis

Alguns desenvolvedores usam URIs para marcar caminhos de arquivos no Android. No entanto, como há sistemas de arquivos separados quando um perfil de trabalho está presente, recomendamos:

Use:
URIs de conteúdo
  • Os URIs de conteúdo contêm a autoridade, o caminho e o ID de um arquivo específico. Você pode gerar esse valor usando a subclasse FileProvider. Saiba mais
  • Compartilhe e conceda permissões para acessar o URI de conteúdo usando uma intent. As permissões só podem ser transmitidas pelo limite do perfil usando intents. Se você conceder a outro app direitos de acesso ao seu arquivo usando Context.grantUriPermission(), ele só será concedido para esse app no mesmo perfil.
Não use:
URI do arquivo
  • Contém o caminho absoluto do arquivo no armazenamento do dispositivo.
  • Um URI de caminho de arquivo válido em um perfil não é válido em outro.
  • Se você anexar um URI de arquivo a uma intent, o gerenciador não poderá acessar o arquivo em outro perfil.

Próximas etapas: quando o app for compatível com perfis gerenciados, teste-o em um perfil de trabalho. Consulte Testar seu app.

Implementar configurações gerenciadas

As configurações gerenciadas são um conjunto de instruções que os administradores de TI podem usar para gerenciar os dispositivos móveis dos usuários de uma maneira específica. Estas instruções são universais e funcionam em qualquer EMM, permitindo que os administradores configurem aplicativos remotamente nos smartphones dos usuários.

Se você estiver desenvolvendo apps empresariais ou governamentais, talvez precise atender ao conjunto específico de requisitos do seu setor. Usando configurações gerenciadas, o administrador de TI pode especificar configurações e aplicar políticas remotamente aos apps Android dos usuários, por exemplo:

  • Configure se um app pode sincronizar dados por rede celular/3G ou somente por Wi-Fi
  • Permitir ou bloquear URLs em um navegador da Web
  • Definir as configurações de e-mail de um app
  • Ativar ou desativar a impressão
  • Gerenciar favoritos

Práticas recomendadas para implementar configurações gerenciadas

O guia Definir configurações gerenciadas é a principal fonte de informações sobre como criar e implantar configurações gerenciadas. Depois de analisar essa documentação, confira as recomendações abaixo para receber mais orientações.

Ao iniciar o app pela primeira vez

Assim que você iniciar um aplicativo, poderá ver se as configurações gerenciadas já estão definidas para ele em onStart() ou onResume(). Além disso, você pode descobrir se o aplicativo é gerenciado ou não gerenciado. Por exemplo, se getApplicationRestrictions() retornar:

  • Um conjunto de restrições específicas do aplicativo: você pode definir as configurações gerenciadas silenciosamente, sem precisar da entrada do usuário.
  • Um pacote vazio: seu aplicativo age como não gerenciado (por exemplo, como o app se comporta em um perfil pessoal).
  • Um pacote com um único par de chave-valor com KEY_RESTRICTIONS_PENDING definido como verdadeiro: seu aplicativo está sendo gerenciado, mas o DPC não está configurado corretamente. Bloqueie esse usuário do seu app e encaminhe-o para o administrador de TI.

Detectar mudanças nas configurações gerenciadas

Os administradores de TI podem alterar as configurações gerenciadas e as políticas que querem aplicar aos usuários a qualquer momento. Por isso, recomendamos que você verifique se o app pode aceitar novas restrições para a configuração gerenciada da seguinte maneira:

  • Buscar restrições na inicialização: seu app precisa chamar getApplicationRestrictions() em onStart() e onResume() e comparar com restrições antigas para ver se mudanças são necessárias.
  • Ouvir durante a corrida: registre dinamicamente ACTION_APPLICATION_RESTRICTIONS_CHANGED nas suas atividades ou serviços em execução, depois de conferir se há novas restrições. Essa intent é enviada somente para listeners registrados dinamicamente, e não para listeners declarados no manifesto do app.
  • Cancelar o registro enquanto não estiver em execução: em onPause(), cancele o registro da transmissão de ACTION_APPLICATION_RESTRICTIONS_CHANGED.

Dispositivos dedicados

Os dispositivos dedicados são quiosques usados para uma única finalidade, como telas de sinalização digital, quiosques de impressão de ingressos ou registros de pagamentos.

Quando um dispositivo Android é configurado como um dispositivo dedicado, o usuário vê um app bloqueado na tela, sem os botões "Início" ou "Apps recentes" para sair do app. Dispositivos dedicados também podem ser configurados para mostrar um conjunto de aplicativos, como um quiosque de biblioteca com um app para o catálogo de bibliotecas e um navegador da Web.

Para conferir as instruções, consulte Dispositivo dedicado.

Configurar o Logon único com guias personalizadas do Chrome

Os usuários corporativos geralmente têm vários apps no dispositivo e preferem fazer login apenas uma vez para acessar todos os aplicativos de trabalho. Normalmente, os usuários fazem login por meio de um WebView. No entanto, há alguns motivos para isso não ser o ideal:

  1. Os usuários geralmente precisam fazer login várias vezes com as mesmas credenciais. A solução de WebView geralmente não é uma experiência de logon único (SSO).
  2. Podem haver riscos de segurança, incluindo aplicativos maliciosos que inspecionam cookies ou injetam JavaScript® para acessar as credenciais de um usuário. Até mesmo desenvolvedores confiáveis correm risco se dependerem de SDKs de terceiros potencialmente maliciosos.

Uma solução para os dois problemas é autenticar usuários com guias personalizadas do navegador em vez da WebView. Isso garante que a autenticação:

  • Ocorre em um contexto seguro (o navegador do sistema) em que o app host não pode inspecionar o conteúdo.
  • Tem um estado de cookie compartilhado, garantindo que o usuário só tenha que fazer login uma vez.

Requisitos

As guias personalizadas têm suporte até o nível 15 da API (Android 4.0.3). Para usar as guias personalizadas, você precisa de um navegador compatível, como o Chrome. No Chrome 45 e versões mais recentes, esse recurso é implementado como guias personalizadas do Chrome.

Como implemento SSO com guias personalizadas?

O Google abriu o código de uma biblioteca de cliente OAuth que usa guias personalizadas, contribuindo para o grupo de trabalho do OpenID Connect da OpenID Foundation. Para configurar guias personalizadas para SSO com a biblioteca AppAuth, consulte a documentação e o exemplo de código no GitHub (em inglês).

Testar o app

Depois de desenvolver seu app, você vai querer testá-lo, tanto em um perfil de trabalho quanto em um dispositivo totalmente gerenciado. Veja as instruções a seguir.

Usar o DPC de teste para testar seu app Android

Fornecemos o app DPC de teste para ajudar os desenvolvedores Android a testar apps em um ambiente corporativo. Com o DPC de teste, é possível definir políticas de EMM ou valores de configuração gerenciados em um dispositivo, como se uma organização gerenciasse o dispositivo usando um EMM. Para instalar o DPC de teste em um dispositivo, escolha um dos seguintes métodos:

Para mais informações sobre como configurar o DPC de teste, consulte as instruções abaixo e o Guia do usuário de teste do DPC.

Provisionar um perfil de trabalho

Para testar seu app em um perfil de trabalho, primeiro você precisa provisionar um perfil de trabalho no dispositivo usando o app DPC de teste, da seguinte maneira:

  1. Instale o DPC de teste no dispositivo.
  2. Na tela de início do Android, toque no ícone do app Configurar DPC de teste.
  3. Siga as instruções na tela.
  4. Instale o app no dispositivo e faça um teste para saber como ele é executado no perfil de trabalho.

O Android cria um perfil de trabalho e instala uma cópia do DPC de teste nele. Use esta instância com selo de trabalho do DPC de teste para definir políticas e configurações gerenciadas no perfil de trabalho. Para saber mais sobre a configuração de um perfil de trabalho para desenvolvimento, leia o guia do desenvolvedor Perfis de trabalho.

Provisionar um dispositivo totalmente gerenciado

As organizações usam dispositivos totalmente gerenciados porque podem aplicar uma gama completa de políticas de gerenciamento no dispositivo. Para provisionar um dispositivo totalmente gerenciado, siga estas etapas:

  1. Instale o DPC de teste no dispositivo.
  2. Confirme se não há outros usuários ou um perfil de trabalho no dispositivo.
  3. Confirme se não há contas no dispositivo.
  4. Execute o seguinte comando do Android Debug Bridge (adb) no seu terminal: 
    adb shell dpm set-device-owner com.afwsamples.testdpc/.DeviceAdminReceiver
  5. Depois de concluir o provisionamento do proprietário do dispositivo, você pode testar seu app nesse dispositivo. É preciso testar especificamente como as configurações gerenciadas e as intents funcionam nesse dispositivo.

Também é possível usar outros métodos de provisionamento. Consulte o Guia do usuário de teste do DPC. Para saber como os administradores de TI normalmente se inscrevem e provisionam dispositivos Android, leia Provisionar dispositivos.

Testes de ponta a ponta

Depois de terminar de testar seu app nos ambientes acima, você provavelmente vai querer testá-lo em um ambiente de produção de ponta a ponta. Esse processo inclui as etapas que um cliente precisa seguir para implantar seu app na organização dele, incluindo:

  • Distribuição de apps pelo Google Play
  • Configuração gerenciada do lado do servidor
  • Controle da política de perfil do lado do servidor

Você precisa acessar um console de EMM para concluir o teste completo. A maneira mais fácil de ter um é solicitar um console de teste ao seu EMM. Quando tiver acesso, conclua estas tarefas:

  1. Crie uma versão de teste do aplicativo com um novo ApplicationId.
  2. Reivindique um domínio gerenciado do Google e vincule-o ao seu EMM. Se você já tiver um domínio de teste vinculado a um EMM, talvez seja necessário desvinculá-lo para testá-lo com o EMM de sua preferência. Consulte seu EMM para saber quais são as etapas específicas de desvinculação.
  3. Publique seu aplicativo no canal privado para o domínio gerenciado do Google dessa pessoa.
  4. Use o console e o aplicativo de EMM para:
    1. Configurar dispositivos de trabalho.
    2. Distribua o aplicativo.
    3. Definir a configuração gerenciada.
    4. Defina as políticas do dispositivo.

Esse processo varia de acordo com seu EMM. Consulte a documentação do EMM para mais detalhes. Parabéns! Você concluiu essas etapas e confirmou que o app funciona bem para usuários corporativos.