Google 致力于为黑人社区推动种族平等。查看具体举措
此页面由 Cloud Translation API 翻译。
Switch to English

A / B (Kesintisiz) Sistem Güncellemeleri

Kesintisiz güncellemeler olarak da bilinen A / B sistem güncellemeleri, kablosuz (OTA) güncelleme sırasında çalışabilir bir önyükleme sisteminin diskte kalmasını sağlar. Bu yaklaşım, bir güncellemeden sonra bir cihazın etkin olmayan bir cihaz olma olasılığını azaltır, bu da onarım ve garanti merkezlerinde daha az cihaz değişimi ve cihaz yeniden yanıp sönmesi anlamına gelir. ChromeOS gibi diğer ticari sınıf işletim sistemleri de A / B güncellemelerini başarıyla kullanır.

A / B sistem güncellemeleri ve nasıl çalıştıkları hakkında daha fazla bilgi için bkz. Bölüm seçimi (yuvalar) .

A / B sistem güncellemeleri aşağıdaki faydaları sağlar:

  • OTA güncellemeleri, sistem çalışırken kullanıcıyı kesintiye uğratmadan gerçekleşebilir. Kullanıcılar bir OTA sırasında cihazlarını kullanmaya devam edebilirler — güncelleme sırasındaki tek aksama süresi, cihazın güncellenmiş disk bölümünde yeniden başlatılmasıdır.
  • Bir güncellemeden sonra yeniden başlatma, normal yeniden başlatmadan daha uzun sürmez.
  • Bir OTA uygulanamazsa (örneğin, kötü bir flaş nedeniyle), kullanıcı etkilenmeyecektir. Kullanıcı eski işletim sistemini çalıştırmaya devam edecek ve istemci güncellemeyi yeniden denemekte serbesttir.
  • Bir OTA güncellemesi uygulanır ancak önyükleme yapamazsa, cihaz eski bölüme yeniden başlayacak ve kullanılabilir durumda kalacaktır. İstemci güncellemeyi yeniden denemekte serbesttir.
  • Herhangi bir hata (G / Ç hataları gibi) yalnızca kullanılmayan bölüm kümesini etkiler ve yeniden denenebilir. Kullanıcı deneyiminin bozulmasını önlemek için G / Ç yükü kasıtlı olarak düşük olduğundan bu tür hataların olasılığı da azalır.
  • Güncellemeler, paketi yüklemeden önce indirme ihtiyacını ortadan kaldırarak A / B cihazlarına aktarılabilir. Akış, kullanıcının güncelleme paketini /data veya /cache üzerinde depolamak için yeterli boş alana sahip olması gerekmediği anlamına gelir.
  • Önbellek bölümü artık OTA güncelleme paketlerini depolamak için kullanılmamaktadır, bu nedenle önbellek bölümünün gelecekteki güncellemeler için yeterince büyük olmasını sağlamaya gerek yoktur.
  • dm-verity, bir aygıtın bozulmamış bir görüntüyü başlatacağını garanti eder. Bir cihaz, kötü bir OTA veya dm-verity sorunu nedeniyle önyükleme yapmazsa, cihaz eski bir görüntüye yeniden başlayabilir. (Android Doğrulanmış Önyükleme , A / B güncellemeleri gerektirmez.)

A / B sistem güncellemeleri hakkında

A / B güncellemeleri hem istemcide hem de sistemde değişiklik yapılmasını gerektirir. Ancak OTA paket sunucusu değişiklik gerektirmemelidir: güncelleme paketleri hala HTTPS üzerinden sunulmaktadır. Google'ın OTA altyapısını kullanan cihazlar için, sistem değişikliklerinin tamamı AOSP'dedir ve istemci kodu Google Play hizmetleri tarafından sağlanır. Google'ın OTA altyapısını kullanmayan OEM'ler, AOSP sistem kodunu yeniden kullanabilecek ancak kendi müşterilerini tedarik etmeleri gerekecek.

Kendi müşterilerini tedarik eden OEM'ler için müşterinin şunları yapması gerekir:

  • Ne zaman güncelleme alacağınıza karar verin. A / B güncellemeleri arka planda gerçekleştiği için artık kullanıcı tarafından başlatılmazlar. Kullanıcıları rahatsız etmekten kaçınmak için, güncellemelerin cihaz gece ve Wi-Fi gibi boşta bakım modundayken planlanması önerilir. Ancak, müşteriniz istediğiniz herhangi bir buluşsal yöntemi kullanabilir.
  • OTA paket sunucularınızla kontrol edin ve bir güncelleme olup olmadığını belirleyin. Bu, cihazın A / B'yi desteklediğini belirtmek istemeniz dışında, çoğunlukla mevcut müşteri kodunuzla aynı olmalıdır. (Google'ın istemcisi ayrıca, kullanıcıların en son güncellemeyi kontrol etmeleri için bir Şimdi kontrol et düğmesi içerir.)
  • Güncelleme paketinizin mevcut olduğunu varsayarak, güncelleme paketiniz için HTTPS URL'si ile update_engine arayın. update_engine , güncelleme paketini yayınlarken şu anda kullanılmayan bölümdeki ham blokları güncelleyecektir.
  • update_engine sonuç koduna göre, sunucularınıza kurulum başarılarını veya hatalarını update_engine . Güncelleme başarılı bir şekilde uygulanırsa, update_engine , önyükleyiciye bir sonraki yeniden başlatmada yeni işletim sisteminde önyükleme update_engine söyleyecektir. Yeni işletim sistemi önyükleme yapamazsa, önyükleyici eski işletim sistemine geri dönecektir, bu nedenle istemciden herhangi bir işlem yapılması gerekmez. Güncelleme başarısız olursa, müşterinin ayrıntılı hata koduna göre ne zaman tekrar deneyeceğine (ve deneyip denemeyeceğine) karar vermesi gerekir. Örneğin, iyi bir müşteri kısmi ("fark") bir OTA paketinin başarısız olduğunu fark edebilir ve bunun yerine tam bir OTA paketi deneyebilir.

Müşteri isteğe bağlı olarak şunları yapabilir:

  • Kullanıcıdan yeniden başlatmasını isteyen bir bildirim gösterin. Kullanıcının rutin olarak güncelleme yapmaya teşvik edildiği bir politika uygulamak istiyorsanız, bu bildirim istemcinize eklenebilir. İstemci, kullanıcılardan bilgi istemezse, kullanıcılar yine de yeniden başlattıklarında güncellemeyi alacaklardır. (Google'ın istemcisinin güncelleme başına yapılandırılabilir bir gecikmesi vardır.)
  • Kullanıcılara yeni bir işletim sistemi sürümüne mi önyükleme yaptıklarını veya bunu yapmaları ancak eski işletim sistemi sürümüne geri dönüp dönmediklerini belirten bir bildirim gösterin. (Google'ın müşterisi genellikle ikisini de yapmaz.)

Sistem tarafında, A / B sistem güncellemeleri aşağıdakileri etkiler:

  • Bölüm seçimi (yuvalar), update_engine arka plan programı ve önyükleyici etkileşimleri (aşağıda açıklanmıştır)
  • Derleme süreci ve OTA güncelleme paketi oluşturma ( A / B Güncellemelerini Uygulama bölümünde açıklanmıştır)

Bölüm seçimi (yuvalar)

A / B sistem güncellemeleri, yuvalar olarak adlandırılan iki bölüm kümesi kullanır (normalde yuva A ve yuva B). Sistem, normal çalışma sırasında çalışan sistem tarafından kullanılmayan yuvadaki bölümlere erişilmezken mevcut yuvadan çalışır. Bu yaklaşım, kullanılmayan yuvayı bir yedek olarak tutarak güncellemeleri hataya dirençli hale getirir: Bir güncelleme sırasında veya hemen sonrasında bir hata oluşursa, sistem eski yuvaya geri dönebilir ve çalışan bir sisteme sahip olmaya devam edebilir. Bu amaca ulaşmak için, geçerli yuva tarafından kullanılan hiçbir bölüm OTA güncellemesinin bir parçası olarak güncellenmemelidir (yalnızca bir kopyası olan bölümler dahil).

Her yuvanın, yuvanın aygıtın önyüklenebileceği doğru bir sistem içerip içermediğini belirten önyüklenebilir bir özniteliği vardır. Geçerli yuva, sistem çalışırken önyüklenebilir, ancak diğer yuvada sistemin eski (hala doğru) bir sürümü, daha yeni bir sürümü veya geçersiz veriler olabilir. Geçerli yuvanın ne olduğuna bakılmaksızın, aktif yuva (önyükleyicinin bir sonraki önyüklemede önyükleyeceği) veya tercih edilen yuva olan bir yuva vardır.

Her yuvanın ayrıca kullanıcı alanı tarafından belirlenen başarılı bir özniteliği vardır, bu yalnızca yuvanın da önyüklenebilir olması durumunda geçerlidir. Başarılı bir yuva önyükleme yapabilmeli, çalışabilmeli ve kendini güncelleyebilmelidir. Başarılı olarak işaretlenmemiş (birkaç kez önyükleme girişiminde bulunulduktan sonra) önyüklenebilir bir yuva, etkin yuvayı başka bir önyüklenebilir yuvaya (normalde önyükleme girişiminden hemen önce çalışan yuvaya) değiştirmek de dahil olmak üzere önyükleyici tarafından başlatılamaz olarak işaretlenmelidir. yeni, aktif olana). Arayüzün belirli ayrıntıları boot_control.h tanımlanmıştır.

Motor arka plan programını güncelleyin

A / B sistem güncellemeleri, sistemi yeni, güncellenmiş bir sürüme önyüklemeye hazırlamak için update_engine adlı bir arka plan arka plan programı kullanır. Bu arka plan programı aşağıdaki eylemleri gerçekleştirebilir:

  • Geçerli yuva A / B bölümlerinden okuyun ve kullanılmayan yuva A / B bölümlerine OTA paketi talimatına göre herhangi bir veri yazın.
  • Ön tanımlı bir iş akışında boot_control arayüzünü çağırın.
  • OTA paketinde belirtildiği gibi, kullanılmayan tüm yuva bölümlerini yazdıktan sonra yeni bölümden bir yükleme sonrası programı çalıştırın. (Ayrıntılar için Kurulum Sonrasına bakın ).

update_engine arka plan programı önyükleme işleminin kendisinde yer almadığından, mevcut yuvadaki SELinux ilkeleri ve özellikleriyle bir güncelleme sırasında yapabilecekleri sınırlıdır (bu tür ilkeler ve özellikler, sistem bir Yeni sürüm). Sağlam bir sistem korumak için, güncelleme işlemi bölümleme tablosunu değiştirmemelidir, şimdiki yuvaya bölümlerin içeriğinin veya bir reset atarak sildi edilemez olmayan, A / B bölümleri içeriği.

Motor kaynağını güncelle

update_engine kaynağı system/update_engine . A / B OTA dexopt dosyaları, installd ve paket yöneticisi arasında bölünür:

Çalışan bir örnek için /device/google/marlin/device-common.mk bakın.

Motor günlüklerini güncelleyin

Android 8.x sürümleri ve önceki sürümler için update_engine günlükleri logcat ve hata raporunda bulunabilir. update_engine günlüklerini dosya sisteminde kullanılabilir hale getirmek için, aşağıdaki değişiklikleri derlemenize ekleyin:

Bu değişiklikler en son update_engine günlüğünün bir kopyasını /data/misc/update_engine_log/update_engine. YEAR - TIME . Mevcut günlüğe ek olarak, en son beş günlük /data/misc/update_engine_log/ altına kaydedilir. Günlük grubu kimliğine sahip kullanıcılar, dosya sistemi günlüklerine erişebilir.

Bootloader etkileşimleri

boot_control HAL, update_engine (ve muhtemelen diğer update_engine programları) tarafından bootloader'a ne önyükleme yapılacağını bildirmek için kullanılır. Yaygın örnek senaryolar ve bunlarla ilişkili durumlar aşağıdakileri içerir:

  • Normal durum : Sistem mevcut yuvasından, ya A ya da B yuvasından çalışıyor. Şu ana kadar hiçbir güncelleme uygulanmadı. Sistemin mevcut yuvası önyüklenebilir, başarılı ve aktif yuvadır.
  • Güncelleme devam ediyor : Sistem B yuvasından çalışıyor, bu nedenle B yuvası önyüklenebilir, başarılı ve etkin yuvadır. A yuvasının içeriği güncellendiği, ancak henüz tamamlanmadığı için A Yuvası başlatılamaz olarak işaretlendi. Bu durumda bir yeniden başlatma, B yuvasından önyüklemeye devam etmelidir.
  • Güncelleme uygulandı, yeniden başlatma bekleniyor : Sistem B yuvasından çalışıyor, yuva B önyüklenebilir ve başarılı, ancak yuva A etkin olarak işaretlendi (ve bu nedenle önyüklenebilir olarak işaretlendi). A Yuvası henüz başarılı olarak işaretlenmemiştir ve önyükleyici tarafından A yuvasından bazı önyükleme girişimlerinin yapılması gerekir.
  • Sistem yeni güncellemeyle yeniden başlatıldı : Sistem A yuvasından ilk kez çalışıyor, yuva B hala önyüklenebilir ve başarılı, yuva A ise yalnızca önyüklenebilir ve hala etkin ancak başarılı değil. Bir kullanıcı alanı daemon'u, update_verifier , bazı kontroller yapıldıktan sonra A yuvasını başarılı olarak işaretlemelidir.

Akış güncelleme desteği

Kullanıcı cihazları, güncelleme paketini indirmek için /data üzerinde her zaman yeterli alana sahip değildir. Ne OEM'ler ne de kullanıcılar bir /cache bölümünde yer israf etmek istemediğinden, bazı kullanıcılar güncelleme yapmaz çünkü aygıtın güncelleme paketini depolayacak yeri yoktur. Bu sorunu gidermek için Android 8.0, blokları /data depolamak zorunda kalmadan, blokları indirildikçe doğrudan B bölümüne yazan akışlı A / B güncellemelerini destekledi. Akış A / B güncellemeleri neredeyse hiç geçici depolama gerektirmez ve yaklaşık 100 KiB meta veri için yeterli depolama alanı gerektirir.

Android 7.1'de akış güncellemelerini etkinleştirmek için aşağıdaki yamaları seçin:

Bu yamaların, Google Mobile Services (GMS) veya başka herhangi bir güncelleme istemcisini kullanıp kullanmadığına bakılmaksızın Android 7.1 ve sonraki sürümlerde A / B güncellemelerinin akışını desteklemek için gereklidir.

Bir A / B güncellemesinin ömrü

Güncelleme işlemi, bir OTA paketi (kodda yük olarak anılır) indirilmek üzere hazır olduğunda başlar. Cihazdaki politikalar, yük indirme işlemini ve uygulamayı pil seviyesi, kullanıcı etkinliği, şarj durumu veya diğer politikalara göre erteleyebilir. Ek olarak, güncelleme arka planda çalıştığından, kullanıcılar bir güncellemenin devam ettiğini bilmeyebilir. Tüm bunlar, güncelleme işleminin politikalar, beklenmeyen yeniden başlatmalar veya kullanıcı eylemleri nedeniyle herhangi bir noktada kesintiye uğrayabileceği anlamına gelir.

İsteğe bağlı olarak, OTA paketindeki meta veriler güncellemenin akışa alınabileceğini gösterir; aynı paket, akışsız kurulum için de kullanılabilir. Sunucu, istemciye akışını bildirmek için meta verileri kullanabilir, böylece istemci update_engine doğru bir şekilde update_engine . Kendi sunucuları ve istemcileri olan cihaz üreticileri, sunucunun güncellemenin akış halinde olduğunu tanımlamasını (veya tüm güncellemelerin akış halinde olduğunu varsaymasını) ve istemcinin akış için update_engine doğru çağrıyı yapmasını sağlayarak akış güncellemelerini etkinleştirebilir. Üreticiler, akış olarak çerçeve tarafına aktarımı tetiklemek için istemciye bir bayrak göndermek için paketin akış varyantı olduğu gerçeğini kullanabilir.

Bir yük mevcut olduktan sonra güncelleme işlemi aşağıdaki gibidir:

Adım Faaliyetler
1 Geçerli yuva (veya "kaynak yuva"), markBootSuccessful() ile başarılı olarak işaretlenir (önceden işaretlenmemişse markBootSuccessful() .
2 Kullanılmayan yuva (veya "hedef yuva"), setSlotAsUnbootable() işlevi çağrılarak başlatılamaz olarak işaretlenir. Geçerli yuva, önyükleyicinin kısa süre sonra geçersiz verilere sahip olacak kullanılmayan yuvaya geri dönmesini önlemek için güncellemenin başında her zaman başarılı olarak işaretlenir. Sistem bir güncellemeyi uygulamaya başlayabileceği noktaya ulaştıysa, mevcut yuva, diğer ana bileşenler (bir kilitlenme döngüsündeki kullanıcı arabirimi gibi) kırılsa bile başarılı olarak işaretlenir, çünkü bunları düzeltmek için yeni yazılımı zorlamak mümkündür sorunlar.

Güncelleme yükü, yeni sürüme güncelleme talimatları içeren opak bir blob'dur. Güncelleme yükü aşağıdakilerden oluşur:
  • Meta veriler . Güncelleme yükünün nispeten küçük bir kısmı olan meta veriler, hedef yuvada yeni sürümü üretmek ve doğrulamak için bir işlem listesi içerir. Örneğin, bir işlem belirli bir blobun sıkıştırmasını açabilir ve bir hedef bölümdeki belirli bloklara yazabilir veya bir kaynak bölümden okuyabilir, ikili bir yama uygulayabilir ve bir hedef bölümdeki belirli bloklara yazabilir.
  • Ekstra veriler . Güncelleme yükünün büyük bir kısmı olarak, işlemlerle ilişkili ekstra veriler bu örneklerde sıkıştırılmış blob veya ikili yamadan oluşur.
3 Yük meta verileri indirilir.
4 Meta verilerde tanımlanan her işlem için, sırayla ilişkili veriler (varsa) belleğe indirilir, işlem uygulanır ve ilişkili bellek atılır.
5 Tüm bölümler yeniden okunur ve beklenen hash'e göre doğrulanır.
6 Yükleme sonrası adım (varsa) çalıştırılır. Herhangi bir adımın yürütülmesi sırasında bir hata olması durumunda, güncelleme başarısız olur ve muhtemelen farklı bir yük ile yeniden denenir. Şimdiye kadarki tüm adımlar başarılı olduysa, güncelleme başarılı olur ve son adım yürütülür.
7 Kullanılmayan yuva , setActiveBootSlot() çağrılarak etkin olarak işaretlenir. Kullanılmayan yuvayı aktif olarak işaretlemek, önyüklemeyi bitireceği anlamına gelmez. Bootloader (veya sistemin kendisi) başarılı bir durumu okumazsa aktif yuvayı geri değiştirebilir.
8 Yükleme sonrası (aşağıda açıklanmıştır), eski sürümde çalışmaya devam ederken "yeni güncelleme" sürümünden bir programın çalıştırılmasını içerir. OTA paketinde tanımlanmışsa, bu adım zorunludur ve program çıkış kodu 0 ile geri dönmelidir; aksi takdirde güncelleme başarısız olur.
9 Sistem, yeni yuvaya yeterince başarılı bir şekilde önyükleme yaptıktan ve yeniden başlatma sonrası kontrolleri tamamladıktan sonra, artık geçerli yuva (eski adıyla "hedef yuva"), markBootSuccessful() çağrısı markBootSuccessful() başarılı olarak işaretlenir.

Yükleme sonrası

Bir yükleme sonrası adımın tanımlandığı her bölüm için, update_engine yeni bölümü belirli bir konuma bağlar ve update_engine bölüme göre update_engine belirtilen programı çalıştırır. Örneğin, yükleme sonrası program sistem bölümünde usr/bin/postinstall olarak tanımlanırsa, kullanılmayan yuvadaki bu bölüm sabit bir konuma ( /postinstall_mount gibi) ve /postinstall_mount/usr/bin/postinstall komutu yürütülür.

Kurulum sonrası işlemin başarılı olması için, eski çekirdek şunları yapabilmelidir:

  • Yeni dosya sistemi biçimini bağlayın . Dosya sistemi türü, sıkıştırılmış bir dosya sistemi (yani SquashFS) kullanılıyorsa kullanılan sıkıştırma algoritması gibi ayrıntılar dahil olmak üzere eski çekirdekte destek olmadıkça değiştirilemez.
  • Yeni bölümün yükleme sonrası program biçimini anlayın . Yürütülebilir ve Bağlanabilir Biçim (ELF) ikili dosyası kullanılıyorsa, eski çekirdekle uyumlu olmalıdır (örneğin, eğer mimari 32 bitlikten 64 bitlik yapılara geçtiyse eski bir 32 bitlik çekirdek üzerinde çalışan 64 bitlik yeni bir program). Yükleyiciye ( ld ) diğer yolları kullanma veya statik bir ikili oluşturma talimatı verilmedikçe, kitaplıklar yeni sistem görüntüsünden değil eski sistem görüntüsünden yüklenecektir.

Örneğin, eski sistemin kabuk ikilisi tarafından bir #! İle yorumlanan yükleme sonrası program olarak bir kabuk komut dosyası kullanabilirsiniz #! işaretleyici), ardından daha karmaşık bir ikili yükleme sonrası programı yürütmek için yeni ortamdan kitaplık yollarını ayarlayın. Alternatif olarak, ana sistem bölümündeki dosya sistemi formatının, geriye dönük uyumluluk sorunları veya basamaklı güncellemeler olmadan güncellenmesini sağlamak için, daha küçük bir bölümden yükleme sonrası adımını çalıştırabilirsiniz; bu, kullanıcıların bir fabrika görüntüsünden doğrudan en son sürüme güncelleme yapmasına olanak tanır.

Yeni yükleme sonrası program, eski sistemde tanımlanan SELinux ilkeleriyle sınırlıdır. Bu nedenle, yükleme sonrası adım, belirli bir cihazda tasarımın gerektirdiği görevleri veya diğer en iyi çaba gerektiren görevleri gerçekleştirmek için uygundur (yani, A / B özellikli ürün yazılımı veya önyükleyiciyi güncellemek, yeni sürüm için veri tabanlarının kopyalarını hazırlamak, vb.) ). Yükleme sonrası adım, öngörülemeyen izinler gerektiren yeniden başlatmadan önce tek seferlik hata düzeltmeleri için uygun değildir .

Seçilen postinstall program, postinstall SELinux bağlamında çalışır. Yeni postinstall_file bölümdeki tüm dosyalar, bu yeni sistemde yeniden başlatıldıktan sonra özniteliklerinin ne olduğuna bakılmaksızın postinstall_file ile etiketlenecektir. Yeni sistemdeki SELinux özniteliklerinde yapılan değişiklikler kurulum sonrası adımı etkilemeyecektir. Yükleme sonrası programın ek izinlere ihtiyacı varsa, bunlar yükleme sonrası içeriğe eklenmelidir.

Yeniden başlattıktan sonra

Yeniden başlatmanın ardından update_verifier , dm-verity kullanarak bütünlük denetimini tetikler. Bu kontrol, Java hizmetlerinin güvenli bir geri dönüşü engelleyecek geri dönüşü olmayan değişiklikler yapmasını önlemek için zigot'tan önce başlar. Bu işlem sırasında, önyükleyici ve çekirdek, doğrulanmış önyükleme veya dm-verity herhangi bir bozulma tespit ederse bir yeniden başlatmayı da tetikleyebilir. Kontrol tamamlandıktan sonra, update_verifier önyüklemeyi başarılı olarak işaretler.

update_verifier , yalnızca /data/ota_package/care_map.txt listelenen ve AOSP kodunu kullanırken A / B OTA paketine dahil edilen blokları okuyacaktır. Java sistem güncellemesi böyle GmsCore özü olarak istemci, care_map.txt , cihazı yeniden başlatmadan önce erişim izni yukarı setleri ve başarıyla bot yeni sürümüne sisteme sonrasında çıkartılan dosyayı siler.