Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release
thay vì aosp-main
để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
Kiểm thử và gỡ lỗi
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Sau đây là một số đề xuất mà bạn nên cân nhắc khi cấu trúc mã VIA để dễ dàng kiểm thử hơn.
Thiết kế cơ sở mã thành các đơn vị độc lập
Các đơn vị chính bao gồm:
- Kích hoạt. Lệnh gọi nhanh, Nhấn để nói (PTT) và Nhấn để trò chuyện (TTT).
- Nhận dạng giọng nói. Tập trung vào việc chuyển đổi luồng âm thanh thành dữ liệu có cấu trúc.
- Thực hiện lệnh. Tập trung vào việc xử lý truy vấn và chuyển đổi truy vấn đó thành một hành động.
Mỗi lớp trong số này phải có thể kiểm thử riêng và độc lập với nhau. Bao gồm và ghi lại:
- Các ý định bổ sung có thể được dùng để chuyển trực tiếp truy vấn của người dùng đến lớp thực hiện lệnh. Điều này cho phép nhà sản xuất thiết bị gốc (OEM) và nhà tích hợp bỏ qua tính năng nhận dạng giọng nói và trực tiếp kiểm thử việc thực hiện lệnh (tích hợp ô tô).
- Một quy trình để truyền các tệp âm thanh được ghi sẵn vào dịch vụ Tương tác bằng giọng nói, cho phép tự kiểm thử tính năng nhận dạng giọng nói, bỏ qua micrô của xe.
Trình mô phỏng để kiểm thử
Trình mô phỏng Android là một nền tảng tuyệt vời để phát triển và kiểm thử vì nó cung cấp cầu nối giữa micrô của máy chủ và thực thể AAOS khách.

Hình 1. Kiểm thử bằng trình mô phỏng
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-26 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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"]]