dh-inspeccion-v2/android-app/RELEASE.md

DH Inspección Android · release final de campo 0.19.1

Candidata vigente

• Fase funcional: Flujo final de campo · Inspección → Acta → Hallazgos → Firma.
• versionName: 0.19.1.
• versionCode: 29.
• Application ID release: com.korexlabs.dhinspeccion.
• Application ID debug/QA: com.korexlabs.dhinspeccion.debug.
• API: https://dhv2.korexlabs.com/api/v3/.

La variante debug es independiente de la app productiva y puede instalarse para QA/presentación sin sobrescribir una instalación release histórica.

Procedimiento operativo validado

La APK 0.19.1 fija como recorrido principal de campo:

1. Iniciar Inspección. Al iniciarla se habilitan Actas, Hallazgos e Inventario de campo.
2. Crear o abrir un Acta. Puede haber varias Actas dentro de una misma Inspección, pero sólo una puede permanecer en elaboración al mismo tiempo.
3. Agregar Hallazgos sobre una Instalación o Subinstalación seleccionada.
4. Si el elemento ya existe, se lo selecciona desde el Inventario del Área/Yacimiento de la Inspección.
5. Si no existe, se da de alta desde campo sin abandonar el Acta.
6. Un elemento nuevo debe completar GPS + fotografía antes de poder recibir Hallazgos.
7. Al terminar el contenido del Acta se usa Cerrar Acta y dejar pendiente de firma. Desde ese momento el contenido queda inmutable y el estado visible es Pendiente de firma.
8. La firma del Inspector y la manifestación/firma o negativa de la empresa completan el Acta, que pasa a Firmada y cerrada.
9. La Inspección sólo puede cerrarse cuando todas sus Actas no canceladas están firmadas y cerradas.

La nomenclatura técnica interna de API (DRAFT, LOCKED, SEALED, etc.) no se muestra al inspector: la interfaz usa textos operativos en castellano.

Alta de Instalaciones y Subinstalaciones

El alta móvil queda alineada con el Dashboard y con las validaciones del servidor.

Instalación

• contexto territorial: Yacimiento/Área de la Inspección;
• clasificación técnica compatible;
• Nombre técnico obligatorio;
• Nombre habitual opcional;
• Descripción opcional;
• atributos técnicos definidos por el tipo; sólo los marcados como obligatorios bloquean el guardado;
• código DH generado por el sistema cuando corresponde;
• GPS de la tablet;
• fotografía obligatoria antes de crear Hallazgos.

Subinstalación

Además de lo anterior requiere elegir primero la Instalación padre. El buscador consulta mientras se escribe y cada resultado es seleccionable tocando la tarjeta.

La clasificación y los atributos se obtienen dinámicamente desde el mismo catálogo administrado por el Dashboard; la APK no mantiene listas técnicas paralelas.

Actas y firma

La terminología visible se simplifica:

• DRAFT → En elaboración;
• LOCKED → Pendiente de firma;
• SEALED → Firmada y cerrada.

Cerrar el contenido no cierra automáticamente la Inspección y tampoco obliga a terminar la firma en ese instante: puede continuarse con otra Acta. Una vez cerrado el contenido, el Acta es inmutable.

Después de la firma/cierre definitivo se mantiene el circuito documental existente: PDF del Acta e informe INF editable (DOCX) para oficina.

Castellano e identidad visual

Se revisaron las pantallas activas de campo para evitar exponer estados y opciones internas en inglés. Entre otros cambios: Pasaporte/Otro en documentos, estados de Inspección/Acta/Hallazgo en castellano, Correo electrónico, Huella de integridad y terminología de cierre orientada al usuario.

La pantalla de ingreso y el desbloqueo biométrico utilizan la identidad visual de Mendoza ya incorporada al proyecto.

Barrera obligatoria

Todo cambio Android o de API que pueda afectar al cliente móvil debe pasar Android CI / RC:

1. validación de identidad, HTTPS y políticas básicas del manifest;
2. Android lint;
3. pruebas unitarias Android reales, con verificación de que exista al menos una prueba ejecutada;
4. assembleDebug;
5. assembleRelease para comprobar que la variante productiva compile;
6. empaquetado del APK debug con SHA-256 y metadata de commit/versionado.

Además, DH V2 CI debe mantener verdes API, WEB y contrato Docker/migraciones antes de promover cambios que afecten al servidor.

Firma release

La clave histórica de firma no se versiona ni se reemplaza. La CI compila la variante release para detectar roturas, pero una APK productiva que deba actualizar com.korexlabs.dhinspeccion tiene que firmarse con la clave histórica.

No se debe crear una clave nueva para resolver una falta de acceso: eso rompería la continuidad de actualización de tablets que ya tengan una versión firmada con la clave anterior.

Criterio de distribución

Antes de distribuir una APK productiva:

• todas las barreras de CI del SHA exacto deben estar verdes;
• comprobar certificado/huella de firma contra la versión histórica si se distribuirá como actualización productiva;
• realizar actualización sobre al menos una tablet con la versión productiva anterior cuando corresponda;
• ejecutar smoke funcional: ingreso, iniciar Inspección, crear Acta, seleccionar/crear Instalación o Subinstalación, GPS/foto, Hallazgo, cerrar Acta → Pendiente de firma, firma/manifestación, cierre de Acta y cierre de Inspección;
• registrar el SHA Git y SHA-256 de la APK distribuida.

Revisión 0.19.1

• Renovación de sesión coordinada entre los cuatro clientes API; no cierra sesión por pérdida de red, HTTP 429/500 o cancelación.
• Una respuesta tardía no puede restaurar una sesión cerrada ni usar la de otro inspector.
• Guardia de escrituras contra doble toque y conteo correcto de operaciones pendientes.
• Búsquedas descartan respuestas antiguas. Cambio de inspección limpia el Acta anterior.
• Mensajes visibles de permisos/GPS en evidencia y respeto de barras de sistema/teclado.
• Diez nuevas pruebas de comportamiento sobre sesión y concurrencia.

Alcance real

Esta candidata requiere conexión. No implementa trabajo offline ni cola persistente de sincronización; un fallo de red no equivale a guardado. Tras un timeout de escritura debe verificarse el registro antes de repetir. No se presenta el artefacto debug como una release productiva. La firma histórica y el smoke en tablet siguen siendo requisitos para distribuir la release final.

Segunda pasada funcional

• Coordenadas normalizadas al contrato API (6 decimales, precisión 3).
• Yacimiento seleccionable para Hallazgos y como padre explícito de nuevas Instalaciones. Se elimina el fallback que podía presentar un tipo Yacimiento como alta de Instalación.
• Formulario Datos técnicos sobre el elemento seleccionado: carga y guarda las definiciones/valores por familia mediante los endpoints existentes del Dashboard; valida obligatorios, números, Sí/No, fechas y opciones. Es un paso separado del alta estructural y GPS/foto.
• Se agregan siete pruebas para coordenadas y valores técnicos.