OTA Boyutunu Azaltma

Bu sayfa, yapılar arasında gereksiz dosya değişikliklerini azaltmak için AOSP'ye eklenen değişiklikleri açıklar. Kendi derleme sistemlerini sürdüren cihaz uygulayıcıları, bu bilgileri kablosuz (OTA) güncellemelerinin boyutunu küçültmek için bir kılavuz olarak kullanabilir.

Android OTA güncellemeleri bazen kod değişikliklerine karşılık gelmeyen değiştirilmiş dosyalar içerir. Aslında sistem yapıları oluşturuyorlar. Bu, farklı zamanlarda, farklı dizinlerden veya farklı makinelerde oluşturulan aynı kod çok sayıda değiştirilmiş dosya oluşturduğunda meydana gelebilir. Bu tür fazla dosyalar bir OTA yamasının boyutunu artırır ve hangi kodun değiştiğini belirlemeyi zorlaştırır.

Bir OTA'nın içeriğini daha şeffaf hale getirmek için, AOSP, OTA yamalarının boyutunu küçültmek için tasarlanmış derleme sistemi değişiklikleri içerir. Derlemeler arasındaki gereksiz dosya değişiklikleri ortadan kaldırıldı ve OTA güncellemelerinde yalnızca yama ile ilgili dosyalar yer alıyor. AOSP ayrıca, daha temiz bir derleme dosyası farkı sağlamak için derlemeyle ilgili yaygın dosya değişikliklerini filtreleyen bir derleme diff aracı ve blok tahsisini tutarlı tutmanıza yardımcı olan bir blok eşleme aracı içerir.

Bir yapı sistemi, çeşitli şekillerde gereksiz yere büyük yamalar oluşturabilir. Bunu azaltmak için, Android 8.0 ve sonraki sürümlerde, her dosya farkının yama boyutunu azaltmak için yeni özellikler uygulandı. OTA güncelleme paketi boyutlarını azaltan iyileştirmeler şunları içerir:

  • A / B olmayan cihaz güncellemelerinde tam görüntüler için genel amaçlı, kayıpsız sıkıştırma algoritması olan Brotli'nin kullanımı. Brotli , sıkıştırmayı optimize etmek için özelleştirilebilir. Dosya sistemindeki iki veya daha fazla bloktan (örneğin system.img ) oluşan daha büyük güncellemelerde, cihaz üreticileri veya ortakları kendi sıkıştırma algoritmalarını ekleyebilir ve aynı güncellemenin farklı bloklarında farklı sıkıştırma algoritmaları kullanabilir.
  • A / B OTA güncelleme üretimi için sıkıştırma ve fark işlevlerini işleyen, söndürme akışları için belirleyici bir yama aracı olan Puffin yeniden sıkıştırmanın kullanımı.
  • bsdiff kitaplığının yamaları sıkıştırmak için nasıl kullanıldığı gibi delta oluşturma araç kullanımındaki değişiklikler. Android 9 ve sonraki sürümlerde, bsdiff aracı, bir yama için en iyi sıkıştırma sonuçlarını verecek sıkıştırma algoritmasını seçer.
  • update_engine iyileştirmeler, A / B cihaz güncellemeleri için yamalar uygulandığında daha az bellek tüketilmesine neden oldu.
  • Blok tabanlı OTA güncellemeleri için büyük zip dosyalarını bölmeye yönelik iyileştirmeler. imgdiff bir mod, giriş adlarına göre büyük boyutlu APK dosyalarını böler. Bu, dosyaları doğrusal olarak bölmeye ve bunları sıkıştırmak için bsdiff aracını kullanmaya kıyasla daha küçük bir yama oluşturur.

Aşağıdaki bölümler, OTA güncelleme boyutlarını etkileyen çeşitli sorunları, bunların çözümlerini ve AOSP'deki uygulama örneklerini tartışmaktadır.

Dosya sırası

Sorun : Dosya sistemleri, bir dizindeki dosyaların bir listesi istendiğinde dosya sırasını garanti etmez, ancak genellikle aynı teslim alma işlemi için aynıdır. ls gibi araçlar sonuçları varsayılan olarak ls , ancak find ve make gibi komutlar tarafından kullanılan joker karakter işlevi sıralama yapmaz. Bu araçları kullanmadan önce çıktıları sıralamanız gerekir.

Çözüm: Aşağıdaki gibi araçları kullanırken find ve make joker işlevi, bunları kullanmadan önce bu komutların sıralama çıkışı ile. Android.mk dosyalarında $(wildcard) veya $(shell find) Android.mk , bunları da sıralayın. Java gibi bazı araçlar girdileri sıralar, bu nedenle dosyaları sıralamadan önce, kullandığınız aracın henüz bunu yapmadığını doğrulayın.

Örnekler: Birçok örnek, all-cpp-files-under içeren yerleşik all-*-files-under makrosu kullanılarak çekirdek yapı sisteminde düzeltildi (birkaç tanım diğer makefile all-cpp-files-under yayıldığı için). Ayrıntılar için aşağıdakilere bakın:

Derleme dizini

Sorun: Şeylerin oluşturulduğu dizini değiştirmek, ikili dosyaların farklı olmasına neden olabilir. Android derlemesindeki çoğu yol göreceli yollardır, bu nedenle C / C ++ 'da __FILE__ bir sorun değildir. Bununla birlikte, hata ayıklama sembolleri varsayılan olarak tam yol adını kodlar ve .note.gnu.build-id , önceden ayrılmış ikili .note.gnu.build-id hashing uygulanmasından üretilir, bu nedenle hata ayıklama sembolleri değişirse değişir.

Çözüm: AOSP artık hata ayıklama yollarını göreceli hale getiriyor. Ayrıntılar için CL'ye bakın: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02 .

Zaman damgaları

Sorun: Derleme çıktısındaki zaman damgaları, gereksiz dosya değişikliklerine neden oluyor. Bunun aşağıdaki konumlarda gerçekleşmesi muhtemeldir:

  • __DATE__/__TIME__/__TIMESTAMP__ makroları C veya C ++ kodunda.
  • Zip tabanlı arşivlere gömülü zaman damgaları.

Çözümler / Örnekler: Derleme çıktısından zaman damgalarını kaldırmak için, aşağıda C / C ++ 'da __DATE __ / __ TIME __ / __ TIMESTAMP__ içinde verilen talimatları kullanın . ve Arşivlere gömülü zaman damgaları .

__DATE __ / __ TIME __ / __ TIMESTAMP__ in C / C ++

Bu makrolar her zaman farklı yapılar için farklı çıktılar üretir, bu yüzden bunları kullanmayın. İşte bu makroları ortadan kaldırmak için birkaç seçenek:

Arşivlere gömülü zaman damgaları (zip, jar)

Android 7.0, zip komutunun tüm kullanımlarına -X ekleyerek zip arşivlerine gömülü zaman damgaları sorununu çözdü. Bu, oluşturucunun UID / GID'sini ve uzatılmış Unix zaman damgasını zip dosyasından kaldırdı.

Yeni bir araç olan ziptime ( /platform/build/+/master/tools/ziptime/ ) zip başlıklarındaki normal zaman damgalarını sıfırlar. Ayrıntılar için BENİOKU dosyasına bakın.

signapk aracı, sunucunun saat dilimine bağlı olarak değişebilen APK dosyaları için zaman damgaları ayarlar. Ayrıntılar için CL https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028 sayfasına bakın.

Sürüm dizeleri

Sorun: APK sürüm dizelerinde genellikle kodlanmış sürümlerine BUILD_NUMBER . Bir APK'de başka hiçbir şey değişmemiş olsa bile, sonuç olarak APK yine de farklı olacaktır.

Çözüm: Derleme numarasını APK sürüm dizesinden kaldırın.

Çözüm: Derleme numarasını APK sürüm dizesinden kaldırın.

Örnekler:

Cihaz üzerinde doğruluk hesaplamasını etkinleştirin

Cihazınızda dm-verity etkinleştirildiyse, OTA araçları otomatik olarak gerçek yapılandırmanızı alır ve cihaz üzerinde doğruluk hesaplamasını etkinleştirir. Bu, OTA paketinizde ham bayt olarak depolanmak yerine, gerçek blokların android cihazlarda hesaplanmasını sağlar. Verity blokları, 2GB'lık bir bölüm için yaklaşık 16MB kullanabilir.

Ancak, cihazda gerçekliğin hesaplanması uzun zaman alabilir. Özellikle, İletilen Hata düzeltme kodu uzun sürebilir. Piksel cihazlarda 10 dakikaya kadar sürebilir. Düşük kaliteli cihazlarda daha uzun sürebilir. Cihaz üzerinde doğruluk hesaplamasını devre dışı bırakmak, ancak yine de dm- ota_from_target_files etkinleştirmek istiyorsanız, bir OTA güncellemesi oluştururken ota_from_target_files aracına --disable_fec_computation ileterek bunu yapabilirsiniz. Bu bayrak, OTA güncellemeleri sırasında cihaz üzerinde doğruluk hesaplamasını devre dışı bırakır. OTA kurulum süresini azaltır, ancak OTA paket boyutunu artırır. Cihazınızda dm-verity etkin değilse, bu bayrağı geçirmenin bir etkisi yoktur.

Tutarlı derleme araçları

Sorun: Yüklü dosyaları oluşturan araçlar tutarlı olmalıdır (belirli bir girdi her zaman aynı çıktıyı üretmelidir).

Çözümler / Örnekler: Aşağıdaki derleme araçlarında değişiklik yapılması gerekiyordu:

Derleme fark aracını kullanma

target_files_diff.py ilgili dosya değişikliklerini ortadan kaldırmanın mümkün olmadığı durumlarda, AOSP, iki dosya paketini karşılaştırmada kullanılmak üzere bir derleme diff aracı olan target_files_diff.py içerir. Bu araç, iki derleme arasında yinelemeli bir fark gerçekleştirir, derlemeyle ilgili yaygın dosya değişiklikleri hariçtir.

  • Derleme çıktısında beklenen değişiklikler (örneğin, bir yapı numarası değişikliği nedeniyle).
  • Mevcut derleme sistemindeki bilinen sorunlardan kaynaklanan değişiklikler.

Derleme diff aracını kullanmak için aşağıdaki komutu çalıştırın:

target_files_diff.py dir1 dir2

dir1 ve dir2 , her derleme için ayıklanmış hedef dosyaları içeren temel dizinlerdir.

Blok tahsisini tutarlı tutmak

Belirli bir dosya için, içeriği iki yapı arasında aynı kalsa da, verileri tutan asıl bloklar değişmiş olabilir. Sonuç olarak, güncelleyicinin bir OTA güncellemesi için blokları hareket ettirmek için gereksiz G / Ç gerçekleştirmesi gerekir.

Bir Sanal A / B OTA güncellemesinde, gereksiz G / Ç, yazma üzerine kopyalama anlık görüntüsünü depolamak için gereken depolama alanını büyük ölçüde artırabilir. A / B olmayan bir OTA güncellemesinde, blok hareketleri nedeniyle daha fazla G / Ç olduğu için blokları bir OTA güncellemesi için hareket ettirmek güncelleme süresine katkıda bulunur.

Bu sorunu çözmek için, Android 7.0'da Google, make_ext4fs blok ayırmayı tutarlı tutmak için make_ext4fs aracını genişletti. make_ext4fs aracı, bir ext4 görüntüsü oluştururken dosyaları aynı bloklara tahsis etmeye çalışan isteğe bağlı bir -d base_fs bayrağını kabul eder. Blok eşleme dosyalarını ( base_fs eşleme dosyaları gibi) önceki yapının hedef dosyalarının zip dosyasından çıkarabilirsiniz. Her ext4 bölümü için, IMAGES dizininde bir .map dosyası vardır (örneğin, IMAGES/system.map system bölümüne karşılık gelir). Bu base_fs dosyaları daha sonra bu örnekte olduğu gibi PRODUCT_<partition>_BASE_FS_PATH aracılığıyla iade edilebilir ve belirtilebilir:

  PRODUCT_SYSTEM_BASE_FS_PATH := path/to/base_fs_files/base_system.map
  PRODUCT_SYSTEM_EXT_BASE_FS_PATH := path/to/base_fs_files/base_system_ext.map
  PRODUCT_VENDOR_BASE_FS_PATH := path/to/base_fs_files/base_vendor.map
  PRODUCT_PRODUCT_BASE_FS_PATH := path/to/base_fs_files/base_product.map
  PRODUCT_ODM_BASE_FS_PATH := path/to/base_fs_files/base_odm.map

Bu, genel OTA paket boyutunu azaltmaya yardımcı olmamakla birlikte, G / Ç miktarını azaltarak OTA güncelleme performansını iyileştirir. Sanal A / B güncellemeleri için, OTA'yı uygulamak için gereken depolama alanı miktarını önemli ölçüde azaltır.

Uygulamaları güncellemekten kaçının

Derleme farklılıklarını en aza indirmenin yanı sıra, uygulama mağazalarından güncelleme alan uygulamalar için güncellemeleri hariç tutarak OTA güncelleme boyutlarını azaltabilirsiniz. APK'ler genellikle bir cihazdaki çeşitli bölümlerin önemli bir bölümünü içerir. Bir OTA güncellemesinde uygulama mağazaları tarafından güncellenen uygulamaların en son sürümlerinin dahil edilmesi, OTA paketleri üzerinde büyük bir etkiye sahip olabilir ve çok az kullanıcı yararı sağlayabilir. Kullanıcılar bir OTA paketi aldıklarında, doğrudan uygulama mağazalarından alınan güncellenmiş uygulamaya veya daha yeni bir sürüme zaten sahip olabilirler.