Google, herhangi bir cihazda A/B OTA'ları kullandı mı?
Evet. A/B güncellemelerinin pazarlama adı sorunsuz güncellemeler'dir. Ekim 2016'da piyasaya sürülen Pixel ve Pixel XL telefonlarda A/B kullanılır. Tüm Chromebook'larda da aynı update_engine
A/B uygulaması kullanılır. Gerekli platform kodu uygulaması, Android 7.1 ve sonraki sürümlerde herkese açıktır.
Neden A/B OTA'lar daha iyidir?
A/B OTA'lar, güncellemeler alınırken daha iyi bir kullanıcı deneyimi sağlar. Aylık güvenlik güncellemelerinden elde edilen ölçümler, bu özelliğin şimdiden başarılı olduğunu gösteriyor: Mayıs 2017 itibarıyla Pixel sahiplerinin% 95'i bir ay sonra en son güvenlik güncellemesini kullanırken Nexus kullanıcılarının% 87'si bu güncellemeyi kullanıyor. Ayrıca Pixel kullanıcıları, Nexus kullanıcılarına kıyasla daha hızlı güncelleme yapıyor. OTA sırasında blokların güncellenememesi artık cihazın başlatılamamasına neden olmuyor. Yeni sistem görüntüsü başarıyla başlatılana kadar Android, önceki çalışan sistem görüntüsüne geri dönme özelliğini koruyor.
system_other nedir?
Uygulamalar, aslında ZIP arşivleri olan .apk dosyalarında saklanır. Her .apk dosyasında, taşınabilir Dalvik bayt kodu içeren bir veya daha fazla .dex dosyası bulunur. .odex dosyası (optimize edilmiş .dex), .apk dosyasından ayrı olarak bulunur ve cihaza özgü makine kodu içerebilir. Bir .odex dosyası varsa Android, uygulamayı her başlattığınızda kodun derlenmesini beklemeden uygulamaları önceden derlenmiş hızlarda çalıştırabilir. .odex dosyası kesinlikle gerekli değildir: Android, .dex kodunu yorumlama veya tam zamanında (JIT) derleme yoluyla doğrudan çalıştırabilir ancak alan varsa .odex dosyası, başlatma hızı ve çalışma zamanı hızının en iyi kombinasyonunu sağlar.
Örnek: Toplam sistem görüntüsü boyutu 2628 MiB (2755792836 bayt) olan Android 7.1'in yüklü olduğu bir Nexus 6P'deki installed-files.txt için, dosya türüne göre genel sistem görüntüsü boyutuna en büyük katkıyı sağlayanları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 resimleri | 163892188 bayt | %5,9 |
| Yazı Tipleri | 38952361 bayt | %1,4 |
| icu locale data | 27468687 bayt | %0,9 |
Bu rakamlar diğer cihazlar için de benzerdir. Bu nedenle, Nexus/Pixel cihazlarda .odex dosyaları sistem bölümünün yaklaşık yarısını kaplar. Bu sayede, ext4'ü kullanmaya devam edebiliyor ancak .odex dosyalarını fabrikada B bölümüne yazıp ilk başlatmada /data'ya kopyalayabiliyorduk. ext4 A/B ile kullanılan gerçek depolama alanı, SquashFS A/B ile aynıdır. Bunun nedeni, SquashFS kullanmış olsaydık önceden optimize edilmiş .odex dosyalarını system_b yerine system_a'da göndermiş olmamızdır.
.odex dosyalarını /data'ya kopyalamak, /system'de kaydedilen alanın /data'da kaybolduğu anlamına gelmez mi?
Pek 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. Bu nedenle, sistem görüntüsündeki .apk ve .odex dosyaları cihazın kullanım ömrünün büyük bir bölümünde kullanılmaz. Bu tür dosyalar tamamen hariç tutulabilir ve kullanıcı her uygulamayı gerçekten kullandığında küçük, profile dayalı .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'daki The Evolution of Art (Sanatın Evrimi) başlıklı konuşmayı inceleyin.
Karşılaştırma birkaç temel nedenden dolayı zordur:
-
Google Play tarafından güncellenen uygulamaların .odex dosyaları, ilk güncellemelerini aldıkları anda
/data'da yer almıştır. - Kullanıcının çalıştırmadığı uygulamalar için .odex dosyası gerekmez.
- Profile dayalı derleme, önceden derlemeye kıyasla daha küçük .odex dosyaları oluşturur (çünkü profile dayalı derleme yalnızca performansı etkileyen kritik kodları optimize eder).
OEM'lerin kullanabileceği ayarlama seçenekleriyle ilgili ayrıntılar için ART'yi yapılandırma başlıklı makaleyi inceleyin.
/data dizininde .odex dosyalarının iki kopyası yok mu?
Bu işlem biraz daha karmaşıktır. 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 işlem, eski sistem hâlâ çalışırken gerçekleşir. Bu nedenle, eski ve yeni .odex dosyaları aynı anda /data üzerinde bulunur.
OtaDexoptService'teki kod (frameworks/base/+/android16-qpr1-release/services/core/java/com/android/server/pm/OtaDexoptService.java), aşırı doldurmayı önlemek için her paketi optimize etmeden önce getAvailableSpace işlevini çağırır
/data. Buradaki kullanılabilir alanın yine de muhafazakar bir değer olduğunu unutmayın: Bu, normal sistemde düşük alan eşiğine ulaşılmadan önce kalan alan miktarıdır (hem yüzde hem de bayt sayısı olarak ölçülür). Bu nedenle, /data doluysa her .odex dosyasının iki kopyası olmaz. Aynı kodda BULK_DELETE_THRESHOLD da bulunur: Cihaz, kullanılabilir alanı doldurmaya yaklaştığında (yukarıda açıklandığı gibi) kullanılmayan uygulamalara ait .odex dosyaları kaldırılır. Bu da her .odex dosyasının iki kopyasının olmadığı başka bir durumdur.
En kötü durumda, /data tamamen dolduğunda güncelleme, cihaz yeni sisteme yeniden başlatılana ve artık eski sistemin .odex dosyalarına ihtiyaç duyulmayana kadar bekler. Bu işlem, PackageManager tarafından gerçekleştirilir: (frameworks/base/+/android16-qpr1-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215). Yeni sistem başarıyla başlatıldıktan sonra installd (frameworks/native/+/android16-qpr1-release/cmds/installd/dexopt.cpp#2422), eski sistem tarafından kullanılan .odex dosyalarını kaldırarak cihazı yalnızca bir kopyanın bulunduğu kararlı duruma geri döndürebilir.
Bu nedenle, /data'da tüm .odex dosyalarının iki kopyası bulunması mümkün olsa da (a) bu durum geçicidir ve (b) yalnızca /data'da zaten bol miktarda boş alanınız varsa meydana gelir. Güncelleme sırasında hariç olmak üzere, yalnızca bir kopya vardır. Ayrıca, ART'nin genel sağlamlık özelliklerinin bir parçası olarak, /data'yı hiçbir zaman .odex dosyalarıyla doldurmaz (çünkü bu, A/B olmayan bir sistemde de sorun olur).
Bu kadar çok yazma/kopyalama işlemi, flash yıpranmasını artırmaz mı?
Yalnızca küçük bir bölümü yeniden yazılır: Tam bir Pixel sistem güncellemesi yaklaşık 2,3 GiB yazar. (Uygulamalar da yeniden derlenir ancak bu, A/B olmayan uygulamalar için de geçerlidir.) Geleneksel olarak, blok tabanlı tam OTA'lar benzer miktarda veri yazıyordu. Bu nedenle, flash yıpranma oranları da benzer olmalıdır.
İki sistem bölümünün yanıp sönmesi, fabrika yanıp sönme süresini artırır mı?
Hayır. Pixel'in sistem görüntüsü boyutu artmadı (yalnızca alanı iki bölüme ayırdı).
B'de .odex dosyalarını tutmak, fabrika verilerine sıfırlamadan sonra yeniden başlatmayı yavaşlatır mı?
Evet. Bir cihazı gerçekten kullandıysanız, OTA aldıysanız ve fabrika verilerine sıfırlama işlemi gerçekleştirdiyseniz ilk yeniden başlatma, aksi takdirde olacağından daha yavaş olur (Pixel XL'de 40 saniye yerine 1 dakika 40 saniye). Bunun nedeni, ilk OTA'dan sonra .odex dosyalarının B'den kaybolması ve bu nedenle /data'ya kopyalanamamasıdır. İşin sırrı bu.
Fabrika verilerine sıfırlama işlemi, normal başlatma işlemine kıyasla daha nadir gerçekleştirilir. Bu nedenle, bu işlemin ne kadar sürdüğü daha az önemlidir. (Bu durum, cihazlarını fabrikadan alan kullanıcıları veya yorumcuları etkilemez. Çünkü bu durumda B bölümü kullanılabilir.) JIT derleyicisinin kullanılması, her şeyi yeniden derlememiz gerekmediği anlamına gelir. Bu nedenle, düşündüğünüz kadar kötü değildir. Ayrıca, manifest dosyasında coreApp="true" kullanarak uygulamaları önceden derleme gerektirecek şekilde işaretlemek de mümkündür: (frameworks/base/+/android16-qpr1-release/packages/SystemUI/AndroidManifest.xml#23). Bu özellik, güvenlik nedeniyle JIT'ye izin verilmediği için şu anda system_server tarafından kullanılmaktadır.
.odex dosyalarını /system yerine /data'da tutmak, OTA'dan sonra yeniden başlatmayı yavaşlatmaz mı?
Hayır. Yukarıda açıklandığı gibi, yeni sistemin ihtiyaç duyacağı dosyaları oluşturmak için eski sistem görüntüsü çalışmaya devam ederken yeni dex2oat çalıştırılır. Bu çalışma yapılana kadar güncelleme kullanıma sunulmuş sayılmaz.
32 GiB A/B cihazı gönderebilir miyiz? 16GiB? 8GiB?
Pixel'de kanıtlandığı üzere 32 GiB iyi çalışır. 16 GiB'in 320 MiB'i %2'lik bir azalma anlamına gelir. Benzer şekilde, 8 GiB'den 320 MiB'lik bir azalma %4'tür. 320 MiB'lik ek yük, toplam kullanılabilir alanın neredeyse% 10'u olduğundan 4 GiB'lik cihazlarda A/B'nin önerilen seçenek olmadığı açıktır.
AVB2.0, A/B OTA'ları gerektirir mi?
Hayır. Android Doğrulanmış Başlatma her zaman blok tabanlı güncellemeler gerektirmiştir ancak A/B güncellemeleri zorunlu değildir.
A/B OTA'lar için AVB2.0 gerekli mi?
Hayır.
A/B OTA'lar, AVB2.0'ın geri alma korumasını bozar mı?
Hayır. Bir A/B sistemi yeni sistem görüntüsüne önyükleme yapamazsa (önyükleyiciniz tarafından belirlenen belirli sayıda yeniden denemeden sonra) otomatik olarak "önceki" sistem görüntüsüne geri döneceğinden bu konuda bir karışıklık var. Ancak buradaki önemli nokta, A/B anlamında "önceki"nin aslında hâlâ "mevcut" sistem görüntüsü olmasıdır. Cihaz yeni bir görüntüyü başarıyla başlattığı anda geri alma koruması devreye girer ve geri dönmenizi engeller. Ancak yeni görüntüyü başarıyla başlatana kadar geri alma koruması, bu görüntüyü mevcut sistem görüntüsü olarak kabul etmez.
Sistem çalışırken güncelleme yüklemek yavaş olmaz mı?
A/B olmayan güncellemelerde amaç, güncelleme uygulanırken kullanıcının beklediği ve cihazını kullanamadığı için güncellemeyi mümkün olduğunca hızlı bir şekilde yüklemektir. A/B güncellemelerinde ise durum tam tersidir. Kullanıcı cihazını kullanmaya devam ettiğinden, güncellemenin mümkün olduğunca az etki yaratması amaçlanır. Bu nedenle güncelleme kasıtlı olarak yavaş ilerler. Java sistem güncelleme istemcisindeki mantık aracılığıyla (Google için GMS tarafından sağlanan temel paket olan GmsCore) Android, kullanıcıların cihazlarını hiç kullanmadığı bir zamanı da seçmeye çalışır. Platform, güncellemenin duraklatılmasını/devam ettirilmesini destekler. Kullanıcı cihazı kullanmaya başladığında istemci, güncellemeyi duraklatmak ve cihaz tekrar boşta kaldığında devam ettirmek için bu özelliği kullanabilir.
OTA sırasında iki aşama vardır. Bunlar, kullanıcı arayüzünde ilerleme çubuğunun altında Adım 1/2 ve Adım 2/2 olarak açıkça gösterilir. 1. adım, veri bloklarının yazılmasına karşılık gelirken 2. adım, .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 işlem, yalnızca blokları yavaşça kopyaladığından kaynak (RAM, CPU, G/Ç) açısından çok az şey gerektirir.
İkinci aşamada, yeni sistem görüntüsünü önceden derlemek için dex2oat çalıştırılır. Bu, gerçek uygulamaları derlediği için gereksinimleri açısından daha az net sınırlara sahiptir. Ayrıca, büyük ve karmaşık bir uygulamayı derlemek için küçük ve basit bir uygulamayı derlemeye kıyasla çok daha fazla çalışma gerekir. 1. aşamada ise diğerlerinden daha büyük veya daha karmaşık disk blokları yoktur.
Bu işlem, Google Play'in 5 uygulama güncellendi bildirimini göstermeden önce uygulama güncellemelerini arka planda yüklediği işleme benzer. Bu işlem yıllardır uygulanmaktadır.
Kullanıcı gerçekten güncellemeyi bekliyorsa ne olur?
GmsCore'daki mevcut uygulama, arka plan güncellemeleri ile kullanıcı tarafından başlatılan güncellemeler arasında ayrım yapmaz ancak gelecekte bu ayrımı yapabilir. Kullanıcının güncellemeyi yüklemesini açıkça istediği veya güncelleme ilerleme ekranını izlediği durumlarda, kullanıcının güncellemenin tamamlanmasını aktif olarak beklediği varsayımıyla güncelleme çalışmasına öncelik verilir.
Güncelleme uygulanamazsa ne olur?
A/B olmayan güncellemelerde, bir güncelleme uygulanamazsa kullanıcı genellikle kullanılamayan bir cihazla karşılaşırdı. Tek istisna, hatanın bir uygulama başlatılmadan önce meydana gelmesiydi (örneğin, paket doğrulanamadığı için). A/B güncellemelerinde, bir güncellemenin uygulanamaması şu anda çalışan sistemi etkilemez. Güncelleme daha sonra tekrar denenebilir.