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 koruyan cihaz uygulayıcıları, bu bilgileri kablosuz (OTA) güncellemelerinin boyutunu küçültmek için kılavuz olarak kullanabilir.

Android OTA güncellemeleri bazen kod değişikliklerine karşılık gelmeyen değiştirilmiş dosyalar içerir. Bunlar aslında derleme sistemi yapılarıdır. Bu durum, 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, OTA yamasının boyutunu artırır ve hangi kodun değiştiğini belirlemeyi zorlaştırır.

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

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

  • A/B bölümü olmayan cihaz güncellemelerinde tam görüntüler için genel amaçlı, kayıpsız sıkıştırma algoritması olan ZSTD'nin kullanımı. ZSTD, sıkıştırma düzeyi artırılarak daha yüksek sıkıştırma oranları için özelleştirilebilir. Sıkıştırma düzeyi, OTA oluşturma sırasında belirlenir ve --vabc_compression_param=zstd,$COMPRESSION_LEVEL işaretini ileterek ayarlanabilir.
  • OTA sırasında kullanılan sıkıştırma penceresi boyutunu artırma. Maksimum sıkıştırma penceresi boyutu, bir cihazın .mk dosyasındaki derleme parametresi özelleştirilerek ayarlanabilir. Bu değişken, PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 262144 olarak ayarlanır.
  • Puffin yeniden sıkıştırma özelliğinin kullanımı: Bu özellik, deflate akışları için deterministik bir yama aracıdır ve A/B OTA güncelleme oluşturma için sıkıştırma ve farklılık işlevlerini yönetir.
  • Yama oluşturma aracı kullanımında yapılan değişiklikler (ör. yamaları sıkıştırmak için bsdiff kitaplığının kullanılma şekli) 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 ile ilgili iyileştirmeler, A/B cihaz güncellemeleri için yamalar uygulandığında daha az bellek tüketilmesini sağladı.

Aşağıdaki bölümlerde, OTA güncelleme boyutlarını etkileyen çeşitli sorunlar, çözümleri ve AOSP'deki 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 aynı ödeme için genellikle aynı sıra kullanılı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: Joker karakter işleviyle find ve make gibi araçları kullandığınızda bu komutların çıkışını kullanmadan önce sıralayın. $(wildcard) veya $(shell find) simgelerini Android.mk dosyalarında 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: Yerleşik all-*-files-under makrosu kullanılarak temel derleme sisteminde birçok örnek düzeltildi. Bu makro, all-cpp-files-under öğesini de içerir (çünkü çeşitli tanımlar diğer makefile'lara yayılmıştı). Ayrıntılar için aşağıdaki makaleleri inceleyin:

Derleme dizini

Sorun: Öğelerin oluşturulduğu dizinin değiştirilmesi, ikili dosyaların farklı olmasına neden olabilir. Android derlemesindeki çoğu yol göreli yoldur. Bu nedenle, C/C++'da __FILE__ sorun oluşturmaz. Ancak hata ayıklama sembolleri, varsayılan olarak tam yol adını kodlar ve .note.gnu.build-id, önceden temizlenmiş ikili dosyanın karma oluşturma işleminden üretilir. Bu nedenle, hata ayıklama sembolleri değişirse .note.gnu.build-id da değişir.

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

Zaman damgaları

Sorun: Derleme çıkışındaki zaman damgaları, gereksiz dosya değişikliklerine neden oluyor. Bu durumun yaşanması muhtemel olan yerler:

  • 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 __DATE__/__TIME__/__TIMESTAMP__ in C/C++. ve Embedded timestamps in archives bölümlerinde verilen talimatları kullanın.

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

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

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

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

ziptime (/platform/build/+/android16-release/tools/ziptime/ içinde bulunur) adlı yeni bir araç, zip üstbilgilerindeki normal zaman damgalarını sıfırlar. Ayrıntılı bilgi için README dosyasına bakın.

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

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

Sürüm dizeleri

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

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

Örnekler:

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

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

Ancak cihazda doğruluk hesaplaması uzun sürebilir. Özellikle İletme Hata Düzeltme Kodu uzun sürebilir. Pixel cihazlarda bu işlem genellikle 10 dakika kadar sürer. Düşük özellikli cihazlarda bu işlem daha uzun sürebilir. Cihaz üzerinde doğruluk hesaplamasını devre dışı bırakmak ancak dm-verity'yi etkinleştirmek istiyorsanız OTA güncellemesi oluştururken --disable_fec_computation aracına ota_from_target_files değerini ileterek bunu yapabilirsiniz. Bu işaret, OTA güncellemeleri sırasında cihaz üzerinde doğruluk hesaplamasını devre dışı bırakır. Bu yöntem, OTA yükleme süresini kısaltır ancak 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ışı vermelidir).

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

Derleme farkı aracını kullanma

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

  • Derleme çıktısında beklenen değişiklikler (ör. derleme numarası değişikliği nedeniyle).
  • Mevcut derleme sistemindeki bilinen sorunlar nedeniyle yapılan 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 çıkarılan hedef dosyaları içeren temel dizinlerdir.

Blok ayırmayı tutarlı tutun

Belirli bir dosyanın içeriği iki derleme arasında aynı kalsa da verileri tutan gerçek bloklar değişmiş olabilir. Sonuç olarak, güncelleyicinin OTA güncellemesi için blokları taşımak üzere 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, blokların OTA güncellemesi için taşınması, blok hareketleri nedeniyle daha fazla G/Ç olduğundan güncelleme süresine katkıda bulunur.

Bu sorunu gidermek için Google, Android 7.0'da blok ayırmayı derlemeler arasında tutarlı tutmak için make_ext4fs aracını genişletti. 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. Blok eşleme dosyalarını (ör. base_fs harita dosyaları) önceki bir derlemenin 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 kullanıma sunulabilir 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 işlem, genel OTA paket boyutunu küçültmese de G/Ç miktarını azaltarak OTA güncelleme performansını artırır. Sanal A/B güncellemelerinde, 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ı üzerinden güncelleme alan uygulamaların güncellemelerini hariç tutarak OTA güncelleme boyutlarını da küçültebilirsiniz. APK'lar genellikle bir cihazdaki çeşitli bölümlerin önemli bir kısmını oluşturur. Uygulama mağazaları tarafından OTA güncellemesiyle güncellenen uygulamaların en son sürümlerinin dahil edilmesi, OTA paketlerinin boyutunu büyük ölçüde etkileyebilir ve kullanıcıya çok az fayda sağlayabilir. Kullanıcılar OTA paketini aldığında güncellenmiş uygulamayı veya uygulama mağazalarından doğrudan alınan daha yeni bir sürümü zaten kullanıyor olabilir.