OTA Boyutunu Küçültme

Bu sayfada, derlemeler arasındaki gereksiz dosya değişikliklerini azaltmak için AOSP'ye eklenen değişiklikler açıklanmaktadır. Kendi yapı sistemlerini koruyan cihaz uygulayıcıları, bu bilgiyi 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ıtları oluşturuyorlar. Bu, farklı zamanlarda, farklı dizinlerden veya farklı makinelerde oluşturulan aynı kod çok sayıda değiştirilmiş dosya ürettiğinde ortaya çıkabilir. Bu tür fazla dosyalar bir OTA yamasının boyutunu büyütür ve hangi kodun değiştirildiğ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 azaltmak için tasarlanmış yapı sistemi değişiklikleri içerir. Yapılar arasındaki gereksiz dosya değişiklikleri ortadan kaldırıldı ve OTA güncellemelerinde yalnızca yama ile ilgili dosyalar yer aldı. AOSP ayrıca, daha temiz bir derleme dosyası farkı sağlamak için yapıyla ilgili yaygın dosya değişikliklerini filtreleyen bir yapı fark aracı ve blok tahsisini tutarlı tutmanıza yardımcı olan bir blok eşleme aracı içerir.

Bir derleme 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 bir dosya farklılığı için yama boyutunu azaltan 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 bir sıkıştırma algoritması olan Brotli'nin kullanımı. Brotli, sıkıştırmayı optimize etmek için özelleştirilebilir. Dosya sisteminde iki veya daha fazla bloktan oluşan daha büyük güncellemelerde (örneğin, system.img ), cihaz üreticileri veya iş 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 fonksiyonlarını işleyen, indirme akışları için belirleyici bir yama aracı olan Puffin yeniden sıkıştırmanın kullanımı.
  • Yamaları sıkıştırmak için bsdiff kitaplığının nasıl kullanıldığı gibi delta oluşturma aracı 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 kullanılmasıyla sonuçlandı.
  • Blok tabanlı OTA güncellemeleri için büyük zip dosyalarını bölmeye yönelik iyileştirmeler. imgdiff bir mod, büyük boyutlu APK dosyalarını giriş adlarına göre 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ümlerde, OTA güncelleme boyutlarını, çözümlerini ve AOSP'deki uygulama örneklerini etkileyen çeşitli sorunlar tartışılmaktadır.

dosya sırası

Sorun : Dosya sistemleri, bir dizindeki dosyaların listesi sorulduğunda bir dosya sırasını garanti etmez, ancak genellikle aynı kullanıma alma için aynıdır. ls gibi araçlar sonuçları varsayılan olarak sıralar, 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 : find ve make gibi araçları joker karakter işleviyle kullandığınızda, bu komutları kullanmadan önce çıktılarını sıralayın. Android.mk dosyalarında $(wildcard) veya $(shell find) kullanırken bunları da sıralayın. Java gibi bazı araçlar girdileri sıralar, bu nedenle dosyaları sıralamadan önce kullandığınız aracın daha önce sıralama yapmadığını doğrulayın.

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

Derleme dizini

Sorun: Nesnelerin oluşturulduğu dizini değiştirmek, ikili dosyaların farklı olmasına neden olabilir. Android derlemesindeki yolların çoğu göreli yollardır, bu nedenle C/C++'da __FILE__ sorun değildir. Bununla birlikte, hata ayıklama sembolleri varsayılan olarak tam yol adını kodlar ve .note.gnu.build-id önceden soyulmuş ikili dosyanın hashlenmesinden üretilir, bu nedenle hata ayıklama sembolleri değişirse değişecektir.

Çözüm: AOSP artık hata ayıklama yollarını göreli 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 olması muhtemeldir:

  • C veya C++ kodunda __DATE__/__TIME__/__TIMESTAMP__ makroları.
  • 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 yönergeleri kullanın. ve Arşivlere katıştırılmış zaman damgaları .

C/C++'da __DATE__/__TIME__/__TIMESTAMP__

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şivlerindeki gömülü zaman damgaları sorununu çözdü. Bu, oluşturucunun UID/GID'sini ve genişletilmiş Unix zaman damgasını zip dosyasından kaldırdı.

Yeni bir araç olan ziptime ( /platform/build/+/master/tools/ziptime/ konumunda bulunur), 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'ye bakın https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028 .

Sürüm dizeleri

Sorun: APK sürüm dizelerinde genellikle sabit kodlu sürümlerine BUILD_NUMBER eklenir. Sonuç olarak APK'da başka hiçbir şey değişmese bile APK yine de farklı olacaktır.

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

Örnekler:

Cihazda doğrulama hesaplamasını etkinleştir

Cihazınızda dm-verity etkinleştirilmişse, OTA araçları otomatik olarak verity yapılandırmanızı alır ve cihaz üzerinde verity hesaplamasını etkinleştirir. Bu, verity bloklarının OTA paketinizde ham bayt olarak saklanmak yerine android cihazlarda hesaplanmasına izin verir. Verity blokları, 2 GB'lık bir bölüm için yaklaşık 16 MB kullanabilir.

Ancak, cihazda gerçekliğin hesaplanması uzun zaman alabilir. Özellikle, İletim Hatası düzeltme kodu uzun sürebilir. Piksel cihazlarda, 10 dakikaya kadar sürebilir. Düşük kaliteli cihazlarda daha uzun sürebilir. Cihazdaki verity hesaplamasını devre dışı bırakmak, ancak yine de dm-verity'yi etkinleştirmek istiyorsanız, bir OTA güncellemesi oluştururken --disable_fec_computation ota_from_target_files aracına ileterek bunu yapabilirsiniz. Bu işaret, OTA güncellemeleri sırasında cihazda veri doğrulama 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 olmaz.

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 oluşturma araçlarında değişiklik yapılması gerekiyordu:

Yapı farkı aracını kullanma

Yapıyla ilgili dosya değişikliklerini ortadan kaldırmanın mümkün olmadığı durumlarda, AOSP, iki dosya paketini karşılaştırmak için bir yapı fark aracı, target_files_diff.py içerir. Bu araç, derlemeyle ilgili yaygın dosya değişikliklerini hariç tutarak, iki derleme arasında özyinelemeli bir fark gerçekleştirir.

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

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

target_files_diff.py dir1 dir2

dir1 ve dir2 her yapı için ayıklanan 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 gerçek bloklar değişmiş olabilir. Sonuç olarak, güncelleyici blokları bir OTA güncellemesi için hareket ettirmek üzere gereksiz G/Ç gerçekleştirmelidir.

Bir Sanal A/B OTA güncellemesinde, gereksiz G/Ç, yazma üzerine kopya 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 hareketlerinden dolayı daha fazla G/Ç olduğundan, OTA güncellemesi için blokların hareket ettirilmesi güncelleme süresine katkıda bulunur.

Bu sorunu çözmek için, Android 7.0'da Google make_ext4fs aracını, blok tahsisini tüm yapılar arasında tutarlı tutmak için genişletti. make_ext4fs aracı, bir ext4 görüntüsü oluştururken dosyaları aynı bloklara ayırmaya çalışan isteğe bağlı bir -d base_fs işaretini kabul eder. Blok eşleme dosyalarını ( base_fs harita dosyaları gibi) önceki bir derlemenin 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 teslim edilebilir ve bu örnekte olduğu gibi PRODUCT_<partition>_BASE_FS_PATH aracılığıyla 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ı olmasa da, G/Ç miktarını azaltarak OTA güncelleme performansını artırır. Sanal A/B güncellemeleri için, OTA'yı uygulamak için gereken depolama alanı miktarını büyük ölçüde azaltır.

Uygulamaları güncellemekten kaçının

Derleme farkları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'lar genellikle bir cihazdaki çeşitli bölümlerin önemli bir bölümünü oluşturur. 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 boyut etkisine 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 güncellenmiş uygulamaya veya daha da yeni bir sürüme zaten sahip olabilirler.