Bu sayfada, derlemeler arasındaki gereksiz dosya değişikliklerini azaltmak için AOSP'ye eklenen değişiklikler açıklanmaktadır. Kendi yapı sistemlerini koruyan cihaz uygulayıcıları, bu bilgiyi kablosuz (OTA) güncellemelerinin boyutunu küçültmek için bir 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ıtları oluşturuyorlar. Bu, 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 bir OTA yamasının boyutunu büyütü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 azaltmak için tasarlanmış yapı sistemi değişiklikleri içerir. Yapılar arasındaki gereksiz dosya değişiklikleri ortadan kaldırıldı ve OTA güncellemelerinde yalnızca yama ile ilgili dosyalar yer aldı. AOSP ayrıca, daha temiz bir derleme dosyası farkı sağlamak için yapıyla ilgili yaygın dosya değişikliklerini filtreleyen bir yapı fark aracı ve blok tahsisini tutarlı tutmanıza yardımcı olan bir blok eşleme aracı içerir.
Bir derleme sistemi, çeşitli şekillerde gereksiz yere büyük yamalar oluşturabilir. Bunu azaltmak için, Android 8.0 ve sonraki sürümlerde, her bir dosya farklılığı için yama boyutunu azaltan yeni özellikler uygulandı. OTA güncelleme paketi boyutlarını azaltan iyileştirmeler şunları içerir:
- 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 etmek için özelleştirilebilir. 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 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 üretimi için sıkıştırma ve fark fonksiyonlarını işleyen, indirme akışları için belirleyici bir yama aracı olan Puffin yeniden sıkıştırmanın kullanımı.
- Yamaları sıkıştırmak için
bsdiff
kitaplığının nasıl kullanıldığı gibi delta oluşturma aracı kullanımındaki değişiklikler. 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
iyileştirmeler, A/B cihaz güncellemeleri için yamalar uygulandığında daha az bellek kullanılmasıyla sonuçlandı. - Blok tabanlı OTA güncellemeleri için büyük zip dosyalarını bölmeye 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ı, çözümlerini ve AOSP'deki uygulama örneklerini etkileyen çeşitli sorunlar tartışılmaktadır.
dosya sırası
Sorun : Dosya sistemleri, bir dizindeki dosyaların listesi sorulduğunda bir dosya sırasını garanti etmez, ancak genellikle aynı kullanıma alma 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ı kullanmadan önce çı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 daha önce sıralama yapmadığını doğrulayın.
Örnekler: Birçok örnek all-*-files-under
yerleşik makrosu kullanılarak, all-cpp-files-under
(birkaç tanım diğer makefiles'e yayıldığı için) kullanılarak çekirdek derleme sisteminde düzeltildi. 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
Derleme dizini
Sorun: Nesnelerin oluşturulduğu dizini değiştirmek, ikili dosyaların farklı olmasına neden olabilir. Android derlemesindeki yolların çoğu göreli yollardır, bu nedenle C/C++'da __FILE__
sorun değildir. Bununla birlikte, hata ayıklama sembolleri varsayılan olarak tam yol adını kodlar ve .note.gnu.build-id
önceden soyulmuş ikili dosyanın hashlenmesinden üretilir, bu nedenle hata ayıklama sembolleri değişirse değişecektir.
Çö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 çıktısındaki zaman damgaları, gereksiz dosya değişikliklerine neden oluyor. Bunun aşağıdaki konumlarda olması muhtemeldir:
- C veya C++ kodunda
__DATE__/__TIME__/__TIMESTAMP__
makroları. - Zip tabanlı arşivlere gömülü zaman damgaları.
Çözümler/Örnekler: Derleme çıktısından zaman damgalarını kaldırmak için aşağıda C/C++'da __DATE__/__TIME__/__TIMESTAMP__ içinde verilen yönergeleri kullanın. ve Arşivlere katıştırılmış zaman damgaları .
C/C++'da __DATE__/__TIME__/__TIMESTAMP__
Bu makrolar her zaman farklı yapılar için farklı çıktılar üretir, bu yüzden bunları kullanmayın. İşte bu makroları ortadan kaldırmak için birkaç seçenek:
- Onları kaldır. Bir örnek için https://android.googlesource.com/platform/system/core/+/30622bbb209db187f6851e4cf0cdaa147c2fca9f adresine bakın.
- Çalışan ikiliyi 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üncellemeyen artımlı derlemeler dışında her şey için geçerlidir). Bir ö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/+/master/tools/ziptime/
konumunda bulunur), zip başlıklarındaki normal zaman damgalarını sıfırlar. Ayrıntılar için BENİOKU dosyasına bakın.
signapk
aracı, sunucunun saat dilimine bağlı olarak değişebilen APK dosyaları için zaman damgaları ayarlar. 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 dizelerinde genellikle sabit kodlu sürümlerine BUILD_NUMBER
eklenir. Sonuç olarak APK'da başka hiçbir şey değişmese bile 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
Cihazda doğrulama hesaplamasını etkinleştir
Cihazınızda dm-verity etkinleştirilmişse, OTA araçları otomatik olarak verity yapılandırmanızı alır ve cihaz üzerinde verity hesaplamasını etkinleştirir. Bu, verity bloklarının OTA paketinizde ham bayt olarak saklanmak yerine android cihazlarda hesaplanmasına izin verir. Verity blokları, 2 GB'lık bir bölüm için yaklaşık 16 MB kullanabilir.
Ancak, cihazda gerçekliğin hesaplanması uzun zaman alabilir. Özellikle, İletim Hatası düzeltme kodu uzun sürebilir. Piksel cihazlarda, 10 dakikaya kadar sürebilir. Düşük kaliteli cihazlarda daha uzun sürebilir. Cihazdaki verity hesaplamasını devre dışı bırakmak, ancak yine de dm-verity'yi etkinleştirmek istiyorsanız, bir OTA güncellemesi oluştururken --disable_fec_computation
ota_from_target_files
aracına ileterek bunu yapabilirsiniz. Bu işaret, OTA güncellemeleri sırasında cihazda veri doğrulama 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 bir etkisi olmaz.
Tutarlı derleme araçları
Sorun: Yüklü dosyalar oluşturan araçlar tutarlı olmalıdır (belirli bir girdi her zaman aynı çıktıyı üretmelidir).
Çözümler/Örnekler: Aşağıdaki oluşturma araçlarında değişiklik yapılması gerekiyordu:
- NOTICE dosya yaratıcısı . NOTICE dosyası oluşturucu, çoğaltılabilir NOTICE koleksiyonları oluşturacak şekilde değiştirildi. CL'ye bakın: https://android.googlesource.com/platform/build/+/8ae4984c2c8009e7a08e2a76b1762c2837ad4f64 .
- Java Android Derleyici Kiti (Jack) . Jack araç zinciri, oluşturulan oluşturucu sıralamasında ara sıra meydana gelen değişiklikleri işlemek için bir güncelleme gerektiriyordu. Araç zincirine yapıcılar için deterministik erişimciler eklendi: https://android.googlesource.com/toolchain/jack/+/056a5425b3ef57935206c19ecb198a89221ca64b .
- ART AOT derleyicisi (dex2oat) . ART derleyici ikili dosyası, belirleyici 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) . Her derleme farklı bir
/system/lib/libpac.so
dosyası oluşturur çünkü V8 anlık görüntüsü her derleme için değişir. Çözüm, anlık görüntüyü kaldırmaktı: https://android.googlesource.com/platform/external/v8/+/e537f38c36600fd0f3026adba6b3f4cbcee1fb29 . - Uygulama önceden dexopt'd (.odex) dosyaları . Ön-dexopt'd (.odex) dosyaları, 64 bit sistemlerde başlatılmamış dolgu içeriyordu. Bu düzeltildi: https://android.googlesource.com/platform/art/+/34ed3afc41820c72a3c0ab9770be66b6668aa029 .
Yapı farkı aracını kullanma
Yapıyla ilgili dosya değişikliklerini ortadan kaldırmanın mümkün olmadığı durumlarda, AOSP, iki dosya paketini karşılaştırmak için bir yapı fark aracı, target_files_diff.py
içerir. Bu araç, derlemeyle ilgili yaygın dosya değişikliklerini hariç tutarak, iki derleme arasında özyinelemeli bir fark gerçekleştirir.
- Derleme çı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.
Yapı farkı 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 ayıklanan hedef dosyaları içeren temel dizinlerdir.
Blok tahsisini tutarlı tutmak
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üncelleyici blokları bir OTA güncellemesi için hareket ettirmek üzere gereksiz G/Ç gerçekleştirmelidir.
Bir Sanal A/B OTA güncellemesinde, gereksiz G/Ç, yazma üzerine kopya 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, blok hareketlerinden dolayı daha fazla G/Ç olduğundan, OTA güncellemesi için blokların hareket ettirilmesi güncelleme süresine katkıda bulunur.
Bu sorunu çözmek için, Android 7.0'da Google make_ext4fs
aracını, blok tahsisini tüm yapılar arasında tutarlı tutmak için genişletti. make_ext4fs
aracı, bir ext4
görüntüsü 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ı ( base_fs
harita dosyaları gibi) önceki bir derlemenin hedef dosyalarının zip dosyasından çıkarabilirsiniz. Her ext4
bölümü için, IMAGES
dizininde bir .map
dosyası vardır (örneğin, IMAGES/system.map
system
bölümüne karşılık gelir). Bu base_fs
dosyaları daha sonra teslim edilebilir ve bu örnekte olduğu gibi PRODUCT_<partition>_BASE_FS_PATH
aracılığıyla 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 paket boyutunu azaltmaya 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ından güncelleme alan uygulamalar için güncellemeleri 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. Bir OTA güncellemesinde uygulama mağazaları tarafından güncellenen uygulamaların en son sürümlerinin dahil edilmesi, OTA paketleri üzerinde büyük bir boyut etkisine sahip olabilir ve çok az kullanıcı yararı sağlayabilir. Kullanıcılar bir OTA paketi aldıklarında, doğrudan uygulama mağazalarından güncellenmiş uygulamaya veya daha da yeni bir sürüme zaten sahip olabilirler.