Dispositivos Android dedicados versus totalmente gerenciados: qual é a diferença?

Resposta curta

No Android Enterprise, um dispositivo totalmente gerenciado e um dispositivo dedicado são ambos corporativos e ambos provisionados de modo que o controlador de políticas do dispositivo (DPC) seja definido como device owner. É o device owner que importa: a organização controla o dispositivo inteiro, em vez de um contêiner de trabalho colocado ao lado do uso pessoal. A diferença entre os dois está na intenção, não no privilégio. Totalmente gerenciado descreve um dispositivo de uso exclusivamente profissional entregue a uma pessoa identificada, que faz login e trabalha dentro de um conjunto de aplicativos controlados pela organização. Um dispositivo dedicado — modo ainda amplamente conhecido pelo rótulo antigo COSU, corporate-owned single-use — é esse mesmo dispositivo totalmente gerenciado, restrito a uma tarefa ou a um conjunto reduzido de tarefas, normalmente sem operador fixo, compartilhado ou voltado ao público. Portanto, um dispositivo dedicado é sempre totalmente gerenciado; um dispositivo totalmente gerenciado nem sempre é dedicado. O perfil de trabalho é a terceira configuração, e é materialmente diferente: nela o DPC é profile owner, o controle para no contêiner de trabalho e o lado pessoal do dispositivo permanece fora da política da organização. A documentação da Android Management API do Google trata esses casos como modos de gerenciamento distintos, e a distinção que realmente vincula é a de propriedade: se o dispositivo é provisionado como device owner ou com um perfil de trabalho fica definido pela via de inscrição e não pode ser alterado depois a partir de um console. Dentro do device owner, as formas totalmente gerenciada e dedicada são uma questão de política, e não de provisionamento — por isso os custos de mudança de modo descritos adiante neste guia diferem tanto. Este guia mantém essa terminologia para que um modo escrito em uma especificação de compra signifique a mesma coisa para o administrador do EMM, para a equipe do aplicativo e para o aprovador que assina o pedido.

O que significa totalmente gerenciado

Um dispositivo totalmente gerenciado é hardware corporativo no qual a plataforma de gerenciamento atua como device owner e a organização define políticas para todo o dispositivo. A imagem familiar é a de um celular ou tablet de trabalho entregue a um funcionário: o usuário faz login, alcança um conjunto de aplicativos de trabalho publicados pelo Google Play gerenciado e percebe que as configurações, a rede e a instalação de aplicativos seguem a política da organização, e não a preferência pessoal. O device owner é o escopo padrão mais amplo que o Android Enterprise oferece sem mexer no firmware — normalmente abrange instalação e remoção silenciosas de aplicativos, concessão de permissões para aplicativos gerenciados, restrições para adicionar contas ou fazer sideload, configuração de Wi-Fi e de certificados, política de atualização do sistema e bloqueio ou limpeza remotos. O conjunto exato de controles disponíveis em um determinado aparelho depende do OEM, da versão do Android e do EMM; por isso descrevemos esses dispositivos como controlados por políticas e gerenciados centralmente e confirmamos os controles específicos no hardware-alvo, em vez de citar uma lista de recursos a partir do menu de um console.

• Dispositivo corporativo inscrito com o DPC definido como device owner
• Política para todo o dispositivo, em vez de um contêiner de trabalho separado
• Conta de usuário com acesso a aplicativos profissionais controlados pela organização
• Uso pessoal restrito conforme a política da organização
• O escopo de controle varia conforme o OEM, a build do Android e o EMM — confirmado por modelo

O que significa dispositivo dedicado

Um dispositivo dedicado é um dispositivo totalmente gerenciado bloqueado em uma finalidade definida, normalmente sem um usuário nomeado associado a ele. O padrão se aplica a quiosques, terminais voltados ao público, aparelhos compartilhados entre turnos e ferramentas de linha de frente que executam uma tarefa ou um conjunto reduzido de tarefas o dia todo. Como o modo dedicado é um subconjunto do totalmente gerenciado, ele herda o mesmo controle de device owner e depois restringe o ambiente de execução à sua função, normalmente por meio do lock task mode: o DPC declara quais pacotes podem ser fixados e — em builds compatíveis — quais recursos do sistema, como a barra de status, o botão home, a visão geral e as notificações, permanecem acessíveis enquanto o dispositivo está bloqueado. As orientações do Google sobre dispositivos dedicados e lock task mode definem o que a plataforma expõe; um EMM, então, disponibiliza algum subconjunto disso. Duas consequências práticas decorrem daí. Primeiro, um dispositivo dedicado costuma ser sem usuário — nenhuma Conta do Google fica conectada e os aplicativos chegam pelo EMM, e não por um download iniciado pelo usuário. Segundo, a força do bloqueio é uma propriedade da política e do launcher, não do nome do modo — por isso o mesmo modo pode produzir um quiosque rígido de aplicativo único ou um brando dispositivo de turno com quatro aplicativos. Essas configurações podem ser ajustadas para MDM/EMM e restritas ao uso pretendido, com o comportamento confirmado no hardware escolhido antes da aprovação de um lote.

• Finalidade única ou conjunto de tarefas com escopo restrito
• Muitas vezes sem usuário, compartilhado, sem operador ou voltado ao público
• O lock task mode fixa os pacotes aprovados e reduz a interface do sistema (UI)
• Um subconjunto bloqueado do modo totalmente gerenciado, não um nível de privilégio separado

Onde o perfil de trabalho se encaixa — e por que o uso pessoal muda a resposta

Os dois modos corporativos são frequentemente comparados a uma terceira configuração que se comporta de forma completamente distinta. Em um dispositivo de propriedade do funcionário, o perfil de trabalho torna o DPC profile owner de um contêiner gerenciado: aplicativos de trabalho, contas corporativas e dados profissionais ficam dentro dele, a organização pode limpar esse contêiner, e tudo o que está fora — o launcher, os aplicativos pessoais, as fotos, o comportamento de restauração de fábrica do aparelho — continua pertencendo ao dono. Esse é um projeto deliberado, não uma lacuna a ser contornada. Isso também significa que uma configuração em dispositivo do funcionário não entrega controle de todo o dispositivo, não permite fixar o aparelho em modo quiosque e não pode ser convertida em uma sem limpar o hardware. Quando um briefing de projeto diz “queremos comportamento de quiosque, mas a equipe também usa os celulares para fins pessoais”, é aí que a especificação precisa ser resolvida, em vez de adiada. O Android Enterprise oferece, sim, um dispositivo corporativo com perfil de trabalho — arranjo frequentemente abreviado como COPE —, em que o provisionamento ainda passa pelo device owner e um perfil de trabalho é criado sobre ele. A partir do Android 11, o lado pessoal desse arranjo é intencionalmente protegido: o administrador não recebe um inventário dos aplicativos pessoais, e o poder sobre todo o dispositivo fica limitado a controles do tipo gestão de ativos, como política de atualização do sistema, identificadores do dispositivo, proteção contra restauração de fábrica e um subconjunto definido de restrições. O conjunto exato depende da versão do Android e do EMM e precisa ser verificado em relação ao que o aprovador acredita ter sido acordado. Em implantações nas quais o dispositivo inteiro pertence à tarefa, totalmente gerenciado ou dedicado é a resposta honesta; quando os funcionários realmente precisam de uso pessoal em hardware da empresa, o perfil de trabalho em dispositivo corporativo é o modo a especificar, e a conversa de aceitação passa a ser sobre quais controles sobrevivem ao limite de privacidade. Nossos programas de dispositivos Android gerenciados e controlados partem dessa decisão, em vez de presumi-la.

• Perfil de trabalho em dispositivo do funcionário: profile owner, apenas o contêiner, sem controle de todo o dispositivo
• Perfil de trabalho em dispositivo corporativo (COPE): provisionamento como device owner e, em seguida, um perfil de trabalho com o lado pessoal protegido
• Totalmente gerenciado e dedicado: hardware de uso exclusivamente profissional, política para todo o dispositivo
• Não é possível construir um quiosque sobre um perfil de trabalho em dispositivo do funcionário

Diferenças de política e de experiência do usuário

Os dois modos corporativos divergem mais no que a pessoa diante do dispositivo experimenta. Um dispositivo de funcionário totalmente gerenciado costuma manter uma tela inicial reconhecível e um ambiente com vários aplicativos atrás de um login de usuário, com as configurações podadas em vez de removidas. Um dispositivo dedicado se apoia no lock task mode para fixar um único aplicativo ou um pequeno launcher gerenciado, suprimir as saídas e ocultar a maior parte da interface do sistema, de modo que um membro do público ou um operador entre turnos não consiga sair da tarefa. Se um dispositivo dedicado mostra um ou vários aplicativos é uma decisão de política, não uma propriedade do modo. A camada que entrega o bloqueio visível — um launcher gerenciado, a política de quiosque do próprio EMM ou o lock task mode acionado diretamente pelo DPC — é outra escolha à parte, e vale a pena torná-la explícita: launcher personalizado versus modo quiosque versus MDM trata dessa decisão de camada em detalhe. Tratamos o bloqueio exato como configurável e sujeito a validação no dispositivo-alvo, porque é no comportamento da interface do sistema em torno de notificações, caixas de diálogo, avisos de acessibilidade e sobreposições do OEM que as vias de escape do quiosque costumam ser encontradas.

• Totalmente gerenciado: login do usuário, vários aplicativos, configurações podadas mas visíveis
• Dedicado: lock task mode fixando um aplicativo ou um pequeno launcher
• Dispositivos dedicados podem ter um ou vários aplicativos, conforme a política
• A camada de entrega do launcher/quiosque é uma decisão separada do modo

Vias de inscrição que alcançam o device owner

Os dois modos corporativos são provisionados como device owner pelas mesmas vias do Android Enterprise e se diferenciam depois pela política que o EMM aplica. Esse é o fato mecânico mais útil desta página: a forma como o dispositivo sai do assistente de configuração determina se ele é device owner ou não, e existe apenas uma janela estreita em que o device owner pode ser definido. Na prática, a via precisa ser executada em um dispositivo restaurado de fábrica ou recém-saído da caixa, antes de adicionar uma conta pessoal e antes de concluir a configuração — por isso a inscrição é uma atividade de bancada, e não algo que um usuário de campo faz depois de desembalar o aparelho na própria mesa. A inscrição zero-touch é a via que escala, mas é uma condição de cadeia de suprimentos antes de ser técnica: os dispositivos elegíveis precisam ser adquiridos por meio de um revendedor zero-touch autorizado e registrados na sua conta, com uma configuração atribuída antes do primeiro boot. Um código QR apresentado no assistente de configuração é a alternativa manual mais comum e a via de preparação habitual para remessas; o NFC e o identificador de DPC digitado no assistente de configuração continuam válidos em builds compatíveis, mas atendem melhor a pequenas quantidades ou a situações específicas de OEM. Cada via traz pré-requisitos que falham silenciosamente na preparação, e não de forma evidente no escopo — rede na tela de boas-vindas, a conta correta de revendedor, um dispositivo genuinamente limpo. A comparação de vias em métodos de provisionamento de dispositivos Android aprofunda os próprios métodos de entrada; a tabela abaixo os lê pela ótica de quais modos de gerenciamento eles alcançam e de como costumam falhar.

Quanto custa, de fato, mudar o modo depois

Nem toda mudança de ideia é cara; o truque é saber quais são. Passar de totalmente gerenciado para dedicado, ou o contrário, normalmente é uma mudança de política: o dispositivo já é device owner, então apertar uma frota no lock task mode, adicionar um launcher gerenciado ou liberar um terminal de volta para uma configuração com vários aplicativos é um envio de política e um reinício do aplicativo, não um retorno à bancada. Entrar ou sair de uma configuração com perfil de trabalho é um trabalho de outra ordem. O device owner só pode ser estabelecido durante a janela de provisionamento descrita acima, de modo que um dispositivo com perfil de trabalho em aparelho pessoal não pode ser promovido a totalmente gerenciado; ele precisa ser restaurado de fábrica e reprovisionado por uma via de device owner. O mesmo vale no sentido inverso e entre as variantes corporativas: mudar uma frota já entregue de totalmente gerenciada para perfil de trabalho em dispositivo corporativo, ou o contrário, exige um estado limpo por unidade. Na escala de um programa, o custo não é a restauração em si, mas a logística ao redor dela — recolher dispositivos nos locais, prepará-los novamente, registrar de novo números de série e IMEIs e refazer a aceitação sobre a nova linha de base. Por isso o modo de gerenciamento pertence à especificação da configuração antes de o primeiro lote ser preparado, e por isso uma amostra de avaliação e uma remessa piloto de vinte a cem unidades são o lugar certo para descobrir que o modo estava errado — e não depois que o programa inteiro foi entregue. Programas desse tipo são cotados a partir de cerca de 500 unidades, portanto um erro de modo descoberto em campo é um engano medido em toques por dispositivo em toda a frota.

• Totalmente gerenciado ↔ dedicado: normalmente uma mudança de política, sem nova inscrição
• Perfil de trabalho → totalmente gerenciado: restauração de fábrica e reprovisionamento, por unidade
• Totalmente gerenciado ↔ perfil de trabalho em dispositivo corporativo: estado limpo exigido por unidade
• Refazer a preparação em campo custa logística, não licenças — decida o modo na especificação da configuração

O que a restauração de fábrica faz com o modo

O modo de gerenciamento não é uma propriedade que sobreviva sozinha a uma limpeza. A restauração de fábrica devolve o hardware a um estado não provisionado, como recém-saído da caixa, e se ele volta gerenciado depende inteiramente da via pela qual foi inscrito. Um dispositivo zero-touch é a exceção que torna a diferença visível: como a atribuição fica no console zero-touch, vinculada ao identificador do hardware, um dispositivo restaurado que alcança a rede durante a configuração recebe novamente a sua configuração e se reprovisiona sozinho. Um dispositivo inscrito por código QR, NFC ou identificador de DPC não tem essa memória — depois de uma restauração, ele é um aparelho de varejo comum até que alguém repita a via em uma bancada. A política pode reduzir a chance de uma restauração não planejada: o device owner pode impedir que o usuário faça a restauração de fábrica pelas configurações, e a proteção contra restauração de fábrica pode exigir uma conta aprovada depois disso, embora combinações de teclas de recuperação e ferramentas de serviço do OEM se comportem de maneira diferente entre fabricantes e precisem ser verificadas no modelo exato, em vez de presumidas. Para uma implantação, isso vira uma questão de aceitação, e não de curiosidade. A amostra deve ser restaurada deliberadamente e trazida de volta, o estado final esperado deve ser registrado e a instrução de recuperação deve ser escrita para quem for guardar os dispositivos — porque, em uma frota dedicada, a diferença entre “volta sozinho ao quiosque” e “chega ao local como um celular de consumo em branco” é a diferença entre um chamado de suporte e o deslocamento de uma equipe.

• A restauração remove o device owner; o modo não fica armazenado no hardware
• O zero-touch oferece novamente a configuração na configuração seguinte, com rede disponível
• As vias por QR, NFC e identificador de DPC exigem repetição na bancada
• As restrições de restauração e a proteção contra restauração de fábrica dependem do OEM e do modelo

Matriz de decisão por caso de uso

A escolha entre os modos se resume a quem detém o dispositivo, ao que ele faz o dia todo e a se alguém precisa dele para outra coisa. Um trabalhador de campo que precisa de vários aplicativos de trabalho, de um login e de uma tela inicial familiar aponta para o totalmente gerenciado; um quiosque, um terminal de inspeção, um conjunto de sala de aula ou um terminal de varejo compartilhado aponta para uma configuração dedicada; um dispositivo que também precise atender ao uso pessoal aponta para longe de ambos e em direção a um perfil de trabalho em dispositivo corporativo. Muitos programas operam mais de um modo — aparelhos gerenciados para a equipe ao lado de terminais dedicados para a tarefa voltada ao público — e não há penalidade nisso, desde que cada grupo tenha seu próprio conjunto de políticas, sua própria amostra e seu próprio registro de aceitação. A matriz abaixo é indicativa, e não prescritiva; o modo certo para o seu hardware, os seus aplicativos e os seus mercados é definido no escopo e depois comprovado na amostra.

Registrar o modo na amostra, na matriz e no lote

Um modo de gerenciamento escolhido em uma reunião é uma opinião; um modo de gerenciamento reproduzido em bancada é uma linha de base. Em uma implantação, a decisão precisa sobreviver em três materiais. A amostra com controle de versão comprova que o modelo exato, o SKU regional e a build de firmware alcançam o modo pretendido a partir de um estado limpo, pela via pretendida, e que a política se comporta como descrito depois disso — inclusive após uma reinicialização e após o cenário de restauração acordado. A matriz de aceitação registra isso como linhas aprovadas, reprovadas ou condicionais, vinculadas a versões e não a um dispositivo esquecido na gaveta de alguém: modo alcançado, via utilizada, pacotes e recursos do lock task, configurações permitidas, vias de escape testadas, estado final após a restauração e as limitações conhecidas que permanecem em aberto. A preparação do lote, então, reproduz o estado aceito unidade a unidade e registra o que foi reproduzido — número de série, IMEI, confirmação da inscrição, versão da política e a verificação de QA contra a amostra de referência —, com uma regra de interrupção quando uma unidade se desvia. Essa progressão é exatamente a distinção traçada em dispositivos Android prontos para MDM versus prontos para implantação: um dispositivo visível em um console demonstrou capacidade de gerenciamento, enquanto um dispositivo aprovado para um lote demonstrou um estado reproduzível. A seleção do modo é uma das primeiras entradas dessa cadeia e uma das mais caras de revisitar, e por isso pertence ao escopo de personalização do dispositivo antes de o hardware ser encomendado, e não depois que ele chega. Informe o dispositivo ou o formato-alvo, o aplicativo, o EMM, os controles exigidos, os países-alvo e a faixa de quantidade, e a análise de viabilidade identificará de qual modo o requisito realmente precisa, qual via de inscrição a cadeia de suprimentos consegue sustentar e o que a amostra precisa comprovar antes da aprovação de um lote.