Comandos remotos
O DataDike RMM combina comandos padrão do Google (via AMAPI) com ações custom via nosso agent (via FCM). Cada seção abaixo enumera o que existe, como acionar via portal e qual limitação Google impõe.
Onde ficam no portal
Todos os comandos ficam no toolbar do detalhe do dispositivo em /sysadmin. Ao clicar em um device na tabela, aparece a barra de ações. Comandos destrutivos (Wipe) sempre abrem modal de confirmação.
Comandos padrão (Android Management API)
LOCK — bloquear tela
Modos suportados: Fully Managed, Dedicated, WPCO, BYOD (só profile)
Efeito: Tela bloqueia imediatamente exigindo senha (ou trava o work profile no BYOD)
Uso típico: Suspeita de perda; parada temporária
API:
enterprises.devices.issueCommand({ type: "LOCK" })Backend:
POST /api/v1/google/device-command/:deviceIdbody{ "action": "LOCK" }
WIPE — reset de fábrica
Modos suportados: Fully Managed, Dedicated, WPCO (full ou só profile), BYOD (só profile)
Efeito: Apaga TODOS os dados do device (ou só do work profile no BYOD)
Parâmetros opcionais:
reason(≤200 chars) — texto mostrado ao usuáriowipeDataFlags: ["WIPE_EXTERNAL_STORAGE"]— apagar também o cartão SDwipeDataFlags: ["PRESERVE_RESET_PROTECTION_DATA"]— manter Factory Reset Protection
Guardrail: o portal EXIGE
confirm: trueno payload — o modal do frontend força confirmação explícitaAPI:
issueCommand({ type: "WIPE", wipeDataFlags, reason })
WIPE é irreversível. Sempre confirme o deviceId correto no modal antes de disparar. O portal registra a ação em -logs com o admin que executou.
REBOOT — reiniciar dispositivo
Modos suportados: Apenas Fully Managed. Não funciona em WPCO nem BYOD por decisão do Google.
Efeito: Reinicialização imediata
API:
issueCommand({ type: "REBOOT" })Uso típico: Aplicar update de sistema, resolver travamento
RESET_PASSWORD — redefinir senha da tela de bloqueio
Modos suportados: Fully Managed, WPCO
Parâmetros:
newPassword(opcional — deixe vazio para limpar)resetPasswordFlags:["REQUIRE_ENTRY"],["DO_NOT_ASK_CREDENTIALS_ON_BOOT"],["LOCK_NOW"]
Limitação: Android 14+ exige mínimo 6 caracteres
API:
issueCommand({ type: "RESET_PASSWORD", newPassword, resetPasswordFlags })
START_LOST_MODE / STOP_LOST_MODE
Modos suportados: Apenas Fully Managed ou WPCO. Não em BYOD.
Efeito: Dispositivo vai para "modo perdido" — trava, mostra mensagem + contato no lockscreen, desabilita UI normal
Parâmetros (pelo menos um obrigatório):
lostMessage— texto mostrado (ex.: "Se encontrado, ligue para o número abaixo")lostPhoneNumber— telefone de contatolostEmailAddress— e-maillostStreetAddress— endereçolostOrganization— nome da organização
API:
issueCommand({ type: "START_LOST_MODE", startLostModeParams: { ... } })
CLEAR_APP_DATA — limpar dados de app específico
Modos suportados: Todos
Parâmetros:
packageNames: ["com.example.app", ...]Efeito: Apaga os dados dos apps listados (equivalente a "Clear data" nas configurações)
Uso típico: App corrompido, forçar re-login, saneamento de troubleshooting
Comandos custom (via nosso agent + FCM)
Estes complementam o AMAPI onde o Google não tem cobertura nativa.
LOCATE_ON_DEMAND
Modos suportados: Qualquer modo onde nosso agent esteja instalado como companion
Efeito: O agent recebe um push FCM, faz snapshot do FusedLocation e envia para o backend imediatamente (fora do cronograma de telemetria normal)
Uso típico: "Onde está esse dispositivo agora?"
Estado: Em roadmap — placeholder no portal
RING
Modos suportados: Qualquer modo com nosso agent
Efeito: Toca alarme no dispositivo (não silenciável do lockscreen) até intervenção manual
Uso típico: Encontrar aparelho perto (esquecido em sala, mochila)
Estado: Em roadmap
PUSH_MESSAGE
Modos suportados: Qualquer modo com nosso agent
Efeito: Modal com mensagem custom exibido no dispositivo, exigindo dismiss explícito
Uso típico: Comunicação urgente ao usuário (sem depender do sistema de push do sistema)
Estado: Em roadmap
O que Google não permite
Estas são decisões de política do Google — nenhum modo destrava. Não prometer para o cliente.
Screen mirroring / remote view
MediaProjection exige consentimento do usuário por sessão. Nenhum DPC (nem o Android Device Policy oficial do Google) pode automatizar isso. Ferramentas de "remote support" tipo TeamViewer usam add-ons OEM-signed em cada fabricante — não é padrão Android.
Gravação de chamadas
Play Policy proíbe apps de call recording (categoria banida). Android 10 fechou o path técnico (áudio de call não é mais capturável por apps 3rd-party).
Ler apps ou dados do lado pessoal (BYOD)
Impossível por design. O work profile é um container Linux separado. DPC no work profile não enxerga UID/PID do container pessoal.
Push de APK arbitrário via URL
Não existe endpoint AMAPI para isso. Alternativas: (a) publicar como Private App no Managed Google Play; (b) em Fully Managed com installUnknownSourcesAllowed, usar PackageInstaller via nosso agent — mas isso é escopo custom.
Captura silenciosa de câmera / microfone
Android 12+ mostra indicador obrigatório (bolinha verde) sempre que câmera ou microfone estão ativos. Não é suprimível programaticamente, nem por DPC.
Full backup de app data
Permissão BACKUP é signature-only (só apps OEM assinam). Nenhum DPC 3rd-party consegue.
Auditoria
Cada comando emitido pelo portal é gravado em {enterpriseId}-{enterpriseName}-logs com:
userId(admin que disparou)type(ex.:DEVICE_COMMAND_LOCK,DEVICE_COMMAND_WIPE)description(ex.:User Walter Neto issued WIPE on device XYZ (reason: device reported lost))timestamp
Consultável via /api/v1/logs/interaction-logs.
Long-Running Operation (LRO)
A API do Google retorna uma Operation (LRO) para cada comando. O portal atualmente não faz polling do status — assume que o comando foi despachado (HTTP 202). Se precisar verificar o resultado, use:
O operationName vem no corpo da resposta do endpoint POST /google/device-command/:deviceId.
Atualizado
Isto foi útil?