A/B Güncellemelerini Uygulama

OEM ve SoC A / B sistem güncellemeleri boot_control HAL onların bootloader uygular sağlamalıdır uygulamak isteyen satıcıları ve geçer doğru parametreleri çekirdeğe.

Önyükleme denetimi HAL'i uygulama

A / B-edebilen bootloaderları uygulamalıdır boot_control de HAL hardware/libhardware/include/hardware/boot_control.h . Sen kullanarak uygulamaları test edebilirsiniz system/extras/bootctl yarar ve system/extras/tests/bootloader/ .

Ayrıca aşağıda gösterilen durum makinesini de uygulamalısınız:

Şekil 1. Bootloader durum makinesi

Çekirdeğin ayarlanması

A/B sistem güncellemelerini uygulamak için:

  1. Aşağıdaki çekirdek yama serisini seçin (gerekirse):
  2. : Çekirdek komut satırı argümanları aşağıdaki ekstra argümanlar olduğundan emin olma
    skip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 android-verity <public-key-id> <path-to-system-partition>"
    ... <public-key-id> (ayrıntılar için bkz değer doğrusu masa imzayı doğrulamak için kullanılan ortak anahtar kimliğidir dm-verity ) .
  3. Ortak anahtarı içeren .X509 sertifikasını sistem anahtarlığına ekleyin:
    1. Biçimlendirilmiş .X509 sertifikasını kopyalayın .der köküne biçimi kernel dizine. .X509 sertifika olarak biçimlendirilmiş ise .pem dosyasında aşağıdakiler kullanmak openssl gelen dönüştürmek için komut .pem için .der formatında:
      openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate>
    2. İnşa zImage sistem anahtarlık parçası olarak sertifika eklemek. Kontrol doğrulamak için procfs girişi (gerektirir KEYS_CONFIG_DEBUG_PROC_KEYS etkinleştirilmesi):
      angler:/# cat /proc/keys
      
      1c8a217e I------     1 perm 1f010000     0     0 asymmetri
      Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f []
      2d454e3e I------     1 perm 1f030000     0     0 keyring
      .system_keyring: 1/4
      .X509 belgesinin başarılı dahil sistemi anahtarlık kamu anahtarı (vurgulamak genel anahtar kimliğini gösterir) varlığını göstermektedir.
    3. Boşluğun yerine # ve olarak geçmesi <public-key-id> çekirdek komut satırında. Örneğin, pas Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f yerine <public-key-id> .

Yapı değişkenlerini ayarlama

A/B özellikli önyükleyiciler aşağıdaki yapı değişkeni kriterlerini karşılamalıdır:

A/B hedefi için tanımlanmalıdır
  • AB_OTA_UPDATER := true
  • AB_OTA_PARTITIONS := \
    boot \
    system \
    vendor
    üzerinden güncellenmiş diğer bölümler update_engine (radyo, bootloader, vs.)
  • PRODUCT_PACKAGES += \
    update_engine \
    update_verifier
Bir örnek için, bakınız /device/google/marlin/+/android-7.1.0_r1/device-common.mk . İsteğe bağlı olarak yükleme sonrası yürütmek (ama-yeniden başlatma öncesi) adım açıklanan dex2oat olabilir Derleme .
A/B hedefi için şiddetle tavsiye edilir
  • Define TARGET_NO_RECOVERY := true
  • Define BOARD_USES_RECOVERY_AS_BOOT := true
  • Tanımlamak etmeyin BOARD_RECOVERYIMAGE_PARTITION_SIZE
A/B hedefi için tanımlanamıyor
  • BOARD_CACHEIMAGE_PARTITION_SIZE
  • BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE
Hata ayıklama derlemeleri için isteğe bağlı PRODUCT_PACKAGES_DEBUG += update_engine_client

Bölümleri ayarlama (yuvalar)

Android artık bu bölümleri kullanmadığından, A/B cihazlarının bir kurtarma bölümüne veya önbellek bölümüne ihtiyacı yoktur. Veri bölümü şimdi indirilen OTA paketi için kullanılıyor ve kurtarma görüntüsü kodu önyükleme bölümünde. Aşağıdaki gibi A / B-ed adlandırılacak olan tüm bölümleri (alanının her zaman adlandırıldığı a , b , vb): boot_a , boot_b , system_a , system_b , vendor_a , vendor_b .

önbellek

A/B olmayan güncellemeler için, önbellek bölümü, indirilen OTA paketlerini depolamak ve güncellemeleri uygularken blokları geçici olarak saklamak için kullanıldı. Önbellek bölümünü boyutlandırmanın hiçbir zaman iyi bir yolu olmadı: Hangi güncellemeleri uygulamak istediğinize bağlı olarak ne kadar büyük olması gerektiği. En kötü durum, sistem görüntüsü kadar büyük bir önbellek bölümü olacaktır. A/B güncellemeleri ile blokları saklamaya gerek yoktur (çünkü her zaman şu anda kullanılmayan bir bölüme yazıyorsunuz) ve A/B akışı ile uygulamadan önce tüm OTA paketini indirmeye gerek yoktur.

Kurtarma

Kurtarma RAM diski şimdi bulunan boot.img dosyası. Kurtarma içine giderken, bootloader koyamazsınız skip_initramfs çekirdek komut satırında seçeneği.

A/B olmayan güncellemeler için kurtarma bölümü, güncellemeleri uygulamak için kullanılan kodu içerir. A / B güncellemeleri tarafından uygulanan update_engine düzenli çizmeli sistem görüntüde çalışan. Fabrika verilerine sıfırlama ve güncelleme paketlerinin yandan yüklenmesini uygulamak için kullanılan bir kurtarma modu hala vardır ("kurtarma" adının geldiği yer burasıdır). Kurtarma modu için kod ve veriler, bir ramdisk'teki normal önyükleme bölümünde saklanır; sistem görüntüsüne önyükleme yapmak için önyükleyici çekirdeğe ramdiski atlamasını söyler (aksi takdirde cihaz kurtarma moduna geçer. Kurtarma modu küçüktür (ve çoğu zaten önyükleme bölümündeydi), bu nedenle önyükleme bölümü artmaz boyutunda.

Fstab

slotselect bağımsız değişken, A / B-ed bölümleri için bir satırda olmalıdır. Örneğin:

<path-to-block-device>/vendor  /vendor  ext4  ro
wait,verify=<path-to-block-device>/metadata,slotselect

Hiçbir bölüm adlı olmalıdır vendor . Bunun yerine, bölme vendor_a veya vendor_b seçilip monte edilecek /vendor bağlama noktası.

Çekirdek yuvası bağımsız değişkenleri

Mevcut yuvası eki Belirli bir aygıt ağacı (DT) düğümü üzerinden ya da (geçilmesi gerekmektedir /firmware/android/slot_suffix ) ya da geçiş androidboot.slot_suffix çekirdek komut hattı veya bootconfig argüman.

Varsayılan olarak, fastboot bir A/B aygıtındaki geçerli yuvayı yanıp söner. Güncelleme paketi diğer, geçerli olmayan yuva için de görüntüler içeriyorsa, fastboot bu görüntüleri de yanıp söner. Mevcut seçenekler şunları içerir:

  • --slot SLOT . Varsayılan davranışı geçersiz kılın ve fastboot'tan bağımsız değişken olarak geçirilen yuvayı flaş etmesini isteyin.
  • --set-active [ SLOT ] . Yuvayı etkin olarak ayarlayın. İsteğe bağlı bir bağımsız değişken belirtilmezse, geçerli yuva etkin olarak ayarlanır.
  • fastboot --help . Komutlarla ilgili ayrıntıları öğrenin.

Bootloader uygular fastboot, bu komut desteklemeli set_active <slot> setleri verilen yuvaya Geçerli etkin yuvası (bu da o alan için unbootable bayrağı temizlemek ve varsayılan değerlere yeniden deneme sayısını sıfırlamak gerekir) olduğunu. Önyükleyici ayrıca aşağıdaki değişkenleri de desteklemelidir:

  • has-slot:<partition-base-name-without-suffix> . Verilen bölüm yuvaları destekliyorsa "evet", aksi takdirde "hayır" döndürür.
  • current-slot . Sonrakinden başlatılacak yuva son ekini döndürür.
  • slot-count . Kullanılabilir yuva sayısını temsil eden bir tamsayı döndürür. Bu yüzden değer Şu anda iki yuva desteklenmektedir 2 .
  • slot-successful:<slot-suffix> . Belirtilen yuva başarıyla önyükleme olarak işaretlendiyse "evet", aksi takdirde "hayır" döndürür.
  • slot-unbootable:<slot-suffix> . Belirtilen yuva başlatılamaz olarak işaretlenmişse "evet", aksi takdirde "hayır" döndürür.
  • slot-retry-count . Verilen yuvayı başlatmayı denemek için kalan yeniden deneme sayısı.

Tüm değişkenleri görüntülemek için koşmak fastboot getvar all .

OTA paketleri oluşturma

OTA paket araçları olmayan A / B cihazlar için komutlar aynı komutları izleyin. target_files.zip dosya A / B hedef yapı değişkenleri tanımlamak tarafından oluşturulmuş olması gerekir. OTA paket araçları, A/B güncelleyici biçiminde paketleri otomatik olarak tanımlar ve oluşturur.

Örnekler:

  • : Tam OTA oluşturmak için
    ./build/make/tools/releasetools/ota_from_target_files \
        dist_output/tardis-target_files.zip \
        ota_update.zip
    
  • : Artımlı OTA oluşturmak için
    ./build/make/tools/releasetools/ota_from_target_files \
        -i PREVIOUS-tardis-target_files.zip \
        dist_output/tardis-target_files.zip \
        incremental_ota_update.zip
    

Bölümleri yapılandırma

update_engine aynı disk tanımlanan bir A / B bölümleri herhangi bir çift güncelleyebilir. Bölmeler bir çift (örneğin ortak bir önek system ya da boot ve (örneğin başına yuvası eki) _a ). Yük jeneratör bir güncelleme yapılandırılmış tanımlar için bölmelerin listesi AB_OTA_PARTITIONS değişken olun.

Bölümleri bir çift Örneğin, bootloader_a ve booloader_b (dahildir _a ve _b yuvası ekleri vardır), ürün veya tahta yapılandırmasına aşağıdaki belirterek bu bölümleri güncelleyebilirsiniz:

AB_OTA_PARTITIONS := \
  boot \
  system \
  bootloader

Güncelleyen tüm bölümleri update_engine sistemin geri kalanı tarafından değiştirilmemelidir. Artımlı veya delta güncellemeleri sırasında, cari yuvadan ikili veri yeni yuvasına verilerini oluşturmak için kullanılır. Herhangi bir değişiklik, güncelleme işlemi sırasında yeni yuva verilerinin doğrulamada başarısız olmasına ve dolayısıyla güncellemenin başarısız olmasına neden olabilir.

Kurulum sonrası yapılandırma

Bir dizi anahtar/değer çifti kullanarak, yükleme sonrası adımını güncellenen her bölüm için farklı şekilde yapılandırabilirsiniz. Bulunan bir programı çalıştırmak için /system/usr/bin/postinst yeni görüntüde, sistem bölümü dosya sisteminin köküne göre yolu belirtin.

Örneğin, usr/bin/postinst olan system/usr/bin/postinst (bir RAM disk kullanılarak değilse). Ayrıca, geçirilecek dosya sistemi türünü belirtmek mount(2) sistem çağrısı. Ürün veya cihaz için aşağıdakileri ekleyin .mk dosyaları (varsa):

AB_OTA_POSTINSTALL_CONFIG += \
  RUN_POSTINSTALL_system=true \
  POSTINSTALL_PATH_system=usr/bin/postinst \
  FILESYSTEM_TYPE_system=ext4

derleme

Güvenlik nedeniyle, system_server kullanamaz just-in-time (JIT) derleme. Önünüzde için zamanın odex dosyaları derlemek gerekir Bu araçlar system_server ve en azından bağımlılıklarından; başka bir şey isteğe bağlıdır.

Uygulamaları arka planda derlemek için ürünün cihaz yapılandırmasına aşağıdakileri eklemelisiniz (ürünün device.mk dosyasında):

  1. Derleme betiğinin ve ikili dosyaların derlendiğinden ve sistem görüntüsüne dahil edildiğinden emin olmak için yerel bileşenleri yapıya dahil edin.
      # A/B OTA dexopt package
      PRODUCT_PACKAGES += otapreopt_script
    
  2. İçin derleme komut bağlayın update_engine çalışır gibi bir adım yükleme sonrası böyle.
      # A/B OTA dexopt update_engine hookup
      AB_OTA_POSTINSTALL_CONFIG += \
        RUN_POSTINSTALL_system=true \
        POSTINSTALL_PATH_system=system/bin/otapreopt_script \
        FILESYSTEM_TYPE_system=ext4 \
        POSTINSTALL_OPTIONAL_system=true
    

Kullanılmayan ikinci sistem bölümü preopted dosyaları yükleme yardım için başvurun DEX_PREOPT dosyalarının ilk önyükleme yüklemesi .