Herramientas y componentes de implementación¶
Esta página identifica las tecnologías que BloqueApp usa realmente. Está dirigida a lectores de ingeniería; la arquitectura explica los límites entre componentes, la página de algoritmos deriva el modelo de costos y la guía de conceptos enlaza con política, crédito del banco y funcionamiento sin conexión. Consulte el glosario y las limitaciones para completar el contexto.
Aplicación Android¶
La aplicación del teléfono usa Java 17 y Views nativas de Android. Su SDK mínimo actual es API 33, y compila y usa como destino el SDK 36. Las API de Android proporcionan visibilidad y suspensión de paquetes, comprobaciones de Device Owner, alarmas, Usage Events, estado de pantalla y bloqueo, y notificaciones de servicios en primer plano. La aplicación mueve el trabajo de política, almacenamiento y uso a un worker; no lo ejecuta en callbacks de accesibilidad o de interfaz.
La política de ejecución y el ledger del banco son colaboradores Java con lógica comprobable mediante pruebas unitarias. PolicyDocumentValidator acepta el subconjunto acotado usado por el esquema de política del repositorio. PolicyVerifier y GrantVerifier comprueban envolturas RS256 con la clave pública fijada en la configuración de confianza. La instantánea firmada se guarda atómicamente en archivos protegidos por dispositivo; el estado de aplicación y los cursores del ledger se guardan en preferencias protegidas por dispositivo. Las credenciales de emparejamiento se cifran con una clave AES guardada por Android Keystore en almacenamiento protegido por credenciales. Son almacenes locales con ciclos de vida distintos; el ledger del banco no usa una base SQL local.
La contabilidad consulta UsageStatsManager.queryEvents y reduce eventos de ciclo de vida e interacción del dispositivo a intervalos. No usa totales de uso agregados diarios como autoridad en tiempo real. En esta ruta la plataforma no expone un identificador único de instancia de actividad, por lo que una superposición sostenida de actividad entre paquetes se considera ambigua. Consulte el análisis y los límites medidos.
Servicio ASP.NET Core y SQLite¶
El servicio usa .NET 10, C# 14, ASP.NET Core Minimal APIs, Microsoft.Data.Sqlite y SignalR. SQLite es el almacén durable de emparejamientos, aprobaciones, decisiones, publicación de política, excepciones permanentes de aplicaciones, suscripciones push y estado de la cola de entrega. Las escrituras que deben observarse como una decisión indivisible usan transacciones. La base de datos es local al proceso del servicio; los flujos descritos no requieren Redis.
Los contratos JSON versionados definen solicitudes de acceso, documentos y envolturas firmadas de política, autorizaciones, decisiones, emparejamiento y registro push. Los validadores de Android y del servicio admiten las palabras clave usadas por el documento de política; una nueva restricción debe agregarse y verificarse en ambos lados. El validador no es un motor general de JSON Schema.
El servicio firma autorizaciones e instantáneas de política con una clave privada RSA configurada. El material privado de firma es un secreto operativo y no está en el repositorio ni se devuelve como credencial a los clientes. El APK Android contiene únicamente los datos de confianza pública correspondientes.
Página aprobadora, Web Push y SignalR¶
La interfaz de aprobación es una aplicación estática HTML/CSS/JavaScript servida desde el mismo origen que la API. Su service worker registra suscripciones push, muestra notificaciones y procesa acciones. La API valida endpoints y claves de suscripción, guarda suscripciones asociadas a la persona propietaria y agrega entregas a SQLite cuando se habilita la entrega durable. Un worker en segundo plano toma elementos de la cola y envía Web Push con autenticación VAPID, límites de tiempo HTTP y reintentos acotados.
SignalR funciona dentro del servicio ASP.NET Core como canal de avisos en vivo para un dispositivo emparejado en primer plano. Las lecturas HTTPS durables siguen siendo la fuente de verdad para solicitudes y decisiones. Web Push es una vía aparte para despertar el navegador. Ninguno de los dos mecanismos concede acceso en el dispositivo.
Mapa de la API HTTP y tiempo real¶
La PWA y la API comparten un origen HTTPS. La tabla enumera las rutas principales del cliente Android y de la persona aprobadora; {requestId} es el identificador de solicitud que proporciona quien llama. Las rutas de dispositivo usan la credencial bearer emparejada en el encabezado Authorization, salvo el registro inicial. Las rutas de aprobación usan la cookie segura de sesión; las mutaciones del navegador también exigen comprobaciones JSON del mismo origen. Use estas rutas como mapa de navegación, no como sustituto de los esquemas versionados de solicitud y respuesta.
| Método y ruta | Llamante y autenticación | Propósito y autoridad |
|---|---|---|
POST /api/v1/devices |
Registro inicial del dispositivo; no requiere bearer previo | Registra una identidad de dispositivo e inicia el emparejamiento. No crea una relación con una persona aprobadora. |
POST /api/v1/approver/session |
Navegador; JSON del mismo origen, crea o recupera la sesión segura por cookie | Establece la sesión de aprobación del navegador. |
POST /api/v1/approver/pairings, GET /api/v1/approver/pairing |
Cookie de aprobación | Reclama un código de emparejamiento de un solo uso y consulta el estado de la asociación. |
POST /api/v1/device/pairing/start, GET /api/v1/device/pairing, POST /api/v1/device/pairing/confirm |
Bearer de dispositivo | Inicia o confirma el emparejamiento y consulta el estado desde el dispositivo. |
GET /api/v1/device/policy |
Bearer de dispositivo emparejado | Devuelve la instantánea firmada de política efectiva para ese dispositivo y asociación. Android la verifica localmente. |
POST /api/v1/device/requests, GET /api/v1/device/requests/{requestId} |
Bearer de dispositivo | Crea una solicitud de acceso y consulta su comprobante durable. Un comprobante aprobado puede incluir una autorización firmada y acotada; el comprobante por sí solo no autoriza. |
GET /api/v1/approver/requests, GET /api/v1/approver/requests/{requestId}, POST /api/v1/approver/requests/{requestId}/decision |
Cookie de aprobación | Lista y consulta solicitudes y registra una decisión confirmada. El servicio persiste la decisión antes de enviar avisos en tiempo real. |
POST /api/v1/device/unrestricted-requests, GET /api/v1/device/unrestricted-requests/{requestId}; rutas /api/v1/approver/unrestricted-requests... correspondientes |
Bearer en rutas de dispositivo; cookie en rutas de aprobación | Gestiona el flujo separado y acotado de solicitud y decisión para conservar una aplicación permanentemente sin restricciones. |
GET /api/v1/approver/push/config, POST /api/v1/approver/push/subscriptions, POST /api/v1/approver/push/subscriptions/remove |
Cookie de aprobación emparejada | Lee la configuración pública push y registra o elimina la suscripción del navegador. La entrega push es opcional y no constituye una decisión. |
SignalR wss://<host-publico>/api/v1/device/events |
Bearer emparejado en el encabezado Authorization; sin token en URL ni cookie de aprobación |
Entrega avisos DeviceReady y RequestChanged de mejor esfuerzo. Luego, el dispositivo obtiene el comprobante por HTTPS. |
GET /health/ready; GET /api/v1/status |
Consultas operativas de solo lectura | Disponibilidad indica que los almacenes requeridos del servicio responden. Estado describe parte de la configuración del servicio. Ninguna ruta informa autoridad de aprobación ni estado de aplicación de reglas del teléfono. |
El cliente autoriza con la política local verificada más reciente y una autorización firmada válida, no por una respuesta 200, una consulta de disponibilidad, un evento del hub o una notificación push. Consulte el límite de autoridad de la arquitectura, seguridad y la guía de uso.
Desarrollo y verificación¶
El proyecto Android usa Gradle y el wrapper del repositorio con JDK 17. Las pruebas JVM enfocadas cubren decisiones de política, reglas de autorizaciones firmadas, aritmética del ledger y reducción de eventos; Android lint y las comprobaciones del APK revisan el empaquetado de plataforma. El backend usa el SDK .NET fijado en global.json, dependencias NuGet bloqueadas y pruebas de integración xUnit sobre flujos del servicio respaldados por SQLite. La PWA es código estático y se publica junto al servicio, sin un runtime de servidor independiente.
Las compilaciones y pruebas unitarias comprueban propiedades del código y el empaquetado, no la aceptación física del bloqueo. Una compilación correcta del paquete no demuestra el aprovisionamiento de Device Owner, el comportamiento del lanzador, la suspensión de aplicaciones reales, la entrega de Web Push en un navegador concreto ni la recuperación tras un reinicio o una pérdida real de red. Son cuestiones de aceptación distintas, descritas en las limitaciones actuales.