Como desenvolver software personalizado para o Rokid AI Glasses Enterprise

Resumo executivo

Rokid AI Glasses Enterprise pode ser transformado em um dispositivo empresarial feito sob medida, em vez de ser usado apenas com aplicativos pré-configurados. A documentação atual do Sprite Enterprise da Rokid disponibiliza um Glasses SDK para aplicativos executados diretamente no Glass3, um Phone SDK para aplicativos complementares Android e serviços OpenAPI para integrações no lado da nuvem. Juntas, essas camadas oferecem suporte a conectividade do dispositivo, mensagens, transferência de arquivos, captura de câmera e mídia, vídeo ao vivo, funções de voz, serviços de IA, reconhecimento, estado do dispositivo e fluxos de trabalho empresariais.

Para uma equipe de desenvolvimento, o caminho prático é familiar: criar projetos Android nativos no Android Studio, adicionar o repositório Maven e as dependências do SDK da Rokid, executar a demonstração oficial de dois projetos da Rokid, estabelecer o Bluetooth para descoberta e controle, passar para o Wi-Fi P2P para arquivos grandes e áudio/vídeo e, então, conectar o fluxo de trabalho ao backend da empresa. Um aplicativo autônomo para os óculos também é possível quando o caso de uso não exige um celular complementar.

Além do SDK, o principal valor vem de substituir uma experiência genérica de wearable por um fluxo de trabalho controlado. Um técnico pode receber uma ordem de serviço, ver a próxima instrução no display, confirmar uma etapa por voz ou por entrada de hardware, capturar evidências visuais e enviar o resultado para um CMMS, ERP ou plataforma personalizada. Isso torna os óculos relevantes para inspeções, serviço de campo, trabalho guiado, logística, documentação e outros processos com as mãos livres. As principais ressalvas são o suporte ao SDK nativo apenas para Android, a compatibilidade de versões e de OTA, a exigência de chaves de API para determinados serviços online e um display compacto de 480 x 640 que exige um design de interface cuidadoso.

O que a Rokid disponibiliza aos desenvolvedores

A Rokid divide a pilha empresarial em um SDK de dois lados mais uma plataforma OpenAPI separada. Entender essa divisão antes de escrever código evita um erro comum: tentar fazer os óculos fazerem tudo quando um celular ou backend é mais adequado para rede, autenticação, armazenamento ou integração com sistemas de negócio.

Aplicativo dos óculos:

• Executado em: Rokid Glass3
• Responsabilidade típica: Renderiza a interface do wearable e acessa recursos do lado dos óculos, como câmera/mídia, estado do dispositivo, mensagens, voz, IA e reconhecimento, por meio do Glasses SDK.

Aplicativo complementar:

• Executado em: Celular Android
• Responsabilidade típica: Descobre o Glass3 e se conecta a ele, gerencia Bluetooth e Wi-Fi P2P, troca mensagens/arquivos, recebe streams de mídia e pode retransmitir dados de negócio.

Camada de nuvem / de negócio:

• Executado em: Seu backend + Rokid OpenAPI, quando aplicável
• Responsabilidade típica: Armazena dados de negócio, autentica usuários, conecta sistemas ERP/CMMS/CRM e pode usar módulos da Rokid OpenAPI, como APIs de mensagens ou de dispositivos, quando provisionados.

Veredito prático: Para software empresarial personalizado, a arquitetura útil costuma ser “interface enxuta no wearable + serviços de dispositivo confiáveis + lógica de negócio no celular/backend”. Manter a experiência dos óculos focada reduz a complexidade da interface e facilita a manutenção do projeto, preservando ao mesmo tempo a interação com as mãos livres onde ela importa.

Visão geral da pilha de desenvolvimento

• Hardware-alvo na documentação empresarial pública: Rokid Glass3
• Modelo de desenvolvimento: Desenvolvimento de aplicativos Android nativos
• Artefato do Glasses SDK: com.rokid.security:glass3.open.sdk
• Artefato do Phone SDK: com.rokid.security:phone.sdk
• Dependência atual exibida no Quick Start: 2.2.0-E para ambos os SDKs
• Entrada mais recente visível no changelog na época da pesquisa: V2.2.0-E, datada de 6 de agosto de 2026, com OTA recomendado 1.19.e006-20260806-150201 ou posterior.
• Ferramentas recomendadas: Android Studio 2022+, JDK 17+
• Ambiente da demonstração: Android SDK 34, JDK 17, celular Android, Rokid Glass3
• Sistema de coordenadas do display dos óculos: Fixo em 480 x 640, orientação retrato
• Principais transportes locais: Bluetooth clássico e Wi-Fi P2P
• Autenticação na nuvem: Chave de API empresarial (Enterprise API Key) para a Rokid OpenAPI e determinados serviços online
• Plataforma de celular compatível: Android; o FAQ público informa que iOS e HarmonyOS nativo não são compatíveis com o Glass3 SDK

O que é possível criar com o Rokid AI Glasses Enterprise?

O SDK público é abrangente o suficiente para dar suporte a mais do que um único aplicativo de demonstração. O produto exato que você cria depende de quais recursos você combina e de quanta lógica mantém no wearable.

Serviço de campo guiado: exibir uma instrução por vez, confirmar a conclusão, capturar fotos ou vídeos e devolver evidências estruturadas a um sistema de ordens de serviço.

Inspeção e conformidade: apresentar checklists, usar captura de câmera ou reconhecimento, anexar evidências com registro de data e hora e escalar exceções.

Fluxos de trabalho de armazém e logística: mostrar informações de separação ou de tarefas, trocar comandos leves via Bluetooth e usar integrações de leitura especializadas quando necessário.

Assistência visual remota: receber um stream de vídeo ao vivo no lado complementar ou integrar um caminho dedicado de colaboração remota. A Rokid removeu as chamadas RTC do Phone SDK principal na versão 2.1.7-E, portanto a colaboração em tempo real deve ser arquitetada com base no Android e na Web: o Remote Collaboration SDK da Rokid ou seu próprio transporte aprovado, em vez de presumir que esteja embutida no SDK base.

Assistente de IA empresarial: combinar entrada de fala, TTS, chat de IA ou serviços de IA da própria empresa com uma interface específica do fluxo de trabalho, em vez de expor os usuários a um chatbot genérico.

Captura de evidências e documentação: acionar imagens, vídeo ou áudio, transferir mídias maiores via P2P e sincronizar os resultados com um backend.

Wearable dedicado de propósito único: iniciar o aplicativo da empresa automaticamente após a reinicialização e mapear eventos de hardware compatíveis para ações do fluxo de trabalho, sujeito à validação no firmware de destino.

Passo a passo: como desenvolver software personalizado para o Rokid AI Glasses Enterprise

Etapa 1: Defina o fluxo de trabalho antes de escolher a arquitetura

Comece pelo processo operacional, não pela lista do SDK. Anote exatamente o que o trabalhador precisa ver, dizer, capturar e confirmar. Em seguida, decida qual dispositivo deve ser responsável por cada função. Um aplicativo de wearable bem delimitado geralmente mostra informações concisas e captura entradas, enquanto o celular ou o backend cuida da lógica de negócio mais pesada.

Aplicativo autônomo nos óculos:

• Mais indicado para: Fluxo de trabalho local simples, captura no próprio dispositivo, operação offline ou com conectividade limitada
• Vantagens: Menos componentes, experiência direta no wearable
• Contrapartida: Você precisa tratar mais lógica de armazenamento/rede nos óculos; algumas funções online ainda exigem credenciais ou conectividade

Óculos + celular Android:

• Mais indicado para: A maioria dos pilotos empresariais, mídia ao vivo, transferência de arquivos, controle remoto, aplicativo de negócio complementar
• Vantagens: Caminho de conectividade mais bem documentado; o celular pode cuidar da autenticação, da rede e da interface que não cabe na lente
• Contrapartida: Exige um celular Android e uma lógica de reconexão robusta

Óculos + celular + backend:

• Mais indicado para: Integração com ERP/CMMS/CRM, trilha de auditoria, ordens de serviço gerenciadas centralmente, serviços de IA
• Vantagens: Mais adequado para fluxos de trabalho de negócio escaláveis e governança de dados
• Contrapartida: Exige mais trabalho de integração, segurança e engenharia de backend

Recomendação: Para uma primeira prova de conceito B2B, use o modelo óculos + celular Android + backend, a menos que o caso de uso se beneficie claramente de um wearable autônomo. Ele corresponde de perto ao fluxo de dois dispositivos documentado pela Rokid e dá à equipe de desenvolvimento margem para tirar dos óculos a rede, as credenciais e o armazenamento de dados.

Etapa 2: Obtenha o hardware e os acessos corretos

Antes de instalar o Android Studio, confirme que o hardware realmente está no caminho de software empresarial. O FAQ da Rokid informa que as builds empresariais/de trabalho geralmente contêm um “e” na versão do sistema. A documentação do SDK também diferencia sistemas empresariais e de consumo, portanto a identificação do firmware faz parte da configuração do projeto, e não é algo para deixar para depois.

Rokid AI Glasses Enterprise (o hardware Rokid Glasses) executando a build / firmware do sistema empresarial (versão do sistema terminada em "e").

O cabo de depuração de dados do Glass3. A Rokid alerta explicitamente que o cabo de carregamento comum pode alimentar os óculos, mas não pode ser usado pelo Android Studio para depuração.

Um celular Android, se você for usar o Phone SDK.

Um PC de desenvolvimento com Android Studio e JDK 17.

Conta empresarial e API Key, se o projeto for usar a Rokid OpenAPI ou recursos online que exijam autenticação.

Acesso à versão exata de OTA que você pretende implantar em toda a frota do piloto.

Não pule a verificação do cabo: A Rokid lista o cabo de depuração de dados como obrigatório porque ele permite que o Android Studio reconheça os óculos, instale APKs e inspecione logs. Se os óculos carregam, mas não aparecem como dispositivo, verifique o cabo antes de depurar o Gradle, o ADB ou o SDK.

Etapa 3: Prepare o ambiente de desenvolvimento Android

O Quick Start da Rokid recomenda o Android Studio 2022 ou posterior e o JDK 17 ou posterior, e afirma que o Glass3 SDK é compatível com Android 8.0 ou posterior. O guia oficial da demonstração atualmente usa o Android SDK 34. O FAQ da Rokid, por sua vez, recomenda Android 7.0 / API 24 ou posterior e orienta a confirmar a configuração do Gradle no pacote do SDK e na demonstração atuais. Em um projeto real, trate os arquivos Gradle da demonstração como a fonte de referência para a versão exata que você está integrando.

1. Instale o Android Studio 2022 ou mais recente.

1. Instale e selecione o JDK 17 ou mais recente para o Gradle.

1. Instale a versão do Android SDK exigida pela demonstração atual da Rokid. O guia atual da demonstração indica o SDK 34.

1. Ative a depuração Android normal no celular de desenvolvimento.

1. Conecte o Glass3 usando o cabo de depuração de dados e confirme que o Android Studio reconhece um destino semelhante a “Rokid RG-glasses”.

1. Instale a ferramenta de projeção / espelhamento de tela da Rokid se quiser inspecionar a interface do wearable a partir do PC. A Rokid recomenda fortemente a projeção durante o desenvolvimento.

Etapa 4: Execute a demonstração oficial da Rokid antes de criar seu próprio aplicativo

Esta é a etapa prática mais importante de todo o processo. A demonstração oficial valida o ambiente de desenvolvimento, os binários do SDK, as permissões, as conexões de hardware e a combinação de versões antes que seu próprio código se torne mais uma variável.

git clone https://gitee.com/as_pixar/glass3sdkdemo.git

# Demonstração dos óculos
cd glassdemo
./gradlew assembleDebug

# Demonstração do celular
cd ../glass3sdkphonedemo
./gradlew assembleDebug

O repositório contém dois projetos Android separados: um para os óculos e outro para o celular Android. A Rokid recomenda executar primeiro a demonstração do lado do celular e depois a do lado dos óculos. Depois que ambas estiverem instaladas, procure o Glass3 a partir da demonstração do celular e estabeleça a conexão.

1. Inicialização do SDK. Critério de aprovação: os dois projetos iniciam e informam um estado válido do SDK.
2. Bluetooth. Critério de aprovação: o celular encontra o Glass3 e se conecta a ele.
3. Mensagens. Critério de aprovação: mensagens de texto ou de controle trafegam entre o celular e os óculos.
4. Transferência de arquivos pequenos. Critério de aprovação: um arquivo pequeno pode ser trocado sem erros.
5. Wi-Fi P2P. Critério de aprovação: é possível estabelecer um canal P2P para operações de alta largura de banda.
6. Mídia. Critério de aprovação: foto, vídeo ou pré-visualização ao vivo podem ser acionados e recebidos.

Por que isso importa comercialmente: Fica muito mais fácil delimitar o escopo de uma prova de conceito para um cliente quando as funções básicas do dispositivo são validadas primeiro. Assim, você pode dedicar o tempo do projeto ao fluxo de trabalho, à integração e à experiência do usuário propriamente ditos, em vez de diagnosticar uma configuração de SDK não verificada.

Etapa 5: Crie seus próprios projetos e adicione o repositório Maven da Rokid

Quando a demonstração funcionar, crie ou abra seus próprios projetos Android. A Rokid publica os artefatos do SDK por meio de seu repositório Maven. Adicione o repositório junto com o Google e o Maven Central e, em seguida, adicione a dependência dos óculos ao aplicativo do wearable e a dependência do celular ao aplicativo complementar.

// settings.gradle - exemplo simplificado
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
        maven { url 'https://maven.rokid.com/repository/maven-public/' }
    }
}

// Aplicativo dos óculos
implementation('com.rokid.security:glass3.open.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

// Aplicativo do celular Android
implementation('com.rokid.security:phone.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

O Quick Start atual da Rokid mostra a versão 2.2.0-E, com OTA recomendado 1.19.e006-20260806-150201 ou posterior. Equipes empresariais devem fixar e testar uma combinação conhecida de SDK + OTA, em vez de atualizar os componentes automaticamente e de forma independente.

Regra de controle de versões: Antes de um piloto ou de uma versão de produção, registre a build de OTA dos óculos, a versão do Glasses SDK, a versão do Phone SDK, o commit da demonstração e as versões de quaisquer SDKs especializados em uma única matriz de compatibilidade. Execute novamente os testes básicos de conexão e de mídia sempre que algum desses componentes mudar.

Etapa 6: Declare apenas as permissões Android de que seu fluxo de trabalho precisa

O Quick Start da Rokid lista permissões comuns para acesso à rede, Wi-Fi, câmera, microfone, armazenamento, Bluetooth e dispositivos próximos. Nas versões modernas do Android, declarar uma permissão no manifesto não basta no caso de permissões perigosas. Seus aplicativos do celular e dos óculos precisam solicitar as permissões necessárias em tempo de execução e tratar a recusa de forma adequada.

• Busca/conexão Bluetooth: Descoberta de dispositivos, pareamento, mensagens pequenas e controle
• Wi-Fi próximo / Wi-Fi Direct: Conexão P2P para arquivos, imagens, vídeo e streams em tempo real
• Câmera: Captura de foto/vídeo e fluxos de reconhecimento visual
• Microfone: Gravação de áudio, ASR e interação por voz
• Rede / Internet: APIs de backend, serviços online da Rokid, sincronização com a nuvem
• Armazenamento: Manipulação de mídia e de arquivos transferidos, conforme o comportamento do Android / SDK de destino

Recomendação para produção: Não copie todo o manifesto da demonstração às cegas. Minimizar as permissões facilita a revisão de segurança e reduz a chance de os usuários recusarem uma permissão de que o fluxo de trabalho nem precisa.

Etapa 7: Inicialize o Glasses SDK e registre a identidade do seu aplicativo

O aplicativo dos óculos se vincula ao serviço de segurança da Rokid e, em seguida, registra um identificador de cliente. A regra de arquitetura importante é que o aplicativo complementar no celular conheça o mesmo client ID quando os dois lados trocam mensagens específicas do aplicativo.

// Estrutura ilustrativa, simplificada a partir do fluxo de inicialização da Rokid
if (!GlassSdk.isReady()) {
    GlassSdk.bindSecurityService(context, object : IServiceConnectionCallback {
        override fun onServiceConnected() {
            GlassSdk.registerClient("FieldServiceApp", messageCallback)
        }
    })
}

Após a inicialização, os recursos do lado dos óculos são acessados por meio de pontos de entrada de serviço expostos pelo GlassSdk. Os grupos da API pública incluem funções comuns/de dispositivo, Bluetooth clássico, P2P, mensagens, mídia, manipulação de arquivos, voz/IA, reconhecimento e outros serviços. Não inicialize todos os recursos na abertura do aplicativo. Obtenha e ative apenas os serviços necessários para a tela ou a etapa atual do fluxo de trabalho.

Verificação de integridade: Use GlassSdk.isReady() como um sinal de diagnóstico simples antes de chamar os serviços de recursos. Se retornar false, corrija a inicialização ou a vinculação do serviço antes de testar funções de nível mais alto.

Etapa 8: Inicialize o Android Phone SDK com client IDs correspondentes

No lado do celular, inicialize o mecanismo móvel da Rokid e registre os client IDs com os quais o celular vai se comunicar. O Phone SDK da Rokid é a camada de conexão e controle para descoberta de dispositivos, Bluetooth/P2P, mensagens, arquivos, recebimento de mídia, sincronização de configurações e operações relacionadas.

// Esboço no nível da aplicação
val engineParam = EngineParam.Builder()
    .setClientIds(listOf("FieldServiceApp"))
    .setApiKeyCredentials(apiKeyCredentials)
    .build()
IMobileEngine.initSDK(engineParam)

// Verificação de diagnóstico
val ready = PSecuritySDK.getMobileEngineService().isInit()

Se determinados recursos online exigirem API Key Credentials, a demonstração contém informações de autenticação provisórias que devem ser substituídas por credenciais obtidas por meio do processo comercial da Rokid. Mantenha os segredos de nuvem fora do controle de versão e evite incorporar chaves de API de plataforma de longa duração em um aplicativo cliente distribuível.

Etapa 9: Conecte primeiro via Bluetooth e depois use P2P para largura de banda

A Rokid documenta dois padrões de transporte local com funções diferentes. O Bluetooth clássico é adequado para descoberta, conexão, mensagens de controle e arquivos pequenos. O Wi-Fi P2P é o canal mais indicado para imagens, arquivos grandes, vídeo e mídia em tempo real. Usar o transporte errado é um jeito fácil de criar um aplicativo que funciona em uma demonstração, mas parece pouco confiável em campo.

Bluetooth clássico:

• Use para: Descoberta, pareamento, comandos de controle, mensagens JSON compactas, arquivos pequenos
• Papel no design: Plano de controle de baixa largura de banda

Wi-Fi P2P:

• Use para: Arquivos grandes, imagens, vídeo, streams de áudio/vídeo, sincronização de alta taxa de transferência
• Papel no design: Plano de dados de alta largura de banda

Wi-Fi direto nos óculos:

• Use para: Acesso ao backend a partir de um aplicativo dos óculos quando o dispositivo está conectado ao Wi-Fi
• Papel no design: Útil para determinados fluxos autônomos; ainda assim, projete o comportamento offline e de novas tentativas

Um aplicativo empresarial robusto deve tratar as conexões como máquinas de estado, e não como eventos pontuais. Trate explicitamente a perda do Bluetooth, o encerramento do P2P, a suspensão do celular, mudanças de Wi-Fi e a reinicialização dos óculos. O usuário deve receber um status simples, como “reconectando” ou “sincronização pendente”, e não uma exceção do Android ou uma falha silenciosa.

Etapa 10: Defina um pequeno protocolo de aplicativo para mensagens de negócio

A Rokid fornece os serviços de transporte e de mensagens, mas seu aplicativo ainda precisa de um contrato que defina o significado de uma mensagem de negócio. Mantenha esse contrato compacto, versionado e independente da interface. JSON é uma escolha prática para projetos iniciais porque é fácil de inspecionar, embora o formato exato do payload seja uma decisão de design do seu aplicativo, e não uma exigência da Rokid.

{
  "schema": 1,
  "type": "WORK_STEP",
  "workOrderId": "WO-10458",
  "step": 3,
  "title": "Check valve pressure",
  "requiresPhoto": true
}

Ao concluir, os óculos podem devolver uma pequena mensagem de status que faz referência ao ID da ordem de serviço e ao número da etapa. O arquivo de mídia em si deve trafegar pelo caminho de arquivos/mídia P2P, em vez de ser incorporado à mensagem de controle. Essa separação mantém o canal de comandos responsivo e simplifica as novas tentativas.

Etapa 11: Projete a interface dos óculos para 480 x 640, não como um aplicativo de celular

O display do Glass3 usa um sistema de coordenadas fixo de 480 x 640 em orientação retrato. O FAQ da Rokid recomenda posicionar o conteúdo principal na região central de 480 x 400, usar os 160 pixels superiores e os 80 pixels inferiores para informações secundárias e deslocar o conteúdo importante para baixo, porque os cerca de 40 pixels superiores podem apresentar reflexo óptico. O sistema operacional não oferece rotação normal da tela, portanto layouts largos precisam ser projetados dentro da área em retrato.

Mostre uma tarefa, instrução ou decisão por vez. Painéis longos não combinam com a lente.

Use fundo preto sempre que possível. A Rokid o recomenda para reduzir a sensação de piscar durante a inicialização ou as transições.

Não coloque textos ou botões críticos na área de reflexo dos ~40 px superiores.

Deixe as mudanças de estado evidentes sem depender de uma codificação de cores complexa. A Rokid recomenda o verde como estilo visual principal.

Ofereça um estado de conexão claro e um estado “sincronizado / pendente” claro para os dados de negócio.

Mantenha os alvos de interação simples o bastante para serem operados com entradas de hardware compatíveis ou por voz, sem exigir uma navegação precisa no estilo touch.

Implicação para o negócio: O display é pequeno, mas isso pode ser uma vantagem para trabalhos procedimentais. Ele incentiva as equipes de software a remover informações não essenciais e a exibir apenas a próxima ação de que o trabalhador precisa.

Etapa 12: Adicione recursos de câmera, foto, vídeo e pré-visualização ao vivo

O Glasses SDK disponibiliza recursos de mídia para foto, vídeo, áudio e pré-visualização. O Phone SDK pode receber streams de mídia dos óculos. O FAQ da Rokid indica um stream de vídeo padrão de 1080P a aproximadamente 15 a 19 quadros por segundo, com cerca de 300 ms de latência de reprodução no celular, e observa que a saída pode ser H.264 ou NV21 decodificado, dependendo da API e do caminho da demonstração. Trate esses números como orientação de implementação atual, e não como um SLA garantido.

Use a captura de imagens estáticas para evidências de inspeção, comprovação de conclusão e processamento posterior por IA.

Use H.264 quando o celular ou o backend precisar principalmente encaminhar ou armazenar o stream. O changelog da versão 2.1.8-E da Rokid adicionou controle sobre a decodificação automática de H.264 para NV21, permitindo evitar decodificações desnecessárias.

Use NV21 quando um pipeline de visão computacional no lado do celular precisar de quadros decodificados.

Use Wi-Fi P2P para pré-visualização ao vivo e transferência de mídia, em vez de Bluetooth clássico.

Se você precisar de câmera com sobreposição na tela no resultado gravado, consulte as APIs atuais de AR Mix / gravação AR da Rokid e verifique a correspondência com a versão do SDK instalada.

Um detalhe prático do FAQ da Rokid é importante para fluxos de evidências: após um upload P2P bem-sucedido, as imagens nos óculos podem ser apagadas pelo sistema. Trate a cópia recebida com sucesso no celular ou no backend como a fonte oficial para o negócio e confirme a conclusão do upload antes de avançar a ordem de serviço.

Etapa 13: Adicione voz, TTS e IA de forma criteriosa

A voz pode ser valiosa quando os trabalhadores não podem usar as mãos, mas deve estar vinculada a ações explícitas do fluxo de trabalho. A documentação do SDK do lado dos óculos disponibiliza recursos de ASR, TTS, tratamento de comandos offline e chat de IA. Atualmente, o FAQ informa que o TTS offline exige o SDK 2.2.0 ou posterior, embora o changelog liste o serviço de TTS offline a partir da versão 2.1.2; teste-o na versão que você fixou. O ASR offline aberto não é compatível por padrão no momento. Para conversão de fala em texto offline, a Rokid direciona os desenvolvedores a serviços privados de ASR/TTS, em vez de afirmar que existe um caminho de ASR offline integrado.

Palavras de comando offline:

• Bom uso: Comandos curtos e fixos, como “próximo”, “voltar”, “capturar”
• Observação de design empresarial: Bom para controle determinístico com as mãos livres

ASR online:

• Bom uso: Conversão livre de fala em texto
• Observação de design empresarial: Exige configuração de rede/serviço e deve ter comportamento de fallback

TTS / TTS offline:

• Bom uso: Ler instruções, avisos ou confirmações curtas
• Observação de design empresarial: Útil quando o display deve permanecer minimalista

Chat de IA / IA privada:

• Bom uso: Assistência contextual ou interpretação
• Observação de design empresarial: Mantenha o modelo subordinado ao fluxo de trabalho. Valide o tratamento de dados, a latência e os limites das respostas.

Etapa 14: Conecte o fluxo de trabalho ao seu backend com segurança

Há duas questões distintas sobre o backend: como seu próprio aplicativo chega aos seus sistemas de negócio e se você vai usar a Rokid OpenAPI. Seu aplicativo pode enviar dados por meio do celular pareado, ou um aplicativo dos óculos pode acessar a internet diretamente quando o Glass3 está conectado ao Wi-Fi. Para sistemas da empresa, APIs de backend padrão normalmente são o ponto de integração mais limpo, porque credenciais, logs de auditoria, validação de dados e regras de negócio permanecem no servidor.

A Rokid OpenAPI é uma camada de plataforma separada. A documentação oficial exige uma conta empresarial ativada e uma API Key. As requisições são autenticadas com um token Bearer, as chaves criadas expiram e a validade padrão é de um mês, salvo configuração em contrário. A Rokid alerta explicitamente para não expor chaves de API em repositórios públicos nem em clientes.

Regra de segurança: Use um proxy no servidor para as credenciais da plataforma Rokid sempre que a arquitetura permitir. Um APK de celular ou dos óculos pode ser inspecionado. Não presuma que esconder uma chave de API em código Kotlin ou nativo a torna secreta.

Os módulos atuais da Rokid OpenAPI incluem APIs de mensagens e de dispositivos, entre outras funções empresariais (observe que essas APIs de mensagens e de dispositivos só podem ser acessadas se os dispositivos estiverem registrados no console Lingmou da Rokid). Por exemplo, a API de dispositivos pode consultar unidades Glass registradas, enquanto a API de mensagens pode enviar uma mensagem de negócio a um dispositivo de destino. Use esses serviços apenas quando eles resolverem uma necessidade real de implantação. Um backend próprio da empresa continua sendo o lugar certo para ERP, CMMS, CRM, identidade e orquestração de fluxos de trabalho.

Etapa 15: Configure comportamentos empresariais, como inicialização automática e tratamento de teclas

Um wearable se torna mais útil nas operações quando o usuário não precisa navegar por um launcher no estilo de consumo toda manhã. A Rokid documenta um mecanismo de inicialização automática que pode abrir um aplicativo configurado após o boot em sistemas empresariais compatíveis. Também documenta a personalização de eventos de hardware e, no changelog da versão 2.1.9-E, APIs de listener/interceptação de eventos.

Use a inicialização automática em fluxos dedicados de inspeção, segurança ou industriais, nos quais os óculos devem abrir diretamente no aplicativo de negócio.

Adie brevemente as tarefas que dependem do SDK após o boot e verifique se os serviços estão prontos antes de iniciar o fluxo de trabalho.

Mapeie os eventos de teclas compatíveis para um pequeno número de ações significativas, como confirmar, capturar ou cancelar.

Valide todos os recursos de inicialização automática ou interceptação no firmware empresarial de destino, pois alguns comportamentos no nível do sistema dependem da versão.

Sempre preserve um caminho de suporte/recuperação. Um fluxo de trabalho bloqueado do qual um administrador não consegue sair é um risco operacional.

Etapa 16: Implemente comportamentos offline, de novas tentativas e de recuperação

Uma demonstração costuma presumir Bluetooth, Wi-Fi e acesso à nuvem perfeitos. Uma implantação em campo não pode fazer isso. Persista o estado mínimo do fluxo de trabalho necessário para sobreviver a uma desconexão do celular, a uma falha de P2P ou a uma queda temporária da rede. Cada ação de negócio deve ser idempotente sempre que possível, para que novas tentativas não criem eventos de ordem de serviço ou registros de mídia duplicados.

Armazene em cache o ID da ordem de serviço atual, o ID da etapa e a última ação confirmada.

Coloque em fila os resultados não enviados, com um estado visível de “sincronização pendente”.

Use IDs de operação únicos para que o backend possa rejeitar duplicatas com segurança.

Reconecte primeiro o Bluetooth e só depois reconstrua o P2P, se for necessária uma transferência de alta largura de banda.

Nunca marque como concluída uma etapa que dependa de mídia até que o recebimento da cópia de destino tenha sido confirmado.

Ofereça um fallback seguro para o usuário quando o ASR online ou a IA estiverem indisponíveis. Comandos offline fixos ainda podem cobrir a navegação essencial.

Etapa 17: Teste em hardware real com uma matriz de testes empresarial

Emuladores não bastam para um projeto de óculos, pois a óptica, o comportamento térmico, o Bluetooth, o P2P, a câmera, o microfone e a ergonomia afetam a experiência do software. Teste o sistema completo exatamente no OTA empresarial planejado para o piloto.

• Boot e inicialização automática: Boot a frio, abertura do aplicativo, prontidão do SDK, recuperação se a vinculação do serviço for lenta
• Bluetooth: Primeiro pareamento, reconexão, suspensão do celular, recuperação após ficar fora de alcance
• P2P: Conexões/desconexões repetidas, arquivo grande, stream ao vivo, mudanças de Wi-Fi
• Permissões: Instalação nova, permissão negada, concessão posterior, diferenças entre versões do Android
• Mídia: Qualidade de foto/vídeo, confirmação de recebimento de arquivos, nova tentativa após falha de upload, limpeza do armazenamento
• Voz: Ambiente ruidoso, sem rede, frase não suportada, interrupção do TTS
• Interface / óptica: Legibilidade, área de reflexo superior, textos longos, visibilidade do status, fadiga do usuário
• Desempenho: Sessão longa, temperatura da CPU, memória disponível, sobrevivência do processo
• Backend: Resposta lenta, requisição duplicada, token expirado, servidor indisponível
• Segurança: Tratamento de credenciais, ocultação de dados sensíveis nos logs, perda do dispositivo, revogação de contas

O FAQ da Rokid sugere especificamente monitorar a memória e a temperatura da CPU durante a triagem de desempenho e alerta que memória disponível muito baixa aumenta a probabilidade de encerramento de processos em segundo plano. Esse é mais um motivo para manter o aplicativo dos óculos focado e transferir serviços não essenciais para outro lugar.

Etapa 18: Empacote o piloto e controle a linha de base da implantação

Durante o desenvolvimento, os APKs podem ser instalados pelo Android Studio usando o cabo de depuração de dados do Glass3. Uma implantação em produção exige um processo de lançamento mais rigoroso. A Rokid não documenta controle de políticas no estilo MDM (como modo quiosque, limpeza remota ou política de aplicativos). Em vez disso, documenta o registro de dispositivos e o acompanhamento de status pelo console Lingmou e pela OpenAPI, enquanto a versão 2.2.0-E permite a instalação de APKs por meio de um aplicativo de leitura de QR code. Coordene o mecanismo de implantação, os direitos de provisionamento, o firmware empresarial e a política de atualizações com a Rokid ou com o distribuidor antes de se comprometer com uma arquitetura de rollout.

1. Congele as versões de SDK e OTA testadas para o piloto.

1. Gere APKs de release assinados para os aplicativos dos óculos e do celular.

1. Documente os client IDs, os nomes de pacote e a configuração dos ambientes de backend.

1. Provisione chaves de API e segredos do backend por meio de infraestrutura segura, e não pelo código-fonte.

1. Defina quem pode atualizar os óculos, o aplicativo do celular e o backend, e em que ordem.

1. Execute testes de regressão após cada mudança de OTA ou SDK antes de atualizar a frota.

1. Crie um canal de suporte para logs, identidade do dispositivo, diagnósticos de conectividade e rollback.

Exemplo de arquitetura: um aplicativo personalizado de inspeção para serviço de campo

A seguir, um exemplo prático de design montado a partir dos recursos documentados pela Rokid. Não se trata de um fluxo de trabalho pronto da Rokid. Ele mostra como a pilha de desenvolvimento pode transformar os óculos em um endpoint de negócio dedicado.

1. Início. Ação técnica: o aplicativo dos óculos inicia automaticamente e verifica se o SDK está pronto. Valor para o negócio: o trabalhador começa diretamente no fluxo de trabalho da empresa.
2. Atribuir tarefa. Ação técnica: o celular/backend envia o resumo da ordem de serviço como uma mensagem compacta. Valor para o negócio: não é preciso fazer consultas manuais em um celular.
3. Orientar. Ação técnica: os óculos mostram uma instrução na área central do display. Valor para o negócio: as mãos ficam livres para a tarefa.
4. Confirmar. Ação técnica: o trabalhador diz um comando fixo ou usa um evento de hardware compatível. Valor para o negócio: interação rápida e determinística.
5. Capturar evidências. Ação técnica: os óculos tiram uma foto ou gravam um clipe curto. Valor para o negócio: a prova visual é anexada à etapa correta.
6. Transferir. Ação técnica: a mídia trafega via P2P; uma pequena mensagem de status confirma o upload. Valor para o negócio: dados volumosos ficam fora do canal de controle de baixa largura de banda.
7. Sincronizar. Ação técnica: o celular ou o backend envia o resultado à API do CMMS/ERP. Valor para o negócio: os sistemas de negócio existentes continuam sendo o sistema de registro.
8. Exceção. Ação técnica: se necessário, o celular recebe um stream ao vivo ou o aplicativo aciona o caminho aprovado de assistência remota. Valor para o negócio: um supervisor pode ver o que o trabalhador vê.
9. Concluir. Ação técnica: o backend confirma a conclusão e envia a próxima tarefa. Valor para o negócio: o usuário recebe um estado final claro e a trilha de auditoria fica completa.

Por que o software personalizado muda a justificativa de negócio do Rokid AI Glasses Enterprise

O principal valor empresarial vem de moldar o dispositivo em torno de um processo operacional existente ou de redesenhar esse processo para o trabalho com as mãos livres.

Interface feita sob medida: remova os menus de consumo e mostre apenas as informações necessárias na etapa atual do trabalho.

Integração com sistemas de negócio: conecte as evidências capturadas e as ações dos trabalhadores a plataformas ERP, CMMS, CRM ou personalizadas já existentes.

Captura de dados com as mãos livres: use câmera, voz e entradas do wearable sem precisar voltar repetidamente a um celular ou tablet.

Conectividade controlada: use Bluetooth para comandos e P2P para dados de alta largura de banda, em vez de forçar todas as funções por um único canal.

Limites personalizados para a IA: use IA onde ela agrega valor, mantendo as regras do fluxo de trabalho, as permissões e a governança de dados sob controle da empresa.

Comportamento de dispositivo dedicado: a inicialização automática e o tratamento de eventos podem reduzir o atrito em implantações de propósito único, quando compatíveis com o firmware empresarial.

Arquitetura expansível: comece com uma prova de conceito local e depois adicione integração com backend, APIs de plataforma, colaboração remota ou SDKs especializados à medida que o fluxo de trabalho amadurece.

O argumento de compra: Para organizações que precisam de uma experiência de aplicativo padrão e fixa, o desenvolvimento personalizado pode ser desnecessário. Para organizações que querem que os óculos de IA passem a fazer parte de um fluxo de trabalho operacional controlado, o Glass3 SDK documentado é o motivo pelo qual o hardware se torna mais interessante. A empresa está comprando um endpoint adaptável, não apenas um display ou uma câmera vestível.

Limitações e riscos de engenharia a considerar no planejamento

• SDK focado em Android: O Glass3 SDK público é voltado para Android nativo. O FAQ da Rokid informa que iOS e HarmonyOS nativo não são compatíveis. Uma integração com uni-app só é possível criando sua própria ponte para o SDK Android nativo.
• Display compacto: A área de 480 x 640 em retrato é adequada para instruções concisas, não para painéis empresariais densos. Um bom design de fluxo de trabalho é obrigatório.
• Divergências entre SDK e changelog: Valide os artefatos do SDK, a demonstração e o OTA em conjunto, levando em conta as diferenças de versão entre os changelogs em chinês e em inglês.
• Dependência de serviços online: Determinadas funções de ASR, IA e OpenAPI exigem acesso à rede, credenciais empresariais ou provisionamento de serviços.
• Sem ASR offline aberto no FAQ atual: O TTS offline e as funções de comandos offline fixos podem viabilizar uma interação resiliente, mas a conversão livre de fala em texto offline não está documentada atualmente como recurso integrado.
• Complexidade de transporte: Bluetooth e P2P resolvem problemas diferentes. Reconexão, permissões e sincronização de estado exigem engenharia com qualidade de produção.
• RTC removido do núcleo: A Rokid removeu as chamadas RTC do Phone SDK base na versão 2.1.7-E. A colaboração remota deve usar o Remote Collaboration SDK da Rokid ou uma solução desenvolvida separadamente.
• Detalhes de implantação exigem validação: A documentação pública do SDK é sólida no que diz respeito ao desenvolvimento, mas o gerenciamento da frota em produção e o provisionamento pelo console Lingmou ou pelo aplicativo de leitura de QR code devem ser confirmados para o ambiente do cliente antes da expansão.

Prós e contras do desenvolvimento empresarial personalizado

Prós:

• Modelo de desenvolvimento Android nativo
• Artefatos Maven públicos
• Demonstração oficial para óculos + celular
• Bluetooth e P2P
• Mensagens/arquivos/mídia
• Câmera e pré-visualização ao vivo
• Serviços de voz/IA/reconhecimento
• Possibilidade de Wi-Fi direto
• OpenAPI empresarial
• Caminhos de inicialização automática e personalização de eventos.

Contras:

• Suporte ao SDK nativo apenas para Android
• Display compacto e fixo
• Coordenação de versões/OTA
• Determinados recursos online exigem acesso empresarial
• Limitação de ASR offline
• Detalhes de provisionamento/gerenciamento de frota em produção precisam de confirmação específica para cada projeto.

Veredito final

Rokid AI Glasses Enterprise vale a pena ser considerado quando o objetivo da empresa é criar um fluxo de trabalho dedicado com as mãos livres, em vez de implantar um aplicativo genérico de consumo. A pilha empresarial atual do Glass3 oferece aos desenvolvedores Android um caminho documentado para desenvolver nos óculos, pareá-los com um celular Android, transmitir dados de controle via Bluetooth, transferir mídia via Wi-Fi P2P e conectar o fluxo de trabalho a sistemas de backend ou a determinados serviços da Rokid OpenAPI.

Os casos de uso mais fortes são inspeções guiadas, serviço de campo, captura de evidências, trabalho procedimental e outras tarefas em que o trabalhador se beneficia de ver uma instrução por vez mantendo as duas mãos livres. A principal limitação não é a falta de APIs. É a disciplina de engenharia exigida em torno do display pequeno, do estado da conectividade, das permissões, da compatibilidade entre SDK/OTA e das dependências de serviços online.

Para um comprador corporativo, a pergunta-chave da avaliação é: “Conseguimos mapear nosso fluxo de trabalho para a pilha de desenvolvimento documentada e conseguimos dar suporte ao aplicativo ao longo de todo o seu ciclo de vida?” Se a resposta for sim, o software personalizado é o caminho para transformar o Rokid Glass3 de óculos de IA de uso geral em um dispositivo operacional feito sob medida.

Para empresas que estão avaliando o Rokid AI Glasses Enterprise para inspeções, serviço de campo, logística, trabalho guiado ou fluxos de trabalho de IA personalizados, a VR Expert pode ajudar a avaliar o hardware, definir uma prova de conceito e validar o caminho de implantação. Acesse a página do produto Rokid AI Glasses Enterprise para conhecer o dispositivo, a disponibilidade e as opções de compra. Para definição de escopo de desenvolvimento personalizado ou orientação sobre rollout, entre em contato com a VR Expert.