Sık sorulan sorular

Google herhangi bir cihazda A/B OTA'yı kullandı mı?

Evet. A/B güncellemelerinin pazarlama adı kesintisiz güncellemelerdir . Ekim 2016'dan itibaren Pixel ve Pixel XL telefonlar A/B ile birlikte gönderilir ve tüm Chromebook'lar aynı update_engine A/B uygulamasını kullanır. Gerekli platform kodu uygulaması Android 7.1 ve üzeri sürümlerde herkese açıktır.

A/B OTA'lar neden daha iyi?

A/B OTA'lar, güncellemeleri alırken daha iyi bir kullanıcı deneyimi sağlar. Aylık güvenlik güncellemelerinden elde edilen ölçümler, bu özelliğin başarısının zaten kanıtlanmış olduğunu gösteriyor: Mayıs 2017 itibarıyla Pixel sahiplerinin %95'i, Nexus kullanıcılarının %87'sine kıyasla en son güvenlik güncellemesini bir ay sonra çalıştırıyor ve Pixel kullanıcıları, Nexus kullanıcılarından daha erken güncelleme yapıyor. OTA sırasında blokların güncellenmemesi artık cihazın önyükleme yapmamasına neden olmuyor; Yeni sistem görüntüsü başarılı bir şekilde önyüklenene kadar Android, önceki çalışma sistemi görüntüsüne geri dönme özelliğini korur.

A/B, 2016 Piksel bölüm boyutlarını nasıl etkiledi?

Aşağıdaki tablo, nakliye A/B yapılandırmasının dahili olarak test edilen A/B olmayan yapılandırmayla karşılaştırmasına ilişkin ayrıntıları içerir:

Piksel bölüm boyutları A/B A/B olmayan
Önyükleyici 50*2 50
Bot 32*2 32
İyileşmek 0 32
Önbellek 0 100
Radyo 70*2 70
SATICI 300*2 300
Sistem 2048*2 4096
Toplam 5000 4680

A/B güncellemeleri, flashta yalnızca 320 MiB'lik bir artış gerektirir; kurtarma bölümünün kaldırılmasıyla 32 MiB tasarruf sağlanır ve önbellek bölümünün kaldırılmasıyla başka bir 100 MiB daha korunur. Bu, önyükleyici, önyükleme bölümü ve radyo bölümü için B bölümlerinin maliyetini dengeler. Satıcı bölümünün boyutu iki katına çıktı (boyut artışının büyük çoğunluğu). Pixel'in A/B sistem görüntüsü, orijinal A/B olmayan sistem görüntüsünün yarısı boyutundadır.

Dahili olarak test edilen Pixel A/B ve A/B olmayan varyantlar için (yalnızca A/B gönderilir), kullanılan alan yalnızca 320 MiB farklılık gösterdi. 32GiB cihazda bu oran %1'in biraz altındadır. 16GiB'lik bir cihaz için bu %2'den az olacaktır ve 8GiB'lik bir cihaz için neredeyse %4 olacaktır (üç cihazın hepsinin aynı sistem görüntüsüne sahip olduğu varsayılarak).

Neden SquashFS'yi kullanmadınız?

SquashFS'yi denedik ancak üst düzey bir cihaz için istenen performansı elde edemedik. Elde taşınır cihazlar için SquashFS'yi kullanmıyor veya önermiyoruz.

Daha spesifik olarak SquashFS, sistem bölümünde yaklaşık %50 boyut tasarrufu sağladı, ancak iyi sıkıştırılan dosyaların büyük çoğunluğu önceden derlenmiş .odex dosyalarıydı. Bu dosyalar çok yüksek sıkıştırma oranlarına sahipti (%80'e yaklaşıyordu), ancak sistem bölümünün geri kalanının sıkıştırma oranı çok daha düşüktü. Ayrıca Android 7.0'daki SquashFS aşağıdaki performans endişelerini dile getirdi:

  • Pixel, önceki cihazlarla karşılaştırıldığında çok hızlı bir flaşa sahiptir ancak çok fazla sayıda yedek CPU döngüsü yoktur, bu nedenle flaştan daha az bayt okumak ancak G/Ç için daha fazla CPU'ya ihtiyaç duymak potansiyel bir darboğaz oluşturuyordu.
  • Yüksüz bir sistem üzerinde yapılan yapay bir kıyaslamada iyi performans gösteren G/Ç değişiklikleri, bazen gerçek dünya yükü altındaki gerçek dünya kullanım durumlarında (Nexus 6'daki kripto gibi) iyi çalışmayabilir.
  • Karşılaştırma bazı yerlerde %85 oranında gerileme gösterdi.

SquashFS olgunlaştıkça ve CPU etkisini azaltacak özellikler ekledikçe (sıkıştırılmaması gereken yaygın olarak erişilen dosyaların beyaz listesi gibi), onu değerlendirmeye devam edeceğiz ve cihaz üreticilerine öneriler sunmaya devam edeceğiz.

SquashFS olmadan sistem bölümünün boyutunu nasıl yarıya indirdiniz?

Uygulamalar aslında ZIP arşivleri olan .apk dosyalarında saklanır. Her .apk dosyasının içinde taşınabilir Dalvik bayt kodunu içeren bir veya daha fazla .dex dosyası bulunur. Bir .odex dosyası (optimize edilmiş .dex), .apk dosyasından ayrı olarak bulunur ve cihaza özel makine kodunu içerebilir. Bir .odex dosyası mevcutsa Android, uygulama her başlatıldığında kodun derlenmesini beklemek zorunda kalmadan uygulamaları önceden derlenmiş hızlarda çalıştırabilir. Bir .odex dosyası kesinlikle gerekli değildir: Android aslında .dex kodunu doğrudan yorumlama veya Tam Zamanında (JIT) derleme yoluyla çalıştırabilir, ancak bir .odex dosyası aşağıdaki durumlarda başlatma hızı ve çalışma zamanı hızının en iyi kombinasyonunu sağlar. yer mevcuttur.

Örnek: Toplam sistem görüntüsü boyutu 2628MiB (2755792836 bayt) olan Android 7.1 çalıştıran bir Nexus 6P'deki yüklü dosyalar.txt dosyası için, dosya türüne göre genel sistem görüntüsü boyutuna en fazla katkıda bulunanların dökümü aşağıdaki gibidir:

.odex 1391770312 bayt %50,5
.apk 846878259 bayt %30,7
.so (yerel C/C++ kodu) 202162479 bayt %7,3
.oat dosyaları/.art görselleri 163892188 bayt %5,9
Yazı tipleri 38952361 bayt %1,4
icu yerel ayar verileri 27468687 bayt %0,9

Bu rakamlar diğer cihazlar için de benzer olduğundan Nexus/Pixel cihazlarda .odex dosyaları sistem bölümünün yaklaşık yarısını kaplar. Bu, ext4'ü kullanmaya devam edebileceğimiz, ancak .odex dosyalarını fabrikadaki B bölümüne yazıp ardından ilk açılışta /data kopyalayabileceğimiz anlamına geliyordu. Ext4 A/B ile kullanılan gerçek depolama SquashFS A/B ile aynıdır, çünkü SquashFS kullanmış olsaydık önceden seçilen .odex dosyalarını system_b yerine system_a'ya gönderirdik.

.Odex dosyalarını /data'ya kopyalamak, /system'de kaydedilen alanın /data'da kaybolduğu anlamına gelmiyor mu?

Tam olarak değil. Pixel'de, .odex dosyalarının kapladığı alanın çoğu, genellikle /data üzerinde bulunan uygulamalar içindir. Bu uygulamalar Google Play güncellemelerini alır, dolayısıyla sistem görüntüsündeki .apk ve .odex dosyaları cihazın kullanım ömrü boyunca kullanılmaz. Kullanıcı her uygulamayı gerçekten kullandığında bu tür dosyalar tamamen hariç tutulabilir ve küçük, profil odaklı .odex dosyalarıyla değiştirilebilir (böylece kullanıcının kullanmadığı uygulamalar için alan gerekmez). Ayrıntılar için Google I/O 2016 konuşması The Evolution of Art'a bakın.

Karşılaştırma birkaç temel nedenden dolayı zordur:

  • Google Play tarafından güncellenen uygulamaların .odex dosyaları, ilk güncellemelerini alır almaz her zaman /data konumunda bulunur.
  • Kullanıcının çalıştırmadığı uygulamaların bir .odex dosyasına ihtiyacı yoktur.
  • Profil odaklı derleme, önceden yapılan derlemeye göre daha küçük .odex dosyaları oluşturur (çünkü ilki yalnızca performans açısından kritik kodu optimize eder).

OEM'lerin kullanabileceği ayarlama seçeneklerine ilişkin ayrıntılar için bkz . ART'ı Yapılandırma .

/data'da .odex dosyalarının iki kopyası yok mu?

Biraz daha karmaşık... Yeni sistem görüntüsü yazıldıktan sonra, yeni .odex dosyalarını oluşturmak için dex2oat'ın yeni sürümü yeni .dex dosyalarına karşı çalıştırılır. Bu, eski sistem hala çalışırken meydana gelir, dolayısıyla eski ve yeni .odex dosyalarının her ikisi de aynı anda /data bulunur.

OtaDexoptService'deki kod ( frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java ), /data aşırı doldurulmasını önlemek için her paketi optimize etmeden önce getAvailableSpace çağırır. Burada mevcut olanın hala ihtiyatlı olduğunu unutmayın: bu, olağan sistem düşük alan eşiğine ulaşmadan önce kalan alan miktarıdır (hem yüzde hem de bayt sayısı olarak ölçülür). Yani /data doluysa, her .odex dosyasının iki kopyası olmayacaktır. Aynı kodda ayrıca bir BULK_DELETE_THRESHOLD bulunur: Cihaz mevcut alanı doldurmaya bu kadar yaklaşırsa (az önce açıklandığı gibi), kullanılmayan uygulamalara ait .odex dosyaları kaldırılır. Bu, her .odex dosyasının iki kopyasının olmadığı başka bir durumdur.

/data tamamen dolduğu en kötü durumda, güncelleme, cihaz yeni sistemde yeniden başlatılana ve artık eski sistemin .odex dosyalarına ihtiyaç duymayana kadar bekler. PackageManager bunu yönetir: ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). Yeni sistem başarılı bir şekilde önyüklendikten sonra, installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) eski sistem tarafından kullanılan .odex dosyalarını kaldırarak cihazı kararlı duruma geri döndürebilir. yalnızca bir kopyanın olduğu yer.

Dolayısıyla, /data tüm .odex dosyalarının iki kopyasını içermesi mümkün olsa da, (a) bu geçicidir ve (b) yalnızca /data yeterince boş alanınız varsa oluşur. Güncelleme haricinde yalnızca bir kopya vardır. ART'ın genel sağlamlık özelliklerinin bir parçası olarak, /data hiçbir zaman .odex dosyalarıyla doldurmaz (çünkü bu, A/B olmayan bir sistemde de sorun olabilir).

Bütün bu yazma/kopyalama flaş aşınmasını artırmıyor mu?

Flash'ın yalnızca küçük bir kısmı yeniden yazılır: Tam Pixel sistem güncellemesi yaklaşık 2,3GiB yazar. (Uygulamalar da yeniden derlenir, ancak bu A/B olmayanlar için de geçerlidir.) Geleneksel olarak blok tabanlı tam OTA'lar benzer miktarda veri yazardı, dolayısıyla flaş aşınma oranları da benzer olmalıdır.

İki sistem bölümünün yanıp sönmesi fabrikada yanıp sönme süresini artırır mı?

Hayır. Pikselin sistem görüntü boyutu artmadı (yalnızca alanı iki bölüme ayırdı).

.Odex dosyalarını B'de tutmak, fabrika verileri sıfırlandıktan sonra yeniden başlatmayı yavaşlatmıyor mu?

Evet. Bir cihazı gerçekten kullandıysanız, OTA aldıysanız ve fabrika verilerine sıfırlama işlemi gerçekleştirdiyseniz, .odex dosyaları kaybolacağından ilk yeniden başlatma işlemi normalden daha yavaş olacaktır (Pixel XL'de 1 dakika 40 saniyeye karşılık 40 saniye). B ilk OTA'dan sonradır ve bu nedenle /data dosyasına kopyalanamaz. Takas budur.

Fabrika verilerine sıfırlama, normal önyüklemeyle karşılaştırıldığında nadir bir işlem olmalıdır, dolayısıyla harcanan süre daha az önemlidir. (Bu, cihazlarını fabrikadan alan kullanıcıları veya incelemecileri etkilemez çünkü bu durumda B bölümü mevcuttur.) JIT derleyicisinin kullanılması, her şeyi yeniden derlememize gerek olmadığı anlamına gelir, dolayısıyla sizin kadar kötü değildir. düşünebilir. Bildirimde coreApp="true" kullanarak uygulamaları önceden derleme gerektiren olarak işaretlemek de mümkündür: ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 ). Bu şu anda system_server tarafından kullanılıyor çünkü güvenlik nedeniyle JIT'e izin verilmiyor.

.Odex dosyalarını /system yerine /data'da tutmak, OTA sonrasında yeniden başlatmayı yavaşlatmıyor mu?

Hayır. Yukarıda açıklandığı gibi, yeni sistemin ihtiyaç duyacağı dosyaları oluşturmak için eski sistem görüntüsü hala çalışırken yeni dex2oat çalıştırılır. Bu çalışma tamamlanana kadar güncellemenin mevcut olduğu kabul edilmez.

32GiB A/B cihazı gönderebilir miyiz (göndermeli miyiz)? 16GiB? 8GiB?

32GiB, Pixel'de kanıtlandığı gibi iyi çalışıyor ve 16GiB'den 320MiB, %2'lik bir azalma anlamına geliyor. Benzer şekilde, 8GiB'den 320MiB'de %4'lük bir azalma. 320MiB ek yükü toplam kullanılabilir alanın neredeyse %10'unu oluşturduğundan, 4GiB'li cihazlarda A/B'nin önerilen seçim olmayacağı açıktır.

AVB2.0 A/B OTA'lara ihtiyaç duyuyor mu?

Hayır. Android Verified Boot her zaman blok tabanlı güncellemeler gerektirmiştir ancak A/B güncellemeleri zorunlu değildir.

A/B OTA'lar AVB2.0 gerektirir mi?

HAYIR.

A/B OTA'lar AVB2.0'ın geri alma korumasını bozar mı?

Hayır. Burada bazı karışıklıklar var çünkü bir A/B sistemi yeni sistem görüntüsüne önyükleme yapmazsa (önyükleyiciniz tarafından belirlenen sayıda yeniden denemeden sonra) otomatik olarak "önceki" sistem görüntüsüne geri döner. Buradaki kilit nokta, A/B anlamında "önceki"nin aslında hala "geçerli" sistem görüntüsü olmasıdır. Cihaz yeni bir görüntüyü başarıyla başlattığında, geri alma koruması devreye girer ve geri dönememenizi sağlar. Ancak yeni görüntüyü gerçekten başarılı bir şekilde önyükleyene kadar, geri alma koruması onu geçerli sistem görüntüsü olarak değerlendirmez.

Sistem çalışırken bir güncelleme yüklüyorsanız bu yavaş değil mi?

A/B olmayan güncellemelerde amaç, güncelleme uygulanırken kullanıcının beklemesi ve cihazını kullanamaması nedeniyle güncellemenin mümkün olan en kısa sürede yüklenmesidir. A/B güncellemelerinde bunun tersi doğrudur; Kullanıcı hala cihazını kullandığından amaç mümkün olduğunca az etki yaratmaktır, bu nedenle güncelleme kasıtlı olarak yavaştır. Java sistem güncelleme istemcisindeki (Google için GMS tarafından sağlanan çekirdek paket olan GmsCore'dur) mantık yoluyla Android, kullanıcıların cihazlarını hiç kullanmadıkları bir zamanı da seçmeye çalışır. Platform, güncellemenin duraklatılmasını/devam ettirilmesini destekler ve istemci, kullanıcı cihazı kullanmaya başlarsa güncellemeyi duraklatmak ve cihaz tekrar boşta kaldığında devam ettirmek için bunu kullanabilir.

OTA alırken, kullanıcı arayüzünde ilerleme çubuğunun altında Adım 1/2 ve Adım 2/2 olarak açıkça gösterilen iki aşama vardır. Adım 1, veri bloklarının yazılmasına karşılık gelirken adım 2, .dex dosyalarının önceden derlenmesidir. Bu iki aşama performans etkisi açısından oldukça farklıdır. İlk aşama basit G/Ç'dir. Bu, çok az kaynak (RAM, CPU, G/Ç) gerektirir çünkü blokların yavaşça kopyalanmasıdır.

İkinci aşamada yeni sistem görüntüsünün önceden derlenmesi için dex2oat çalıştırılır. Bunun, gerçek uygulamaları derlediği için gereksinimleri konusunda daha az net sınırlara sahip olduğu açıktır. Ve büyük ve karmaşık bir uygulamayı derlemek, küçük ve basit bir uygulamadan çok daha fazla iş gerektirir; oysa 1. aşamada diğerlerinden daha büyük veya daha karmaşık disk blokları yoktur.

Süreç, Google Play'in yıllardır yapıldığı gibi, 5 uygulama güncellendi bildirimini göstermeden önce arka planda bir uygulama güncellemesi yüklemesine benzer.

Peki ya bir kullanıcı gerçekten güncellemeyi bekliyorsa?

GmsCore'daki mevcut uygulama, arka plan güncellemeleri ile kullanıcı tarafından başlatılan güncellemeler arasında ayrım yapmamaktadır ancak gelecekte bunu yapabilir. Kullanıcının güncellemenin yüklenmesini açıkça talep etmesi veya güncelleme ilerleme ekranını izlemesi durumunda, aktif olarak güncellemenin bitmesini bekledikleri varsayımına dayanarak güncelleme çalışmasına öncelik vereceğiz.

Bir güncelleme uygulanmazsa ne olur?

A/B olmayan güncellemelerde, bir güncelleme uygulanamazsa kullanıcı genellikle kullanılamaz bir cihazla kalır. Bunun tek istisnası, hatanın bir uygulama başlamadan önce meydana gelmesiydi (çünkü paket doğrulanamadı diyelim). A/B güncellemelerinde, bir güncellemenin uygulanmaması o anda çalışan sistemi etkilemez. Güncelleme daha sonra yeniden denenebilir.

Çip üzerindeki hangi sistemler (SoC'ler) A/B'yi destekler?

15.03.2017 itibarıyla aşağıdaki bilgilere sahibiz:

Android 7.x ve öncesi Android 8.x ve üzeri
Qualcomm OEM isteklerine bağlı olarak Tüm yonga setleri destek alacak
Mediatek OEM isteklerine bağlı olarak Tüm yonga setleri destek alacak

Programlarla ilgili ayrıntılar için SoC kişilerinize danışın. Yukarıda listelenmeyen SoC'ler için doğrudan SoC'nize ulaşın.