Launcher personalizado versus modo quiosque versus MDM: de qual camada você precisa?

Resposta curta

Esses três termos descrevem camadas diferentes da mesma pilha, e não produtos concorrentes. Um launcher personalizado altera a interface do usuário — a tela inicial que a pessoa vê e como ela navega pelo dispositivo. O modo quiosque restringe o dispositivo a uma tarefa ou a um conjunto definido de aplicativos, usando o lock task mode em um dispositivo cujo controlador de políticas do dispositivo (DPC) está configurado como device owner. O MDM ou EMM é a camada de políticas da frota, responsável por inscrever dispositivos, enviar e alterar políticas, distribuir aplicativos e reportar conformidade. Uma quarta camada fica abaixo das três: a integração com o OEM em nível de sistema, alcançada por OEMConfig, APIs de administração do fornecedor ou trabalho de firmware, onde residem os controles que a API pública de políticas não expõe. A maioria dos programas usa várias camadas ao mesmo tempo, então a pergunta útil não é qual delas escolher, e sim a qual camada pertence cada requisito individual — e se essa camada consegue impor o requisito ou apenas exibi-lo. Uma segunda pergunta vem logo em seguida e é respondida mais adiante nesta página: se a configuração resultante é gravada no dispositivo uma única vez, durante a preparação, ou mantida sob gerenciamento remoto contínuo por toda a vida útil da frota.

Quatro camadas de controle, não três produtos

Os requisitos chegam em forma de frases — “deve executar apenas o nosso aplicativo”, “precisa ter a cara do nosso produto”, “vamos precisar mudar a lista de permissão depois”, “os usuários não podem chegar às configurações”. Cada uma dessas frases pertence a uma camada diferente, e o modo de falha mais comum em projetos de dispositivos é colocar um requisito em uma camada incapaz de impô-lo. A camada de experiência é o launcher: o que a tela mostra e para onde os toques levam. A camada de restrição de tarefa é o lock task mode: em qual aplicativo o dispositivo fica fixado e quais elementos da interface do sistema continuam acessíveis. A camada de políticas da frota é o DPC e a plataforma de gerenciamento por trás dele: inscrição, restrições de usuário, distribuição de aplicativos, comandos remotos e relatórios. A camada de sistema é tudo o que o OEM expõe além da superfície padrão de políticas — frameworks de leitura de códigos e de remapeamento de teclas, controle silencioso de atualização de firmware, permissões privilegiadas de aplicativo, persistência após restaurações. Relacionar qual controle pertence ao Android Enterprise, ao EMM, ao OEM ou a um launcher é exatamente a função da Matriz de dependências de OEM/MDM, e a decisão de recorrer ou não à camada de sistema é o tema de MDM versus ROM Android personalizada. A ordem importa: a camada mais leve capaz de impor um requisito normalmente é a correta, porque cada degrau abaixo custa tempo de validação, reduz a lista de dispositivos candidatos e acrescenta gatilhos de revalidação.

• Camada de experiência — launcher personalizado: o que o usuário vê e como navega
• Camada de restrição de tarefa — lock task/quiosque: em qual aplicativo o dispositivo é mantido
• Camada de políticas da frota — DPC como device owner mais o console do EMM: o que é permitido e o que muda
• Camada de sistema — integração com o OEM, OEMConfig ou firmware: controles que a API pública de políticas não expõe

O que um launcher personalizado altera

Um launcher personalizado substitui o aplicativo de tela inicial padrão para remodelar a superfície em que o usuário chega — os ícones de aplicativo exibidos, a navegação entre eles, a identidade visual e o primeiro ponto de entrada de conteúdo. É uma camada de experiência: controla a aparência e a sensação de uso do dispositivo, não o que ele tem permissão técnica para fazer. Em uma configuração com device owner, o DPC pode definir o launcher como handler preferencial persistente da intent de tela inicial, de modo que ele seja aplicado no provisionamento em vez de ficar a cargo do usuário, e nenhuma caixa de escolha aparece na primeira inicialização. Esse único detalhe é o que separa um launcher implantável de outro que o usuário pode simplesmente abandonar. Um launcher também pode trazer valor operacional legítimo além da marca — uma lista de verificação de início de turno, um único botão grande de ação para uso com luvas, uma faixa de status com o estado da sincronização ou a saúde da bateria, um idioma padrão adequado ao local em vez da conta. O que um launcher não consegue fazer é impedir. Ele apresenta um conjunto menor de opções; não remove as opções subjacentes. Toda restrição que precisa resistir a um usuário determinado — ou apenas curioso — tem de ser expressa na camada de políticas e, depois, confirmada na amostra, em vez de presumida a partir da captura de tela.

• Uma tela inicial com a identidade da marca e um conjunto selecionado de ícones de aplicativo
• Navegação e um ponto de entrada de conteúdo desenhados em torno do fluxo de trabalho
• Definido pelo DPC como handler padrão de tela inicial no provisionamento, não escolhido pelo usuário
• Apenas experiência e identidade visual — não é, por si só, uma fronteira de controle

O que o modo quiosque e o lock task realmente controlam

Modo quiosque é o nome operacional do lock task mode, um recurso do framework concedido por um device owner — ou, em usuários e perfis afiliados a partir do Android 9, por um profile owner, embora o hardware dedicado de propriedade corporativa normalmente seja provisionado como device owner de qualquer forma. O DPC coloca em lista de permissão os pacotes autorizados a entrar em lock task, e o dispositivo é então mantido dentro desse aplicativo, seja porque o próprio aplicativo entra no modo, seja porque a plataforma de gerenciamento aplica uma configuração de quiosque em seu nome; o Google documenta o mecanismo em lock task mode para dispositivos dedicados. Além da fixação em si, a política seleciona quais recursos de lock task permanecem disponíveis — os botões de tela inicial e de visão geral, o painel de notificações, o menu de ações globais, o bloqueio de tela e as informações do sistema na barra de status. Um quiosque de um único aplicativo serve a um dispositivo que faz uma só coisa; uma configuração de vários aplicativos apresenta uma tela inicial gerenciada com um conjunto definido de aplicativos aprovados, o que a Android Management API expressa como um tipo de instalação de quiosque ou um launcher de quiosque gerenciado, conforme o formato necessário. Vale enunciar dois limites desde já. O lock task bloqueia atividades de pacotes fora da lista de permissão, mas não fiscaliza o que acontece dentro de um aplicativo permitido, de modo que uma web view incorporada, um visualizador de documentos ou uma tela de ajuda ainda podem expor uma navegação que a política não pretendia — e, se um handler do sistema como o seletor de documentos for permitido para que o fluxo de trabalho funcione, tudo o que esse handler alcança também se torna acessível. Além disso, o lock task é uma propriedade do modo gerenciado em que o dispositivo está inscrito, e o modo em si é uma decisão à parte, tratada em dispositivos Android dedicados versus totalmente gerenciados. Essas restrições são configuráveis para MDM/EMM e permanecem sujeitas à validação técnica no hardware e na compilação escolhidos.

• Quiosque de um único aplicativo para um dispositivo dedicado a uma só tarefa
• Quiosque de vários aplicativos para um conjunto definido de aplicativos aprovados atrás de uma tela inicial gerenciada
• Os recursos de lock task determinam quais elementos da interface do sistema continuam acessíveis
• As intents disparadas de dentro de um aplicativo permitido são a via de escape que mais precisa ser testada

O que a camada de políticas da frota acrescenta

O MDM ou EMM opera em escala de frota. Ele inscreve dispositivos por uma via de provisionamento acordada, aplica restrições de usuário e perfis de configuração, distribui e atualiza aplicativos, entrega configuração gerenciada aos aplicativos que publicam uma, reporta inventário e conformidade e emite comandos remotos como bloquear, reiniciar ou redefinir a senha. Enquanto um launcher e uma política de quiosque moldam um único dispositivo, a camada de políticas da frota é como esse estado é aplicado a centenas de unidades e mantido atualizado depois. A maior parte das restrições efetivas mora aqui, e não em outro lugar: bloquear a instalação a partir de fontes desconhecidas, desabilitar a inicialização em modo de segurança, impedir uma restauração de fábrica iniciada pelo usuário, restringir quais configurações o usuário pode alterar, controlar o acesso de depuração. A restrição no nível do aplicativo também costuma morar aqui — um navegador que publica uma configuração gerenciada pode receber do EMM uma lista de permissão ou de bloqueio, mas apenas para os campos que o desenvolvedor efetivamente expôs, e é por isso que a restrição de navegador é uma das primeiras coisas a testar, em vez de prometer. A profundidade disponível depende do OEM e da plataforma e varia entre plataformas de gerenciamento, de modo que um controle documentado para a API não está automaticamente presente no console que você licenciou, na compilação que você comprou.

• Inscrição por uma via de provisionamento acordada e política aplicada a cada check-in
• Restrições de usuário: fontes desconhecidas, inicialização em modo de segurança, restauração de fábrica, escopo das configurações e depuração
• Distribuição de aplicativos, controle de versão e entrega de configuração gerenciada
• Inventário, estado de conformidade e comandos remotos como bloquear ou reiniciar

O que apenas a integração em nível de sistema acrescenta

Alguns requisitos não se resolvem em nenhuma das três camadas acima, porque o controle não faz parte da superfície padrão de políticas do Android Enterprise. Exemplos típicos são o remapeamento de teclas físicas, o comportamento do gatilho de leitura de códigos e de RFID, a concessão de uma permissão privilegiada a um aplicativo privado, a manutenção de uma versão de firmware enquanto o restante da frota é atualizado, o controle de uma base de carregamento ou de um barramento de periféricos, ou a preservação de uma configuração após uma restauração. Esses pontos ficam com o OEM e são alcançados por OEMConfig — um esquema de configuração gerenciada publicado pelo fornecedor e entregue por um EMM padrão —, por um SDK de administração do fornecedor usado por um agente personalizado, ou por trabalho de firmware no nível da plataforma. A consequência prática para um projeto de dispositivos é que essa camada reduz a lista de dispositivos candidatos antes de qualquer outra coisa: o requisito deixa de ser “um tablet Android” e passa a ser “um tablet Android de um fornecedor que expõe esse controle nesta compilação”. Ela também cria uma obrigação de manutenção, porque os frameworks dos fornecedores evoluem em versões independentes do próprio Android. Trate o trabalho em nível de sistema como uma escalada deliberada, com um responsável nomeado, adotada apenas quando um requisito realmente não puder ser atendido acima dela, e registre-o como uma limitação conhecida com um gatilho de revalidação, e não como um item resolvido.

• OEMConfig — configurações do fornecedor enviadas por um EMM padrão, sem agente personalizado
• SDKs de administração do fornecedor — usados por um agente personalizado onde o OEMConfig não alcança
• Trabalho de firmware ou de plataforma — a opção mais pesada e menos portável
• Escale de forma deliberada: essa camada reduz a lista de dispositivos candidatos e acrescenta gatilhos de revalidação

Política estática versus gerenciamento remoto: o segundo eixo

A escolha das camadas responde ao que é controlado. Uma segunda pergunta, independente, decide como esse controle é mantido: a política é gravada no dispositivo uma única vez durante a preparação ou o dispositivo é mantido sob gerenciamento remoto contínuo por toda a sua vida útil? Ambos são desenhos legítimos, e a premissa errada aqui sai cara de um jeito que só aparece meses depois da entrega. Um dispositivo configurado estaticamente carrega seu estado aceito desde a bancada de preparação. O provisionamento aplica o launcher, a configuração de lock task, o conjunto de aplicativos e as restrições; o dispositivo então opera sem uma relação de gerenciamento permanente. Nada precisa fazer check-in, nada precisa de licença para continuar funcionando e nenhum console precisa de um administrador. O custo recai sobre a mudança: uma nova entrada na lista de permissão, um aplicativo atualizado ou uma configuração corrigida significam nova preparação, unidade devolvida ou visita ao local, e esse custo se multiplica por cada unidade em campo. Um dispositivo gerenciado remotamente mantém uma relação ativa com um tenant de EMM. A política é versionada de forma centralizada e aplicada no check-in seguinte, os aplicativos são atualizados no próprio dispositivo, a conformidade fica visível e um dispositivo perdido pode ser bloqueado. O custo recai sobre a dependência: o desenho pressupõe um caminho de rede, uma assinatura ativa e uma pessoa nomeada como responsável pelo tenant após a transferência. Esse último ponto é o que mais fica sem dono. O tenant está vinculado a uma identidade corporativa, e alguém precisa guardar as credenciais de administrador, renovar as licenças, aprovar aplicativos e responder quando um dispositivo sai de conformidade. Se esse responsável não for nomeado antes da aprovação do lote, a frota se torna ingerenciável exatamente no momento em que o gerenciamento é necessário. O caso offline merece uma resposta explícita, e não uma suposição. Um dispositivo que nunca faz check-in não perde sua política: ele mantém o último estado aplicado com sucesso e continua funcionando. O que ele perde é toda mudança posterior — novas políticas, atualizações de aplicativos, revogações de acesso e comandos remotos ficam na fila e nunca chegam —, e o console exibe um horário de última conexão desatualizado que pode ser confundido com um dispositivo saudável. Programas com locais genuinamente desconectados costumam terminar em um híbrido: uma linha de base estática forte o bastante para estar operacionalmente correta por si só, mais uma inscrição que acrescenta gerenciamento central onde houver conectividade. Esse híbrido precisa ser um desenho declarado, com uma janela offline acordada, e não um acidente descoberto durante a primeira alteração de política.

Por que um launcher sozinho não é uma fronteira de controle

Um launcher personalizado instalado sem uma política de device owner por trás normalmente pode ser abandonado. O usuário pode chegar à interface original pelo modo de segurança, por um caminho nas configurações que altera o aplicativo de tela inicial padrão, por uma intent disparada por um aplicativo permitido ou por uma restauração de fábrica — porque o launcher pinta uma superfície em vez de remover uma capacidade. A imposição vem da camada de device owner e das APIs do OEM que ela expõe: as restrições de usuário que bloqueiam a inicialização em modo de segurança e as fontes desconhecidas, a configuração de lock task que decide qual interface do sistema sobrevive, a política de restauração que decide se o usuário pode ou não apagar o dispositivo. A impossibilidade de contorno é uma propriedade da camada de políticas, não da tela inicial. Vale escrever essa distinção no documento de requisitos em termos claros, porque “bloqueado” significa coisas muito diferentes para um designer e para um administrador. Na prática, a formulação honesta é um par: o launcher define o caminho pretendido e a camada de políticas fecha os não pretendidos. Ambos são então testados, e os que não puderem ser fechados no hardware escolhido são registrados como exceções aceitas, em vez de silenciosamente omitidos.

• Um launcher sem política de device owner pode ser contornado pelo modo de segurança ou por um caminho nas configurações
• Uma restauração de fábrica comum remove o device owner e devolve o dispositivo à interface original
• As restrições efetivas ficam na camada de device owner, restrições de usuário e APIs do OEM
• O launcher define o caminho pretendido; a política fecha os não pretendidos

Arquiteturas combinadas comuns

Na prática, as camadas se empilham, e um pequeno número de combinações cobre a maioria das implantações. Launcher mais políticas de frota entrega uma superfície com identidade de marca que também é gerenciada centralmente e atualizável — o formato usual para um dispositivo voltado ao cliente ou à equipe de campo. Lock task mais um aplicativo distribuído de forma privada produz um dispositivo dedicado a um único fluxo de trabalho, com o papel do launcher praticamente absorvido pelo aplicativo fixado. O OEMConfig envia configurações do fornecedor pelo EMM padrão quando um comportamento de hardware precisa mudar, mas um agente personalizado seria desproporcional. Um agente personalizado fecha lacunas deixadas pela API pública de políticas, ao custo de uma obrigação de manutenção. E uma linha de base preparada estaticamente, com ou sem inscrição posterior, atende às frotas que não terão um caminho de rede confiável. Nenhuma dessas opções é um nível de produto; são combinações escolhidas requisito a requisito, e um programa pode conter mais de uma — uma mesma implantação frequentemente mistura uma variante totalmente bloqueada para dispositivos compartilhados entre turnos com uma configuração mais leve para supervisores.

• Launcher mais políticas de frota: uma superfície com identidade de marca gerenciada centralmente
• Lock task mais um aplicativo privado: um dispositivo dedicado a um único fluxo de trabalho
• OEMConfig: configurações do fornecedor enviadas por um EMM padrão
• Agente personalizado: fechar lacunas que a API pública de políticas não cobre
• Linha de base preparada estaticamente: um estado aceito que se sustenta sem conexão de gerenciamento

Matriz de decisão entre requisito e camada

Mapear cada requisito para uma camada mantém a configuração proporcional e torna concreta a conversa sobre aceitação: para cada linha abaixo existe um mecanismo que a impõe e um teste que mostra que ela se sustentou. A tabela é indicativa — a via de imposição para um modelo específico, uma versão do Android, uma plataforma de gerenciamento e um aplicativo é definida durante a validação e registrada antes de qualquer compromisso, porque o mesmo requisito pode recair sobre camadas diferentes conforme o que o hardware escolhido expõe.

Comprovar cada camada na amostra com controle de versão

Um mapa de camadas é uma hipótese até que uma amostra o teste. A amostra com controle de versão é a unidade que fixa o modelo e o SKU regional exatos, a versão do Android e a compilação de firmware, o pacote e a versão do aplicativo, a versão da política e a via de provisionamento — para que cada afirmação abaixo esteja ligada a algo reproduzível, e não a uma família de dispositivos. Cada camada produz um tipo diferente de evidência, e confundi-las é como um projeto chega ao lote com uma surpresa desagradável. Uma afirmação restrita ao launcher, testada com honestidade, se parece com isto: a tela inicial com a identidade da marca aparece, os ícones estão corretos e então um testador abre o painel de notificações, chega às configurações, altera o aplicativo de tela inicial padrão, inicia em modo de segurança e executa uma restauração de fábrica. Se esses caminhos levarem a algum lugar que o requisito proíbe, o requisito nunca esteve na camada do launcher — ele pertence à política, e a matriz de aceitação registra o mecanismo, não a aparência. A evidência de restrição de tarefa é comportamental e adversarial por concepção. A amostra não é comprovada pelo aplicativo abrir; é comprovada pelo aplicativo permanecer aberto após reinicialização, chamada recebida, notificação, desconexão do carregador, atualização, parada forçada e desligamento por bateria fraca — e por uma via de saída de supervisor aprovada que funcione para a equipe sem virar um contorno geral. Os testes de contorno pertencem à matriz de aceitação como cenários nomeados com resultado aprovado, reprovado ou condicional, porque são esses os caminhos que um usuário real encontra nas primeiras duas semanas: inicialização em modo de segurança, o link direto para as configurações, a folha de compartilhamento, um seletor de arquivos dentro de um aplicativo permitido, os handlers de download, uma web view incorporada que segue um link externo, os serviços de acessibilidade, a depuração USB e a própria restauração de fábrica. A evidência da camada de políticas de frota é evidência de console mais um teste de mudança: o dispositivo aparece com a identidade e a compilação esperadas, a versão de política aprovada é a que está aplicada, e uma alteração deliberada de política é publicada e observada chegando ao dispositivo dentro da janela acordada. A evidência da camada de sistema é a mais estreita e a mais específica por modelo — um controle do fornecedor funciona nesta compilação ou não funciona, e o resultado fica atrelado a uma versão de firmware que pode mudar. Tudo o que não pode ser fechado é registrado em vez de descartado: a biblioteca de limitações conhecidas existe para que vias de escape residuais, aprovações condicionais e responsáveis por dependências permaneçam visíveis para quem aprova. A estrutura dos próprios resultados — cenário, comportamento esperado, comportamento observado, veredito e responsável — segue a matriz de aceitação da amostra. A preparação do lote então reproduz o estado aceito em vez de reinventá-lo: a mesma via de provisionamento, a mesma versão de política, a mesma compilação do aplicativo, verificadas unidade por unidade em relação à amostra de referência, com uma regra de parada quando uma unidade se desvia. É isso que transforma uma amostra que funciona em um programa, normalmente cotado a partir de cerca de 500 unidades, com uma remessa piloto de vinte a cem dispositivos dentro do programa, usada para confirmar as decisões de camada em condições reais antes que as unidades restantes sejam preparadas.

• Vincule cada afirmação de camada a uma única amostra com controle de versão — modelo, SKU, compilação, aplicativo, política e via de provisionamento
• Teste o launcher tentando sair dele: painel de notificações, configurações, troca da tela inicial padrão, modo de segurança e restauração de fábrica
• Registre os cenários de contorno na matriz de aceitação com veredito aprovado, reprovado ou condicional e um responsável nomeado
• Comprove as políticas de frota com uma mudança real: publique uma versão de política e observe sua chegada dentro da janela acordada
• Reproduza, não reinvente — a preparação do lote repete o estado aceito e para quando uma unidade se desvia

Limitações conhecidas do modelo de camadas

O modelo de camadas é uma ferramenta de planejamento, não uma garantia, e vale dizer onde ele deixa de ser arrumado. As camadas não são perfeitamente separáveis na prática: uma configuração de lock task pode alterar o comportamento de um launcher, uma atualização de aplicativo pode mover um controle da camada de aplicativo para a camada de políticas, e uma implementação do OEM pode divergir do comportamento documentado do framework na mesma versão do Android. A disponibilidade depende do OEM, da versão do Android, do EMM e do hardware em toda a linha, de modo que um controle confirmado em um modelo não está confirmado em seu sucessor.

• A configuração gerenciada só expõe os campos que o desenvolvedor do aplicativo publicou — um EMM não pode inventá-los.
• O lock task bloqueia pacotes fora da lista de permissão, não a navegação dentro de um aplicativo permitido; web views e handlers do sistema permitidos continuam sendo a via de escape habitual.
• Uma restauração de fábrica padrão remove o device owner; a persistência depende da via de provisionamento e de um comportamento do OEM que precisa ser confirmado modelo a modelo.
• As ações remotas exigem que o dispositivo receba e execute o comando; unidades offline ou danificadas precisam de uma via de recuperação própria.
• Atualizações de firmware e de aplicativos podem deslocar comportamentos entre camadas e devem acionar uma revalidação, em vez de uma presunção de continuidade.
• A documentação do console descreve a capacidade da plataforma, não o conjunto de recursos licenciados no seu tenant nem o comportamento na sua compilação exata.

Decida a camada antes de decidir o dispositivo

O momento mais barato para corrigir uma decisão de camada é antes da seleção do hardware, porque a camada determina a lista de candidatos muito mais do que a ficha técnica. Um requisito que se resolve com as políticas padrão do Android Enterprise mantém ampla a escolha do dispositivo; outro que exige um framework de administração do fornecedor a reduz a um punhado de modelos e acrescenta uma obrigação de manutenção. Traga a lista de requisitos em vez de uma ideia de produto: o que o usuário precisa ver, o que o dispositivo precisa ser impedido de fazer, o que vai precisar mudar após a entrega, se a frota terá conectividade, quem manterá o tenant de gerenciamento e a faixa de quantidade em discussão. A Vantora mapeia cada linha nas camadas de experiência, restrição de tarefa, políticas de frota e sistema, indica quais são impostas e quais são apenas aparência, e registra as limitações residuais antes de qualquer compromisso — a sequência de checkpoints está descrita em como funciona uma implantação validada de dispositivos Android, e o trabalho de integração em si, em Integração de aplicativo, MDM e quiosque.