Construye una aplicación de escáner de códigos de barras Cordova: Guía de 2026

Tienes probablemente una de dos situaciones. O has heredado una aplicación Cordova que todavía importa a la empresa, o estás manteniendo una aplicación híbrida estable mientras el equipo se desplaza lentamente hacia herramientas más nuevas. Luego llega una solicitud de producto: escanear etiquetas de inventario, boletos, paquetes o etiquetas de estantería con la cámara del teléfono.

Eso es donde lector de códigos de barras Cordova El trabajo se vuelve interesante. La demo básica es fácil. La integración de producción no lo es. Las partes difíciles son elegir un plugin que coincida con tus formatos de códigos de barras, configurar permisos nativos de manera limpia y tratar con las peculiaridades de las plataformas que solo se muestran en dispositivos reales. Si tu aplicación también interactúa con operaciones de campo o flujos de inventario, la característica de escaneo suele conectarse con preocupaciones operativas más amplias como el manejo de componentes de TI críticosdonde la aplicación móvil se convierte en parte de un flujo de activos y servicios más grande.

Cordova sigue siendo una pila real en el mantenimiento de empresas. A mediados de la década de 2010, el escaneo de códigos de barras en Cordova ya había superado los ejemplos de juguete y se había movido a aplicaciones híbridas de empresa construidas para Android y conectadas a servicios de backend, incluyendo un flujo documentado utilizando cordova create, cordova platform add androidy un generado barcodeScanner-debug.apk en un ejemplo de construcción de aplicación práctica de el recorrido de escaneo de Cordova de SitePointSi tu equipo también está ponderando elecciones de arquitectura a largo plazo, esta comparación de aplicaciones nativas vs aplicaciones web ayuda a definir por qué las aplicaciones híbridas siguen apareciendo en los pipelines de entrega móvil serios.

Contenido de la Tabla

• Why Add a Scanner de Código de Barras to Your App de Cordova
  • Cordova still makes sense in maintenance mode
  • The value is in the workflow, not the demo
• Choosing Your Plugin de Scanner de Código de Barras de Cordova
  • What matters before you install anything
  • Tabla de comparación de plugins
• Instalación y configuración de plataforma
  • Start with the flujo de integración
  • Pasos de instalación de Cordova
  • Configuración nativa que usualmente se rompe primero
• Implementing the Scanner de Código de Barras in Your Application Code
  • Example de JavaScript plano
  • Ejemplo de TypeScript
  • ¿Qué hacer con el resultado de la escaneo?
• Pruebas y depuración de errores comunes
  • El visor de Android detrás del error de la aplicación
  • Fallas de permisos y falsos negativos
  • Problemas de construcción y pruebas de dispositivo
• Consejos de rendimiento y migración a Capacitor
  • Un camino de migración práctico a Capacitor

¿Por qué agregar un escáner de códigos de barras a tu aplicación Cordova?

Un escáner cambia lo que una aplicación Cordova puede hacer en el campo. En lugar de pedir a los usuarios que escriban números de serie, IDs de pedido o códigos de producto, permites que la cámara se convierta en el dispositivo de entrada. Eso reduce la fricción, pero críticamente, reduce el número de formas en que un usuario puede ingresar un valor incorrecto.

En la práctica, el escaneo de códigos de barras aparece donde las aplicaciones móviles se encuentran con operaciones reales. La recepción de almacén, la búsqueda de retail, la validación de partes de servicio de campo, el registro de visitantes y el seguimiento de activos internos se benefician de él. Un escáner también cambia las expectativas de los usuarios. Una vez que la cámara está disponible, los usuarios dejan de tolerar la entrada manual code a menos que haya un fallback claro.

Cordova sigue siendo útil en modo de mantenimiento

A muchas equipos les gusta hablar de Cordova como si hubiera desaparecido. No es así. Se ha convertido en un mantenimiento pesado en los portafolios de empresas, donde reemplazar una aplicación que funciona es más difícil que extenderla. Si la aplicación ya maneja la autenticación, sincronización, formularios y almacenamiento en caché, agregar un escáner a menudo es más bajo riesgo que rehacer todo el producto.

Regla práctica: No trates una solicitud de escaneo como un trigger de reescritura a menos que el resto de la aplicación ya esté fallando la operación de tu equipo.

Cordova también ganó su lugar porque los plugins expusieron las capacidades de dispositivo nativo de una manera en la que el web code podía utilizarla. Eso es por qué el escaneo de códigos de barras se volvió tan común en aplicaciones móviles híbridas. Se ajustaba al patrón exacto para el que se construyó Cordova: poner una capacidad nativa detrás de un API de JavaScript y dejar que el flujo de la aplicación se mantenga principalmente web.

El valor está en el flujo de trabajo, no en la demostración

Un botón de escaneo que devuelve texto es la parte fácil. El trabajo principal es todo lo que lo rodea:

• Seleccionar las simbologías soportadas: Tus aplicaciones pueden necesitar solo QR, o pueden necesitar códigos de retail y logística también.
• Manejar las permisos de manera limpia: Si el acceso a la cámara falla una vez, los usuarios a menudo asumen que la característica está rota.
• Diseñar la acción posterior al escaneo: La búsqueda, la validación, la navegación y el manejo de duplicados importan más que la interfaz de la cámara UI.
• Planificación de modernización: Si su equipo está moviéndose hacia Capacitor, necesita un enfoque que no atrape la característica en suposiciones de Cordova únicamente.

Es un punto importante. Los equipos a menudo tienen éxito con la integración inicial de Cordova, pero luego encuentran problemas durante la migración porque el modelo de renderizado nativo cambia debajo del plugin. El escáner sigue funcionando. La vista previa simplemente no muestra donde se espera.

Elige tu plugin de escáner de códigos de barras de Cordova

Antes de escribir cualquier aplicación code, decida qué estás optimizando. Algunos equipos necesitan un soporte de códigos de barras amplio. Otros solo necesitan una capa de cámara para flujos de QR. Seleccionar el plugin incorrecto al principio crea retrasos posteriores, especialmente cuando el producto solicita un formato de código de barras adicional después del lanzamiento.

El plugin que más desarrolladores reconocerán es cordova-plugin-barcodescanner. Su npm paquete documenta un scan(success, fail) API y soporte para símbolos comunes incluyendo QR_CODE, DATA_MATRIX, UPC_A, EAN_13, CODE_128, PDF_417, y AZTEC, lo que es por qué se ajusta a escenarios de retail y logística en lugar de solo casos de uso basados en QR, como se muestra en la documentación del paquete del plugin en npm.

Para equipos que evalúan la estrategia de plugin de manera más amplia, esta visión general de ¿Qué saber sobre los plugins de Capacitor es útil porque destaca las diferencias entre las suposiciones de plugins de estilo Cordova más antiguos y los modelos de puentes nativos más nuevos

¿Qué importa antes de instalar cualquier cosa

No comiences con la popularidad sola. Comienza con tu trabajo de escaneo

Si la aplicación debe leer varias familias de códigos de barras en diferentes contextos de operación, la soporte de símbolos más amplio importa más que un API mínimo. Si la aplicación solo necesita verificar el código QR, puedes aceptar una herramienta más estrecha si te da una experiencia de cámara más simple. Lo que los desarrolladores junior a menudo pasan por alto es que el trabajo de escaneo es menos sobre '¿puede escanear' y más sobre '¿puede escanear los etiquetas exactas utilizadas por las operaciones sin soluciones de trabajo incómodas'

Una buena lista de verificación de selección se parece a esto:

• Cobertura de códigos de barras: Confirmar los formatos exactos utilizados en producción
• Expectativas de plataforma: Verificar qué equipo todavía apoya hoy, no qué plugin apoyó históricamente
• Modelo de interfaz de usuario: Algunos plugins abren un flujo de escaneo nativo. Otros esperan un enfoque de vista previa integrada.
• Umbral de migración: Pregúntese si este plugin se volverá doloroso si la aplicación se mueve a Capacitor más tarde.

Un plugin que funciona en una demostración pero lucha con el diseño de la aplicación, el ciclo de vida o el camino de migración suele ser el plugin incorrecto.

Tabla de comparación de plugins

La tabla refleja el ajuste práctico, no una tarjeta de puntuación. Si necesita símbolos de código de barras de retail y logística, la categoría de plugin más amplia es usualmente la elección más segura. Si solo escanea QR y quiere una experiencia de vista previa más controlada, un camino orientado a QR puede ser más ligero

El error que veo más a menudo es elegir una herramienta enfocada en QR porque la primera versión solo necesita QR, luego forzarla a UPC o Code 128 para trabajar más tarde. Si hay alguna posibilidad de que los usuarios de su negocio escanee etiquetas de impresoras, estantes, contenedores o documentos de envío, elija para ese futuro ahora.

Instalación y Configuración de la Plataforma

La integración suele fallar antes de la primera escaneo, no después. La mayoría de los errores provienen de la desviación de configuración entre las expectativas de JavaScript y la configuración nativa de la plataforma. Trate esta parte como una lista de verificación, no como una instalación rápida.

Un flujo de implementación sólido comienza con la adición del plugin o SDK, la creación del contexto de captura, la limitación de los símbolos a los códigos que se utilizan en producción, la configuración de la interfaz de usuario y solo entonces el registro de un escuchador de escaneo. Esa secuencia se destaca en la guía de Scandit para Cordova SparkScan, y coincide con cómo las integraciones de escáneres profesionales permanecen mantenibles en aplicaciones híbridas, como se describe en La guía del desarrollador de Scandit para el escaneo de códigos de barras en Cordova. Si su aplicación sigue siendo híbrida a nivel de arquitectura, esta guía sobre el desarrollo de aplicaciones híbridas en Cordova es una compañera útil. Una laptop con __CAPGO_KEEP_0__ editor, un teléfono móvil en un soporte y una placa de circuito en una mesa de madera.

Una característica de escaneo se ve mejor cuando decide estos items primero:

Qué tipos de códigos de barras debe aceptar la aplicación.

1. Instalación y configuración de la plataforma es crucial para evitar errores en la integración del escaneo de códigos de barras.
2. ¿Se trata de una acción de pantalla completa o parte de un flujo de trabajo integrado?
3. ¿Qué debe hacer la aplicación después de una lectura exitosa?
4. ¿Qué existe como alternativa cuando no se puede utilizar la cámara?

¿Qué mantiene la instalación del plugin vinculada a un flujo de trabajo real en lugar de una capacidad de dispositivo genérica?

Pasos de instalación de Cordova

Para una configuración tradicional de Cordova utilizando el plugin de escáner de códigos de barras común, el punto de partida es el comando de instalación estándar documentado por el paquete:

cordova plugin add cordova-plugin-barcodescanner

Una secuencia de configuración de proyecto típica se ve así:

cordova create barcodeScannerApp
cd barcodeScannerApp
cordova platform add android
cordova platform add ios
cordova plugin add cordova-plugin-barcodescanner
cordova build android
cordova build ios

Esa secuencia es simple, pero no te detengas ahí. Construye inmediatamente después de la instalación del plugin para capturar problemas de dependencia nativa antes de conectar la interfaz de usuario code. Si la construcción falla, resuelve eso primero.

Configuración nativa que suele romperse primero

En iOS, se debe declarar correctamente el acceso a la cámara en los ajustes de proyecto nativo. Si la descripción de uso de la privacidad de la cámara está ausente o vaga, el escáner no funcionará como una característica funcional para los usuarios. Agrega una descripción de privacidad de cámara clara en Info.plist Eso explica por qué la aplicación necesita la cámara.

On Android, revise las entradas del manifiesto y las permisos relacionados con plugins después de la instalación. El plugin puede agregar lo que necesita, pero los proyectos más antiguos a menudo contienen cambios de configuración acumulados, ajustes de Gradle personalizados o superposición de plugins que causan advertencias de compilación o confusión en tiempo de ejecución. No asuma que el manifiesto está limpio solo porque el plugin se instaló con éxito.

Utilice este rápido checklist:

• Verifique las versiones de plataforma: Los proyectos de Cordova más antiguos a menudo llevan paquetes de plataforma obsoletos.
• Revisa las solicitudes de permiso: La redacción y el momento importan para la confianza del usuario.
• Pruebe en un dispositivo real temprano: Los emuladores no le dirán lo suficiente sobre el comportamiento de la cámara.
• Mantenga el alcance del escáner estrecho: Activa solo los tipos code que acepta tu flujo de trabajo.

Si su escáner necesita solo uno o dos formatos, configure para esos primero. El escaneo amplio parece flexible, pero a menudo hace que la depuración sea más lenta porque cada etiqueta ininteligible se vuelve ambigua.

Para los desarrolladores junior, la lección clave es esta: la instalación no es solo una instrucción de terminal. Es la alineación del proyecto nativo. Si Android e iOS no se configuran intencionalmente, la capa de JavaScript no te salvará.

Implementar el Escáner en su Aplicación Code

Una vez que el plugin está instalado y la aplicación se compila, mantenga la primera implementación aburrida. Coloque la acción de escaneo detrás de un botón, registre el resultado completo y pruebe el flujo de llamada antes de diseñar una interfaz de usuario pulida alrededor de él.

El patrón de escáner Cordova común utiliza el método de la scan(success, fail) El estilo de llamada por devolución de llamada es antiguo, pero es confiable en las bases de código legado y fácil de envolver más tarde si su aplicación ha pasado a promesas o abstracciones de TypeScript. Si desea una modelo mental más claro de cómo las llamadas web code llaman a los módulos nativos code en estos proyectos, esta explicación de how Capacitor bridges web and native code Una persona sosteniendo un teléfono móvil utilizando una aplicación de cámara para escanear un código de barras en una caja de cartón.

Ejemplo de implementación mínimo para una aplicación Cordova más antigua:

Ejemplo de implementación mínima para una aplicación Cordova más antigua:

<button id="scan-button">Scan barcode</button>
<div id="scan-result"></div>

document.addEventListener('deviceready', function () {
  var button = document.getElementById('scan-button');
  var resultEl = document.getElementById('scan-result');

  button.addEventListener('click', function () {
    cordova.plugins.barcodeScanner.scan(
      function (result) {
        if (result.cancelled) {
          resultEl.textContent = 'Scan cancelled';
          return;
        }

        resultEl.textContent =
          'Text: ' + result.text +
          ' | Format: ' + result.format;
      },
      function (error) {
        resultEl.textContent = 'Scan failed: ' + error;
      }
    );
  });
});

Esto hace tres cosas útiles. Espera a deviceready, vincula la escaneo a una acción intencional del usuario, y maneja tanto el éxito como el fracaso de manera explícita. No omita el caso cancelado. Los usuarios se deshacen de las flujos de cámara todo el tiempo.

Ejemplo de TypeScript

Si tu proyecto utiliza TypeScript, define la forma del resultado tú mismo para que el resto de la aplicación pueda consumirlo limpiamente:

interface BarcodeScanResult {
  text: string;
  format: string;
  cancelled: boolean;
}

function scanBarcode(): void {
  cordova.plugins.barcodeScanner.scan(
    (result: BarcodeScanResult) => {
      if (result.cancelled) {
        renderStatus('Scan cancelled');
        return;
      }

      handleScannedCode(result);
    },
    (error: unknown) => {
      renderStatus(`Scan failed: ${String(error)}`);
    }
  );
}

function handleScannedCode(result: BarcodeScanResult): void {
  renderStatus(`Scanned ${result.format}: ${result.text}`);

  if (!result.text) {
    renderStatus('Empty scan result');
    return;
  }

  lookupItemByCode(result.text);
}

function renderStatus(message: string): void {
  const el = document.getElementById('scan-result');
  if (el) el.textContent = message;
}

function lookupItemByCode(code: string): void {
  console.log('Lookup code:', code);
}

Esta versión separa la escaneo de la lógica de negocio. Eso importa porque el plugin de escaneo solo debe capturar la entrada. La validación, la búsqueda y la navegación pertenecen a otro lugar.

¿Qué hacer con el resultado de la escaneo?

Un buen flujo posterior a la escaneo es normalmente uno de estos:

• Flujo de búsqueda: Utiliza el texto escaneado para recuperar un registro de producto, orden o activo.
• Flujo de validación: Compara el valor escaneado contra un valor esperado code ya en pantalla.
• Flujo de navegación: Ruta el usuario a una tarea relacionada con el artículo escaneado.
• Captura de flujo: Almacene el valor localmente para sincronizarlo más tarde.

No permita que el callback del escáner se convierta en un contenedor para llamadas de API, actualizaciones de DOM, análisis y navegación. Pase el valor rápidamente.

También, registre el resultado bruto durante la prueba inicial. Incluso si su interfaz de usuario de producción solo necesita textel valor devuelto format es útil para depurar etiquetas desincronizadas. Si operaciones dice “el escáner no puede leer este code,” el formato de datos a menudo le dice si el problema es el tipo de código de barras, no la calidad del código de barras.

Pruebas y Resolución de Problemas de Errores Comunes

La mayoría de los problemas de escáner de código de barras de Cordova no provienen del escaneo API en sí. Proviene de la frontera entre la interfaz de usuario web, las vistas nativas y los permisos del dispositivo. Aquí, las demostraciones limpias se convierten en informes de errores confusos.

El problema más difícil de diagnosticar es el error de renderizado de Android que aparece durante Capacitor las migraciones o los conjuntos mixtos de Cordova-Capacitor. Un desarrollador en Capacitor issue #1213 lo describió claramente: “Intenté este plugin en mi capacitor aplicación pero parece que el escáner está detrás de la aplicación”, y la solución requiere hacer el fondo del navegador web nativo transparente junto con los cambios de transparencia de DOM, que los tutoriales de Cordova estándar a menudo no cubren, como se documenta en el Capacitor Problema de rendimiento de Android en discusión. Si está depurando una migración híbrida, esta guía para depurar aplicaciones __CAPGO_KEEP_0__ es útil mantenerla abierta. debugging Capacitor apps Síntoma

Comienza el escáner. Los permisos parecen estar bien. No hay un crash obvio. Pero la previsualización de la cámara aparece invisible, bloqueada o 'detrás' de la interfaz de usuario de la aplicación.

Causa
La vista de escáner nativa y la vista de web están configuradas de manera diferente a lo que esperaba el plugin de Cordova original. En Android en configuraciones de tipo __CAPGO_KEEP_0__, el fondo de la vista de web puede permanecer opaco, por lo que la previsualización nativa existe pero se mantiene oculta debajo de ella.

Solución
The native scanner view and the webview are layered differently than the original Cordova plugin expected. On Android in Capacitor-style setups, the webview background can remain opaque, so the native preview exists but stays hidden beneath it.

Lado nativo:
__CAPGO_KEEP_0__ Problema de rendimiento de Android en discusión

• __CAPGO_KEEP_0__ apps debugging guide Establezca el fondo de la vista web en transparente.
• Lado web: Elimine los fondos opacos de los elementos de contenedor que se encuentran sobre la vista previa del escáner.
• Lado de la disposición: Verifique los contenedores de página de marco por defecto, cápsulas modales y contenedores de página de marco para colores de fondo por defecto.
• Lado de la prueba: Valida en un dispositivo Android físico porque el comportamiento de la disposición puede ser engañoso en las cápsulas de desarrollo.

Esto es el bug que hace que los desarrolladores piensen que el plugin está roto cuando en realidad es un problema de composición de vistas.

Fallas de permiso y falsos negativos

Las permisiones fallan de maneras que parecen ser errores del escáner.

Si el usuario deniega el acceso a la cámara, su callback puede mostrar un error genérico, o el escáner puede no presentarse como se espera. Maneje la denegación de permiso como una rama normal en la interfaz. Informe al usuario sobre lo que sucedió y cómo volver a intentarlo después de habilitar el acceso. En iOS, especialmente, el texto de permiso poco claro crea desconfianza antes de que el usuario vea el escáner.

Unos pocos hábitos ayudan:

• Activar la escaneo desde una acción de usuario clara: Las solicitudes de permiso parecen menos sospechosas.
• Mostrar entrada de fallback: La entrada manual mantiene el flujo de trabajo vivo.
• Prueba los caminos de denegación y reintento: Muchas equipos solo prueban el camino feliz una vez.

Problemas de construcción y pruebas de dispositivo

Algunas fallas solo se muestran en ciertos entornos.

Resta la página a un botón y un elemento de resultado cuando se depure. Si el escáner funciona allí, tu problema suele ser de diseño o caja de app code, no el plugin

Consejos de rendimiento y migración a Capacitor

Un escáner de códigos de barras puede decodificar correctamente y fallar al usuario en la práctica. El problema suele manifestarse como retraso, parpadeo, problemas de visor de cámara, o una pantalla de Android que se comporta de manera diferente en diferentes dispositivos del mismo conjunto de pruebas.

En aplicaciones de Cordova más antiguas, el decodificador a menudo no es el punto débil. La vista web, la capa de visualización y el code que reacciona a los resultados de escaneo suelen causar más problemas que la reconocimiento de códigos de barras en sí.

Comience limitando la pantalla de escaneo a un alcance estrecho. Si la pantalla está diseñada para escanear etiquetas de inventario, hágalo. Los filtros adicionales, los paneles animados y las actualizaciones de estado amplias agregan trabajo de redibujo justo donde la renderización de Android webview ya es frágil.

Unos cambios pueden tener un impacto rápido:

• Limitar los formatos de códigos de barras aceptados Si su plugin lo admite. Esto reduce las lecturas falsas y hace que la cobertura de pruebas sea más fácil de razonar.
• Mantenga la lógica posterior al escaneo corta. Analice, valide y actualice la parte más pequeña posible de la interfaz de usuario.
• Bloquee lecturas duplicadas durante un momento. Algunos dispositivos dispararán el mismo resultado varias veces antes de que el usuario mueva la cámara.
• Diseñe la entrada manual en el flujo. Etiquetas dañadas, mala iluminación y empaquetado reflectante aún ocurren en entornos de producción.
• Monitorea el costo de Android de repintar con atención. Superposiciones pesadas, transiciones CSS y componentes superpuestos pueden desestabilizar la vista previa de la cámara dentro de un navegador de Cordova.

Un camino de migración práctico a Capacitor

La migración más limpia de Cordova a Capacitor se realiza en etapas, no de manera heroica. Los equipos se meten en problemas cuando intercambian el contenedor de la aplicación, el plugin de escaneo, el flujo de permisos y las capas de la interfaz de usuario en una sola pasada, y luego no pueden determinar qué cambio causó la rotura.

Use este orden en su lugar:

1. Realice un auditorio de plugins actuales
   Liste cada plugin de Cordova y marque cada uno como activo, reemplazable o de riesgo porque depende de comportamientos de plataforma más antiguos.

2. Desplace la caja de la aplicación primero
   Ejecute el existente web app dentro de Capacitor antes de reemplazar el escaneo code. Eso separa los problemas del contenedor de los problemas del plugin.

3. Conservar plugins de Cordova durante una transición corta si es necesario
   La compatibilidad temporal a menudo es más segura que reescribir el escáner, el acceso a archivos y el manejo de permisos al mismo tiempo.

4. Sustituye las piezas del escáner frágiles temprano
   Los plugins antiguos que dependen de capas de sobreposición personalizadas, el comportamiento de Android no documentado o el manejo de cámaras desactualizado deben moverse cerca de la parte superior de la cola.

El bug de la vista previa de la cámara de Android merece una atención especial porque desperdicia mucho tiempo de depuración. He visto pantallas de escáner fallar porque la vista previa nativa se encuentra detrás del webview, se corta en los bordes o se renderiza negro en dispositivos Android específicos. En ese punto, el plugin de código de barras se culpa primero, incluso aunque la composición de vistas es el problema subyacente.

Trátalo como una investigación de renderizado, no solo una investigación de escáner. Elimina las capas de sobreposición decorativas. Reduzca la página a la vista previa, un trigger y un campo de resultado. Si la vista previa se vuelve estable después de eso, el problema suele ser tu estructura de pantalla o CSS, no la decodificación.

Esto es también donde una migración a Capacitor comienza a justificarse. Capacitor no elimina todos los bugs de la cámara, pero suele darte una frontera más limpia entre el manejo de vistas nativas y la interfaz de usuario web code. Para el escaneo de códigos de barras @capgo/cámara-previa muestra una alimentación de cámara en vivo como una capa de sobreposición nativa con controles personalizables, así que puedes decodificar frames en JavaScript sin que la vista previa se encuentre detrás del webview. Para el escaneo empresarial en dispositivos Zebra @capgo/capacitor-zebra-datawedge gestiona perfiles de DataWedge y triggers de escaneo. Para flujos de trabajo de etiquetas NFC @capgo/capacitor-nfc gestiona la descubierta, lectura y escritura de etiquetas nativas en iOS y Android.

Los proyectos de Cordova tenden a romperse debido a la edad de los plugins, el desplazamiento de la plataforma y suposiciones ocultas en las integraciones más antiguas. Los proyectos Capacitor exponen diferentes problemas, principalmente alrededor del manejo de la vida cíclica y la capa nativa, pero esas fallas son más fáciles de rastrear porque el lado nativo es más explícito.

Si su escáner de Cordova funciona solo después de una pila de arreglos específicos del dispositivo, detenga la adición de parches. Estabilice la pantalla de escaneo, confirme si el problema de la vista previa de Android realmente es un problema de capa de vista previa y luego migre en pasos controlados. Ese camino es más lento durante una semana y más rápido para el resto del proyecto.