Kullanıcı Verileri Kontrol Noktası

Android 10'da, Android kablosuz bağlantı (OTA) güncellemesi başarısız olduğunda Android'in önceki durumuna dönmesini sağlayan Kullanıcı Verileri Kontrol Noktası (UDC) özelliği kullanıma sunulmuştur. UDC sayesinde, Android OTA güncellemesi başarısız olursa cihaz güvenli bir şekilde önceki durumuna geri dönebilir. A/B güncellemeleri erken önyükleme için bu sorunu çözse de kullanıcı verileri bölümü (/data üzerine monte edilmiş) değiştirildiğinde geri alma işlemi desteklenmez.

UDC, cihazın değiştirildikten sonra bile kullanıcı verileri bölümünü geri döndürmesini sağlar. UDC özelliği, bunu dosya sistemine yönelik kontrol noktası özellikleri, dosya sistemi kontrol noktalarını desteklemediğinde alternatif bir uygulama, A/B olmayan güncellemeleri desteklerken önyükleyici A/B mekanizmasıyla entegrasyon, anahtar sürüm bağlama ve anahtar geri alma önleme desteği ile gerçekleştirir.

Kullanıcıya etkisi

OTA güncellemesi başarısız olduğunda daha az kullanıcının verilerini kaybetmesi nedeniyle UDC özelliği, kullanıcılar için OTA güncelleme deneyimini iyileştirir. Bu sayede, güncelleme işlemi sırasında sorun yaşayan kullanıcıların destek araması sayısını azaltabilirsiniz. Ancak OTA güncellemesi başarısız olduğunda kullanıcılar cihazın birden çok kez yeniden başlatıldığını fark edebilir.

İşleyiş şekli

Farklı dosya sistemlerinde kontrol noktası işlevi

UDC, F2FS dosya sistemi için 4.20 Linux çekirdeğine kontrol noktası işlevini ekler ve Android 10 çalıştıran cihazlar tarafından desteklenen tüm yaygın çekirdeklere geri gönderir.

UDC, diğer dosya sistemlerinde kontrol noktası işlevi için dm_bow adlı bir cihaz eşleyici sanal cihazı kullanır. dm_bow, cihaz ile dosya sistemi arasında yer alır. Bir bölüm monte edildiğinde, dosya sisteminin tüm boş bloklarda trim komutları yayınlamasına neden olan bir kırpma işlemi gerçekleştirilir. dm_bow bu kırpmaları durdurur ve ücretsiz bir engellenenler listesi oluşturmak için kullanır. Okuma ve yazma işlemleri daha sonra cihaza değiştirilmeden gönderilir. Ancak yazmaya izin verilmeden önce, geri yükleme için gereken veriler ücretsiz bir bloka yedeklenir.

Kontrol noktası süreci

checkpoint=fs/block işareti içeren bir bölüm monte edildiğinde Android, cihazın mevcut bir kontrol noktasını geri yüklemesine izin vermek için sürücüdeki restoreCheckpoint işlevini çağırır. Ardından init, cihazın bir önyükleyici A/B durumunda olup olmadığını veya güncelleme yeniden deneme sayısını ayarlayıp ayarlamadığını belirlemek için needsCheckpoint işlevini çağırır. Bu iki koşuldan biri doğruysa Android, bağlama işaretleri eklemek veya dm_bow cihazı oluşturmak için createCheckpoint'ü çağırır.

Bölüm eklendikten sonra, kırpma işlemlerini yapmak için kontrol noktası kodu çağrılır. Ardından, önyükleme işlemi normal şekilde devam eder. LOCKED_BOOT_COMPLETE noktasında Android, mevcut kontrol noktasını kaydetmek için commitCheckpoint işlevini çağırır ve güncelleme normal şekilde devam eder.

Anahtar yöneticisi anahtarlarını yönetme

Anahtar yöneticisi anahtarları, cihaz şifreleme veya başka amaçlar için kullanılır. Android, bu anahtarları yönetmek için kontrol noktası tamamlanana kadar anahtar silme çağrılarını geciktirir.

Sağlığı izleme

Sağlık hizmet daemon'ı, kontrol noktası oluşturmak için yeterli disk alanı olup olmadığını doğrular. Sağlık hizmetli, cp_healthDaemon bölümündeki Checkpoint.cpp'da bulunur.

Durum arka plan programı, yapılandırılabilen aşağıdaki davranışlara sahiptir:

  • ro.sys.cp_msleeptime: Cihazın disk kullanımını ne sıklıkta kontrol ettiğini kontrol eder.
  • ro.sys.cp_min_free_bytes: Sağlık hizmetlisinin aradığı minimum değeri kontrol eder.
  • ro.sys.cp_commit_on_full: Sağlık hizmetlisinin cihazı yeniden başlatıp başlatmayacağını veya disk dolduğunda kontrol noktasını kaydedip devam edip etmeyeceğini kontrol eder.

Checkpoint API'leri

Kontrol noktası API'leri, UDC özelliği tarafından kullanılır. UDC tarafından kullanılan diğer API'ler için IVold.aidl bölümüne bakın.

geçersiz startCheckpoint(int yeniden deneyin)

Kontrol noktası oluşturur.

Çerçeve, güncelleme başlatmaya hazır olduğunda bu yöntemi çağırır. Kontrol noktası, userdata gibi kontrol noktası atanmış dosya sistemleri yeniden başlatıldıktan sonra R/W olarak bağlanmadan önce oluşturulur. Yeniden deneme sayısı pozitifse API, yeniden denemelerin izlenmesini yönetir ve güncelleyici, güncellemenin geri alınması gerekip gerekmediğini kontrol etmek için needsRollback'ü çağırır. Yeniden deneme sayısı -1 ise API, A/B önyükleyicinin kararına bağlı kalır.

Normal bir A/B güncellemesi yapılırken bu yöntem çağrılmaz.

void commitChanges()

Değişiklikleri kaydeder.

Çerçeve, değişiklikler kaydedilmeye hazır olduğunda yeniden başlatıldıktan sonra bu yöntemi çağırır. Bu işlev, veriler (ör. resim, video, SMS, sunucu makbuzu) userdata'ya yazılmadan ve BootComplete çağrılmadan önce çağrılır.

Etkin bir kontrol noktası güncellemesi yoksa bu yöntemin etkisi olmaz.

abortChanges()

Yeniden başlatmayı zorlar ve kontrol noktasına geri döner. İlk yeniden başlatmadan sonraki tüm kullanıcı verisi değişiklikleri iptal edilir.

Çerçeve bu yöntemi yeniden başlatma işleminden sonra ancak commitChanges'ten önce çağırır. Bu yöntem çağrıldığında retry_counter azalır. Günlük girişleri oluşturulur.

bool needsRollback()

Geri alma işleminin gerekli olup olmadığını belirler.

Kontrol noktası olmayan cihazlarda false değerini döndürür. Kontrol noktası cihazlarında, kontrol noktası olmayan bir önyükleme sırasında true döndürür.

UDC'yi uygulama

Referans uygulama

UDC'nin nasıl uygulanabileceğine dair bir örnek için dm-bow.c dosyasına bakın. Özellikle ilgili ek dokümanlar için dm-bow.txt dosyasına bakın.

Kurulum

init.hardware.rc dosyanızdaki on fs bölümünde şunları sağladığınızdan emin olun:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early

init.hardware.rc dosyanızdaki on late-fs bölümünde şunları sağladığınızdan emin olun:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

fstab.hardware dosyanızda /data öğesinin latemount olarak etiketlendiğinden emin olun.

/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

Meta veri bölümü ekle

UDC, önyükleme dışındaki yeniden deneme sayısını ve anahtarları depolamak için bir meta veri bölümü gerektirir. Bir meta veri bölümü oluşturun ve /metadata konumuna erken bağlayın.

fstab.hardware dosyanızda /metadata öğesinin earlymount veya first_stage_mount olarak etiketlendiğinden emin olun.

/dev/block/by-name/metadata           /metadata           ext4
noatime,nosuid,nodev,discard,sync
wait,formattable,first_stage_mount

Bölümü tümüyle sıfır olarak başlatın.

BoardConfig.mk dosyasına aşağıdaki satırları ekleyin:

BOARD_USES_METADATA_PARTITION := true
BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata

Sistemleri güncelleme

F2FS sistemleri

Verileri biçimlendirmek için F2FS kullanan sistemlerde, F2FS sürümünüzün kontrol noktalarını desteklediğinden emin olun. Daha fazla bilgi için Farklı dosya sistemlerindeki kontrol noktası işlevine bakın.

/data adresinde monte edilen cihaz için fstab'ın <fs_mgr_flags> bölümüne checkpoint=fs işaretini ekleyin.

F2FS olmayan sistemler

F2FS olmayan sistemlerde dm-bow, çekirdek yapılandırmasında etkinleştirilmelidir.

/data adresinde monte edilen cihaz için fstab'ın <fs_mgr_flags> bölümüne checkpoint=block işaretini ekleyin.

Günlükleri kontrol etme

Günlük girişleri, Checkpoint API'leri çağrıldığında oluşturulur.

Doğrulama

UDC uygulamanızı test etmek için VtsKernelCheckpointTest VTS testi grubunu çalıştırın.