A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Test e debug
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Di seguito sono riportati diversi consigli da prendere in considerazione durante la strutturazione del codice VIA per semplificarne il test.
Progetta la base di codice in unità indipendenti
Le unità principali includono:
- Attivazione. Hotwording, push-to-talk (PTT) e tap-to-talk (TTT).
- Riconoscimento vocale. Incentrata sulla conversione di stream audio in dati strutturati.
- Evasione dei comandi. Si concentrano sull'elaborazione di una query e sulla sua traduzione in un'azione.
Ognuno di questi livelli deve essere testabile autonomamente e indipendente dall'altro. Includi e documenta:
- Componenti aggiuntivi dell'intenzione che possono essere utilizzati per passare le query degli utenti direttamente al livello di esecuzione dei comandi. In questo modo, OEM e integratori potrebbero saltare il riconoscimento vocale e testare direttamente l'esecuzione dei comandi (integrazioni con l'auto).
- Un processo per trasmettere file audio preregistrati al servizio di interazione vocale, che consente di testare il riconoscimento vocale da solo, ignorando il microfono del veicolo.
Emulatore per i test
Android
Emulator è una piattaforma eccellente per lo sviluppo e i test, in quanto fornisce il collegamento tra il microfono host e l'istanza AAOS guest.
Figura 1. Test dell'emulatore
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-26 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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"]]
