Google, herhangi bir cihazda A/B OTA'ları kullandı mı?
Evet. A/B güncellemelerinin pazarlama adı seamless updates (seamless updates) olarak belirlenmiştir. Ekim 2016'dan itibaren A/B ile birlikte gönderilen Pixel ve Pixel XL telefonlar ve tüm Chromebook'lar aynı A/B uygulamasını kullanır.update_engine Gerekli platform kodu uygulaması, Android 7.1 ve sonraki sürümlerde herkese açıktır.
A/B OTA'lar neden daha iyi?
A/B OTA'lar, güncelleme alı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 kullanıcılarının% 95'i, Nexus kullanıcılarının% 87'sine kıyasla bir ay sonra en son güvenlik güncellemesini kullanıyor ve Pixel kullanıcıları, Nexus kullanıcılarına kıyasla güncellemeleri daha erken alıyor. OTA sırasında blokların güncellenememesi artık cihazın başlatılamamasına neden olmaz. Yeni sistem resmi başarıyla başlatılana kadar Android, önceki çalışan sistem resmine geri dönme özelliğini korur.
system_other nedir?
Uygulamalar, aslında ZIP arşivleri olan .apk dosyalarında depolanı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, uygulama her başlatıldığında kodun derlenmesini beklemek zorunda kalmadan uygulamaları önceden derlenmiş hızlarda çalıştırabilir. .odex dosyası kesinlikle gerekli değildir: Android, .dex kodunu doğrudan yorumlama veya Tam Zamanında (JIT) derleme yoluyla çalıştırabilir ancak alan varsa .odex dosyası, başlatma hızı ile çalışma hızı arasında en iyi kombinasyonu sağlar.
Örnek: Android 7.1 çalıştıran ve toplam sistem görüntüsü boyutu 2.628 MiB (2.755.792.836 bayt) olan bir Nexus 6P'deki installed-files.txt dosyasında, toplam sistem görüntüsü boyutuna en fazla katkıda bulunan dosyaların dosya türüne göre 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 yerel ayar verileri | 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 edebilirdik ancak .odex dosyalarını fabrikada B bölümüne yazıp ilk açılışta /data'e kopyalayabilirdik. ext4 A/B ile kullanılan gerçek depolama alanı, SquashFS A/B ile kullanılan alanla aynıdır. Çünkü SquashFS kullansaydık önceden seçilen .odex dosyalarını system_b yerine system_a'ya gönderirdik.
.odex dosyalarının /data'ya kopyalanması, /system'de tasarruf edilen alanın /data'da kaybedileceği anlamına gelmez mi?
Pek değil. Pixel'de .odex dosyalarının kapladığı alanın çoğu, genellikle /data'te bulunan uygulamalara aittir. Bu uygulamalar Google Play güncellemelerini alır. Bu nedenle, sistem resmindeki .apk ve .odex dosyaları, cihazın kullanım ömrünün büyük bir kısmında kullanılmaz. Bu tür dosyalar, kullanıcı her uygulamayı gerçekten kullandığında tamamen hariç tutulabilir ve küçük, profile dayalı .odex dosyalarıyla değiştirilebilir (böylece kullanıcının kullanmadığı uygulamalar için yer gerekmez). Ayrıntılar için Google I/O 2016'daki Sanatın Evrimi konuşmasına bakın.
Karşılaştırmanın zor olmasının birkaç önemli nedeni vardır:
-
Google Play tarafından güncellenen uygulamaların .odex dosyaları, ilk güncellemeyi aldıktan sonra her zaman
/data'te bulunur. - Kullanıcının çalıştırmadığı uygulamalar için .odex dosyasına hiç gerek yoktur.
- Profil odaklı derleme, önceden derlemeye kıyasla daha küçük .odex dosyaları oluşturur (çünkü yalnızca performans açısından kritik kodu optimize eder).
OEM'lerin kullanabileceği ayar seçenekleri hakkında ayrıntılı bilgi için ART'ı yapılandırma başlıklı makaleyi inceleyin.
/data klasöründe .odex dosyalarının iki kopyası yok mu?
İş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ında çalıştırılır. Bu durum, eski sistem hâlâ çalışırken gerçekleşir. Bu nedenle, eski ve yeni .odex dosyaları aynı anda /data üzerinde bulunur.
OtaDexoptService (frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java) kodundaki kod, /data'nin aşırı doldurulmasını önlemek için her paketi optimize etmeden önce getAvailableSpace'yi çağırır. Buradaki kullanılabilir değerinin yine de muhafazakar olduğunu unutmayın: Bu değer, normal 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). Bu nedenle, /data doluysa her .odex dosyasının iki kopyası olmaz. Aynı kodda BULK_DELETE_THRESHOLD da vardır: Cihaz, kullanılabilir alanı doldurmaya yakın bir seviyeye gelirse (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'ün tamamen dolu olduğu en kötü durumda güncelleme, cihazın yeni sisteme yeniden başlatılıp eski sistemin .odex dosyalarına ihtiyaç duymayana kadar bekler. Bu işlemi PackageManager (frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215) yönetir. Yeni sistem başarıyla başlatıldıktan sonra installd (frameworks/native/+/main/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 döndürebilir.
Bu nedenle, /data'te tüm .odex dosyalarının iki kopyasının bulunması mümkündür ancak (a) bu durum geçicidir ve (b) yalnızca /data'te zaten çok fazla boş alanınız varsa gerçekleşir. Güncelleme sırasında hariç olmak üzere yalnızca bir kopya vardır. Ayrıca ART'ın genel sağlamlık özellikleri kapsamında, /data hiçbir zaman .odex dosyalarıyla doldurulmaz (çünkü bu, A/B dışı bir sistemde de sorun olur).
Tüm bu yazma/kopyalama işlemleri, flash'ın aşınmasını artırmıyor mu?
Flash'ın yalnızca küçük bir kısmı yeniden yazılır: Tam bir Pixel sistem güncellemesi yaklaşık 2,3 GB yazar. (Uygulamalar da yeniden derlenir ancak bu durum A/B olmayan sürümler için de geçerlidir.) Geleneksel olarak, blok tabanlı tam OTA'lar benzer miktarda veri yazıyordu. Bu nedenle, flash aşınma oranları da benzer olmalıdır.
İki sistem bölümünü flaşlamak fabrika flaşlama süresini artırır mı?
Hayır. Pixel'in sistem görüntü boyutu artmadı (sadece alanı iki bölüme ayırdı).
.odex dosyalarını B'de tutmak, fabrika verilerine sıfırlama işleminden sonra yeniden başlatmayı yavaşlatmaz mı?
Evet. Bir cihazı gerçekten kullandıysanız, OTA aldıysanız ve fabrika verilerini sıfırladıysanız ilk yeniden başlatma normalden daha yavaş olur (Pixel XL'de 1 dk. 40 sn. ve 40 sn.). Bunun nedeni, .odex dosyalarının ilk OTA'dan sonra B'den kaybolması ve /data'ye kopyalanamamasıdır. Bu bir takastır.
Fabrika verilerini sıfırlama işlemi, normal önyükleme işlemine kıyasla nadir bir işlem olduğundan, bu işlemin süresi daha az önemlidir. (Bu durum, cihazlarını fabrikadan alan kullanıcıları veya yorumcuları etkilemez. 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ü bir durum değildir. Uygulamaları, manifest dosyasında coreApp="true" kullanılarak önceden derleme gerektiren olarak da işaretleyebilirsiniz: (frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23). Güvenlik nedeniyle JIT'ye izin verilmediğinden bu yöntem şu anda system_server tarafından kullanılmaktadır.
.odex dosyalarını /system yerine /data üzerinde tutmak, OTA'dan sonra yeniden başlatmayı yavaşlatmaz mı?
Hayır. Yukarıda açıklandığı gibi, yeni sistem görüntüsünün hâlâ çalıştığı sırada yeni dex2oat çalıştırılarak yeni sistemin ihtiyaç duyacağı dosyalar oluşturulur. Bu çalışma tamamlanana kadar güncelleme kullanıma hazır kabul edilmez.
32 GB A/B cihaz gönderebilir miyiz (göndermeli miyiz)? 16GiB? 8GiB?
32 GB, Pixel'de kanıtlandığı gibi iyi çalışır ve 16 GB'tan 320 MB, %2'lik bir azalma anlamına gelir. Benzer şekilde, 8 GB'tan 320 MiB, %4'lük bir azalmadır. 320 MiB ek yük, kullanılabilir toplam alanın neredeyse% 10'unu oluşturduğundan, 4 GiB'lık cihazlarda A/B testinin önerilen seçenek olmadığı açıktır.
AVB2.0 için A/B OTA'lar gerekli mi?
Hayır. Android Doğrulanmış Önyükleme için her zaman blok tabanlı güncellemeler gerekir ancak bu güncellemeler A/B güncellemeleri olmayabilir.
A/B OTA'lar için AVB2.0 gerekli mi?
Hayır.
A/B OTA'lar AVB2.0'ın geri alma korumasını ihlal eder mi?
Hayır. Burada bir karışıklık var. Çünkü A/B sistemi yeni sistem görüntüsünde önyükleme yapamazsa (açılış yükleyiciniz tarafından belirlenen bir dizi yeniden deneme sonrasında) otomatik olarak "önceki" sistem görüntüsüne döner. Buradaki önemli nokta, A/B bağlamında "önceki"nin aslında hâlâ "mevcut" sistem görüntüsünün olmasıdır. Cihaz yeni bir görüntüyü başarıyla başlatır başlatmaz geri alma koruması devreye girer ve geri dönemezsiniz. 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ü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üncellemeyi mümkün olduğunca hızlı bir şekilde yüklemektir. A/B güncellemelerinde ise bunun tam tersi geçerlidir. Kullanıcı cihazını kullanmaya devam ettiğinden, mümkün olduğunca az etki sağlamak hedef olduğundan güncelleme kasıtlı olarak yavaştır. Android, Java sistem güncelleme istemcisinin (Google için GMS tarafından sağlanan temel paket olan GmsCore) mantığıyla, kullanıcıların cihazlarını hiç kullanmadığı bir zamanı seçmeye de çalışır. Platform, güncellemenin duraklatılmasını/devam ettirilmesini destekler. İstemci, kullanıcı cihazı kullanmaya başladığında güncellemeyi duraklatmak ve cihaz tekrar boşta olduğunda devam ettirmek için bu özelliği kullanabilir.
OTA'nın iki aşaması vardır. Bu aşamalar, 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ıyla, 2. adım ise .dex dosyalarının önceden derlenmesiyle ilgilidir. Bu iki aşama, performans üzerindeki etkisi açısından oldukça farklıdır. İlk aşama basit G/Ç'dir. Bu işlem, blokları yavaşça kopyaladığından çok az kaynak (RAM, CPU, G/Ç) gerektirir.
İkinci aşamada, yeni sistem resmini önceden derlemek için dex2oat çalıştırılır. Gerçek uygulamaları derlediği için bu sürümün koşulları daha net değildir. Ayrıca, büyük ve karmaşık bir uygulamayı derlemenin küçük ve basit bir uygulamayı derlemekten çok daha fazla iş gerektirdiği açıktır. Buna karşılık, 1. aşamada diğerlerinden daha büyük veya daha karmaşık disk blokları yoktur.
Bu süreç, Google Play'in yıllardır yaptığı gibi 5 uygulama güncellendi bildirimini göstermeden önce arka planda bir uygulama güncellemesi yüklemesine benzer.
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üncellemenin yüklenmesini açıkça istediği veya güncelleme ilerleme ekranını izlediği durumlarda, güncellemenin tamamlanmasını aktif olarak beklediği varsayılarak 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şı karşıya kalıyordu. Tek istisna, hatanın uygulama henüz başlatılmadan önce gerçekleşmesidir (ör. 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.