Android 10 presenta el punto de control de datos del usuario (UDC), que
permite que Android vuelva a su estado anterior cuando una versión inalámbrica de Android
(OTA) falla. Con UDC, si falla una actualización inalámbrica de Android, el dispositivo puede
revertir de manera segura
a su estado anterior. Si bien
Las actualizaciones A/B solucionan este problema para el inicio anticipado y la reversión
no es compatible cuando se modifica la partición de datos del usuario (activada en /data).
El UDC permite que el dispositivo revierta la partición de datos del usuario modificados. La función UDC lo logra con capacidades de punto de control al de archivos, una implementación alternativa cuando el sistema de archivos no es compatible puntos de control, integración con el mecanismo A/B del bootloader y compatibilidad con actualizaciones que no sean A/B y compatibilidad con la vinculación de versiones de clave y la reversión de claves prevención de amenazas.
Impacto en los usuarios
La función UDC mejora la experiencia de la actualización inalámbrica para los usuarios, ya que disminuyen las pérdidas. sus datos cuando falla una actualización OTA. Esto puede reducir la cantidad de llamadas de asistencia de los usuarios que tienen problemas durante el proceso de actualización. Sin embargo, cuando se configura si falla la actualización, es posible que los usuarios noten que el dispositivo se reinicia varias veces.
Cómo funciona
Funcionalidad de punto de control en diferentes sistemas de archivos
Para el sistema de archivos F2FS, UDC agrega la funcionalidad de punto de control al sistema kernel 4.20 de Linux y portabilidad a versiones anteriores a todos los kernels comunes compatibles con los dispositivos con Android 10.
Para otros sistemas de archivos, UDC usa un dispositivo virtual de asignador de dispositivos llamado dm_bow
para la funcionalidad de punto de control. dm_bow se encuentra entre el dispositivo y el archivo.
en un sistema de archivos. Cuando se activa una partición, se emite un recorte, lo que causa que el sistema de archivos
emite comandos de recorte en todos los bloques libres. dm_bow intercepta estos recortes y usa
una lista de bloqueo gratuita. Luego, las operaciones de lectura y escritura se envían al dispositivo.
sin modificar, pero antes de que se permita una operación de escritura, se respaldan los datos necesarios para el restablecimiento
hasta un bloque libre.
Proceso del punto de control
Cuando se activa una partición con la marca checkpoint=fs/block, Android llama
restoreCheckpoint en la unidad para permitir que el dispositivo restablezca la configuración de fábrica.
punto de control. init luego llama a la función needsCheckpoint para determinar si
El dispositivo está en estado A/B de bootloader o configuró el reintento de actualización.
recuento. Si alguno es verdadero, Android llama a createCheckpoint para agregar la activación.
o compilar un dispositivo dm_bow.
Después de activar la partición, se llama al código del punto de control para emitir recortes.
Luego, el proceso de inicio continúa con normalidad. En LOCKED_BOOT_COMPLETE, Android
Llama a commitCheckpoint para confirmar el punto de control actual y la actualización.
continúa con normalidad.
Administrar claves maestras de claves
Las claves de Keymaster se usan para encriptar dispositivos y otros fines. Para administrar estas , Android retrasa las llamadas de eliminación de claves hasta que se confirme el punto de control.
Supervisa el estado
Un daemon de estado verifica que haya suficiente espacio en el disco para crear un
punto de control. El daemon de salud se encuentra en
cp_healthDaemon
en Checkpoint.cpp.
El daemon de estado tiene los siguientes comportamientos que se pueden configurar:
ro.sys.cp_msleeptime: Controla la frecuencia con la que el dispositivo verifica el uso del disco.ro.sys.cp_min_free_bytes: Controla el valor mínimo que busca el daemon de salud.ro.sys.cp_commit_on_full: Controla si el daemon de salud reinicia el dispositivo o confirma la punto de control y continúa cuando el disco está lleno.
API de punto de control
La función UDC usa las APIs de punto de control. Para conocer otras APIs que usa UDC, consulta
IVold.aidl
void startCheckpoint(reintento)
Crea un punto de control.
El framework llama a este método cuando está listo para iniciar una actualización. El
punto de control se crea antes de que los sistemas de archivos de control
montado de lectura y escritura después del reinicio. Si el recuento de reintentos es positivo, la API controla
realiza un seguimiento de los reintentos y el actualizador llama a needsRollback para verificar si se realizó una reversión
de la actualización es obligatoria. Si el recuento de reintentos es -1, la API aplaza a la instancia A/B.
a tu criterio del bootloader.
No se llama a este método cuando se realiza una actualización A/B normal.
void commitChanges()
Confirma los cambios.
El framework llama a este método después del reinicio, cuando los cambios están listos.
comprometida. Se llama antes que los datos (como imágenes, video, SMS, servidores,
el recibo de recepción) se escribe en userdata y antes del BootComplete.
Si no existe una actualización activa de punto de control, este método no tiene efecto.
abortChanges()
Fuerza el reinicio y vuelve al punto de control. Abandona todas las modificaciones de userdata desde el primer reinicio.
El framework llama a este método después del reinicio, pero antes de commitChanges.
retry_counter disminuye cuando se llama a este método. Las entradas de registro tienen las siguientes características:
de red.
bool needRollback()
Determina si se requiere una reversión.
En los dispositivos que no tienen punto de control, muestra false. En los dispositivos de punto de control, devuelve true.
durante un inicio sin
punto de control.
Implementa UDC
Implementación de referencia
Para ver un ejemplo de cómo se puede implementar el UDC, consulta dm-bow.c Para obtener documentación adicional sobre esta función, consulta dm-bow.txt.
Configuración
En el archivo init.hardware.rc de on fs, asegúrate de tener lo siguiente:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
En el archivo init.hardware.rc de on late-fs, asegúrate de tener lo siguiente:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
En tu archivo fstab.hardware, asegúrate de que /data esté etiquetado como latemount.
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs
Agregar partición de metadatos
El UDC requiere una partición de metadatos para almacenar el recuento de reintentos que no es de bootloader y
claves. Configura una partición de metadatos y actívala de manera anticipada en /metadata.
En tu archivo fstab.hardware, asegúrate de que /metadata esté etiquetado como earlymount
o first_stage_mount.
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Inicializa la partición con todos los ceros.
Agrega las siguientes líneas a BoardConfig.mk:
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Actualizar sistemas
Sistemas F2FS
En el caso de los sistemas que usan F2FS para dar formato a los datos, asegúrate de que tu versión de F2FS admite puntos de control. Para obtener más información, consulta Función de punto de control en diferentes sistemas de archivos.
Agrega la marca checkpoint=fs a la sección <fs_mgr_flags> de fstab para el
dispositivo montado en /data.
Sistemas que no son F2FS
Para los sistemas que no son F2FS, dm-bow debe estar habilitado en la configuración del kernel.
Agrega la marca checkpoint=block a la sección <fs_mgr_flags> de fstab para el
dispositivo montado en /data.
Verifica los registros
Las entradas de registro se generan cuando se llama a las APIs de Checkpoint.
Validación
Para probar tu implementación de UDC, ejecuta el conjunto VtsKernelCheckpointTest de VTS
y pruebas.