A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Cómo probar y depurar
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
A continuación, se incluyen varias recomendaciones que debes tener en cuenta a la hora de estructurar tu código de VIA para facilitar su prueba.
Diseña la base de código en unidades independientes
Entre las unidades principales, se incluyen las siguientes:
- Activación. Palabras clave, pulsar para hablar (PTT) y presionar para hablar (TTT).
- Reconocimiento de voz. Se enfoca en convertir transmisiones de audio en datos estructurados.
- Cumplimiento de comandos. Se enfocan en procesar una consulta y traducirla en una acción.
Cada una de estas capas debe poder probarse por sí sola y ser independiente de las demás. Incluye y documenta lo siguiente:
- Intent extras que se pueden usar para pasar las consultas del usuario directamente a la capa de entrega de comandos. Esto permitiría a los OEMs y a los integradores omitir el reconocimiento de voz y probar la entrega de comandos (integraciones de vehículos) directamente.
- Es un proceso para pasar archivos de audio pregrabados al servicio de interacción por voz, lo que permite probar el reconocimiento de voz por sí solo, sin usar el micrófono del vehículo.
Emulador para pruebas
Android Emulator es una excelente plataforma para el desarrollo y las pruebas, ya que proporciona una conexión entre el micrófono del host y la instancia de AAOS de invitado.
Figura 1: Pruebas con emulador
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-26 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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"]]
