Levar uma aplicação Android que já tem para o Vuzix LX1

Resumo executivo

Vuzix LX1: o desenvolvimento de aplicações Android pode começar pela aplicação empresarial que a sua equipa já mantém. O LX1 executa um sistema Android 15 modificado e a Vuzix documenta suporte para aplicações com um nível mínimo de API Android de 35 ou inferior. Reutilize a lógica de negócio e as ligações aos sistemas da empresa e, depois, adapte o layout do ecrã, a navegação e as dependências do dispositivo. Uma instalação bem-sucedida é apenas a primeira verificação.

Este guia de adaptação aborda o layout para um ecrã monocular, a navegação por botões e o que deixa de funcionar. Os programadores vão abrir um projeto existente do Android Studio, ligar um LX1 real, instalar uma compilação de teste, melhorar a interface e preparar uma versão empresarial assinada. Planeie desde cedo a ausência dos serviços Google e teste todo o percurso do trabalhador, incluindo o início de sessão, a leitura de códigos e a recuperação após a perda de Wi-Fi.

Para o planeamento de hardware, consulte a página do produto Vuzix LX1 na VR Expert.

Ilustração conceptual, não é uma captura de ecrã do dispositivo.

Introdução

O Vuzix LX1 é um computador vestível Android autónomo para fluxos de trabalho em armazéns, na indústria e no terreno. Um ecrã monocular é um ecrã visto por um só olho. O seu ecrã OLED a cores apresenta o conteúdo da aplicação ao lado da visão normal do trabalhador; trata-se de um ecrã oclusivo, o que significa que o próprio ecrã não é transparente. Os utilizadores podem usá-lo sobre qualquer um dos olhos.

Vuzix LX1: o software utiliza ferramentas Android conhecidas e bibliotecas Vuzix opcionais para voz, leitura de códigos de barras e componentes de interface. Adaptar (porting) significa ajustar software existente a outro dispositivo. Numa aplicação de picking de armazém, isso pode significar manter a consulta de encomendas e as atualizações de stock, transformando um ecrã de telemóvel denso numa única instrução, numa confirmação e num percurso claro para exceções. Estas são recomendações de design, não resultados medidos num ensaio com o LX1.

Factos sobre o software e as versões do Vuzix LX1

Instalação e gestão:

• USB através de ADB ou Vuzix View
• Vuzix App Store
• Opções de MDM de vários parceiros.

• Sistema operativo: Android 15 modificado; nível de API 35. O SDK mínimo tem de ser 35 ou inferior.
• Ecrã: OLED a cores de 980 × 550; paisagem ou paisagem invertida para qualquer um dos olhos.
• Hardware: Qualcomm QCS4490, 6 GB de RAM e 128 GB de armazenamento.
• Entrada: Quatro botões de controlo no total; três botões de navegação têm ações de pressão curta e longa, além do controlo por voz.
• Serviços Google: Sem Google Play Store nem suporte completo para GMS. Não assuma que as dependências do telemóvel funcionam.
• Firmware de referência publicado: A Vuzix indica a v15.2.0, lançada a 12-08-2026, com atualizações do Speech SDK 1.98.0 e do Barcode SDK 2.0.0.

O firmware é o software de sistema instalado no dispositivo. A versão publicada é um ponto de referência, não uma prova de que todos os dispositivos da empresa têm essa compilação. Registe a compilação instalada durante os passos seguintes.

Passo 1 Abrir o projeto da aplicação empresarial existente

O Android Studio é a aplicação de desenvolvimento usada para editar, compilar e depurar aplicações Android. O Gradle é o sistema de compilação que transforma o projeto num pacote instalável.

· Abra o projeto de origem. Inicie o Android Studio, selecione Open e escolha a pasta que contém settings.gradle ou settings.gradle.kts. Aguarde que a sincronização do Gradle termine. Se tiver apenas um APK, obtenha junto do respetivo proprietário o projeto de origem e a autorização para o modificar.

· Localize os ficheiros relevantes. No painel Project, à esquerda, selecione a vista Android. Abra app > manifests > AndroidManifest.xml e Gradle Scripts > build.gradle.kts (Module :app), ou o equivalente build.gradle.

· Escolha uma tarefa do trabalhador. Comece por um fluxo de negócio completo, como abrir uma tarefa de picking, ler um artigo e confirmar a quantidade. Mantenha intactas a integração com o backend e as regras de validação enquanto adapta os ecrãs.

Passo 2 Preparar o LX1 e a respetiva rede empresarial

Um SSID é o nome de uma rede Wi-Fi. Utilize um dispositivo de teste e uma rede aprovada pela equipa de TI que consiga aceder aos sistemas de teste da sua empresa.

· Registe o sistema instalado. No LX1, abra Settings e localize a secção de informações do dispositivo ou About. Registe a versão do Android e a compilação aí apresentadas; os nomes dos menus podem variar consoante o firmware. Compare a compilação com as notas de versão da Vuzix.

· Gere um código Wi-Fi. No computador, abra vuzix.com/wifiQR. Introduza os dados da rede aprovada nos campos da página e gere o código QR. A Vuzix afirma que a geração ocorre localmente no navegador. Numa rede empresarial com certificados ou autenticação especial, peça à equipa de TI que utilize o método de aprovisionamento suportado.

· Ligue-se à rede. No launcher do LX1, abra Camera, selecione o leitor (scanner), aponte-o para o código e selecione Join. Em alternativa, abra Settings > Network & Internet > Wi-Fi, ative o Wi-Fi, escolha a rede e introduza a palavra-passe.

Passo 3 Ligar o Android Studio ao LX1

O ADB, abreviatura de Android Debug Bridge, é uma ferramenta que permite a um computador de desenvolvimento instalar aplicações e ler diagnósticos do dispositivo. Um APK é o pacote de aplicação instalável do Android.

· Instale as ferramentas no computador. No Android Studio, abra Tools > SDK Manager. Selecione SDK Tools, ative Android SDK Platform-Tools e clique em Apply. Tome nota do Android SDK Location apresentado nesta janela; o ADB encontra-se na respetiva pasta platform-tools.

· Ative a ligação ao LX1. Nos óculos, abra Settings > Connected Devices > Allow ADB e ative a opção. Ligue um cabo USB com capacidade de transferência de dados. Se o dispositivo não aparecer, ative também a transferência de ficheiros por USB em Connected Devices, conforme indicado pela Vuzix. Siga os requisitos de alimentação USB do LX1; o procedimento de cópia de ficheiros especifica que se deve desligar a bateria e usar uma porta USB-C ou uma porta USB 3.1 de alta potência do computador.

· Verifique a autorização. Abra o separador Terminal do Android Studio. Execute adb devices a partir da pasta platform-tools ou adicione essa pasta ao PATH do computador, a lista de localizações onde os comandos são procurados. Aceite um pedido de autorização de depuração no LX1, caso apareça. O dispositivo deverá ser listado com o estado device.

adb devices adb shell getprop ro.build.version.release adb shell getprop ro.build.version.sdk adb shell getprop ro.build.display.id adb shell wm size adb shell wm density adb shell getprop ro.product.cpu.abilist

Execute estes comandos apenas com o LX1 de teste ligado. Com vários dispositivos, insira -s SERIAL a seguir a adb, usando o número de série devolvido por adb devices. A densidade converte píxeis físicos em unidades de layout do Android. ABI designa o formato de processador usado pelas bibliotecas nativas; compare a lista indicada com quaisquer bibliotecas .so incluídas no seu APK.

Tome nota da densidade indicada; espera-se que o LX1 indique 240 dpi (hdpi), o que adb shell wm density confirma. Converta com dp = píxeis x 160 / dpi: a 240 dpi, o ecrã de 980 x 550 píxeis dá um espaço de design de cerca de 653 x 367 dp. Conceba os layouts para caberem nessa área, e não nas dimensões brutas em píxeis.

Passo 4 Instalar uma versão de referência inalterada e identificar falhas

O Logcat é o painel do Android Studio para mensagens da aplicação e do dispositivo. Uma versão de referência (baseline) é a compilação original usada para comparar alterações posteriores.

· Execute a aplicação existente. Na barra de ferramentas superior do Android Studio, selecione a configuração de execução da aplicação e escolha o LX1 ligado no seletor de dispositivos. Clique em Run. Quando a aplicação abrir, experimente a tarefa do trabalhador selecionada no Passo 1. O Android Studio instala automaticamente a compilação de desenvolvimento.

· Registe as falhas. Abra View > Tool Windows > Logcat, selecione o LX1 e filtre pelo pacote da sua aplicação. Registe encerramentos inesperados, controlos inacessíveis, texto cortado, problemas de início de sessão e serviços não suportados antes de fazer alterações.

· Instale um APK de teste fornecido, se necessário. No Terminal, utilize o comando abaixo com o caminho real do APK. A opção -r atualiza uma aplicação instalada mantendo os dados, desde que o pacote e o certificado de assinatura coincidam. Não desinstale uma aplicação que contenha trabalho não sincronizado só para contornar um erro de assinatura.

adb install -r "/absolute/path/to/business-app.apk"

O Vuzix View é uma aplicação de computador que espelha os óculos e pode instalar APK. Em alternativa, transfira-o a partir do Vuzix Support, ative Allow ADB, ligue o LX1, selecione-o na lista de dispositivos ligados, prima View e arraste o APK para a interface espelhada. Utilize os botões físicos no teste de usabilidade, mesmo que a interação no computador ajude durante a depuração.

Passo 5 Conceber o layout para um ecrã monocular

dp é a unidade do Android para o tamanho do layout; sp é a unidade para texto que respeita as definições de tamanho de texto. Uma Activity é um ecrã de uma aplicação Android, e o manifesto declara os componentes e as permissões da aplicação.

· Corrija a orientação. Volte a app > manifests > AndroidManifest.xml. Localize cada Activity usada pelos trabalhadores. Remova qualquer orientação vertical forçada. Se for necessária uma restrição à orientação paisagem, use sensorLandscape nessa Activity para que a interface possa rodar para qualquer um dos olhos. Preserve os restantes atributos e filtros de intenção.

<activity android:name=".PickingActivity" android:screenOrientation="sensorLandscape" />

· Simplifique o ecrã da tarefa. Abra app > res > layout e selecione o ficheiro XML do ecrã atual do trabalhador. Numa aplicação Compose, abra antes o ficheiro Kotlin que contém esse ecrã. O Compose é o toolkit do Android para criar interfaces em Kotlin. Mostre a localização atual, o artigo, a quantidade e a próxima ação. Passe as tabelas longas e as definições detalhadas para um ecrã separado.

· Dimensione para a janela real. Utilize as dimensões e a densidade obtidas no Passo 3. A resolução documentada de 980 × 550 corresponde a píxeis físicos, não a uma tela de design de 980 dp. Comece com texto legível, contraste forte e poucos controlos; avalie o resultado com o dispositivo colocado.

· Proteja o conteúdo visível. Os insets são os espaços ocupados pelas barras do sistema ou por outros elementos do ecrã. Se o destino for a API 35, reveja as regras edge-to-edge do Android 15 e aplique insets onde for necessário para que os botões e as instruções continuem visíveis. Teste as caixas de diálogo, os teclados e os pedidos de permissão, além do ecrã principal.

Ilustração conceptual, não é uma captura de ecrã do dispositivo.

Passo 6 Tornar todas as ações acessíveis com botões

O foco é a seleção visível que mostra qual o controlo que responderá a Select. Um KeyEvent é a mensagem do Android que descreve o premir de um botão. Os botões de navegação do LX1 enviam os seguintes eventos documentados.

Dianteiro:

• Pressão curta: Direita ou controlo inferior seguinte; DPAD_RIGHT
• Pressão longa: Menu de contexto; MENU

Central:

• Pressão curta: Esquerda ou controlo superior anterior; DPAD_LEFT
• Pressão longa: Início; HOME

Traseiro:

• Pressão curta: Selecionar o controlo com foco; DPAD_CENTER
• Pressão longa: Retroceder; BACK

· Defina o percurso do foco. No XML de layout do ecrã, torne os controlos interativos focáveis e defina nextFocusLeft e nextFocusRight. Mesmo um formulário vertical precisa destes percursos, porque as pressões curtas de navegação do LX1 enviam esquerda e direita. Não deixe etiquetas nem contentores decorativos no percurso.

· Adicione um estado de seleção visível. Crie app > res > drawable > lx1_action_background.xml e cole o seletor abaixo. Um seletor (selector) é um recurso que altera a aparência consoante o estado de um controlo. Este exemplo usa um contorno, para que o foco seja visível sem depender apenas da cor.

<selector xmlns:android="http://schemas.android.com/apk/res/android"> <item android:state_focused="true"> <shape> <solid android:color="#12354A" /> <stroke android:width="3dp" android:color="#FFFFFF" /> <corners android:radius="6dp" /> </shape> </item> <item> <shape> <solid android:color="#242424" /> <corners android:radius="6dp" /> </shape> </item> </selector>

· Ligue duas ações. No layout do ecrã existente, coloque estes botões dentro do respetivo contentor. Este é um exemplo com Views; mantenha a arquitetura Compose atual se a aplicação usar Compose. Adapte os IDs e o texto ao seu fluxo de trabalho. O XML abaixo pressupõe o drawable criado no passo anterior.

<Button android:id="@+id/confirmButton" android:layout_width="match_parent" android:layout_height="wrap_content" android:focusable="true" android:nextFocusLeft="@id/exceptionButton" android:nextFocusRight="@id/exceptionButton" android:background="@drawable/lx1_action_background" android:backgroundTint="@null" android:textColor="#FFFFFF" android:text="Confirm quantity"> <requestFocus /> </Button> <Button android:id="@+id/exceptionButton" android:layout_width="match_parent" android:layout_height="wrap_content" android:focusable="true" android:nextFocusLeft="@id/confirmButton" android:nextFocusRight="@id/confirmButton" android:background="@drawable/lx1_action_background" android:backgroundTint="@null" android:textColor="#FFFFFF" android:text="Report shortage" />

· Utilize os handlers de negócio existentes. Na Activity, após setContentView, ligue estes botões às funções de confirmação e de falta de stock já existentes com setOnClickListener. Não intercete todos os eventos de tecla: os botões padrão com foco conseguem processar a seleção. Reponha o foco na ação adequada após uma caixa de diálogo ou uma mudança de tarefa.

// Na sua Activity, após setContentView: findViewById<Button>(R.id.confirmButton).setOnClickListener { confirmQuantity() // A sua ação de negócio validada existente } findViewById<Button>(R.id.exceptionButton).setOnClickListener { reportShortage() // O seu fluxo de exceção existente }

Importe android.widget.Button. Substitua os dois nomes de funções pelos handlers reais do seu projeto; não são APIs fornecidas pelo Android.

· Verifique todo o percurso. Volte a executar a aplicação no LX1. Use apenas os botões de navegação para iniciar sessão, chegar a cada ação, selecioná-la e regressar com Back. Repita depois de abrir uma caixa de diálogo e depois de mudar o dispositivo para o outro olho. Em Compose, implemente percursos de foco equivalentes com focusRequester e focusProperties.

Passo 7 Remover dependências de telemóvel que o LX1 não consegue satisfazer

GMS significa Google Mobile Services, os serviços Android proprietários da Google. Uma API é uma interface de software usada para aceder a uma funcionalidade. O microG é uma implementação de compatibilidade para algumas interfaces de serviços Google; a sua presença não garante suporte completo para os serviços Google.

· Audite as dependências. Abra o bloco dependencies do módulo e qualquer catálogo de versões libs.versions.toml. Procure com.google.android.gms, Firebase, início de sessão Google, mapas, licenciamento e aprendizagem automática fornecida por serviços. Teste cada dependência usada no fluxo do trabalhador. A Vuzix afirma que o LX1 não suporta o GMS completo, embora o firmware v15.2.0 inclua uma atualização do microG GmsCore.

· Substitua as integrações necessárias quando for preciso. Utilize o método de início de sessão suportado pela sua empresa, as APIs de servidor e a configuração gerida. A visão geral de desenvolvimento atual da Vuzix para o LX1 ainda indica que se deve usar a Google Play Services Client Library 9.8.0 ou anterior para Cloud Messaging e Maps. Trate isso como uma nota antiga (o Google Cloud Messaging foi descontinuado em 2018 e desativado em 2019) e não como uma solução empresarial atual; peça à Vuzix e ao responsável pela dependência que confirmem a interface específica.

· Reveja os requisitos do dispositivo. Em AndroidManifest.xml, inspecione as declarações uses-feature e as permissões relativas a ecrã tátil, telefonia e localização. Torne o hardware opcional apenas quando a aplicação tiver uma alternativa funcional. Uma declaração não cria hardware em falta. Teste a recusa das permissões de câmara e microfone sem perder a tarefa.

· Mantenha métodos de entrada adequados ao trabalho. Substitua a introdução repetida de texto por leitura aprovada, uma lista curta selecionável ou definições geridas. No início de sessão, mantenha a autenticação com o sistema de identidade da empresa; um identificador lido, por si só, não deve autorizar um trabalhador.

Passo 8 Adicionar leitura de códigos de barras ou voz apenas quando necessário

Um SDK é um conjunto de ferramentas para aceder a uma funcionalidade de software ou do dispositivo. O Vuzix Barcode SDK inicia o leitor integrado e devolve um resultado; o Vuzix Speech SDK acrescenta comandos de voz personalizados; o HUD Resources e o HUD ActionMenu fornecem componentes de interface opcionais.

· Escolha a abordagem de leitura de códigos de barras. Para leituras ocasionais de início de sessão ou de configuração, comece pelo repositório oficial do Vuzix Barcode SDK e pelos Javadocs associados. Utilize as interfaces da versão 2.0.0 ou posterior para o LX1. Os modos incorporado e contínuo do antigo SDK 1.x não são suportados no LX1. Para leitura contínua em armazém com a sua própria pré-visualização, integre uma API de câmara e um motor de descodificação adequado.

· Inclua um modelo de descodificação se usar o ML Kit. O ML Kit é o toolkit de aprendizagem automática da Google. O seu modelo de códigos de barras pode ser incluído na aplicação, evitando a transferência do modelo através dos Google Play Services. Em app/build.gradle.kts > dependencies, adicione a dependência incluída (bundled) documentada abaixo e clique em Sync Now. Não adicione as variantes bundled e unbundled em simultâneo. Esta dependência não é um leitor completo: ligue as frames da câmara e os resultados de leitura com base no exemplo oficial.

implementation("com.google.mlkit:barcode-scanning:17.3.0")

· Adicione comandos de voz específicos da tarefa. Abra Vuzix Support > Developer Resources e siga Working with the Vuzix Speech SDK. Confirme uma versão da biblioteca compatível com o firmware do dispositivo, adicione o respetivo repositório e a dependência do módulo, sincronize o projeto e, depois, registe comandos como Confirm quantity e Report shortage com a API documentada. Encaminhe os comandos reconhecidos pelos mesmos handlers de validação que os botões.

· Teste também a compilação de lançamento. Se adicionar SDK da Vuzix, verifique as regras de redução (shrinking) atuais e execute a compilação assinada e otimizada. A documentação mais antiga inclui instruções com jcenter e android.enableR8=false; não as cole numa compilação moderna sem confirmar que se aplicam. Teste o ruído, o idioma, comandos duplicados e leituras do artigo errado.

O que deixa de funcionar quando uma aplicação Android para telemóvel passa para o LX1

Não é possível chegar a um controlo:

• Causa provável: Gestos exclusivamente táteis ou percursos de foco em falta
• Solução prática: Disponibilize ações focáveis e percursos explícitos esquerda/direita.

Texto ou caixas de diálogo cortados:

• Causa provável: Layout de telemóvel, bloqueio na orientação vertical ou insets em falta
• Solução prática: Simplifique o ecrã, suporte ambas as orientações em paisagem e aplique insets.

Falhas no início de sessão, nos mapas ou nas notificações:

• Causa provável: A dependência pressupõe serviços Google completos
• Solução prática: Valide a API exata e substitua as integrações não suportadas.

A migração do leitor falha:

• Causa provável: Modo antigo do Vuzix SDK 1.x ou dependência da transferência de modelos
• Solução prática: Utilize as interfaces 2.x suportadas ou um motor incluído na aplicação.

A instalação ou o carregamento nativo falha:

• Causa provável: minSdk, chave de assinatura ou ABI nativa incompatíveis
• Solução prática: Analise o erro de instalação e faça corresponder a plataforma e o certificado testados.

O trabalho desaparece ou repete-se:

• Causa provável: Estado não reposto ou pedido enviado duas vezes
• Solução prática: Guarde o trabalho pendente de forma persistente e utilize proteção contra duplicados no servidor.

O trabalho em segundo plano para:

• Causa provável: Regras da versão do Android ou trabalhador a sair da aplicação
• Solução prática: Reveja o comportamento do Android 15 e teste transições reais do ciclo de vida.

Estes são riscos a testar, não uma afirmação de que todas as aplicações vão falhar. O Android 15 também altera o comportamento dos serviços em primeiro plano. Um serviço em primeiro plano é uma operação prolongada de uma aplicação com uma notificação visível. Reveja tanto as alterações do Android para todas as aplicações como as desencadeadas pelo nível de API de destino, sobretudo no caso de carregamentos, assistência remota e sincronização sem supervisão.

Passo 9 Testar o fluxo de trabalho empresarial no dispositivo

· Repita a tarefa real. Teste ambas as posições dos olhos, os botões, os comandos de voz aprovados, os formatos de códigos de barras, os pedidos de permissão e a expiração da sessão. Espelhe o ecrã com o Vuzix View para observação, mas peça ao trabalhador que utilize os óculos reais.

· Teste a recuperação. Perca o Wi-Fi durante a confirmação, volte a ligar, reabra a aplicação e verifique o sistema da empresa. As transações pendentes devem manter-se e as transações concluídas não devem ser duplicadas. Teste Home e Back separadamente, bem como o reinício do dispositivo e a passagem de turno.

· Meça o piloto. Compare o tempo de conclusão, os erros de introdução, o tempo de recuperação e os pedidos de suporte com o processo existente. Teste a carga de leitura e de vídeo nas condições de turno previstas. Comunique os resultados observados antes de prometer uma melhoria de produtividade ou de bateria.

Âmbito dos testes: este artigo baseia-se na documentação oficial, não numa verificação prática de um LX1 ou da sua aplicação. Os exemplos de código são pontos de partida para a integração e exigem uma revisão específica do projeto.

Passo 10 Assinar o APK e preparar a implementação empresarial

A assinatura da aplicação anexa um certificado que identifica o editor da aplicação. O MDM, ou gestão de dispositivos móveis (mobile device management), permite à equipa de TI aprovisionar, configurar e atualizar centralmente os dispositivos empresariais.

· Crie o pacote de lançamento. No Android Studio, abra Build > Generate Signed Bundle / APK. Selecione APK, clique em Next e escolha o módulo da aplicação. Introduza o caminho do keystore aprovado, o alias da chave e as palavras-passe. Utilize a identidade de assinatura existente para uma atualização. Escolha a variante release e a pasta de saída e, depois, clique em Create ou Finish, conforme a sua versão do Studio.

· Teste o APK assinado. Instale-o no LX1 de teste, repita a tarefa principal e, em seguida, teste uma atualização sobre a compilação assinada anterior. Confirme a retenção de dados, o acesso à câmara e ao microfone, as leituras, a voz e a conectividade com o servidor. O sucesso numa compilação de depuração não prova a compatibilidade da compilação de lançamento.

· Entregue à equipa de TI. Forneça o APK, o ID do pacote, o código de versão, o firmware suportado, as permissões, os endpoints de rede e os requisitos de configuração. A Vuzix anuncia a disponibilidade de MDM através de vários parceiros; confirme junto do seu fornecedor o suporte específico para o LX1, o método de inscrição e o processo de instalação de aplicações privadas. Não assuma que o Managed Google Play está disponível.

· Implemente por fases. Implemente num pequeno grupo de trabalhadores, analise os resultados medidos e alargue depois de os percursos de atualização e de recuperação funcionarem. Guarde o pacote assinado anterior e defina um plano de recuperação compatível com os dados. Desative o acesso de desenvolvimento nos dispositivos de produção de acordo com a política de TI.

Vantagens e limitações para as empresas

· Vantagens. Reutilizar a lógica de negócio Android existente pode reduzir trabalho de desenvolvimento duplicado. Um fluxo de trabalho focado pode facilitar a confirmação de encomendas, a inspeção e o tratamento de exceções, enquanto os trabalhadores mantêm as mãos livres. Valide a vantagem através do piloto.

· Limitações. Ecrãs muito dependentes do toque, integrações dependentes da Google e pressupostos antigos dos SDK do dispositivo podem exigir alterações substanciais. O suporte da frota, as atualizações de firmware e os testes de lançamento continuam a fazer parte do esforço de implementação.

Para contexto sobre a plataforma, consulte a visão geral de software e plataforma do Vuzix LX1 da VR Expert.

Conclusão

Levar uma aplicação Android existente para o Vuzix LX1 começa por verificar as dependências do Android e dos serviços, ligar um dispositivo de teste e instalar uma versão de referência. Adapte o layout monocular, torne todas as ações acessíveis por botões, adicione leitura de códigos ou voz onde o trabalho beneficie disso e teste a versão de lançamento assinada antes da implementação gerida. Para as empresas, esta abordagem preserva a integração com os sistemas existentes, criando ao mesmo tempo um fluxo de trabalho adequado a trabalhadores que usam óculos inteligentes. Um piloto com medições mostra se a adaptação reduz os erros e poupa tempo.

Discuta um piloto do LX1 e os requisitos de implementação com a equipa de hardware empresarial da VR Expert.