Android 10'da kök dosya sistemi artık ramdisk.img'e dahil edilmez ve bunun yerine system.img ile birleştirilir (yani system.img, BOARD_BUILD_SYSTEM_ROOT_IMAGE ayarlanmışsa her zaman oluşturulur). Android 10 ile kullanıma sunulan cihazlar:
- Kök olarak sistem bölümü düzeni kullanın (davranış değiştirme seçeneği olmadan derleme tarafından otomatik olarak zorunlu kılınmıştır).
- dm-linear için gerekli olan bir ramdisk kullanılmalıdır.
BOARD_BUILD_SYSTEM_ROOT_IMAGE,falseolarak ayarlanmalıdır. Bu ayar yalnızca ramdisk kullanan cihazlar ile ramdisk kullanmayan (ve bunun yerinesystem.img'ü doğrudan bağlayan) cihazlar arasında ayrım yapmak için kullanılır.
Kök olarak sistem yapılandırmasının anlamı Android 9 ile Android 10 arasında farklılık gösterir. Android 9 kök sistem yapılandırmasında BOARD_BUILD_SYSTEM_ROOT_IMAGE, true olarak ayarlanır. Bu, derlemeyi kök dosya sistemini system.img ile birleştirmeye ve ardından system.img dosya sistemini kök dosya sistemi (rootfs) olarak bağlamaya zorlar. Bu yapılandırma, Android 9 ile kullanıma sunulan cihazlar için zorunlu ancak Android 9'a yükseltilen cihazlar ve Android'in daha eski sürümlerini çalıştıran cihazlar için isteğe bağlıdır. Android 10'da kök olarak sistem yapılandırmasında, derleme her zaman $TARGET_SYSTEM_OUT ve $TARGET_ROOT_OUT'yi system.img olarak birleştirir. Bu yapılandırma, Android 10 çalıştıran tüm cihazlar için varsayılan davranıştır.
Android 10, dinamik bölümleri desteklemek için daha fazla değişiklik yapar. Bu, kablosuz güncellemelerin bölüm oluşturmasına, yeniden boyutlandırmasına veya bölümleri silmesine olanak tanıyan bir kullanıcı alanı bölümlendirme sistemidir. Bu değişiklik kapsamında, Linux çekirdeği artık Android 10 çalıştıran cihazlarda mantıksal sistem bölümünü bağlayamaz. Bu nedenle, bu işlem ilk aşama init tarafından yönetilir.
Aşağıdaki bölümlerde, yalnızca sistem için OTA'lar ile ilgili kök olarak sistem gereksinimleri açıklanmakta, cihazları kök olarak sistem kullanacak şekilde güncellemeyle ilgili yol gösterici bilgiler verilmektedir (bölüm düzeni değişiklikleri ve dm-verity çekirdek gereksinimleri dahil). Ramdisk'te yapılan değişikliklerle ilgili ayrıntılar için Ramdisk bölümlendirme bölümüne bakın.
Yalnızca sistem için OTA'lar hakkında
Android sürümlerinin diğer bölümleri değiştirmeden system.img ve product.img bölümünü güncellemesini sağlayan yalnızca sistem OTA'ları, kök olarak sistem bölüm düzeni gerektirir. Android 10 çalıştıran tüm cihazlarda, yalnızca sistem için OTA'ları etkinleştirmek amacıyla kök olarak sistem bölümü düzeni kullanılmalıdır.
systembölümünü rootfs olarak bağlayan A/B cihazlar zaten kök olarak sistem kullanır ve sistem OTA'larını desteklemek için değişiklik yapılması gerekmez.systembölümünü/systemkonumuna bağlayan A/B olmayan cihazlar, sistem OTA'larını desteklemek için kök olarak sistem bölümü düzeni kullanacak şekilde güncellenmelidir.
A/B ve A/B olmayan cihazlarla ilgili ayrıntılar için A/B (Sorunsuz) Sistem Güncellemeleri başlıklı makaleyi inceleyin.
Tedarikçi firma yer paylaşımını kullanma (<=AOSP 14)
Tedarikçi firma yer paylaşımı, cihazın önyükleme sırasında vendor bölümündeki değişiklikleri yer paylaşımı olarak eklemenize olanak tanır. Tedarikçi firma yer paylaşımı, cihaz açıldığında product bölümündeki tedarikçi firma modüllerinin vendor bölümüne yerleştirildiği, mevcut modüllerin yerini aldığı ve bunlara eklendiği bir tedarikçi firma modülü grubudur.
Cihaz açıldığında init işlemi ilk aşamada bağlamayı tamamlar ve varsayılan özellikleri okur. Ardından, aşağıdaki koşullar karşılanırsa /product/vendor_overlay/<target_vendor_version>'de arama yapar ve her alt dizini ilgili vendor bölüm dizinine bağlar:
/vendor/<overlay_dir>mevcut./product/vendor_overlay/<target_vendor_version>/<overlay_dir>,/vendor/<overlay_dir>ile aynı dosya bağlamına sahiptir.inituygulamasının/vendor/<overlay_dir>dosya bağlamına monte edilmesine izin verilir.
Sağlayıcı yer paylaşımını uygulama
Tedarikçi firma yer paylaşımı dosyalarını /product/vendor_overlay/<target_vendor_version>'e yükleyin. Bu dosyalar, cihaz açıldığında vendor bölümünü kaplar, aynı ada sahip dosyaları değiştirir ve yeni dosyalar ekler. Tedarikçi firma yer paylaşımı, vendor bölümündeki dosyaları kaldıramaz.
Tedarikçi firma yer paylaşımı dosyaları, vendor bölümünde değiştirdikleri hedef dosyalarla aynı dosya bağlamına sahip olmalıdır. Varsayılan olarak, /product/vendor_overlay/<target_vendor_version> dizinindeki dosyalarda vendor_file bağlamı bulunur. Tedarikçi firma yer paylaşımı dosyaları ile değiştirdikleri dosyalar arasında dosya bağlamı uyuşmazlığı varsa bunu cihaza özgü güvenlik politikasında belirtin. Dosya bağlamı, dizin düzeyinde ayarlanır. Bir tedarikçi firma yer paylaşımı dizininin dosya bağlamı hedef dizinle eşleşmiyorsa ve cihaza özgü sepolicy dosyasında doğru dosya bağlamı belirtilmiyorsa söz konusu tedarikçi firma yer paylaşımı dizini hedef dizine yerleştirilmez.
Tedarikçi firma yer paylaşımını kullanmak için çekirdeğin CONFIG_OVERLAY_FS=y ayarını yaparak OverlayFS'yi etkinleştirmesi gerekir. Ayrıca, çekirdek 4.4 veya sonraki sürümlerin ortak çekirdeğinden birleştirilmiş ya da "overlayfs:
override_creds=off option bypass creator_cred" ile yamalı olmalıdır.
Tedarikçi firma yer paylaşımı uygulama örneği
Bu prosedürde, /vendor/lib/*, /vendor/etc/* ve /vendor/app/* dizinlerini kapsayan bir tedarikçi yer paylaşımı uygulanması gösterilmektedir.
-
device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/'te önceden oluşturulmuş tedarikçi firma dosyalarını ekleyin:device/google/device/vendor_overlay/28/lib/libfoo.so device/google/device/vendor_overlay/28/lib/libbar.so device/google/device/vendor_overlay/28/etc/baz.xml device/google/device/vendor_overlay/28/app/qux.apk
-
Önceden oluşturulmuş tedarikçi firma dosyalarını
device/google/device/device.mk'dakiproduct/vendor_overlay'ye yükleyin:PRODUCT_COPY_FILES += \ $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)
-
Hedef
vendorbölüm dosyalarınınvendor_filedışında bağlamları varsa dosya bağlamlarını tanımlayın./vendor/lib/*,vendor_filebağlamını kullandığından bu örnekte söz konusu dizin yer almıyor.device/google/device-sepolicy/private/file_contextsalanına aşağıdakileri ekleyin:/(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)? u:object_r:vendor_configs_file:s0 /(product|system/product)/vendor_overlay/[0-9]+/app(/.*)? u:object_r:vendor_app_file:s0
-
initsürecinin, tedarikçi yer paylaşımınıvendor_filedışındaki dosya bağlamlarına monte etmesine izin verin.initİşlemi zatenvendor_filebağlamında bağlama izni olduğundan bu örnektevendor_filepolitikası tanımlanmaz.device/google/device-sepolicy/public/init.tealanına aşağıdakileri ekleyin:allow init vendor_configs_file:dir mounton; allow init vendor_app_file:dir mounton;
Tedarikçi firma yer paylaşımını doğrulama
Tedarikçi firma yer paylaşımı yapılandırmasını doğrulamak için /product/vendor_overlay/<target_vendor_version>/<overlay_dir> içine dosya ekleyin ve dosyaların /vendor/<overlay_dir> içindeki dosyaların üzerine yerleştirilip yerleştirilmediğini kontrol edin.
userdebug derlemeleri için Atest modülü vardır:
$ atest -v fs_mgr_vendor_overlay_test
Kök olarak sistem güncellemesi
A/B olmayan cihazları kök olarak sistem kullanacak şekilde güncellemek için boot.img ve system.img için bölümlendirme şemasını güncellemeniz, dm-verity'yi ayarlamanız ve cihaza özgü kök klasörlerdeki tüm önyükleme bağımlılıkları kaldırmanız gerekir.
Bölümleri güncelleme
/boot'ü kurtarma bölümü olarak yeniden kullanan A/B cihazların aksine, A/B olmayan cihazlarda yedek yuva bölümü olmadığından /recovery bölümünü ayrı tutmaları gerekir (örneğin, boot_a ile boot_b arasında). A/B olmayan cihazlarda /recovery kaldırılırsa ve A/B şemasına benzer hale getirilirse /boot bölümündeki başarısız bir güncelleme sırasında kurtarma modu bozulabilir. Bu nedenle, A/B olmayan cihazlarda /recovery bölümü /boot'ten ayrı bir bölüm olmalıdır. Bu, kurtarma görüntüsünün ertelenmiş şekilde güncellenmeye devam ettiği anlamına gelir (yani Android 8.1.0 veya daha eski sürümleri çalıştıran cihazlardakiyle aynı).
Aşağıdaki tabloda, Android 9'dan önce ve sonra A/B olmayan cihazlar için resim bölümü farklılıkları listelenmiştir.
| Resim | Ramdisk (9'dan önceki sürümler) | Kök olarak sistem (9'dan sonra) |
|---|---|---|
boot.img |
Bir çekirdek ve ramdisk.img içerir:
ramdisk.img
-/
- init.rc
- init
- etc -> /system/etc
- system/ (mount point)
- vendor/ (mount point)
- odm/ (mount point)
... |
Yalnızca normal bir önyükleme çekirdeği içerir. |
recovery.img |
Kurtarma çekirdeği ve kurtarma ramdisk.img içerir. |
|
system.img |
Şunları içerir:
system.img
-/
- bin/
- etc
- vendor -> /vendor
- ... |
Orijinal system.img ve ramdisk.img'nin birleştirilmiş içeriğini içerir:
system.img
-/
- init.rc
- init
- etc -> /system/etc
- system/
- bin/
- etc/
- vendor -> /vendor
- ...
- vendor/ (mount point)
- odm/ (mount point)
... |
Bölümlerin kendisi değişmez. Hem ramdisk hem de kök olarak sistem aşağıdaki bölüm şemasını kullanır:
/boot/system/system/recovery/vendorvb.
dm-verity'yi ayarlama
Kök olarak sistemde çekirdek, system.img dosyasını dm-verity ile / (yükleme noktası) altında bağlamalıdır. AOSP, system.img için aşağıdaki dm-verity uygulamalarını destekler.
vboot 1.0
vboot 1.0 için çekirdek, /system üzerinde Android'e özgü meta verileri ayrıştırmalı, ardından dm-verity'yi ayarlamak için dm-verity parametrelerine dönüştürmelidir (bu çekirdek yamaları gerekir).
Aşağıdaki örnekte, çekirdek komut satırında root olarak sistem için dm-verity ile ilgili ayarlar gösterilmektedir:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="system none ro,0 1 android-verity /dev/sda34" veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f
vboot 2.0
vboot 2.0 (AVB) için önyükleyici, external/avb/libavb dosyasını entegre etmelidir. Bu dosya, /system için hashtree tanımlayıcısını ayrıştırır, dm-verity parametrelerine dönüştürür ve son olarak parametreleri çekirdek komut satırı üzerinden çekirdeğe iletir. (/system için karma ağacı tanımlayıcılar /vbmeta üzerinde veya /system üzerinde olabilir.)
vboot 2.0 için aşağıdaki çekirdek yamaları gerekir:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- kernel 4.4 yamaları, kernel 4.9 yamaları vb.
Aşağıdaki örnekte, çekirdek komut satırında root olarak sistem için dm-verity ile ilgili ayarlar gösterilmektedir:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="1 vroot none ro 1,0 5159992 verity 1 PARTUUID=00000016-0000-0000-0000-000000000000 PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999 sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2 8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption ignore_zero_blocks use_fec_from_device PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks 650080 fec_start 650080"
Cihaza özel kök klasörleri kullanma
Kök olarak sistem kullanıldığında, genel sistem resmi (GSI) cihaza yüklendikten sonra (ve Tedarikçi Testi Paketi testleri çalıştırılmadan önce) BOARD_ROOT_EXTRA_FOLDERS ile eklenen cihaza özel kök klasörler kaldırılır. Bunun nedeni, kök dizin içeriğinin tamamının kök olarak sistem GSI ile değiştirilmesidir. Cihazlara özgü kök klasörlere bağımlılık varsa (ör. bu klasörler bağlama noktası olarak kullanılıyorsa) bu klasörlerin kaldırılması cihazın başlatılamamasına neden olabilir.
Bu sorunu önlemek için cihaza özgü kök klasörler eklemek üzere BOARD_ROOT_EXTRA_FOLDERS kullanmayın. Cihaza özgü montaj noktalarını belirtmeniz gerekiyorsa /mnt/vendor/<mount point> (bu değişiklik listelerine eklenmiştir) kullanın. Tedarikçiye özgü bu bağlama noktaları, ek kurulum gerekmeden doğrudan hem fstab cihaz ağacında (ilk aşama bağlama için) hem de /vendor/etc/fstab.{ro.hardware} dosyasında belirtilebilir (fs_mgr bunları /mnt/vendor/* altında otomatik olarak oluşturduğundan).