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ümlerdebsdiff
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çinbsdiff
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:
- https://android.googlesource.com/platform/build/+/4d66adfd0e6d599d8502007e4ea9aaf82e95569f
- https://android.googlesource.com/platform/build/+/379f9f9cec4fe1c66b6d60a6c19fecb81b9eb410
- https://android.googlesource.com/platform/build/+/7c3e3f8314eec2c053012dd97d2ae649ebeb5653
- https://android.googlesource.com/platform/build/+/5c64b4e81c1331cab56d8a8c201f26bb263b630c
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:
- Onları kaldır. Örnek için https://android.googlesource.com/platform/system/core/+/30622bbb209db187f6851e4cf0cdaa147c2fca9f adresine bakın.
- Çalışan ikili dosyayı benzersiz bir şekilde tanımlamak için ELF başlığından yapı kimliğini okuyun.
- İşletim sisteminin ne zaman oluşturulduğunu öğrenmek için
ro.build.date
okuyun (bu, bu tarihi güncellemeyebilecek artımlı derlemeler dışında her şey için işe yarar). Örnek için https://android.googlesource.com/platform/external/libchrome/+/8b7977eccc94f6b3a3896cd13b4aeacbfa1e0f84 adresine bakın.
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:
- https://android.googlesource.com/platform/packages/apps/Camera2/+/5e0f4cf699a4c7c95e2c38ae3babe6f20c258d27
- https://android.googlesource.com/platform/build/+/d75d893da8f97a5c7781142aaa7a16cf1dbb669c
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:
- NOTICE dosya yaratıcısı . NOTICE dosyasının oluşturucusu, tekrarlanabilir NOTICE koleksiyonları oluşturacak şekilde değiştirildi. CL'ye bakın: https://android.googlesource.com/platform/build/+/8ae4984c2c8009e7a08e2a76b1762c2837ad4f64 .
- Java Android Derleyici Seti (Jack) . Jack araç zinciri, oluşturulan yapıcı sıralamasında ara sıra yapılan değişiklikleri ele almak için bir güncelleme gerektiriyordu. Yapıcılar için deterministik erişimciler araç zincirine eklendi: https://android.googlesource.com/toolchain/jack/+/056a5425b3ef57935206c19ecb198a89221ca64b .
- ART AOT derleyicisi (dex2oat) . ART derleyici ikili programı, deterministik bir görüntü oluşturma seçeneği ekleyen bir güncelleme aldı: https://android.googlesource.com/platform/art/+/ace0dc1dd5480ad458e622085e51583653853fb9 .
- Libpac.so dosyası (V8) . V8 anlık görüntüsü her yapı için değiştiğinden, her yapı farklı bir
/system/lib/libpac.so
dosyası oluşturur. Çözüm anlık görüntüyü kaldırmaktı: https://android.googlesource.com/platform/external/v8/+/e537f38c36600fd0f3026adba6b3f4cbcee1fb29 . - Uygulama öncesi dexopt (.odex) dosyaları . Dexopt öncesi (.odex) dosyaları, 64 bit sistemlerde başlatılmamış dolgu içeriyordu. Bu düzeltildi: https://android.googlesource.com/platform/art/+/34ed3afc41820c72a3c0ab9770be66b6668aa029 .
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.