Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
Testen und Fehler beheben
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Im Folgenden finden Sie einige Empfehlungen, die Sie beim Strukturieren Ihres VIA-Codes beachten sollten, um das Testen zu erleichtern.
Codebasis in unabhängige Einheiten strukturieren
Zu den primären Einheiten gehören:
- Trigger Hotwording, Push-to-Talk (PTT) und Tippen-zum-Sprechen (TTT)
- Spracherkennung Konzentriert sich auf die Umwandlung von Audiostreams in strukturierte Daten.
- Befehlsausführung Konzentriert sich darauf, eine Anfrage zu verarbeiten und in eine Aktion umzuwandeln.
Jede dieser Schichten sollte für sich allein und unabhängig voneinander getestet werden können. Fügen Sie Folgendes hinzu und dokumentieren Sie es:
- Intent-Extras, mit denen Nutzeranfragen direkt an die Ausführungsebene übergeben werden können. So können OEMs und Integratoren die Spracherkennung überspringen und die Befehlsausführung (Autointegrationen) direkt testen.
- Ein Prozess, bei dem voraufgezeichnete Audiodateien an den Sprachinteraktionsdienst übergeben werden, um die Spracherkennung unabhängig vom Mikrofon des Fahrzeugs zu testen.
Emulator für Tests
Der Android-Emulator ist eine hervorragende Plattform für die Entwicklung und Tests, da er eine Brücke zwischen dem Hostmikrofon und der Gast-AAOS-Instanz herstellt.
Abbildung 1: Emulatortests
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-26 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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"]]
