Configurações gerenciadas no Android: configurando aplicativos para trabalhadores antes de abri-los

Um chamado de suporte comum no primeiro dia é assim. Um trabalhador abre o aplicativo da empresa, o aplicativo pede o endereço de um servidor e ninguém no chão de fábrica sabe qual é. Alguém da TI então digita a mesma URL, o mesmo nome de conta ou a mesma configuração em cada dispositivo, e cedo ou tarde um deles fica com um erro de digitação.

O Android Enterprise possui uma forma padrão de evitar isso, chamada de configurações gerenciadas (managed configurations). Você define os valores de um app uma única vez na política do seu MDM. Eles chegam a todos os dispositivos cobertos por essa política e o aplicativo os lê ao ser iniciado. Quando um funcionário abre o Chrome, o cliente de e-mail, um app de scanner ou o aplicativo corporativo interno da sua empresa, ele já sabe onde se conectar e o que é permitido.

Este tutorial aborda os dois lados da configuração. Você aprenderá como encontrar e aplicar configurações gerenciadas para aplicativos comuns no editor de políticas do seu MDM. Também aprenderá o que solicitar aos seus desenvolvedores internos para que seus próprios APKs ofereçam suporte ao mesmo mecanismo.

O que é uma configuração gerenciada e quem define os campos

Uma configuração gerenciada é um conjunto de parâmetros chave-valor que uma organização envia para um aplicativo em um dispositivo Android gerenciado. A documentação do Android Enterprise do Google descreve o fluxo da seguinte forma:

1. O desenvolvedor do aplicativo define o esquema (schema). No arquivo res/xml/app_restrictions.xml do aplicativo, o desenvolvedor declara cada configuração que o app aceitará: sua chave, seu tipo (string, boolean, integer, choice, multi-select, bundle e assim por diante), um título e um valor padrão.
2. O Google Play publica o esquema. Quando o aplicativo é enviado ao Google Play, o Play lê esse arquivo. O Google Play gerenciado (Managed Google Play) pode então exibir os campos para os consoles de EMM como um formulário.
3. Seu MDM envia os valores. Por meio da Android Management API, a entrada do aplicativo na política de dispositivos carrega os valores que você escolheu.
4. O aplicativo os lê. No dispositivo, o app chama RestrictionsManager.getApplicationRestrictions() e aplica o que encontra.

Portanto, o desenvolvedor do aplicativo decide quais campos existem, não o seu MDM. Se o desenvolvedor não publicou uma chave para "URL do servidor", nenhum console poderá pré-configurar a URL do servidor. O console só pode preencher os campos que o desenvolvedor expôs.

Observação: As configurações gerenciadas são separadas das políticas de dispositivos. Uma política de dispositivo controla o próprio Android, por exemplo, a câmera, o USB ou o Wi-Fi. Uma configuração gerenciada controla parâmetros dentro de um aplicativo específico. Geralmente, você precisa de ambos.

Antes de começar

• Os dispositivos estão inscritos no seu MDM com o Android Enterprise (totalmente gerenciados ou com perfil de trabalho).
• Os aplicativos que você deseja configurar estão aprovados no Google Play gerenciado ou são aplicativos privados publicados lá pelos seus desenvolvedores.
• Você tem um dispositivo de teste inscrito sob uma política de teste, não a sua política de produção.
• Você conhece os valores que deseja enviar, como nomes de host do servidor, URLs permitidas e formatos de conta.

Etapa 1: Verificar se o aplicativo oferece suporte a configurações gerenciadas

Antes de planejar qualquer coisa, confirme se o aplicativo publica um esquema. Você pode verificar em três lugares:

1. No editor de políticas do seu MDM. Adicione o aplicativo a uma política de teste e veja se um formulário de configuração aparece. Se aparecer, o desenvolvedor publicou um esquema.
2. Na documentação empresarial do fornecedor. Muitos fornecedores publicam suas chaves. Por exemplo, o Google lista as políticas corporativas do Chrome, com o suporte de plataforma para cada uma, em chromeenterprise.google/policies.
3. Com a equipe de suporte do fornecedor. Pergunte: "O seu aplicativo Android oferece suporte a configurações gerenciadas do Android Enterprise e quais chaves ele disponibiliza?"

Anote cada chave necessária e o tipo dela. Os tipos de esquema incluem string, bool, integer, choice, multi-select, hidden, bundle e bundle_array. Um campo bool espera true ou false, e não o texto "true", e um campo multi-select espera valores de uma lista fixa.

Resultado esperado: Para cada aplicativo, você sabe se há suporte a configurações gerenciadas e quais campos irá definir.

Aviso: Se um aplicativo não possuir um esquema, não há solução alternativa dentro do sistema de configurações gerenciadas. Suas opções são pedir ao fornecedor para adicionar um, trocar de aplicativo ou manter uma etapa documentada de configuração manual para esse app.

Etapa 2: Adicionar o aplicativo à política e abrir sua configuração

1. Abra a política que abrange os dispositivos de destino. Use sua política de teste primeiro.
2. Adicione o aplicativo a partir do Google Play gerenciado, caso ele ainda não esteja na política.
3. Abra o formulário de configuração do aplicativo.

No Nomid MDM, o card do aplicativo no editor de políticas abre a configuração gerenciada do aplicativo. É o conjunto de configurações que o desenvolvedor publica pelo Google Play, exibido como campos a preencher. Os próprios aplicativos Android da Nomid leem suas configurações da mesma forma.

Resultado esperado: Você vê um formulário cujos campos correspondem às chaves listadas na Etapa 1.

Observação: O Google Play lê o esquema do aplicativo enviado, então o formulário aparece para aplicativos distribuídos pelo Google Play gerenciado, públicos e privados. Na Nomid, aplicativos privados hospedados na Nomid Store também mostram um formulário de configuração quando o aplicativo enviado declara um esquema. Para qualquer outra forma de distribuição, verifique como a configuração funciona antes de depender dela.

Etapa 3: Preencher a configuração para aplicativos comuns

Antes de preencher valores, leia as Etapas 4 e 5. Decida quais valores são iguais para todos os dispositivos da política e quais mudam por unidade ou dispositivo, para não precisar refazer os formulários depois.

Abaixo estão os três padrões que a maioria das frotas necessita. Os nomes dos campos variam entre fornecedores, portanto trate as chaves como exemplos e confirme-as no formulário de cada aplicativo.

3a. Navegador: página inicial e listas de URLs (Chrome)

O Chrome no Android aceita muitas das mesmas políticas empresariais que o Chrome para desktop, entregues como configuração gerenciada. As políticas frequentemente utilizadas em dispositivos corporativos incluem:

Antes de depender de uma política, consulte a lista de políticas do Chrome Enterprise para confirmar se há suporte no Android. Algumas políticas de desktop, especialmente relacionadas à inicialização e ao comportamento da página inicial, funcionam de forma diferente ou não estão disponíveis no Android. Se você precisar de uma tela inicial fixa, favoritos gerenciados ou um link da web em um inicializador de modo quiosque costumam ser mais previsíveis. Se você bloquear tudo com URLBlocklist ["*"], adicione também as páginas de login do seu provedor de identidade em URLAllowlist, ou os sites de trabalho que exigem login não vão carregar.

3b. Cliente de e-mail: servidor e conta

Aplicativos de e-mail corporativos geralmente disponibilizam campos como:

• Endereço de e-mail ou nome de usuário
• Nome de host do servidor (por exemplo, um host do Exchange ActiveSync)
• Requisito de SSL/TLS
• Se contas pessoais podem ser adicionadas

Valores por usuário, como o endereço de e-mail, são abordados na Etapa 5. Por enquanto, preencha os campos que são iguais para todos, como o host do servidor e as opções de segurança.

3c. Aplicativos de scanner e de linha de negócios: URL do servidor e comportamento

Utilitários para dispositivos robustos, aplicativos de leitura/scanner e aplicativos corporativos geralmente disponibilizam:

• URL base da API ou do backend, por exemplo https://wms.example.com/api
• Código do locatário (tenant), filial ou armazém
• Chaves de ativação de recursos (feature toggles), como modo offline, leitura por câmera versus leitor dedicado de hardware, ou desativação de logs de depuração

Salve a política. Em seguida, confirme que o dispositivo de teste está atribuído a ela. Resultado esperado: O formulário de cada aplicativo contém os valores compartilhados desta política, a política está salva e o dispositivo de teste a utiliza.

Aviso: Evite inserir senhas ou segredos de longa duração em configurações gerenciadas. Os valores são armazenados no dispositivo e podem ser lidos pelo aplicativo. Prefira fluxos onde a configuração direciona o aplicativo para o servidor correto e o funcionário ou o aplicativo realiza a autenticação em seguida.

Etapa 4: Definir uma única vez por política

A configuração gerenciada pertence à política, não a um dispositivo individual. Todos os dispositivos vinculados à política recebem os mesmos valores. Use isso a seu favor:

1. Agrupe dispositivos pelo que difere entre eles. Se a loja A e a loja B usam URLs de backend diferentes, elas precisam de configurações diferentes. Organize suas políticas ou grupos de políticas com base nessa diferença.
2. Reutilize uma linha de base comprovadamente funcional. Crie uma política totalmente configurada e use-a como ponto de partida para novos locais, para não ter que reconstruir a configuração manualmente. Na Nomid, modelos de política e grupos de políticas servem para essa finalidade.
3. Altere uma vez, implemente em todos os lugares. Quando a URL do servidor mudar, edite-a na política. Os dispositivos receberão o novo valor na próxima sincronização de política.

Resultado esperado: Cada conjunto distinto de valores mapeia para exatamente uma política ou grupo de políticas, e nada é configurado manualmente por dispositivo.

Etapa 5: Lidar com valores específicos por dispositivo

Alguns valores são diferentes em cada dispositivo: o endereço de e-mail de um usuário, o nome de um dispositivo, uma etiqueta de patrimônio ou um número de série que seu aplicativo exige para licenciamento. Desde o Android 10, aplicativos comuns não podem ler o número de série do hardware diretamente, portanto, transmiti-lo por meio de configurações gerenciadas é um padrão comum.

Existem duas abordagens gerais:

• Variáveis. A Android Management API permite que um console associe variáveis de configuração a um modelo de configuração gerenciada. Um único modelo pode, então, ser resolvido com valores diferentes em cada dispositivo. A forma como um console expõe isso e quais variáveis ele disponibiliza varia entre produtos. Confirme com seu fornecedor quais atributos de dispositivo ou de usuário podem ser inseridos antes de planejar sua arquitetura em torno deles.
• Escopos de política menores. Se o valor por dispositivo realmente corresponder a um local ou equipe, crie uma política dedicada para esse grupo. Para poucos dispositivos, isso é simples. Para centenas, não é escalável, o que indica a necessidade de usar variáveis ou fazer uma alteração no aplicativo.

Uma terceira opção fica do lado do aplicativo. O aplicativo pode receber um valor compartilhado, como uma identificação de locatário (tenant ID), a partir da configuração e, em seguida, buscar parâmetros específicos do dispositivo em seu próprio backend após o login. Isso geralmente se sustenta melhor do que enviar todos os detalhes individuais de cada dispositivo pelo MDM.

Resultado esperado: Você escolheu, para cada campo, se o valor é compartilhado (nível de política), variável (resolvido por dispositivo) ou buscado pelo aplicativo após o login.

Etapa 6: Verificar se o aplicativo aplicou a alteração

1. Confirme se o dispositivo recebeu a política. Verifique o status de última visualização ou de sincronização no seu console. Na Nomid, a lista de ativos mostra a última visualização e o status de contato.
2. Confirme que o aplicativo está instalado. Uma configuração enviada antes do fim da instalação é aplicada assim que o aplicativo estiver presente, mas ele precisa de fato estar instalado. Verifique a lista de aplicativos do dispositivo no console ou no próprio dispositivo.
3. Force o encerramento e reabra o aplicativo. Muitos aplicativos só leem a configuração ao iniciar. Force o encerramento pela página do aplicativo em Configurações. Se a política bloquear as Configurações, como em um quiosque, reinicie o dispositivo, o que pode ser feito remotamente.
4. Verifique dentro do aplicativo. O campo do servidor deve estar pré-preenchido e bloqueado para edição, o site bloqueado deve estar inacessível e assim por diante. Uma captura de tela remota permite verificar sem precisar manusear o dispositivo fisicamente.

Resultado esperado: No dispositivo de teste, cada aplicativo configurado mostra os valores enviados sem nenhuma digitação. Depois, implante em etapas: anote os valores atuais para poder reverter, copie os valores testados para a política de produção, aplique-a primeiro a um pequeno grupo piloto e amplie quando os dispositivos piloto mostrarem os valores corretos.

Observação: Se o aplicativo ainda exibir os valores antigos após forçar a parada, consulte a seção de perguntas frequentes sobre solução de problemas abaixo. A causa geralmente está na forma como o aplicativo gerencia as configurações, não na entrega.

Para aplicativos internos: solicite que seus desenvolvedores publiquem um esquema

Se o seu próprio aplicativo ainda solicita que os funcionários digitem a URL do servidor, a solução está no código do app. Você pode enviar as seguintes instruções para a sua equipe de desenvolvimento.

1. Declarar o esquema

Crie res/xml/app_restrictions.xml:

<?xml version="1.0" encoding="utf-8"?>
<restrictions xmlns:android="http://schemas.android.com/apk/res/android">
    <restriction
        android:key="server_url"
        android:title="@string/cfg_server_url_title"
        android:description="@string/cfg_server_url_desc"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="site_code"
        android:title="@string/cfg_site_code_title"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="allow_offline"
        android:title="@string/cfg_offline_title"
        android:restrictionType="bool"
        android:defaultValue="false" />
</restrictions>

2. Fazer referência no manifesto

<application ...>
    <meta-data
        android:name="android.content.APP_RESTRICTIONS"
        android:resource="@xml/app_restrictions" />
</application>

3. Ler os valores e reagir a alterações

class MainActivity : AppCompatActivity() {
    private val configReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context, intent: Intent) = applyConfig()
    }

    override fun onResume() {
        super.onResume()
        applyConfig() // picks up changes made while the app was in the background
        registerReceiver(
            configReceiver,
            IntentFilter(Intent.ACTION_APPLICATION_RESTRICTIONS_CHANGED)
        )
    }

    override fun onPause() {
        unregisterReceiver(configReceiver)
        super.onPause()
    }

    private fun applyConfig() {
        val rm = getSystemService(Context.RESTRICTIONS_SERVICE) as RestrictionsManager
        val config = rm.applicationRestrictions
        val serverUrl = config.getString("server_url", "")
        val allowOffline = config.getBoolean("allow_offline", false)
        // Apply serverUrl and allowOffline to the app's settings here
    }
}

O broadcast ACTION_APPLICATION_RESTRICTIONS_CHANGED só é entregue a receptores registrados em tempo de execução. O aplicativo também deve ler a configuração novamente no método onResume() para que as alterações feitas enquanto ele estava em segundo plano sejam aplicadas.

4. Publicar pelo Google Play gerenciado

Faça o upload do aplicativo no Google Play — como um app privado para sua organização, caso não seja público — para que o Play possa ler o esquema e exibir o formulário no seu MDM. Cada nova versão que adicione ou renomeie uma chave precisará de um novo upload.

Lista de verificação para desenvolvedores

• Mantenha as chaves estáveis. Renomear server_url quebra todas as políticas que a utilizam.
• Oculte um campo na interface quando ele for definido por configuração, para que os funcionários não possam substituí-lo.
• Trate ausências de dados de forma elegante quando uma chave estiver vazia, por exemplo, exibindo uma mensagem clara para "entrar em contato com a TI".
• Nunca exija dados secretos na configuração. Use-a para localizar o servidor e faça a autenticação adequada em seguida.
• Teste com o aplicativo TestDPC do Google em um dispositivo que não esteja registrado no seu MDM. O TestDPC precisa ser o aplicativo de gerenciamento do dispositivo, então não roda em um dispositivo que seu MDM já gerencia.

Perguntas frequentes sobre solução de problemas

O aplicativo não exibe um formulário de configuração no editor de políticas.

O desenvolvedor não publicou um esquema pelo Google Play, ou a versão no Play é anterior à inclusão do esquema. Consulte a documentação do fornecedor ou pergunte diretamente a ele. Para aplicativos internos, confirme se a entrada meta-data existe no manifesto e se a compilação (build) com o esquema foi enviada. Uma chave adicionada em uma nova versão só aparece no formulário depois que essa versão é enviada ao Google Play e processada.

Alterei um valor, mas o aplicativo continua mostrando o antigo.

Siga estas etapas em ordem:

1. O dispositivo sincronizou a política atualizada? Verifique a última visualização.
2. Force a parada e reabra o aplicativo. Se o novo valor aparecer agora, o aplicativo só lê a configuração na inicialização e não escuta a transmissão (broadcast) de alteração.
3. Se ainda não aparecer, o aplicativo pode ter guardado o valor antigo no próprio armazenamento. Limpar os dados do aplicativo resolve isso, mas apaga tudo o que está salvo só no dispositivo, como leituras offline ainda não sincronizadas, então sincronize antes. Caso contrário, o desenvolvedor precisa corrigir o aplicativo.

O valor chega, mas o aplicativo o ignora.

Verifique se o nome da chave e o tipo correspondem exatamente ao esquema. As chaves diferenciam maiúsculas de minúsculas (case-sensitive), e um booleano enviado como string não será lido como booleano. Verifique também se a versão do aplicativo no dispositivo é anterior à que introduziu a chave. Em um dispositivo com perfil de trabalho, confirme que o trabalhador abriu a cópia de trabalho do aplicativo, marcada com o ícone de maleta. A cópia pessoal nunca recebe a configuração.

Algumas políticas do Chrome funcionam e outras não.

Nem todas as políticas do Chrome Enterprise são suportadas no Android. Verifique o suporte de plataforma de cada uma na lista de políticas do Chrome Enterprise e confira a versão do Chrome no dispositivo.

Posso enviar um valor diferente para cada dispositivo?

Sim, mas não por padrão. Use variáveis de configuração se o seu console oferecer suporte para o atributo necessário, divida os dispositivos em políticas menores ou faça com que o aplicativo busque parâmetros específicos de cada dispositivo em seu backend. Consulte a Etapa 5.

A configuração foi aplicada, mas o funcionário ainda consegue editar o campo.

Bloquear um campo é responsabilidade do aplicativo, não do Android. Solicite ao desenvolvedor que desative ou oculte as configurações originadas de configurações gerenciadas.

Como posso testar sem impactar a produção?

Use uma política de teste dedicada e um único dispositivo inscrito. Para aplicativos internos, os desenvolvedores podem usar o TestDPC antes mesmo de o app chegar ao seu MDM.

Próximas etapas

Principais pontos para lembrar:

• O desenvolvedor do aplicativo define o que pode ser configurado. Seu MDM apenas preenche esses campos e nada mais.
• Confirme o suporte primeiro, registre as chaves e tipos e teste em um dispositivo antes de fazer a implementação ampla.
• Valores compartilhados devem ficar na política. Valores específicos por dispositivo exigem variáveis, escopos menores ou consultas no lado do aplicativo.
• Para aplicativos internos, adicionar um esquema requer uma alteração pequena e bem documentada, eliminando a etapa de configuração manual para os funcionários.

Comece esta semana com o aplicativo que gera mais chamados de configuração. Mapeie suas chaves, crie uma política de teste e valide em um dispositivo. Em seguida, envie a lista de verificação de desenvolvedores acima para a equipe responsável pelo seu aplicativo interno.

Se você quiser experimentar esse fluxo com o Nomid MDM, o cartão do aplicativo no editor de políticas abre a configuração gerenciada de cada app, e o plano gratuito abrange até 10 dispositivos sem limite de tempo. Isso é suficiente para uma política de teste e um grupo piloto. O acesso remoto e a API não estão incluídos no plano gratuito.

FAQ

O que é uma configuração gerenciada do Android?

É um conjunto de parâmetros chave-valor que uma organização envia para um aplicativo em um dispositivo Android gerenciado. Os exemplos incluem uma URL de servidor, sites permitidos ou ativação/desativação de recursos. O desenvolvedor do aplicativo define os campos disponíveis em um esquema publicado pelo Google Play, e o MDM envia os valores por meio da política de dispositivos.

Como saber se um aplicativo oferece suporte a configurações de app no Android Enterprise?

Adicione o aplicativo a uma política de teste no seu MDM e veja se um formulário de configuração aparece. Você também pode consultar a documentação empresarial do fornecedor ou perguntar à equipe de suporte quais chaves de configuração gerenciada o aplicativo disponibiliza.

O que é o app_restrictions.xml?

É o arquivo XML localizado nos recursos de um aplicativo Android onde o desenvolvedor declara o esquema de configuração gerenciada: a chave, o tipo, o título e o valor padrão de cada configuração. O arquivo é referenciado no manifesto do aplicativo e o Google Play o lê quando o app é enviado.

Uma alteração na configuração gerenciada é aplicada imediatamente?

O dispositivo a recebe na próxima sincronização de política. Se o aplicativo a aplica imediatamente ou não, depende do próprio aplicativo. Aplicativos que escutam o broadcast de alteração de restrições são atualizados enquanto estão em execução, enquanto outros apenas leem a configuração na próxima inicialização.