OTA boyutunu azaltın

Bu sayfada, derlemeler arasındaki gereksiz dosya değişikliklerini azaltmak için AOSP'ye eklenen değişiklikler açıklanmaktadır. Kendi derleme sistemlerini sürdüren cihaz uygulayıcıları, bu bilgileri kablosuz (OTA) güncellemelerinin boyutunu azaltmak için bir kılavuz olarak kullanabilir.

Android OTA güncellemeleri zaman zaman kod değişikliklerine karşılık gelmeyen değiştirilmiş dosyalar içerir. Aslında sistem eserleri oluşturuyorlar. Bu, farklı zamanlarda, farklı dizinlerden veya farklı makinelerde oluşturulan aynı kodun çok sayıda değiştirilmiş dosya üretmesi durumunda ortaya çıkabilir. Bu tür fazla dosyalar OTA yamasının boyutunu artırı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 küçültecek şekilde tasarlanmış yapı sistemi değişiklikleri içerir. Derlemeler arasındaki gereksiz dosya değişiklikleri ortadan kaldırıldı ve OTA güncellemelerinde yalnızca yamayla ilgili dosyalar yer alıyor. AOSP ayrıca, daha temiz bir derleme dosyası diff 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 derecede büyük yamalar oluşturabilir. Bunu hafifletmek için Android 8.0 ve sonraki sürümlerde, her dosya farklılığının yama boyutunu küçültecek yeni özellikler uygulandı. OTA güncelleme paketi boyutlarını azaltan iyileştirmeler arasında şunlar yer alıyor:

  • 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 edecek şekilde özelleştirilebilir. Dosya sistemindeki 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 oluşturma için sıkıştırma ve fark işlevlerini yöneten, akışları söndürmeye yönelik deterministik bir yama aracı olan Puffin yeniden sıkıştırmanın kullanımı.
  • Delta oluşturma aracının kullanımında yapılan değişiklikler (ör. yamaları sıkıştırmak için bsdiff kitaplığının nasıl kullanıldığı). 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 yapılan iyileştirmeler, A/B cihazı güncellemeleri için yamalar uygulandığında daha az bellek tüketilmesine neden oldu.
  • Büyük zip dosyalarının blok tabanlı OTA güncellemeleri için bölünmesine 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ı etkileyen çeşitli sorunlar, bunların çözümleri ve AOSP'deki uygulama örnekleri tartışılmaktadır.

Dosya sırası

Sorun : Dosya sistemleri, bir dizindeki dosyaların listesi istendiğinde dosya sırasını garanti etmez, ancak bu genellikle aynı ödeme için aynıdır. ls gibi araçlar sonuçları varsayılan olarak sıralar ancak find ve make gibi komutların kullandığı 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 fonksiyonuyla kullandığınızda, kullanmadan önce bu komutların çı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 bunu henüz yapmadığını doğrulayın.

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

Dizin oluştur

Sorun: Nesnelerin oluşturulduğu dizini değiştirmek, ikili dosyaların farklı olmasına neden olabilir. Android yapısındaki yolların çoğu göreceli yollardır, dolayısıyla C/C++'daki __FILE__ sorun değildir. Bununla birlikte, hata ayıklama sembolleri varsayılan olarak tam yol adını kodlar ve .note.gnu.build-id önceden ayrıştırılmış ikili dosyanın hashlenmesinden oluşturulur, dolayısıyla hata ayıklama sembolleri değişirse değişecektir.

Çö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:

  • C veya C++ kodundaki __DATE__/__TIME__/__TIMESTAMP__ makroları.
  • Zip tabanlı arşivlere yerleştirilmiş zaman damgaları.

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

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

Bu makrolar her zaman farklı yapılar için farklı çıktılar üretir; bu nedenle bunları kullanmayın. Bu makroları ortadan kaldırmak için birkaç seçenek şunlardır:

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/+/main/tools/ziptime/ konumunda bulunur), zip başlıklarındaki normal zaman damgalarını sıfırlar. Ayrıntılar için README dosyasına bakın.

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

Sürüm dizeleri

Sorun: APK sürüm dizelerinin sabit kodlanmış sürümlerine genellikle BUILD_NUMBER eklendi. APK'da başka hiçbir şey değişmese bile sonuç olarak APK yine de farklı olacaktır.

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

Örnekler:

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

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

Ancak cihaz üzerinde bilgi işlem doğruluğu uzun zaman alabilir. Özellikle, İletim Hatası düzeltme kodunun işlenmesi uzun zaman alabilir. Piksel cihazlarda bu işlem genellikle 10 dakika kadar sürer. Düşük kaliteli cihazlarda bu süre daha uzun olabilir. Cihaz içi doğrulama hesaplamasını devre dışı bırakmak ancak yine de dm-verity'yi etkinleştirmek istiyorsanız, bunu bir OTA güncellemesi oluştururken --disable_fec_computation ota_from_target_files aracına ileterek yapabilirsiniz. Bu işaret, OTA güncellemeleri sırasında cihazdaki 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 hiçbir etkisi olmaz.

Tutarlı oluşturma araçları

Sorun: Yüklü dosyaları oluşturan araçların tutarlı olması gerekir (belirli bir giriş 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ı kullanın

Yapıyla 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 target_files_diff.py bir derleme diff aracı içerir. Bu araç, aşağıdakiler gibi derlemeyle ilgili yaygın dosya değişiklikleri hariç olmak üzere, iki yapı arasında özyinelemeli bir fark gerçekleştirir.

  • Yapı çı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.

Build diff 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 çıkarılan hedef dosyaları içeren temel dizinlerdir.

Blok tahsisini tutarlı tutun

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üncelleyicinin, OTA güncellemesi için blokları hareket ettirmek amacıyla gereksiz G/Ç yapması gerekir.

Sanal A/B OTA güncellemesinde, gereksiz G/Ç, yazarken kopyalanan anlık görüntüyü depolamak için gereken depolama alanını büyük ölçüde artırabilir. A/B olmayan bir OTA güncellemesinde, OTA güncellemesi için blokların taşınması, blok hareketleri nedeniyle daha fazla G/Ç olacağından güncelleme süresine katkıda bulunur.

Bu sorunu çözmek için Android 7.0'da Google, blok tahsisinin yapılar arasında tutarlı olmasını sağlamak amacıyla make_ext4fs aracını genişletti. make_ext4fs aracı, bir ext4 görüntüsü oluştururken dosyaları aynı bloklara ayırmaya çalışan isteğe bağlı -d base_fs bayrağını kabul eder. Blok eşleme dosyalarını ( base_fs eşleme dosyaları gibi) önceki bir yapının hedef dosyalarının zip dosyasından çıkarabilirsiniz. Her ext4 bölümü için IMAGES dizininde bir .map dosyası bulunur (ö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 teslim 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 paketi boyutunun azaltılmasına 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ı aracılığıyla güncelleme alan uygulamaların güncellemelerini hariç tutarak OTA güncelleme boyutlarını da azaltabilirsiniz. APK'lar genellikle bir cihazdaki çeşitli bölümlerin önemli bir bölümünü oluşturur. Uygulama mağazaları tarafından güncellenen uygulamaların en son sürümlerinin bir OTA güncellemesine dahil edilmesi, OTA paketleri üzerinde büyük boyutta bir etkiye sahip olabilir ve kullanıcıya çok az fayda sağlayabilir. Kullanıcılar bir OTA paketi aldıklarında, doğrudan uygulama mağazalarından alınmış güncellenmiş uygulamaya veya daha yeni bir sürüme zaten sahip olabilirler.