Android 10, Android kablosuz (OTA) güncellemesi başarısız olduğunda Android'in önceki durumuna geri dönmesine olanak tanıyan Kullanıcı Verileri Kontrol Noktası'nı (UDC) kullanıma sunar. 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 almasını sağlar. UDC özelliği, bunu dosya sisteminde kontrol noktası özellikleri, dosya sistemi kontrol noktalarını desteklemediğinde alternatif bir uygulama, A/B olmayan güncellemeleri desteklerken önyükleme 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.
Diğer dosya sistemlerinde UDC, 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. Ardından okuma ve yazma işlemleri, değiştirilmeden cihaza gönderilir. Ancak yazma işlemine izin verilmeden önce, geri yükleme için gereken veriler boş bir bloğa 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üde 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 monte edildikten sonra, kırpma işlemini 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 anahtar silme çağrılarını kontrol noktası kaydedilene kadar 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.
Sağlık hizmetlisinin yapılandırılabilir aşağıdaki davranışları vardır:
ro.sys.cp_msleeptime: Cihazın disk kullanımını ne sıklıkta kontrol edeceğ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.
void startCheckpoint(int retry)
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, veriler (ör. resimler, 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 hiçbir 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şikliklerini terk eder.
Ç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ı olmayan bir cihazda 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ü ekleme
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şlevi başlıklı makaleyi inceleyin.
/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
Checkpoint API'leri çağrıldığında günlük girişleri oluşturulur.
Doğrulama
UDC uygulamanızı test etmek için VtsKernelCheckpointTest VTS testi grubunu çalıştırın.