OTA boyutunu azaltma

Bu sayfada, derlemeler arasında gereksiz dosya değişikliklerini azaltmak için AOSP'ye eklenen değişiklikler açıklanmaktadır. Kendi derleme sistemlerini yöneten cihaz uygulayıcıları, kablosuz (OTA) güncellemelerinin boyutunu küçültmek için bu bilgileri 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ını oluştururlar. Bu durum, farklı zamanlarda, farklı dizinlerden veya farklı makinelerde oluşturulan aynı kod çok sayıda değiştirilmiş dosya oluşturduğunda ortaya çıkabilir. Bu tür fazladan dosyalar OTA yamasının boyutunu artırır ve hangi kodun değiştiğini belirlemeyi zorlaştırır.

AOSP, OTA'nın içeriğini daha şeffaf hale getirmek için OTA yamalarını küçültmek üzere tasarlanmış derleme sistemi değişiklikleri içerir. Derlemeler arasındaki gereksiz dosya değişiklikleri kaldırıldı ve OTA güncellemelerinde yalnızca düzeltmeyle ilgili dosyalar yer alıyor. AOSP ayrıca, daha temiz bir yapı dosyası karşılaştırması sunmak için yapıyla ilgili yaygın dosya değişikliklerini filtreleyen bir yapı karşılaştırma aracı ve blok tahsisini tutarlı tutmanıza yardımcı olan bir blok eşleme aracı içerir.

Derleme sistemi, çeşitli şekillerde gereksiz yere büyük yamalar oluşturabilir. Bu sorunu hafifletmek için Android 8.0 ve sonraki sürümlerde her dosya karşılaştırmasının yama boyutunu azaltmak amacıyla yeni özellikler uygulandı. OTA güncelleme paketi boyutlarını küçülten iyileştirmeler şunlardır:

  • A/B dışı cihaz güncellemelerinde tam resimler için genel amaçlı, kayıpsız sıkıştırma algoritması olan ZSTD'nin kullanımı. ZSTD, sıkıştırma düzeyini artırarak daha yüksek sıkıştırma oranları için özelleştirilebilir. Sıkıştırma seviyesi, OTA oluşturma sırasında belirlenir ve işareti iletilerek ayarlanabilir --vabc_compression_param=zstd,$COMPRESSION_LEVEL
  • OTA sırasında kullanılan sıkıştırma aralığı boyutunu artırma. Maksimum sıkıştırma aralığı boyutu, bir cihazın .mk dosyasında derleme parametresi özelleştirilerek ayarlanabilir. Bu değişken şu şekilde ayarlanır: PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 262144
  • A/B OTA güncellemesi oluşturma için sıkıştırma ve fark işlevlerini yöneten, deflate akışları için belirlenebilir bir yama aracı olan Puffin yeniden sıkıştırma aracının kullanılması.
  • Değişiklik oluşturma aracının kullanımında yapılan değişiklikler (ör. bsdiff kitaplığının yamalar için sıkıştırma işleminde nasıl kullanıldığı). Android 9 ve sonraki sürümlerde bsdiff aracı, bir yamada en iyi sıkıştırma sonuçlarını verecek sıkıştırma algoritmasını seçer.
  • update_engine ile ilgili iyileştirmeler, A/B cihaz güncellemeleri için yamalar uygulanırken daha az bellek tüketilmesine yol açtı.

Aşağıdaki bölümlerde, OTA güncelleme boyutlarını etkileyen çeşitli sorunlar, bunların çözümleri ve AOSP'de uygulama örnekleri ele alınmaktadır.

Dosya sırası

Sorun: Dosya sistemleri, bir dizindeki dosyaların listesi istendiğinde dosya sırasını garanti etmez. Ancak 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 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ın çıktısını kullanmadan önce sıralayın. Android.mk dosyalarında $(wildcard) veya $(shell find) kullanırken bunları da sıralayın. Java gibi bazı araçlar girişleri sıralar. Bu nedenle, dosyaları sıralamadan önce kullandığınız aracın bunu yapmadığını doğrulayın.

Örnekler: Temel derleme sisteminde birçok örnek, all-cpp-files-under içeren yerleşik all-*-files-under makrosu kullanılarak düzeltildi (çünkü birçok tanım diğer makefile'lere yayılmıştı). Ayrıntılı bilgi için aşağıdakilere bakın:

Derleme dizini

Sorun: Öğelerin derlendiği dizini değiştirmek, ikili programların farklı olmasına neden olabilir. Android derlemesindeki çoğu yol göreli yol olduğundan C/C++'da __FILE__ bir sorun değildir. Ancak hata ayıklama sembolleri varsayılan olarak tam yol adını kodlar ve .note.gnu.build-id, önceden soyulmuş ikili dosyanın karma oluşturma işlemiyle oluşturulur. Bu nedenle, hata ayıklama sembolleri değişirse .note.gnu.build-id de değişir.

Çö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 çıkışındaki zaman damgaları gereksiz dosya değişikliklerine neden oluyor. Bu durum aşağıdaki konumlarda yaşanabilir:

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

Çözümler/Örnekler: Derleme çıktısından zaman damgalarını kaldırmak için C/C++'ta __DATE__/__TIME__/__TIMESTAMP__ ve Arşivlere yerleştirilmiş zaman damgalarını bölümünde verilen talimatları kullanın.

C/C++'ta __DATE__/__TIME__/__TIMESTAMP__

Bu makrolar, farklı derlemeler için her zaman farklı çıkışlar üretir. Bu nedenle, bunları kullanmayın. Bu makroları kaldırmak için kullanabileceğiniz birkaç seçenek aşağıda verilmiştir:

Arşivlere yerleştirilmiş zaman damgaları (zip, jar)

Android 7.0, zip komutunun tüm kullanımlarına -X ekleyerek zip arşivlerine yerleştirilmiş zaman damgası sorununu düzeltti. Bu işlem, ZIP dosyasından derleyicinin UID/GID'sini ve genişletilmiş Unix zaman damgasını kaldırdı.

ziptime (/platform/build/+/android16-release/tools/ziptime/ konumunda) adlı yeni bir araç, zip üstbilgilerindeki normal zaman damgalarını sıfırlar. Ayrıntılar için BENİOKU dosyasını inceleyin.

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

signapk aracı, APK dosyaları için sunucu saat dilimine bağlı olarak değişebilecek zaman damgaları belirler. 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 dizelerine genellikle kodlanmış sürümlerine BUILD_NUMBER ekleniyordu. APK'da başka hiçbir şey değişmemiş olsa bile APK yine de farklı olur.

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

Örnekler:

Cihaz üzerinde doğrulama hesaplamasını etkinleştirme

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

Ancak cihaz üzerinde doğrulama işleminin yapılması uzun zaman alabilir. Özellikle, Hata Düzeltme Kodu'nu iletme işlemi uzun sürebilir. Pixel cihazlarda bu işlem 10 dakika kadar sürebilir. Düşük özellikli cihazlarda bu işlem daha uzun sürebilir. Cihaz üzerinde Verity hesaplamasını devre dışı bırakmak ancak dm-Verity'yi etkin tutmak istiyorsanız OTA güncellemesi oluştururken --disable_fec_computation parametresini ota_from_target_files aracına ileterek bunu yapabilirsiniz. Bu işaret, OTA güncellemeleri sırasında cihaz üzerinde doğrulama hesaplamasını devre dışı bırakır. OTA yükleme süresini kısaltsa da OTA paket boyutunu artırır. Cihazınızda dm-verity etkin değilse bu işaretin iletilmesinin hiçbir etkisi olmaz.

Tutarlı derleme araçları

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

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

Derleme karşılaştırma aracını kullanma

Derlemeyle ilgili dosya değişikliklerini ortadan kaldırmanın mümkün olmadığı durumlarda AOSP, iki dosya paketini karşılaştırmak için kullanılabilen bir derleme karşılaştırma aracı target_files_diff.py içerir. Bu araç, derlemeyle ilgili yaygın dosya değişiklikleri (ör.

  • Derleme çıkışında beklenen değişiklikler (ör. derleme numarası değişikliği nedeniyle).
  • Mevcut derleme sistemindeki bilinen sorunlardan kaynaklanan değişiklikler.

Derleme karşılaştırma 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ıklanan hedef dosyaların bulunduğu temel dizinlerdir.

Blok tahsisini tutarlı tutun

Belirli bir dosyanın içeriği iki derleme arasında aynı kalsa da verileri barındıran gerçek bloklar değişmiş olabilir. Sonuç olarak, güncelleyicinin OTA güncellemesi için blokları taşımak amacıyla gereksiz G/Ç işlemleri yapması gerekir.

Sanal A/B OTA güncellemesinde, gereksiz G/Ç, yazma sırasında 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, OTA güncellemesi için blokların taşınması, blok hareketleri nedeniyle daha fazla G/Ç olduğu için güncelleme süresine katkıda bulunur.

Google, bu sorunu gidermek için Android 7.0'da make_ext4fs aracını genişleterek blok tahsisini derlemeler arasında tutarlı hale getirdi. make_ext4fs aracı, ext4 resmi oluştururken dosyaları aynı bloklara ayırmaya çalışan isteğe bağlı bir -d base_fs işaretini kabul eder. Önceki bir derlemenin hedef dosyalarının ZIP dosyasından blok eşleme dosyalarını (base_fs harita dosyaları gibi) ayıklayabilirsiniz. Her ext4 bölümünde, IMAGES dizininde bir .map dosyası bulunur (örneğin, IMAGES/system.map system bölümüne karşılık gelir). Bu base_fs dosyaları, bu örnekte gösterildiği gibi PRODUCT_<partition>_BASE_FS_PATH aracılığıyla kontrol edilerek 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 işlem, genel OTA paket boyutunu küçültmez ancak G/Ç miktarını azaltarak OTA güncelleme performansını iyileştirir. Sanal A/B güncellemeleri için OTA'yı uygulamak üzere gereken depolama alanı miktarını önemli ölçüde azaltır.

Uygulamaları güncellemekten kaçının

Derleme farklarını en aza indirmenin yanı sıra, uygulama mağazaları üzerinden güncelleme alan uygulamaların güncellemelerini 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. Uygulama mağazaları tarafından güncellenen uygulamaların en son sürümlerinin OTA güncellemesine dahil edilmesi, OTA paketlerinin boyutunu büyük ölçüde etkileyebilir ve kullanıcılara çok az fayda sağlayabilir. Kullanıcılar OTA paketini aldığında, güncellenmiş uygulamaya veya doğrudan uygulama mağazalarından alınan daha da yeni bir sürüme sahip olabilirler.