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

DH Inspección Android · release de campo 0.19.0

Candidata vigente

• Fase funcional: Campo final / Inspección → Acta → Inventario → Hallazgos → Firma.
• versionName: 0.19.0.
• versionCode: 28.
• 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 de campo validado

1. La inspección se planifica y asigna desde el tablero web. La APK no crea inspecciones nuevas.
2. En la tablet el inspector abre una inspección asignada y, al llegar al lugar, pulsa Iniciar inspección.
3. Con la inspección en curso se crea o selecciona el Acta de trabajo. Sólo puede existir un Acta en borrador a la vez; una inspección puede contener varias Actas sucesivas.
4. Los Hallazgos se registran exclusivamente sobre Instalaciones o Subinstalaciones.
5. Si el elemento ya existe, se busca y selecciona desde Inventario de campo.
6. Si no existe, se da de alta desde la APK siguiendo la misma estructura que el tablero:
   • Instalación dentro del Yacimiento de la inspección;
   • Subinstalación dentro de una Instalación seleccionada;
   • nombre técnico / identificación obligatorio;
   • Código DH de campo autogenerado por el servidor;
   • nombre habitual opcional;
   • descripción y observaciones de alta opcionales;
   • clasificación técnica obligatoria cuando el tipo la requiera;
   • atributos técnicos dinámicos obligatorios según la configuración del tipo;
   • Área y Operadora heredadas de la inspección planificada;
   • ubicación del dispositivo y fotografía obligatorias antes de habilitar Hallazgos.
7. Sobre el elemento se selecciona un Hallazgo del catálogo contextual o OTROS cuando corresponda; se registra descripción, gravedad y evidencia fotográfica si aplica.
8. Al terminar el contenido se pulsa Cerrar Acta y dejar pendiente de firma. El contenido y los Hallazgos quedan inmutables y el estado visible pasa a Pendiente de firma.
9. Se registran las firmas y la manifestación de la empresa. La ausencia por sí sola no modifica el contenido cerrado: el Acta permanece pendiente hasta resolver el circuito de firma/manifestación conforme a la regla vigente.
10. Una vez resuelta la firma, el Acta queda Firmada e inmutable. La inspección sólo puede cerrarse cuando todas sus Actas no canceladas estén finalizadas.

Castellano y presentación

La navegación operativa de la APK se presenta en castellano. Los valores técnicos que la API conserva internamente (DRAFT, LOCKED, SEALED, PLANNED, etc.) no se muestran al inspector; se traducen a Borrador, Pendiente de firma, Firmada, Planificada, En curso, etc.

También se incorporó la marca oficial de Mendoza provista para esta release en las pantallas de acceso y desbloqueo biométrico.

Integridad del alta de Inventario

El alta móvil no duplica los formularios administrativos del tablero. Conserva los datos necesarios para que el registro tenga identidad y trazabilidad en campo, mientras que los datos administrativos que ya vienen determinados por la inspección (Área y Operadora) se heredan automáticamente.

El servidor continúa siendo la autoridad para:

• generar el Código DH CAM-* cuando el alta nace en campo;
• validar la jerarquía Yacimiento → Instalación → Subinstalación;
• exigir la familia/clasificación técnica compatible;
• validar atributos dinámicos configurados en el tablero;
• registrar ubicación de creación;
• impedir crear Hallazgos sobre un alta de campo que todavía no tenga ubicación y fotografía;
• conservar la trazabilidad si el alta provisional se fusiona posteriormente con un registro existente.

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. unit tests Android reales, incluyendo contratos del procedimiento final;
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 incorporar la release a main.

Firma release

La clave histórica de firma no se versiona ni se reemplaza. La CI compila la variante release para detectar roturas, pero la APK productiva final debe firmarse con la clave histórica antes de instalarse como actualización de com.korexlabs.dhinspeccion.

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;
• realizar actualización sobre al menos una tablet con la versión productiva anterior;
• ejecutar smoke funcional contra producción: ingreso, abrir inspección asignada, iniciar inspección, crear Acta, buscar Instalación/Subinstalación, alta de campo, ubicación/foto, Hallazgo, cerrar Acta a pendiente de firma, firma/finalización y cierre de inspección;
• registrar el SHA Git y SHA-256 de la APK distribuida.