Dev Hub
Modos de enrollment
Cómo BLANK distingue entre los 3 productos que vende y por qué esa distinción no es cosmética — es la capa que determina qué puede o no hacer el teléfono.
¿Qué es esto y por qué importa?
Bajo la marca BLANK conviven 3 productos distintos: el teléfono que vendemos ya configurado (BLANK-Owned), el modelo que el cliente trae, resetea y convierte en un BLANK equivalente (BYOD Full), y el modelo donde el cliente instala la app sobre su teléfono personal sin resetear (BYOD Limited). La capa de enrollment es lo que detecta en qué modo está cada dispositivo y decide qué capacidades están disponibles.
La diferencia es técnicamente real, no un detalle comercial. Android solo deja aplicar políticas duras (bloquear Settings, kiosk, wipe remoto) si la app tiene permisos de Device Owner — y Device Owner solo se concede al primer arranque o tras un factory reset. Confundir estos 3 modos en producto o en copy sería vender algo que después no podremos cumplir. De ahí la matriz de capacidades, los 3 SKUs separados y la transparencia obligatoria con el cliente.
Los 3 modos
| Modo | Setup | Reset requerido | Capacidades completas | Support tier | SKU | Precio |
|---|---|---|---|---|---|---|
| BLANK-Owned | QR provisioning de fábrica (Device Owner al primer arranque) | No (el teléfono llega listo) | Sí — todas | Tier 1 (completo, responsabilidad BLANK) | BLANK Phone | Teléfono + suscripción familiar |
| BYOD Full | Factory reset + QR provisioning (Device Owner tras reset) | Sí — explícito, con consentimiento | Sí — mismas que BLANK-Owned | Tier 2 (completo en software, hardware best-effort) | BLANK Full | Solo suscripción familiar |
| BYOD Limited | Instalación como app normal (sin Device Owner) | No | No — subset parcial | Tier 3 (limitado, documentado) | BLANK Limited | Suscripción reducida |
Matriz de capacidades resumida
Solo 8 features representativos. La matriz completa vive en docs/architecture/capability-matrix.csv.
| Feature | BLANK-Owned | BYOD Full | BYOD Limited |
|---|---|---|---|
| App allowlist | SUPPORTED | SUPPORTED | SUPPORTED_DEGRADED |
| Screen time schedules | SUPPORTED | SUPPORTED | SUPPORTED_DEGRADED |
| Lock task / kiosk | SUPPORTED | SUPPORTED | UNSUPPORTED |
| Disable Settings | SUPPORTED | SUPPORTED | UNSUPPORTED |
| OTA policy push | SUPPORTED | SUPPORTED | SUPPORTED_DEGRADED |
| Remote lock/wipe | SUPPORTED | SUPPORTED | UNSUPPORTED |
| Usage reporting | SUPPORTED | SUPPORTED | SUPPORTED_DEGRADED |
| SOS button | SUPPORTED | SUPPORTED | SUPPORTED |
Dónde vive esto en el código
android/launcher/.../enrollment/— DeviceOwnershipDetector, EnrollmentMode, CapabilityResolver.android/launcher/.../capabilities/— Capability, CapabilityMatrix, CapabilityGuard.backend/shared/blank_shared/capabilities/— matriz compartida (fuente de verdad).backend/device-service/app/services/enrollment_classifier.py— clasificación del dispositivo en registro.backend/policy-service/app/services/policy_compatibility_service.py— gating de políticas contra capacidades.apps/parent-dashboard/src/components/EnrollmentBadge.tsxyCapabilityList.tsx— UI de padres.
Reglas de oro del producto
- Nunca ocultar limitaciones en Limited mode — siempre visibles en Parental Settings.
- Nunca prometer que BYOD Limited equivale a BLANK-Owned. Son productos distintos.
- Siempre ofrecer el upgrade path cuando se surface una limitación.
- El reset es una decisión del usuario, con consentimiento explícito y registrado.
- Las 3 SKUs tienen tier de soporte diferente — reflejarlo en pricing y docs.
Links clave
- docs/architecture/adr-006-byod-control-levels.md — ADR que establece los niveles de control.
- docs/architecture/adr-007 / 008 / 009 — decisiones relacionadas sobre capacidades, provisioning y downgrade.
- docs/guides/enrollment-flows.md — flujos paso a paso por modo.
- intranet /ops/compatibility-matrix — ops console (pending implementation).