Offline
Evolución del FRP y Seguridad de Cuentas en Android (2010–2027)
🗓 2010–2014 (Android 2.x–4.4 KitKat)
No existía FRP.
Particiones: /data (reset) · /system intacto.
OEMs: ninguna capa extra.
Seguridad: Muy baja.
🗓 2015 (Android 5.1 Lollipop)
Nace FRP (pide cuenta Google tras reset).
Particiones: /system (flag), /persist (algunos fabricantes).
OEMs:
Samsung: primeros bloqueos en efs.
Huawei / LG: sin refuerzo adicional aún.
Seguridad: Baja (bypass fáciles).
🗓 2016–2018 (Android 6–8 Marshmallow–Oreo)
FRP movido a particiones más seguras (persistent, metadata).
Bloqueados atajos de accesibilidad en Setup Wizard.
Particiones: /persistent, /metadata, efs (Samsung), oeminfo (Huawei).
OEMs:
Samsung: Knox → protección en efs + boot.
Huawei: FRP ligado a oeminfo + validación de ID.
LG: integración básica con cuenta Google.
Seguridad: Media.
🗓 2019–2021 (Android 9–11 Pie–R)
🛡 Android Verified Boot (AVB) → detecta modificaciones en particiones.
Particiones: FRP en partición propia · boot (verificación) · efs (Samsung) · persist (Xiaomi).
OEMs:
Samsung: Knox Guard (KG), sincronización con servidores.
Huawei: bloqueo fuerte con ID en oeminfo, validación online obligatoria.
Xiaomi: primera implementación seria de Mi Account en persist.
Seguridad: Alta.
🗓 2022–2024 (Android 12–14)
Scoped Storage + rollback protection (fuses en misc).
FRP sincronizado con Google Play Services.
Particiones: /metadata · misc (rollback fuses) · almacenamiento en TEE/TrustZone o Knox Vault.
OEMs:
Samsung: Knox Vault → claves en chip seguro, FRP protegido en hardware.
Xiaomi: FRP + Mi Account alojado en persist y validación en la nube.
Huawei: TEE en chips Kirin, ID en servidores.
Oppo / Vivo / Realme: ligan cuentas propias (Oppo ID, Vivo Cloud) al boot y metadatos.
Seguridad: Muy Alta.
🗓 2025–2027 (Android 15–17, estimado)
Google exige identidad verificada de desarrolladores → reduce malware que intentaba saltar FRP.
FRP y credenciales ahora en particiones protegidas por hardware.
Particiones: vbmeta (verificación de firmas) · metadata (FRP data) · /userdata cifrado y ligado al TEE · claves en SoC (Titan M, TrustZone, Knox Vault, eFuses).
OEMs:
Samsung: Knox Vault + eFuses → nivel bancario, validación obligatoria en servidores.
Xiaomi: TEE + Mi Account en nube, imposible activar sin credenciales.
Huawei: ID ligado a oeminfo + validación en servidores Huawei incluso en fastboot.
Google Pixel: Titan M2 → FRP y cuentas ancladas en chip de seguridad.
Oppo/Vivo/Realme: cuentas propias reforzadas con TEE regionales.
Seguridad: Máxima 
🗓 2010–2014 (Android 2.x–4.4 KitKat)
🗓 2015 (Android 5.1 Lollipop)
Samsung: primeros bloqueos en efs.
Huawei / LG: sin refuerzo adicional aún.
🗓 2016–2018 (Android 6–8 Marshmallow–Oreo)
Samsung: Knox → protección en efs + boot.
Huawei: FRP ligado a oeminfo + validación de ID.
LG: integración básica con cuenta Google.
🗓 2019–2021 (Android 9–11 Pie–R)
🛡 Android Verified Boot (AVB) → detecta modificaciones en particiones.
Samsung: Knox Guard (KG), sincronización con servidores.
Huawei: bloqueo fuerte con ID en oeminfo, validación online obligatoria.
Xiaomi: primera implementación seria de Mi Account en persist.
🗓 2022–2024 (Android 12–14)
Samsung: Knox Vault → claves en chip seguro, FRP protegido en hardware.
Xiaomi: FRP + Mi Account alojado en persist y validación en la nube.
Huawei: TEE en chips Kirin, ID en servidores.
Oppo / Vivo / Realme: ligan cuentas propias (Oppo ID, Vivo Cloud) al boot y metadatos.
🗓 2025–2027 (Android 15–17, estimado)
Samsung: Knox Vault + eFuses → nivel bancario, validación obligatoria en servidores.
Xiaomi: TEE + Mi Account en nube, imposible activar sin credenciales.
Huawei: ID ligado a oeminfo + validación en servidores Huawei incluso en fastboot.
Google Pixel: Titan M2 → FRP y cuentas ancladas en chip de seguridad.
Oppo/Vivo/Realme: cuentas propias reforzadas con TEE regionales.