Desenvolver para o RealWear Navigator 520 sem SDK: como funciona o WearHF

Desenvolver para o RealWear Navigator 520 sem SDK: como funciona o WearHF

Resumo executivo

RealWear Navigator 520: desenvolver para este equipamento não exige um SDK de voz separado para a interação básica por voz. O WearHF faz parte do software do dispositivo. Consegue analisar um ecrã Android, identificar as vistas interativas suportadas e disponibilizar comandos de voz para elas. Assim, um botão Android padrão com a etiqueta CONTINUE pode ser ativado dizendo «CONTINUE», sem importar nenhuma biblioteca da RealWear.

Comece com uma aplicação Android padrão e teste-a no firmware do Navigator a que se destina. O WearHF consegue reconhecer os controlos de ecrã suportados sem código de voz do lado da aplicação. Adicione uma diretiva de vista em android:contentDescription quando um controlo precisar de frases alternativas ou de um comportamento especial. Use OVERRIDE_COMMANDS apenas quando a aplicação tiver de assumir o controlo do reconhecedor e tratar ela própria os comandos. Estes caminhos têm efeitos diferentes, descritos abaixo.

Importante: «sem SDK» não significa «sem código». Continua a ter de construir a interface Android e a lógica de negócio. A aplicação não precisa de um SDK de voz da RealWear separado para o controlo básico por voz, porque é o WearHF que fornece essa capacidade ao nível do dispositivo.

Conceito central: para o controlo básico por voz, não abre o WearHF, não instala o WearHF nem importa um SDK do WearHF. O WearHF é executado em segundo plano como parte do sistema operativo da RealWear.

O que é o RealWear Navigator 520?

O RealWear Navigator 520 é um computador monocular robusto de realidade assistida, concebido para trabalho na linha da frente, como manutenção, inspeção e assistência técnica no terreno. O firmware 2.x do Navigator 500/520 da RealWear baseia-se no Android 13, e a versão de manutenção Ari OS 2.0 de 17-09-2026 (firmware 3.0, build 3.0.3-15, disponibilizada a dispositivos com a build 2.2.3-33) faz o dispositivo passar para o Android 16. Os roteiros de firmware podem mudar, por isso trate o SO do dispositivo como uma restrição de implementação: registe na sua matriz de lançamentos a build de firmware testada, o nível de API Android, o minSdk/targetSdk da aplicação e o modelo do dispositivo. Não deduza o minSdk nem o targetSdk apenas a partir da versão Android do headset.

Para os programadores, isto significa que constroem e empacotam uma aplicação Android normal. O WearHF é executado no dispositivo e pode disponibilizar os controlos suportados para comando por voz; não implementa o seu fluxo de trabalho, não autoriza uma ação de negócio nem substitui a validação do lado da aplicação.

O que é o WearHF?

O WearHF é o serviço integrado da RealWear para voz e interação mãos-livres. Interpreta as vistas Android suportadas e as diretivas de ecrã e, em seguida, ativa uma vista ou envia um evento de voz consoante a integração escolhida. A interação básica com vistas não precisa de uma biblioteca de voz da RealWear separada. As diretivas incorporadas são lidas a partir de android:contentDescription; os comandos programáticos usam broadcast intents Android documentados. Não confunda um clique numa vista com uma substituição do reconhecedor: uma substituição assume o controlo do reconhecedor e pode suprimir os comandos incorporados/por script até ser reposta.

O que precisa antes de construir a primeira aplicação

· Um Navigator 520 com a build de firmware que pretende suportar; registe a build exata e a versão do Android.

· Um computador Windows, macOS ou Linux.

· Android Studio com o Android SDK e as Platform Tools (ADB). Use o nível de API Android exigido pela sua aplicação e valide com o firmware suportado pela RealWear.

· Um cabo de dados USB-C.

· Nenhum SDK da RealWear para a primeira aplicação.

· Um fluxo de trabalho de negócio para testar, como avançar um passo de inspeção ou comunicar um problema num equipamento.

Como construir uma aplicação Android controlada por voz sem um SDK da RealWear

Passo 1: criar um projeto Android normal

Para este guia, comece com um projeto Android Views. No Android Studio, escolha uma Empty Activity baseada em Views (não um modelo exclusivo de Compose) e, depois, selecione Java ou Kotlin. Os exemplos abaixo usam Java. O Compose também pode funcionar com o WearHF em software suportado, mas a respetiva semântica e árvore de acessibilidade devem ser testadas na build de destino.

1. Abra o Android Studio e selecione New Project.

2. Escolha uma Empty Activity baseada em Views. Se o assistente apresentar campos para a linguagem e o SDK mínimo, selecione Java e defina o minSdk como a API Android mais baixa que a sua aplicação realmente suporta; não copie um valor deste exemplo sem verificar as suas dependências e a sua frota de dispositivos.

3. Introduza os detalhes da aplicação. Defina o nome da aplicação, o nome do pacote e a localização onde será guardado e, em seguida, crie o projeto.

4. Aguarde que o projeto abra. O Android Studio conclui a sincronização do Gradle e abre o projeto.

Não acrescente nada por agora: não está à procura de um modelo de projeto da RealWear. O objetivo da primeira build é provar que uma aplicação Android padrão consegue ser executada no Navigator 520.

Passo 2: adicionar um botão Android e ligá-lo ao Java

Comece por criar um botão. Vai adicionar o respetivo layout Android, ligar a ação de clique em Java e, depois, testá-lo no dispositivo.

1. No painel Project do Android Studio, abra app > res > layout > activity_main.xml. O caminho completo do ficheiro é app/src/main/res/layout/activity_main.xml.

2. Selecione Code no editor de layout. Substitua o conteúdo do ficheiro pelo XML completo apresentado a seguir.

XML: um botão com um comando WearHF

Cole o layout completo em activity_main.xml e guarde o ficheiro:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:padding="24dp">

<Button android:id="@+id/continueButton" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="CONTINUE" android:contentDescription="hf_commands:CONTINUE" />

</LinearLayout>

Explicação rápida: `LinearLayout` empilha o seu conteúdo na vertical. `android:text` é a etiqueta visível do botão. `android:contentDescription` contém a diretiva do WearHF; os serviços de acessibilidade do Android também leem este campo, por isso confirme que o controlo continua a ser compreensível para os seus utilizadores.

Em seguida, abra app > java > o seu pacote > MainActivity.java no painel Project. O caminho completo é app/src/main/java/<your.package.name>/MainActivity.java. Mantenha a classe Activity gerada e o método `onCreate()`.

Se ainda não existir, adicione `import android.widget.Button;` junto das importações no início de MainActivity.java. Dentro do método `onCreate()` existente, cole estas linhas imediatamente a seguir a `setContentView(R.layout.activity_main);`:

Button continueButton = findViewById(R.id.continueButton); continueButton.setOnClickListener(v -> openNextStep());

Adicione este método abaixo de `onCreate()`, mas antes da chaveta de fecho final da classe MainActivity:

private void openNextStep() { // Navigate to the next inspection or work-order step. }

Como ajustar: altere `android:text` para a etiqueta adequada ao seu fluxo de trabalho. Altere `hf_commands:CONTINUE` para a frase que os trabalhadores devem dizer, por exemplo `hf_commands:Continue Work, Next Step`. O ID XML `continueButton` tem de corresponder a `R.id.continueButton` em Java; se lhe mudar o nome, atualize ambos. Substitua o comentário em `openNextStep()` pela ação de navegação ou de negócio de que a sua aplicação precisa. O controlo básico por voz não requer um SDK do WearHF separado nem a permissão `RECORD_AUDIO`.

Passo 3: preparar o Navigator 520 para desenvolvimento Android

O computador de desenvolvimento precisa de autorização ADB para instalar e depurar a aplicação. Use um cabo USB-C com capacidade de dados; os cabos só de carregamento não serão reconhecidos como dispositivo ADB.

1. Abra Advanced Settings. No ecrã inicial do Navigator, diga MY SETTINGS para aceder à lista de definições do Android.

2. Abra About Device. Diga ABOUT DEVICE e, depois, PAGE DOWN até o Build Number ficar visível.

3. Ative as Developer Options. Diga BUILD NUMBER repetidamente, cerca de sete vezes, até o dispositivo confirmar que o modo de programador está ativado.

4. Abra as Developer Options. Diga NAVIGATE BACK, depois SYSTEM e, a seguir, DEVELOPER OPTIONS.

5. Ative a depuração USB. Dentro das Developer Options, ative USB debugging.

6. Ligue o cabo USB-C e aprove o pedido de depuração RSA no dispositivo. Confirme a ligação com `adb devices`; o dispositivo deve aparecer como `device` e não como `unauthorized`.

Se o Android Studio não listar o headset, execute `adb devices`. Se aparecer `unauthorized`, desbloqueie o headset e aprove o pedido RSA. Para reinstalar a partir da raiz do projeto, use `adb install -r app/build/outputs/apk/debug/app-debug.apk`; substitua o caminho se a variante de build ou o nome do APK forem diferentes. Use o Logcat do Android Studio ou `adb logcat` para analisar falhas e registos da aplicação.

A depuração USB é uma definição de desenvolvimento. Desative-a depois dos testes em laboratório ou faça a sua gestão de acordo com a política de segurança de dispositivos da organização; não deixe o acesso de desenvolvimento ativado em dispositivos da frota de produção.

Passo 4: executar a aplicação no Navigator 520

1. Selecione o Navigator no Android Studio. Use o seletor de dispositivos na barra de ferramentas superior e escolha o dispositivo RealWear ligado.

2. Clique em Run. Selecione o triângulo verde Run ou use Run > Run 'app'.

3. Aguarde pela instalação. O Android Studio compila o APK e instala-o no Navigator através do ADB.

4. Abra a aplicação instalada a partir do launcher de aplicações do dispositivo ou execute `adb shell monkey -p your.application.id 1` num terminal de desenvolvimento. Substitua `your.application.id` pelo applicationId indicado no ficheiro de build Gradle do módulo da aplicação.

5. Confirme que o botão CONTINUE está visível e ativado.

Passo 5: testar o WearHF sem adicionar qualquer SDK

O WearHF já está a ser executado no Navigator 520. Com apenas o botão CONTINUE no ecrã, teste primeiro este controlo:

1. Diga CONTINUE e verifique se o listener de clique normal da aplicação é executado exatamente uma vez.

2. Diga SHOW HELP para ver o comando que o WearHF disponibiliza para este ecrã. Confirme que aparece CONTINUE.

3. Verifique os indicadores do WearHF e teste a seleção numérica, se estiver disponível. Não dependa de um indicador como única forma de identificar uma ação crítica para a segurança.

Opcional: adicionar uma segunda ação depois do teste do CONTINUE

Depois de o primeiro botão funcionar, pode adicionar REPORT ISSUE. Em activity_main.xml, coloque este Button dentro do LinearLayout, abaixo de CONTINUE e antes de </LinearLayout>:

<Button android:id="@+id/reportIssueButton" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="REPORT ISSUE" />

Em MainActivity.java, adicione este listener dentro de onCreate(), a seguir ao listener de CONTINUE:

Button reportIssueButton = findViewById(R.id.reportIssueButton); reportIssueButton.setOnClickListener(v -> openIssueReport());

Adicione openIssueReport() abaixo de onCreate(), dentro de MainActivity. Substitua o comentário pelo fluxo de comunicação de problemas da sua aplicação:

private void openIssueReport() { // Open the equipment issue form. }

Volte a compilar e a instalar a aplicação e, em seguida, diga REPORT ISSUE. Confirme que o fluxo de comunicação de problemas abre.

Conclusão

Desenvolver para o RealWear Navigator 520 sem um SDK dedicado prova que um código Android limpo e padrão já está preparado para voz, apoiando-se no serviço WearHF integrado para transformar vistas visíveis e diretivas contentDescription em controlos mãos-livres intuitivos. Para as equipas técnicas, isto evita o excesso de bibliotecas de terceiros e motores de voz complexos, mantendo a lógica de negócio central dentro da arquitetura Android padrão. Do ponto de vista do negócio, esta abordagem acelera o time-to-market e minimiza os custos de implementação: as empresas podem tirar partido diretamente das aplicações Android existentes e das competências dos seus programadores internos, evitar a dependência de SDK proprietários e modernizar sem sobressaltos os fluxos de trabalho da linha da frente, sem perturbar a sua stack de software.

Para um primeiro protótipo empresarial, construa um ecrã de inspeção ou manutenção, verifique as etiquetas das vistas e as descrições acessíveis e, depois, teste a ativação por voz no firmware exato do Navigator 520 usado pela frota piloto. Adicione diretivas incorporadas para necessidades específicas da interface e substituições do reconhecedor apenas quando o fluxo de trabalho exigir controlo total dos comandos.

João Noronha

Escrito por

João Noronha

Perguntas frequentes

Este artigo

Sim. A aplicação continua a ser uma aplicação Android, por isso os programadores escrevem a interface e a lógica de negócio em Java, Kotlin, XML Views ou outro toolkit de interface Android suportado. A interação básica do WearHF com vistas não requer um SDK de voz da RealWear separado.

Não para comandos básicos de vistas. O WearHF está integrado no software da RealWear e consegue derivar comandos a partir das vistas Android suportadas. Para comportamentos personalizados, use as diretivas ou os intents documentados.

Não o abre como uma aplicação separada. O WearHF é executado em segundo plano como parte do software do Navigator 520.

Para as vistas clicáveis suportadas, o WearHF pode derivar um comando a partir do texto ou da descrição de conteúdo da vista, consoante a diretiva e a hierarquia de vistas. Teste o comando disponibilizado no ecrã real; uma etiqueta visível não é garantia para todas as vistas personalizadas.

Diga SHOW HELP no Navigator 520. A RealWear apresenta os comandos associados a esse ecrã.

Numa aplicação baseada em Views, abra o XML do layout (por exemplo, app/src/main/res/layout/activity_main.xml) e defina `android:contentDescription` na vista. Use `hf_commands:Phrase One, Phrase Two` para várias frases e `-` entre várias diretivas.

`hf_commands` é uma diretiva do WearHF ao nível da vista. Coloque-a na contentDescription da vista, seguida de frases separadas por vírgulas; cada frase reconhecida clica nessa vista.

Não é necessária nenhuma biblioteca WearHF separada para as diretivas incorporadas. São cadeias de texto na contentDescription do Android que o serviço do dispositivo interpreta. Como a contentDescription também é usada pelos serviços de acessibilidade, mantenha uma etiqueta acessível útil e teste ambos os comportamentos.

Use OVERRIDE_COMMANDS quando a lista de comandos do reconhecedor tiver de ser substituída em tempo de execução. Para comandos ao nível do ecrã que complementam as vistas, considere `hf_add_commands`. Lembre-se de que o modo de substituição suprime temporariamente os comandos incorporados/por script e tem de ser reposto ou registado novamente nos pontos do ciclo de vida documentados.

As notas de lançamento do Collaborate de maio de 2026 da RealWear indicam que o WearHF suporta o Jetpack Compose de forma nativa. Isto constitui uma prova do suporte da plataforma ao Compose, mas não dispensa testar a semântica, os composables personalizados, as etiquetas de acessibilidade e as sobreposições de comandos na sua própria aplicação. Este tutorial usa XML Views para que o mapeamento entre vistas e comandos seja explícito. Referência: a nota de lançamento do Collaborate 2.5.1 regista que o WearHF suporta o Compose de forma nativa (publicada a 2026-05-07). Aplique essa afirmação apenas a software de dispositivo que inclua o suporte correspondente e verifique o comportamento na sua build de destino.

A versão de firmware 2.2 publicada para o Navigator 500/520 baseia-se no Android 13. A política de firmware da RealWear indica o plano de migrar os dispositivos suportados para um SO baseado no Android 16 durante 2026; um plano não é uma garantia de lançamento. Consulte as notas de lançamento GA atuais e teste a build exata da frota antes de escolher compileSdk, targetSdk, minSdk, permissões ou o comportamento da versão.