27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.

Bu sayfa, Cloud Translation API ile çevrilmiştir.

Bölüm düzeni
Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

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, false olarak ayarlanmalıdır. Bu ayar yalnızca ramdisk kullanan cihazlar ile ramdisk kullanmayan (ve bunun yerine system.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.

system bö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.
system bölümünü /system konumuna 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.
init uygulaması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'daki product/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 vendor bölüm dosyalarının vendor_file dışında bağlamları varsa dosya bağlamlarını tanımlayın. /vendor/lib/*, vendor_file bağlamını kullandığından bu örnekte söz konusu dizin yer almıyor.

device/google/device-sepolicy/private/file_contexts alanı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
```
init sürecinin, tedarikçi yer paylaşımını vendor_file dışındaki dosya bağlamlarına monte etmesine izin verin. initİşlemi zaten vendor_file bağlamında bağlama izni olduğundan bu örnekte vendor_file politikası tanımlanmaz.

device/google/device-sepolicy/public/init.te alanı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
/vendor vb.

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:

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).