A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Testar e depurar
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Confira a seguir várias recomendações para considerar ao estruturar o código da VIA
para facilitar o teste.
Projetar a base de código em unidades independentes
As unidades principais incluem:
- Acionamento. Palavra-chave, push-to-talk (PTT) e toque para falar (TTT).
- Reconhecimento de voz. Foco na conversão de streams de áudio em dados estruturados.
- Execução de comandos. Foco no processamento de uma consulta e na conversão dela em
uma ação.
Cada uma dessas camadas precisa ser testável por conta própria e independente uma da
outra. Inclua e documente:
- Extras de intent que podem ser usados para transmitir consultas do usuário diretamente para a camada de atendimento
de comandos. Isso permitiria que OEMs e integradores pulassem o reconhecimento de voz e testassem o comando
de voz (integrações de carro) diretamente.
- Um processo para transmitir arquivos de áudio pré-gravados ao serviço de interação por voz, permitindo
testar o reconhecimento de voz por conta própria, pulando o microfone do veículo.
Emulador para testes
O Android
Emulator é uma plataforma excelente para desenvolvimento e teste, porque oferece ponte
entre o microfone do host e a instância do AAOS convidado.
Figura 1. Testes de emulador
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-26 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-26 UTC."],[],[],null,["# Test and debug\n\nFollowing are several recommendations to consider as you structure your VIA\ncode to make it easier to test.\n\nArchitect the code base into independent units\n----------------------------------------------\n\nPrimary units include:\n\n- **Triggering.** Hotwording, Push-to-Talk (PTT) and Tap-to-Talk (TTT).\n- **Voice recognition.** Focused on converting audio streams into structured data.\n- **Command fulfillment.** Focused into processing a query and translate it into an action.\n\nEach of these layers should be testable on its own and independent from each\nother. Include and document:\n\n- Intent extras that can be used to pass user queries directly to the command fulfillment layer. This would allow OEMs and integrators to skip the voice recognition and test command fulfillment (car integrations) directly.\n- A process to pass prerecorded audio files into the Voice Interaction service, allowing to test voice recognition on its own, skipping the vehicle microphone.\n\nEmulator for testing\n--------------------\n\n[Android\nEmulator](https://developer.android.com/studio/run/emulator) is an excellent platform for development and testing as it provides bridging\nbetween the host microphone and the guest AAOS instance.\n\n**Figure 1.** Emulator testing"]]
