¿Qué impide específicamente que se utilicen OTA en sistemas/modificados y por qué no se puede desactivar?

He tenido una pesadilla constante al no poder recibir OTA en ninguno de mis dispositivos (rooteados). Se inician en TWRP, se quejan de la huella digital de compilación y no se instalan, por lo que tengo que esperar un .zip completo y actualizar mis sistemas manualmente.

¿Qué es lo que impide que las OTA se instalen en una partición /system modificada y por qué no se puede anular o deshabilitar?

Si no se puede anular/deshabilitar, ¿por qué mi sistema/modificado no puede mentir sobre su huella digital de compilación para engañar a esta validación y permitir que se instalen las OTA?

Respuestas (2)

Los archivos OTA funcionan parcheando archivos en lugar de reemplazarlos con una copia completa de la nueva versión del archivo. Esto significa que tiene que verificar que los archivos existentes sean exactamente como espera o el proceso de aplicación de parches no funcionará (o podría dañar el archivo). Si tuviera que falsificar la huella dactilar y forzar la aplicación de OTA, podría terminar con un dispositivo que no puede arrancar debido a que algunos archivos están corruptos.

Android 5.0 (creo) pasó de verificar solo los archivos que estaba parcheando a verificar la partición en su conjunto, por lo que cualquier modificación (incluso en un archivo que no se está parcheando) hará que esto falle.

¿Tienes alguna idea de por qué no se puede eliminar o derrotar?
Oh, ya veo, estás diciendo que el contenido de las OTA ahora se basa en el sistema sin modificar, hmm. En ese caso, estoy confundido sobre lo que podría ser tan 'diferente' en un / sistema que había sido rooteado y luego 'Full Unroot'ed.
Hola, ¿entonces crees que las OTA están realizando verificaciones similares a las de dmverity ahora?
@moonbutt74, parece que sí . Creo que se debe a que la eliminación de archivos extraños /systemdurante el desrooteo no funciona para engañar a una actualización del sistema porque la disposición de los bits en un bloque antes del enrutamiento y después del desrooteo sin duda sería diferente.

Además de la respuesta publicada por @bmdixon

  1. Los OEM como Samsung tienen un contador Knox que se dispara una vez que rooteas o reemplazas la recuperación de stock por encargo. Hubo trabajo antes de esto, pero Note 4 en adelante, al hacer tropezar a Knox, "quema" esta información en el hardware. ¡La única forma de revertir el estado de Knox es cambiando ese chip en la placa base! (No sé cómo se logra esto, pero está registrado como una respuesta de correo electrónico de Samsung). Espero que OTA verifique esto primero

  2. Los OEM como Huawei (mi dispositivo actual es Honor 6), le permiten desbloquear el cargador de arranque y cubrirlo con garantía, lo que permite actualizaciones OTA si está rooteado pero la recuperación de stock está intacta. Reemplazar la recuperación falla OTA

  3. Sospecho que los operadores que "bloquean" a sus clientes también emplearán sus propios medios para verificar antes de permitir OTA (probablemente esta sea una de las razones por las que hay un retraso variable en el despliegue de OTA por parte de los operadores)

Por lo tanto, puede que no sea una solución simple tener el truco de recuperación OTA... demasiados trucos para aprender y propietarios, que NO es el propósito de TWRP.