OTA boyutunu küçült

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ı bu bilgileri kılavuz olarak kullanabilir kablosuz güncellemelerinin boyutunu küçültmeyi amaçlıyor.

Android OTA güncellemeleri bazen kod değişikliklerine karşılık gelmeyen değiştirilmiş dosyalar içerir. Bunlar aslında derlenen sistem yapılarıdır. Bu durum, aynı kod farklı değerlerde derlendiğinde ortaya çıkabilir. ya da farklı makinelerde gerçekleşen tüm dönüşüm tarihlerine kıyasla dosyası olarak da kaydedebilir. Bu tür aşırı dosyalar, OTA yamasının boyutunu artırır ve bu tür dosyaların tespit edilmesini zorlaştırır. hangi kodun değiştiğini öğrenin.

AOSP, bir OTA'nın içeriğini daha şeffaf hale getirmek için tasarlanan derleme sistem değişikliklerini içerir kullanarak OTA yamalarının boyutunu küçültebilirsiniz. Yapılar arasında gereksiz dosya değişiklikleri ve OTA güncellemelerine yalnızca yama ile ilgili dosyalar dahil edilir. AOSP ayrıca bir derleme farkı aracını kullanın. Bu araç, daha temiz bir derleme dosyası farkı sağlamak için dosya değişiklikleri engelleme eşleme aracını kullanın tutarlıdır.

Derleme sistemi, gereksiz derecede büyük yama oluşturmak için çeşitli yöntemler kullanabilir. Bu durumu azaltmak amacıyla Android 8.0 ve sonraki sürümlerin her biri için yama boyutunu küçültecek yeni özellikler uygulandı dosya farkları OTA güncelleme paketi boyutlarını küçülten iyileştirmeler şunlardır:

  • Tam kapasite için genel amaçlı, kayıpsız bir sıkıştırma algoritması olan Brotli'nin kullanımı A/B olmayan cihaz güncellemelerindeki resimler. Brotli, optimize edilecek şekilde özelleştirilebilir sağlayabilirsiniz. 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 vardır ve farklı bloklar üzerinde farklı sıkıştırma algoritmaları kullanabilir aynı güncelleme.
  • Söndürme için deterministik bir yama aracı olan Puffin rekompresyon kullanımı akışlar arasındaki bir farktır.
  • Delta oluşturma aracı kullanımında yapılan değişiklikler (ör. bsdiff kitaplığınız yamaları sıkıştırmak için kullanılır. Android 9 ve sonraki sürümlerde bsdiff aracı, en yüksek performansı gösteren sıkıştırma algoritmasını en iyi sıkıştırma sonuçlarını verir.
  • İyileştirmeler update_engine. nedeniyle, A/B cihaz güncellemeleri için yamalar uygulandığında daha az bellek harcandı.
  • Blok tabanlı OTA güncellemeleri için büyük zip dosyalarını bölmeyle ilgili iyileştirmeler. Şu modda: imgdiff. giriş adlarına göre aşırı büyük APK dosyalarını böler. Bu, 2008'e kıyasla daha küçük bir yama üretir dosyaları doğrusal olarak bölün ve sıkıştırmak için bsdiff aracını kullanın.

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

Dosya sırası

Sorun: Dosya sistemleri, içeren bir dizindir. Ancak aynı ödeme işlemi için bu genellikle aynıdır. Örneğin, ls sonuçları varsayılan olarak sıralar ancak şu gibi komutların kullandığı joker karakter işlevi: bu nedenle find ve make sıralanmaz. Bu araçları kullanmadan önce çıktı.

Çözüm: find ve joker karakter işleviyle make, kullanmadan önce bu komutların çıkışını sıralayın gerekir. Şu uygulamada $(wildcard) veya $(shell find) kullanılırken Android.mk dosyayı da sıralayın. Java gibi bazı araçlarda girişleri sıralar. dosyaları sıralamadan önce, kullandığınız aracın bunu yapmadığından emin olun.

Örnekler: Temel derleme sisteminde birçok örnek, yerleşik all-*-files-under makrosu all-cpp-files-under (diğer oluşturma dosyalarında çeşitli tanımlar bulunduğu için). Ayrıntılar için aşağıdaki kaynakları inceleyin:

Derleme dizini

Sorun: Öğelerin derlendiği dizini değiştirmek, farklı olmasını sağlayabilirsiniz. Android derlemesindeki çoğu yol göreli yollardır C/C++ ürününde __FILE__ sorun değil. Ancak hata ayıklama sembolleri, yol adı varsayılan olarak kullanılır ve .note.gnu.build-id, önceden sadeleştirilmiş ikili program kapsamındadır. Dolayısıyla hata ayıklama sembolleri değişirse bu da 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 büyük olasılıkla aşağıdaki konumlarda gerçekleşir:

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

Çözümler/Örnekler: Derleme çıkışından zaman damgalarını kaldırmak için aşağıdaki talimatlarda belirtilen __DATE__/__TIME__/__TIMESTAMP__ C/C++. ve Arşivlere yerleştirilmiş zaman damgaları.

__DATE__/__TIME__/__TIMESTAMP__ C/C++

Bu makrolar farklı derlemeler için her zaman farklı çıkışlar ürettiğinden bunları kullanmayın. Burası şu makroları ortadan kaldırmak için birkaç seçenek bulunur:

ziyaret edin.

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

Android 7.0, -X komutunun tüm kullanımlarına zip komutu ekler. Bu işlem, oluşturucu ve genişletilmiş Unix zaman damgasını içerir.

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

signapk aracı, APK dosyaları için zaman damgalarını ayarlar. Zaman damgaları, sunucu saat dilimini kullanır. 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 BUILD_NUMBER eklenmişti kendi sürümleriyle uyumlu hale getirin. APK'da başka hiçbir şey değişmemiş olsa bile, sonuç olarak APK farklı olacaktır.

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

Örnekler:

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

dm-verity etkinleştirildiğinde, OTA araçları sürüm yapılandırmanızı otomatik olarak alır ve cihaz üzerinde doğrulama hesaplamasını etkinleştirme. Bu, Android'de doğrulama bloklarının hesaplanmasına olanak tanır depolarız. Verity blokları, 2 GB'lık bir bölüm için yaklaşık 16 MB'tır.

Ancak, cihazda işlem doğrulama işlemi uzun sürebilir. Özellikle, Yönlendirilmiş Hata düzeltme kodu uzun sürebilir. Piksel cihazlarda ise bu dosya için piksellerin dakika. Düşük teknoloji cihazlarda bu süre daha uzun olabilir. Cihaz üzerinde sürümü devre dışı bırakmak istiyorsanız ancak yine de dm-verity özelliğini etkinleştirirseniz bunu, Şu durumlarda ota_from_target_files aracına --disable_fec_computation: OTA güncellemesi oluşturuyoruz. Bu işaret, OTA güncellemeleri sırasında cihaz üzerinde sürüm hesaplamasını devre dışı bırakır. OTA yükleme süresini kısaltır ancak OTA paket boyutunu artırır. Cihazınız başlamazsa dm-verity'yi etkinleştirdiğiniz için bu işareti iletmenin herhangi bir etkisi olmaz.

Tutarlı derleme araçları

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

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

Derleme farkı aracını kullanma

AOSP, derlemeyle ilgili dosya değişikliklerini ortadan kaldırmanın mümkün olmadığı durumlarda, karşılaştırma aracı sayesinde target_files_diff.py. karşılaştırmada kullanılmak üzere tasarlanmıştır. Bu araç, iki dönüşüm arasında yinelemeli bir derlemelerle ilgili yaygın dosya değişiklikleri hariç,

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

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

target_files_diff.py dir1 dir2

dir1 ve dir2, ayıklanan hedefi içeren temel dizinlerdir dosyalarını yüklemenizi sağlar.

Blok paylaştırmanın tutarlı olmasını sağlayın

Belirli bir dosya için, içeriği iki derleme arasında aynı kalsa da asıl bloklar verileri muhafaza eden filtreler değişmiş olabilir. Sonuç olarak, güncelleyicinin gereksiz G/Ç işlemi yapması gerekir OTA güncellemesi için blokları harekete geçirin.

Sanal A/B OTA güncellemesinde gereksiz G/Ç, gereken depolama alanını büyük ölçüde artırabilir depolamaya izin verir. A/B olmayan bir OTA güncellemesinde, blokları bir sonraki OTA güncellemesi, blok hareketleri nedeniyle daha fazla G/Ç olduğundan güncelleme zamanına katkıda bulunur.

Google, bu sorunu çözmek için Android 7.0'da make_ext4fs aracını Böylece derlemeler arasında blok ayırmanın tutarlı olmasını sağlayabilirsiniz. make_ext4fs aracı şunları kabul eder: dosyaları aynı bloklara ayırmaya çalışan isteğe bağlı bir -d base_fs işareti ext4 resmi oluştururken. Blok eşleme dosyalarını (ör. base_fs harita dosyası) önceki bir derlemenin hedef dosyalarından zip dosyası olarak kaydedin. Her bir ext4 bölümlendirmesinde, .map IMAGES dizini (örneğin, IMAGES/system.map system bölüm). Bu base_fs dosya daha sonra giriş yapabilir ve aşağıdaki örnekte olduğu gibi PRODUCT_<partition>_BASE_FS_PATH aracılığıyla belirtilir:

  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 paketinin boyutunu küçültmeye yardımcı olmasa da OTA güncellemesini iyileştirir azaltarak performansı artırır. Sanal A/B güncellemelerinde, yükleme sayısını önemli ölçüde OTA'yı uygulamak için gereken depolama alanı miktarı.

Uygulamaları güncellemekten kaçınma

Derleme farklılıklarını en aza indirmenin yanı sıra, güncellemeleri hariç tutarak OTA güncelleme boyutlarını da azaltabilirsiniz. Google Analytics 4'te tarama odaklı bir dizi araç kullanıma sunuldu. APK'lar genellikle uygulamanın çeşitli bölümlere ayrılmış. Uygulamaya göre güncellenen uygulamaların en yeni sürümleri dahil OTA güncellemesindeki mağazaların, OTA paketleri üzerinde büyük etkisi olabilir ve bu durum fayda sağlar. Kullanıcılar OTA paketi aldıklarında uygulama zaten güncellenmiş olabilir veya doğrudan uygulama mağazalarından alınan daha yeni bir sürüm olacaktır.