Android 10 memperkenalkan User Data Checkpoint (UDC), yang memungkinkan Android untuk kembali ke keadaan sebelumnya ketika pembaruan over-the-air (OTA) Android gagal. Dengan UDC, jika pembaruan Android OTA gagal, perangkat dapat kembali ke kondisi sebelumnya dengan aman. Meskipun pembaruan A/B memecahkan masalah ini untuk boot awal, rollback tidak didukung ketika partisi data pengguna (dipasang pada /data ) dimodifikasi.
UDC memungkinkan perangkat untuk mengembalikan partisi data pengguna bahkan setelah dimodifikasi. Fitur UDC menyelesaikan ini dengan kemampuan pos pemeriksaan ke sistem file, implementasi alternatif ketika sistem file tidak mendukung pos pemeriksaan, integrasi dengan mekanisme A/B bootloader sementara juga mendukung pembaruan non-A/B, dan dukungan untuk pengikatan versi kunci dan pencegahan rollback kunci.
Dampak pengguna
Fitur UDC meningkatkan pengalaman pembaruan OTA bagi pengguna karena lebih sedikit pengguna yang kehilangan data saat pembaruan OTA gagal. Ini dapat mengurangi jumlah panggilan dukungan dari pengguna yang mengalami masalah selama proses pembaruan. Namun, ketika pembaruan OTA gagal, pengguna mungkin melihat perangkat melakukan boot ulang beberapa kali.
Bagaimana itu bekerja
Fungsionalitas pos pemeriksaan di sistem file yang berbeda
Untuk sistem file F2FS, UDC menambahkan fungsionalitas pos pemeriksaan ke kernel Linux 4.20 upstream dan mem-backportnya ke semua kernel umum yang didukung oleh perangkat yang menjalankan Android 10.
Untuk sistem file lain, UDC menggunakan perangkat virtual pemetaan perangkat yang disebut dm_bow untuk fungsionalitas pos pemeriksaan. dm_bow berada di antara perangkat dan sistem file. Ketika sebuah partisi dipasang, trim dikeluarkan yang menyebabkan sistem file mengeluarkan perintah trim pada semua blok bebas. dm_bow memotong trim ini dan menggunakannya untuk menyiapkan daftar blokir gratis. Baca dan tulis kemudian dikirim ke perangkat tanpa dimodifikasi, tetapi sebelum penulisan diizinkan, data yang diperlukan untuk pemulihan dicadangkan ke blok gratis.
Proses pemeriksaan
Ketika sebuah partisi dengan flag checkpoint=fs/block dipasang, Android akan memanggil restoreCheckpoint pada drive untuk memungkinkan perangkat memulihkan pos pemeriksaan saat ini. init kemudian memanggil fungsi needsCheckpoint untuk menentukan apakah perangkat berada dalam status A/B bootloader atau telah menyetel jumlah percobaan ulang pembaruan. Jika salah satunya benar, Android akan memanggil createCheckpoint untuk menambahkan flag mount atau membuat perangkat dm_bow .
Setelah partisi dipasang, kode pos pemeriksaan dipanggil untuk mengeluarkan trim. Proses boot kemudian berlanjut seperti biasa. Pada LOCKED_BOOT_COMPLETE , Android memanggil commitCheckpoint untuk melakukan checkpoint saat ini dan pembaruan berlanjut seperti biasa.
Mengelola kunci keymaster
Kunci keymaster digunakan untuk enkripsi perangkat atau tujuan lain. Untuk mengelola kunci ini, Android menunda panggilan penghapusan kunci hingga pos pemeriksaan dilakukan.
Memantau kesehatan
Daemon kesehatan memverifikasi bahwa ada cukup ruang disk untuk membuat pos pemeriksaan. Daemon kesehatan terletak di cp_healthDaemon di Checkpoint.cpp .
Daemon kesehatan memiliki perilaku berikut yang dapat dikonfigurasi:
-
ro.sys.cp_msleeptime: Mengontrol seberapa sering perangkat memeriksa penggunaan disk. -
ro.sys.cp_min_free_bytes: Mengontrol nilai minimum yang dicari daemon kesehatan. -
ro.sys.cp_commit_on_full: Mengontrol apakah daemon kesehatan me-reboot perangkat atau melakukan checkpoint dan melanjutkan saat disk penuh.
API pos pemeriksaan
API pos pemeriksaan digunakan oleh fitur UDC. Untuk API lain yang digunakan oleh UDC, lihat IVoid.aidl .
void startCheckpoint(int coba lagi)
Membuat pos pemeriksaan.
Kerangka kerja memanggil metode ini ketika sudah siap untuk memulai pembaruan. Pos pemeriksaan dibuat sebelum sistem file pos pemeriksaan seperti data pengguna dipasang R/W setelah reboot. Jika jumlah percobaan ulang positif, API akan menangani percobaan ulang pelacakan, dan pembaru memanggil needsRollback untuk memeriksa apakah rollback pembaruan diperlukan. Jika jumlah percobaan ulang adalah -1 , API akan mengikuti penilaian bootloader A/B.
Metode ini tidak dipanggil saat melakukan pembaruan A/B normal.
batalkan perubahan komit()
Melakukan perubahan.
Kerangka kerja memanggil metode ini setelah reboot ketika perubahan siap untuk dilakukan. Ini dipanggil sebelum data (seperti gambar, video, SMS, tanda terima penerimaan server) ditulis ke data pengguna dan sebelum BootComplete .
Jika tidak ada pembaruan checkpointed aktif, metode ini tidak berpengaruh.
batalkanPerubahan()
Memaksa reboot dan kembali ke pos pemeriksaan. Abaikan semua modifikasi data pengguna sejak reboot pertama.
Kerangka kerja memanggil metode ini setelah reboot tetapi sebelum commitChanges . retry_counter berkurang saat metode ini dipanggil. Entri log dibuat.
kebutuhan boolRollback()
Menentukan apakah rollback diperlukan.
Pada perangkat noncheckpoint, mengembalikan false . Pada perangkat pos pemeriksaan, mengembalikan nilai true selama boot nonpos pemeriksaan.
Menerapkan UDC
Implementasi referensi
Untuk contoh bagaimana UDC dapat diimplementasikan, lihat dm-bow.c . Untuk dokumentasi tambahan tentang fitur tersebut, lihat dm-bow.txt .
Mempersiapkan
Di on fs di file init.hardware.rc Anda, pastikan Anda memiliki:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
Pada on late-fs di file init.hardware.rc Anda, pastikan Anda memiliki:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Di file fstab.hardware Anda, pastikan /data diberi tag sebagai 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
Menambahkan partisi metadata
UDC memerlukan partisi metadata untuk menyimpan jumlah dan kunci coba lagi nonbootloader. Siapkan partisi metadata dan pasang lebih awal di /metadata .
Di file fstab.hardware Anda, pastikan /metadata diberi tag sebagai earlymount atau first_stage_mount .
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Inisialisasi partisi ke semua nol.
Tambahkan baris berikut ke BoardConfig.mk :
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Memperbarui sistem
sistem F2FS
Untuk sistem yang menggunakan F2FS untuk memformat data, pastikan versi F2FS Anda mendukung pos pemeriksaan. Untuk informasi selengkapnya, lihat Fungsionalitas pos pemeriksaan di sistem file yang berbeda .
Tambahkan flag checkpoint=fs ke bagian <fs_mgr_flags> fstab untuk perangkat yang dipasang di /data .
Sistem non-F2FS
Untuk sistem non-F2FS, dm-bow harus diaktifkan di konfigurasi kernel.
Tambahkan flag checkpoint=block ke bagian <fs_mgr_flags> dari fstab untuk perangkat yang dipasang di /data .
Memeriksa log
Entri log dibuat saat API Checkpoint dipanggil.
Validasi
Untuk menguji implementasi UDC Anda, jalankan rangkaian pengujian VTS VtsKernelCheckpointTest .
Android 10 memperkenalkan User Data Checkpoint (UDC), yang memungkinkan Android untuk kembali ke keadaan sebelumnya ketika pembaruan over-the-air (OTA) Android gagal. Dengan UDC, jika pembaruan Android OTA gagal, perangkat dapat kembali ke kondisi sebelumnya dengan aman. Meskipun pembaruan A/B memecahkan masalah ini untuk boot awal, rollback tidak didukung ketika partisi data pengguna (dipasang pada /data ) dimodifikasi.
UDC memungkinkan perangkat untuk mengembalikan partisi data pengguna bahkan setelah dimodifikasi. Fitur UDC menyelesaikan ini dengan kemampuan pos pemeriksaan ke sistem file, implementasi alternatif ketika sistem file tidak mendukung pos pemeriksaan, integrasi dengan mekanisme A/B bootloader sementara juga mendukung pembaruan non-A/B, dan dukungan untuk pengikatan versi kunci dan pencegahan rollback kunci.
Dampak pengguna
Fitur UDC meningkatkan pengalaman pembaruan OTA bagi pengguna karena lebih sedikit pengguna yang kehilangan data saat pembaruan OTA gagal. Ini dapat mengurangi jumlah panggilan dukungan dari pengguna yang mengalami masalah selama proses pembaruan. Namun, ketika pembaruan OTA gagal, pengguna mungkin melihat perangkat melakukan boot ulang beberapa kali.
Bagaimana itu bekerja
Fungsionalitas pos pemeriksaan di sistem file yang berbeda
Untuk sistem file F2FS, UDC menambahkan fungsionalitas pos pemeriksaan ke kernel Linux 4.20 upstream dan mem-backportnya ke semua kernel umum yang didukung oleh perangkat yang menjalankan Android 10.
Untuk sistem file lain, UDC menggunakan perangkat virtual pemetaan perangkat yang disebut dm_bow untuk fungsionalitas pos pemeriksaan. dm_bow berada di antara perangkat dan sistem file. Ketika sebuah partisi dipasang, trim dikeluarkan yang menyebabkan sistem file mengeluarkan perintah trim pada semua blok bebas. dm_bow memotong trim ini dan menggunakannya untuk menyiapkan daftar blokir gratis. Baca dan tulis kemudian dikirim ke perangkat tanpa dimodifikasi, tetapi sebelum penulisan diizinkan, data yang diperlukan untuk pemulihan dicadangkan ke blok gratis.
Proses pemeriksaan
Ketika sebuah partisi dengan flag checkpoint=fs/block dipasang, Android akan memanggil restoreCheckpoint pada drive untuk memungkinkan perangkat memulihkan pos pemeriksaan saat ini. init kemudian memanggil fungsi needsCheckpoint untuk menentukan apakah perangkat berada dalam status A/B bootloader atau telah menyetel jumlah percobaan ulang pembaruan. Jika salah satunya benar, Android akan memanggil createCheckpoint untuk menambahkan flag mount atau membuat perangkat dm_bow .
Setelah partisi dipasang, kode pos pemeriksaan dipanggil untuk mengeluarkan trim. Proses boot kemudian berlanjut seperti biasa. Pada LOCKED_BOOT_COMPLETE , Android memanggil commitCheckpoint untuk melakukan checkpoint saat ini dan pembaruan berlanjut seperti biasa.
Mengelola kunci keymaster
Kunci keymaster digunakan untuk enkripsi perangkat atau tujuan lain. Untuk mengelola kunci ini, Android menunda panggilan penghapusan kunci hingga pos pemeriksaan dilakukan.
Memantau kesehatan
Daemon kesehatan memverifikasi bahwa ada cukup ruang disk untuk membuat pos pemeriksaan. Daemon kesehatan terletak di cp_healthDaemon di Checkpoint.cpp .
Daemon kesehatan memiliki perilaku berikut yang dapat dikonfigurasi:
-
ro.sys.cp_msleeptime: Mengontrol seberapa sering perangkat memeriksa penggunaan disk. -
ro.sys.cp_min_free_bytes: Mengontrol nilai minimum yang dicari daemon kesehatan. -
ro.sys.cp_commit_on_full: Mengontrol apakah daemon kesehatan me-reboot perangkat atau melakukan checkpoint dan melanjutkan saat disk penuh.
API pos pemeriksaan
API pos pemeriksaan digunakan oleh fitur UDC. Untuk API lain yang digunakan oleh UDC, lihat IVoid.aidl .
void startCheckpoint(int coba lagi)
Membuat pos pemeriksaan.
Kerangka kerja memanggil metode ini ketika sudah siap untuk memulai pembaruan. Pos pemeriksaan dibuat sebelum sistem file pos pemeriksaan seperti data pengguna dipasang R/W setelah reboot. Jika jumlah percobaan ulang positif, API akan menangani percobaan ulang pelacakan, dan pembaru memanggil needsRollback untuk memeriksa apakah rollback pembaruan diperlukan. Jika jumlah percobaan ulang adalah -1 , API akan mengikuti penilaian bootloader A/B.
Metode ini tidak dipanggil saat melakukan pembaruan A/B normal.
batalkan perubahan komit()
Melakukan perubahan.
Kerangka kerja memanggil metode ini setelah reboot ketika perubahan siap untuk dilakukan. Ini dipanggil sebelum data (seperti gambar, video, SMS, tanda terima penerimaan server) ditulis ke data pengguna dan sebelum BootComplete .
Jika tidak ada pembaruan checkpointed aktif, metode ini tidak berpengaruh.
batalkanPerubahan()
Memaksa reboot dan kembali ke pos pemeriksaan. Abaikan semua modifikasi data pengguna sejak reboot pertama.
Kerangka kerja memanggil metode ini setelah reboot tetapi sebelum commitChanges . retry_counter berkurang saat metode ini dipanggil. Entri log dibuat.
kebutuhan boolRollback()
Menentukan apakah rollback diperlukan.
Pada perangkat noncheckpoint, mengembalikan false . Pada perangkat pos pemeriksaan, mengembalikan nilai true selama boot nonpos pemeriksaan.
Menerapkan UDC
Implementasi referensi
Untuk contoh bagaimana UDC dapat diimplementasikan, lihat dm-bow.c . Untuk dokumentasi tambahan tentang fitur tersebut, lihat dm-bow.txt .
Mempersiapkan
Di on fs di file init.hardware.rc Anda, pastikan Anda memiliki:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
Pada on late-fs di file init.hardware.rc Anda, pastikan Anda memiliki:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Di file fstab.hardware Anda, pastikan /data diberi tag sebagai 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
Menambahkan partisi metadata
UDC memerlukan partisi metadata untuk menyimpan jumlah dan kunci coba lagi nonbootloader. Siapkan partisi metadata dan pasang lebih awal di /metadata .
Di file fstab.hardware Anda, pastikan /metadata diberi tag sebagai earlymount atau first_stage_mount .
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Inisialisasi partisi ke semua nol.
Tambahkan baris berikut ke BoardConfig.mk :
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Memperbarui sistem
sistem F2FS
Untuk sistem yang menggunakan F2FS untuk memformat data, pastikan versi F2FS Anda mendukung pos pemeriksaan. Untuk informasi selengkapnya, lihat Fungsionalitas pos pemeriksaan di sistem file yang berbeda .
Tambahkan flag checkpoint=fs ke bagian <fs_mgr_flags> fstab untuk perangkat yang dipasang di /data .
Sistem non-F2FS
Untuk sistem non-F2FS, dm-bow harus diaktifkan di konfigurasi kernel.
Tambahkan flag checkpoint=block ke bagian <fs_mgr_flags> dari fstab untuk perangkat yang dipasang di /data .
Memeriksa log
Entri log dibuat saat API Checkpoint dipanggil.
Validasi
Untuk menguji implementasi UDC Anda, jalankan rangkaian pengujian VTS VtsKernelCheckpointTest .