À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Tester et déboguer
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Vous trouverez ci-dessous plusieurs recommandations à prendre en compte lorsque vous structurez votre code VIA pour le rendre plus facile à tester.
Organiser la base de code en unités indépendantes
Voici les unités principales:
- Déclenchement Commande vocale, mode PTT (Appuyer pour parler) et mode TTT (Appuyer pour parler).
- Reconnaissance vocale Axée sur la conversion des flux audio en données structurées.
- Exécution de la commande. Il est axé sur le traitement d'une requête et sa traduction en action.
Chacune de ces couches doit être testable individuellement et indépendamment les unes des autres. Incluez et documentez les éléments suivants:
- Éléments supplémentaires d'intent pouvant être utilisés pour transmettre les requêtes des utilisateurs directement à la couche d'exécution des commandes. Cela permettrait aux OEM et aux intégrateurs d'ignorer la reconnaissance vocale et de tester directement l'exécution des commandes (intégrations dans les voitures).
- Processus permettant de transmettre des fichiers audio préenregistrés au service Voice Interaction, ce qui permet de tester la reconnaissance vocale seule, en ignorant le micro du véhicule.
Émulateur pour les tests
Android Emulator est une excellente plate-forme de développement et de test, car elle permet de faire le pont entre le micro hôte et l'instance AAOS invitée.
Figure 1 : Tests avec un émulateur
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/26 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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"]]
