Android paylaşılan sistem görüntüsü

Bu sayfada, Android cihaz OEM'lerinin ürün gruplarında kendi paylaşılan sistem görüntülerini (SSI) kullanmak için yararlanabileceği çeşitli mekanizmalar açıklanmaktadır. Ayrıca, bir OEM'ye ait SSI'yi AOSP'de oluşturulan genel sistem görüntüsüne (GSI) dayandırma prosedürü de önerilir.

Arka plan

Project Treble ile birlikte, monolitik Android iki bölüme ayrıldı: donanıma özgü bölüm (satıcı uygulaması) ve genel işletim sistemi bölümü (Android işletim sistemi çerçevesi). Her birinin yazılımı ayrı bir bölüme yüklenir: donanıma özel yazılım için tedarikçi bölümü, genel işletim sistemi yazılımı için ise sistem bölümü. Tedarikçi arayüzü (VINTF) adı verilen sürüm oluşturulmuş bir arayüz, iki bölüm arasında tanımlanır ve zorunlu kılınır. Bu bölümleme sistemini kullanarak sistem bölümünü tedarikçi bölümünü değiştirmeden, tedarikçi bölümünü de sistem bölümünü değiştirmeden değiştirebilirsiniz.

Motivasyon

AOSP'de yayınlanan çerçeve kodu, Treble mimarisine uygun ve eski tedarikçi uygulamalarıyla geriye dönük uyumluluğu koruyacak şekilde geliştirilmiştir. Örneğin, Android 10 AOSP kaynaklarından oluşturulan genel bir sistem görüntüsü, Android 8 veya daha yeni bir sürümü çalıştıran ve Treble ile uyumlu herhangi bir cihazda çalıştırılabilir. Tüketici cihazlarında gönderilen Android sürümü, SoC tedarikçileri ve OEM'ler tarafından değiştirilir. (Android sürümünün yaşam döngüsü başlıklı makaleyi inceleyin.) Çerçevede yapılan bu değişiklikler ve uzantılar, geriye dönük uyumluluğu korumak için yazılmadığından işletim sistemi yükseltmesinde daha fazla karmaşıklığa ve daha yüksek maliyete yol açtı. Cihaza özel değişiklikler ve modifikasyonlar, Android işletim sistemi sürümünü yükseltmenin maliyetini ve karmaşıklığını artırır.

Android 11'den önce, iş ortaklarının Android OS çerçevesine modüler uzantılar oluşturmasına olanak tanıyan net bir mimari yoktu. Bu belgede, SoC satıcılarının ve OEM'lerin SSI oluşturmak için uygulayabileceği adımlar açıklanmaktadır. Bu, birden fazla cihazda yeniden kullanılmak üzere Android işletim sistemi çerçevesi kaynaklarından oluşturulan, satıcı uygulamalarıyla geriye dönük uyumluluğu koruyan ve Android işletim sistemi yükseltmelerinin karmaşıklığını ve maliyetini önemli ölçüde azaltan tek bir resim anlamına gelir. SSI oluşturmak için gereken adımları GSI tabanlı SSI için önerilen adımlar bölümünde bulabilirsiniz. Dört adımın tamamını uygulamanız gerekmediğini unutmayın. Hangi adımları seçeceğiniz (örneğin, yalnızca 1. adım) uygulamanıza bağlıdır.

SSI'ya genel bakış

SSI ile ürüne özel yazılım bileşenleri ve OEM uzantıları yeni bir /product bölümüne yerleştirilir. /product bölümündeki bileşenler, /system bölümündeki bileşenlerle etkileşim kurmak için iyi tanımlanmış ve kararlı bir arayüz kullanır. OEM'ler tek bir SSI oluşturmayı veya birden fazla cihaz SKU'sunda kullanılmak üzere az sayıda SSI oluşturmayı seçebilir. Android işletim sisteminin yeni bir sürümü yayınlandığında OEM'ler, SSI'larını en son Android sürümüne güncellemek için yalnızca bir kez yatırım yapar. Bu kullanıcılar, /product bölümünü güncellemeden birden fazla cihazı güncellemek için SSIs'leri yeniden kullanabilir.

OEM'lerin ve SoC tedarikçilerinin, bir OEM'in ihtiyaç duyduğu tüm özel özellikleri ve değişiklikleri içeren SSI'lar oluşturduğunu unutmayın. Bu sayfada sunulan mekanizmalar ve en iyi uygulamalar, OEM'lerin aşağıdaki temel hedeflere ulaşmak için kullanması amaçlanmıştır:

• SSI'yı birden fazla cihaz SKU'sunda yeniden kullanın.
• İşletim sistemi yükseltmelerini kolaylaştırmak için Android sistemini modüler uzantılarla güncelleyin.

Ürüne özel bileşenleri ürün bölümüne ayırma fikri, SoC'ye özel bileşenleri satıcı bölümüne ayırma fikri olan Treble'a benzer. Bir ürün arayüzü (VINTF'ye benzer) SSI ile ürün bölümü arasında iletişime olanak tanır. SSI ile ilgili olarak "bileşenler" teriminin, görüntülere yüklenen tüm kaynakları, ikili dosyaları, metinleri, kitaplıkları vb. tanımladığını ve bunların esasen bölümler haline geldiğini unutmayın.

SSI ile ilgili bölümler

Şekil 1'de SSI etrafındaki bölümler ve bölümler genelindeki sürüm oluşturulmuş arayüzler ile arayüzlerdeki politikalar gösterilmektedir. Bu bölümde, her bir bölüm ve arayüz ayrıntılı olarak açıklanmaktadır.

1. şekil. SSI ile ilgili bölümler ve arayüzler

Resimler ve bölümler

Bu bölümdeki bilgiler, resim ve bölüm terimleri arasındaki farkı açıklar.

• İmaj, bağımsız olarak güncellenebilen kavramsal bir yazılım parçasıdır.
• Bölüm, bağımsız olarak güncellenebilen fiziksel bir depolama konumudur.

Şekil 1'deki bölümler aşağıdaki şekilde tanımlanır:

• SSI: SSI, bir OEM'ye özgü olan ve birden fazla cihazda bulunabilen resimdir. Donanıma veya ürüne özel bileşenleri yoktur. Belirli bir SSI'daki her şey, tanım gereği bu SSI'yı kullanan tüm cihazlar arasında paylaşılır. SSI, Şekil 1'de gösterildiği gibi tek bir /system resimden veya /system ve /system_ext bölümlerinden oluşur.

  • /system bölümü AOSP tabanlı bileşenleri içerirken /system_ext bölümü, uygulandığında OEM ve SoC tedarikçisi uzantılarını ve AOSP bileşenleriyle sıkı bir şekilde bağlı olan bileşenleri içerir. Örneğin, OEM'in kendi uygulamaları için özel API'ler sağlayan bir OEM Java çerçeve kitaplığı, /system bölümünden ziyade /system_ext bölümüne daha iyi uyar. Hem /system hem de /system_ext bölümleri için içerik, OEM tarafından değiştirilmiş Android kaynaklarından oluşturulur.

  • /system_ext bölümü isteğe bağlıdır ancak AOSP tabanlı bileşenlerle sıkı bir şekilde bağlantılı olan özel özellikler ve uzantılar için kullanılması faydalıdır. Bu ayrım, söz konusu bileşenleri zaman içinde /system_ext bölümünden /product bölümüne taşımak için yapmanız gereken değişiklikleri belirlemenize yardımcı olur.

• Ürün: Android işletim sisteminde OEM özelleştirmelerini ve uzantılarını temsil eden, ürüne veya cihaza özel bileşenler koleksiyonu. SoC'ye özgü bileşenleri /vendor bölümüne yerleştirin. SoC tedarikçileri, SoC'den bağımsız olanlar gibi uygun bileşenler için /product bölümünü de kullanabilir. Örneğin, bir SoC tedarikçisi OEM müşterilerine SoC'den bağımsız bir bileşen sağlıyorsa (ürünle birlikte gönderilmesi isteğe bağlıdır) SoC tedarikçisi bu bileşeni ürün resmine yerleştirebilir. Bir bileşenin konumu, sahipliğine göre değil, amacına göre belirlenir.

• Sağlayıcı: SoC'ye özgü bileşenlerin bir koleksiyonu.

• ODM: SoC tarafından sağlanmayan, kart özelinde bileşenler koleksiyonu. Genellikle SoC satıcısı, satıcı görüntüsünün sahibidir. Cihaz üreticisi ise ODM görüntüsünün sahibidir. Ayrı bir /odm bölümü olmadığında hem SoC satıcısı hem de ODM görüntüleri /vendor bölümünde birleştirilir.

Resimler arasındaki arayüzler

SSI ile ilgili olarak satıcı ve ürün resimleri için iki ana arayüz vardır:

• Tedarikçi Arayüzü (VINTF): VINTF, tedarikçi ve ODM görüntülerinde bulunan bileşenlerin arayüzüdür. Ürün ve sistem görüntülerindeki bileşenler, yalnızca bu arayüz üzerinden satıcı ve ODM görüntüleriyle etkileşimde bulunabilir. Örneğin, bir satıcı resmi, sistem görüntüsünün özel bir bölümüne bağlı olamaz ve bunun tersi de geçerlidir. Bu, başlangıçta Project Treble'da tanımlanmıştır. Project Treble, görüntüleri sistem ve tedarikçi bölümlerine ayırır. Arayüz, aşağıdaki mekanizmalar kullanılarak açıklanır:

  • HIDL (Passthrough HAL yalnızca system ve system_ext modüllerinde kullanılabilir)
  • Kararlı AIDL
  • Yapılandırmalar
    • Sistem özellikleri API'si
    • Yapılandırma dosyası şeması API'si
  • VNDK
  • Android SDK API'leri
  • Java SDK kitaplığı

• Ürün arayüzleri: Ürün arayüzü, SSI ile ürün resmi arasındaki arayüzdür. Kararlı bir arayüz tanımlamak, ürün bileşenlerini bir SSI'deki sistem bileşenlerinden ayırır. Ürün arayüzü, VINTF ile aynı kararlı arayüzleri gerektirir. Ancak Android 11 (ve sonraki sürümler) ile kullanıma sunulan cihazlarda yalnızca VNDK ve Android SDK API'leri zorunlu kılınır.

Android 11'de SSI'yı etkinleştirme

Bu bölümde, Android 11'de SSI'yı desteklemek için kullanıma sunulan yeni özelliklerin nasıl kullanılacağı açıklanmaktadır.

/system_ext bölümü

/system_ext bölümü, Android 11'de isteğe bağlı bir bölüm olarak kullanıma sunuldu. (Bu, /system bölümündeki AOSP tanımlı bileşenlerle sıkı bağlantısı olan AOSP dışı bileşenlerin yeridir.) /system_ext bölümünün, iki bölüm arasında tanımlanmış bir arayüz olmadan /system bölümünün OEM'e özgü uzantısı olduğu varsayılır. /system_ext bölümündeki bileşenler /system bölümüne özel API çağrıları yapabilir ve /system bölümündeki bileşenler /system_ext bölümüne özel API çağrıları yapabilir.

İki bölüm sıkı bir şekilde bağlı olduğundan yeni bir Android sürümü yayınlandığında her iki bölüm de birlikte yükseltilir. Android'in önceki sürümü için oluşturulan /system_ext bölümünün, bir sonraki Android sürümündeki /system bölümüyle uyumlu olması gerekmez.

Bir modülü /system_ext bölümüne yüklemek için Android.bp dosyasına system_ext_specific: true ekleyin. /system_ext bölümü olmayan cihazlarda bu tür modülleri /system bölümündeki ./system_ext alt dizinine yükleyin.

Geçmiş

/system_ext bölümüyle ilgili bazı bilgiler: Tasarım hedefi, ortak olup olmadıklarına bakılmaksızın tüm OEM'e özgü bileşenleri /product bölümüne yerleştirmekti. Ancak, özellikle bazı bileşenler /system bölümüyle sıkı bir şekilde bağlı olduğundan hepsini aynı anda taşımak mümkün değildi. Sıkı bağlı bir bileşeni /product bölümüne taşımak için ürün arayüzünün genişletilmesi gerekir. Bu durum genellikle bileşenin kendisinin kapsamlı bir şekilde yeniden düzenlenmesini gerektiriyordu. Bu da çok fazla zaman ve çaba harcanmasına neden oluyordu. /system_ext bölümü, /product bölümüne taşınmaya hazır olmayan bileşenleri geçici olarak barındırmak için oluşturuldu. SSI'nin amacı, sonunda /system_ext bölümünü ortadan kaldırmaktı.

Ancak /system_ext bölümü, /system bölümünü AOSP'ye mümkün olduğunca yakın tutmak için kullanışlıdır. SSI ile yükseltme çabasının çoğu /system ve /system_ext bölümlerindeki bileşenlere harcanır. Sistem görüntüsü, AOSP'deki kaynaklara mümkün olduğunca benzer kaynaklardan oluşturulduğunda yükseltme çalışmalarını system_ext görüntüsüne odaklayabilirsiniz.

/system ve /system_ext bölümlerindeki bileşenleri /product bölümüne taşıma

Android 9, /system bölümüyle eşleştirilmiş bir /product bölümü tanıttı. /product bölümündeki modüller, sistem kaynaklarını herhangi bir kısıtlama olmadan kullanır ve bunun tersi de geçerlidir. Android 10'da SSI'nin mümkün olması için ürün bileşenleri /system_ext ve /product bölümlerine ayrılmıştır. /system_ext bölümü, Android 9'da /product bölümünün uyması gereken sistem bileşenlerini kullanma kısıtlamalarına uymak zorunda değildir. Android 10'dan itibaren /product bölümü, /system bölümünden ayrılmalı ve /system ile /system_ext bölümlerindeki kararlı arayüzleri kullanmalıdır.

/system_ext bölümünün asıl amacı, /system_ext partition bölümünde açıklandığı gibi paketlenmiş ürün modüllerini yüklemek değil, sistem özelliklerini genişletmektir. Bunu yapmak için ürüne özel modüllerin paketini açın ve bunları /product bölümüne taşıyın. Ürüne özel modüllerin paketinden çıkarılması, cihazlarda /system_ext ortak hale getirir. (Daha ayrıntılı bilgi için /system_ext bölümünü ortak yapma başlıklı makaleyi inceleyin.)

/product bölümünü sistem bileşenlerinden ayırmak için /product bölümü, Project Treble ile daha önce ayrılmış olan /vendor bölümüyle aynı zorunlu kılma politikasına sahip olmalıdır.

Android 11'den itibaren, /product bölümü için yerel ve Java arayüzleri aşağıda açıklandığı şekilde zorunlu kılınır. Daha fazla bilgi için Ürün bölümü arayüzlerini zorunlu kılma başlıklı makaleyi inceleyin.

• Yerel arayüzler: /product bölümündeki yerel modüllerin diğer bölümlerden ayrılması gerekir. Ürün modüllerinden yalnızca /system bölümündeki bazı VNDK kitaplıklarına (LLNDK dahil) izin verilir. Ürün uygulamalarının bağlı olduğu JNI kitaplıkları NDK kitaplıkları olmalıdır.
• Java arayüzleri: /product bölümündeki Java (uygulama) modülleri, kararsız oldukları için gizli API'leri kullanamaz. Bu modüller yalnızca /system bölümündeki herkese açık API'leri ve sistem API'lerini, /system veya /system_ext bölümündeki Java SDK kitaplıklarını kullanmalıdır. Özel API'ler için Java SDK kitaplıkları tanımlayabilirsiniz.

GSI tabanlı SSI için önerilen adımlar

Şekil 2. GSI tabanlı SSI için önerilen bölümler

Genel sistem görüntüsü (GSI), doğrudan AOSP'den oluşturulan sistem görüntüsüdür. Treble uygunluk testleri (ör. CTS-on-GSI) için ve uygulama geliştiricilerin, gerekli Android sürümünün yüklü olduğu gerçek bir cihazları olmadığında uygulamalarının uyumluluğunu test etmek için kullanabileceği bir referans platform olarak kullanılır.

OEM'ler, SSI'larını oluşturmak için GSI'yi de kullanabilir. Resimler ve bölümler bölümünde açıklandığı gibi, SSI, AOSP tarafından tanımlanan bileşenler için sistem görüntüsünden ve OEM tarafından tanımlanan bileşenler için system_ext görüntüsünden oluşur. GSI, system resmi olarak kullanıldığında OEM, yükseltme için system_ext resmine odaklanabilir.

Bu bölümde, AOSP veya AOSP'ye yakın bir sistem görüntüsü kullanırken özelleştirmelerini /system_ext ve /product bölümlerine ayırmak isteyen OEM'ler için bir kılavuz sunulmaktadır. OEM'ler sistem görüntüsünü AOSP kaynaklarından oluşturursa oluşturdukları sistem görüntüsünü AOSP tarafından sağlanan GSI ile değiştirebilir. Ancak OEM'lerin son adıma (GSI'yi olduğu gibi kullanma) tek seferde ulaşması gerekmez.

1. Adım: OEM'in sistem görüntüsü (OEM GSI) için generic_system.mk'yı devralın.

Sistem görüntüsü (OEM GSI), generic_system.mk (Android 11'de mainline_system.mk olarak adlandırılmış, AOSP'de ise generic_system.mk olarak yeniden adlandırılmıştır) devraldığı için AOSP GSI'nin sahip olduğu tüm dosyaları içerir. Bu dosyalar OEM'ler tarafından değiştirilebilir. Böylece OEM GSI, AOSP GSI dosyalarına ek olarak OEM'e özel dosyaları da içerebilir. Ancak OEM'lerin generic_system.mk dosyasını değiştirmesine izin verilmez.

3.Şekil OEM'in sistem görüntüsü için generic_system.mk'yı devralma

2. adım: OEM GSI'nin, AOSP GSI ile aynı dosya listesine sahip olmasını sağlama

OEM GSI'sinde bu aşamada ek dosyalar bulunamaz. OEM'in tescilli dosyaları system_ext veya product bölümlerine taşınmalıdır.

Şekil 4. Eklenen dosyaları OEM GSI'sinden taşıma

3. Adım: OEM GSI'deki değiştirilmiş dosyaları sınırlamak için izin verilenler listesi tanımlama

Değiştirilen dosyaları kontrol etmek için OEM'ler compare_images aracını kullanabilir ve AOSP GSI ile OEM GSI'yi karşılaştırabilir. AOSP lunch hedefinden generic_system_* AOSP GSI'yi edinin.

compare_images aracını allowlist parametresiyle düzenli olarak çalıştırarak izin verilen liste dışındaki farklılıkları izleyebilirsiniz. Bu, OEM GSI'de ek değişiklikler yapılmasını önler.

5.şekil OEM GSI'deki değiştirilmiş dosyalar listesini azaltmak için izin verilenler listesi tanımlama

4. Adım. OEM GSI'nin AOSP GSI ile aynı ikili dosyalara sahip olmasını sağlama

İzin verilenler listesinin temizlenmesi, OEM'lerin kendi ürünlerinde sistem resmi olarak AOSP GSI'yi kullanmasına olanak tanır. OEM'ler, izin verilenler listesini temizlemek için OEM GSI'deki değişikliklerini bırakabilir veya değişikliklerini AOSP'ye aktarabilir. Böylece AOSP GSI, değişikliklerini içerir.

6.şekil OEM GSI'nin AOSP GSI ile aynı ikili dosyalara sahip olmasını sağlama

OEM'ler için SSI'yı tanımlama

Derleme sırasında /system bölümünü koruma

/system bölümünde ürüne özel değişiklikler yapılmasını önlemek ve OEM GSI'yi tanımlamak için OEM'ler, makro çağrıldıktan sonra sistem modüllerinin bildirilmesini önlemek üzere require-artifacts-in-path adlı bir makefile makrosu kullanabilir. Makefile oluşturma ve yapay ürün yolu kontrolünü etkinleştirme örneğini inceleyin.

OEM'ler, ürüne özel modüllerin /system bölümüne geçici olarak yüklenmesine izin vermek için bir liste tanımlayabilir. Ancak, OEM GSI'nin OEM'nin tüm ürünlerinde ortak olması için listenin boş olması gerekir. Bu işlem, OEM GSI'yi tanımlamak içindir ve AOSP GSI'ye yönelik adımlardan bağımsız olabilir.

Ürün arayüzlerini zorunlu kılma

OEM'ler, /product bölümünün paketlenmediğini garanti etmek için cihazlarının yerel modüller için PRODUCT_PRODUCT_VNDK_VERSION:= current, Java modülleri için PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true ayarlayarak ürün arayüzlerini zorunlu kıldığından emin olabilir. Bu değişkenler, cihazın PRODUCT_SHIPPING_API_LEVEL değeri 30 veya daha yüksekse otomatik olarak ayarlanır. Ayrıntılı bilgi için Ürün Bölümü Arayüzlerini Zorunlu Kılma başlıklı makaleyi inceleyin.

/system_ext bölümünü ortak yapma

/system_ext bölümü, cihaza özel ve sistemle birlikte gelen modüller içerebileceği için cihazlar arasında farklılık gösterebilir. SSI, /system ve /system_ext bölümlerinden oluştuğu için /system_ext bölümündeki farklılıklar, OEM'lerin SSI tanımlamasını engeller. OEM'ler kendi SSI'lerine sahip olabilir ve farklılıkları kaldırıp /system_ext bölümünü ortak hale getirerek bu SSI'yi birden fazla cihaz arasında paylaşabilir.

Bu bölümde, /system_ext bölümünü ortak hale getirme önerileri verilmektedir.

Sistem bölümündeki gizli API'leri kullanıma sunma

Ürüne özgü birçok uygulama, ürün bölümünde yasaklanan gizli API'ler kullandığı için ürün bölümüne yüklenemez. Cihaza özel uygulamaları ürün bölümüne taşımak için gizli API'lerin kullanımını kaldırın.

Gizli API'leri uygulamalardan kaldırmanın tercih edilen yolu, bunları değiştirecek alternatif herkese açık veya sistem API'leri bulmaktır. Gizli API'lerin yerini alacak API'ler yoksa OEM'ler, cihazları için yeni sistem API'lerini tanımlamak üzere AOSP'ye katkıda bulunabilir.

Alternatif olarak OEM'ler, /system_ext bölümünde kendi Java SDK kitaplıklarını oluşturarak özel API'ler tanımlayabilir. Sistem bölümündeki gizli API'leri kullanabilir ve API'leri ürün veya satıcı bölümündeki uygulamalara sağlayabilir. OEM'ler, geriye dönük uyumluluk için ürüne yönelik API'leri dondurmalıdır.

Tüm APK'ların üst kümesini dahil edin ve her cihaz için bazı paket yüklemelerini atlayın.

Sistemle birlikte gelen belirli paketler, cihazlar arasında yaygın değildir. Bu APK modüllerini ürün veya satıcı bölümüne taşımak için paketinden çıkarmak zor olabilir. OEM'ler, geçici bir çözüm olarak SSI'ya tüm modülleri dahil edebilir ve ardından SKU özelliği (ro.boot.hardware.sku) kullanarak istenmeyen modülleri filtreleyebilir. Filtreyi kullanmak için OEM'ler çerçeve kaynaklarını config_disableApkUnlessMatchedSku_skus_list ve config_disableApksUnlessMatchedSku_apk_list olarak yerleştirir.

Daha hassas ayarlar için gereksiz paketleri devre dışı bırakan bir yayın alıcı bildirin. Yayın alıcısı, setApplicationEnabledSetting çağrısı yaparak ACTION_BOOT_COMPLETED mesajını aldığında paketi devre dışı bırakır.

Statik kaynak yer paylaşımı kullanmak yerine RRO'yu tanımlayın

Statik kaynak yerleşimi, yerleştirilmiş paketleri değiştirir. Ancak bu durum, SSI'nin tanımlanmasını engelleyebilir. Bu nedenle, RRO'nun özelliklerinin etkinleştirildiğinden ve doğru şekilde ayarlandığından emin olun. OEM'ler, özellikleri aşağıdaki gibi ayarlayarak otomatik olarak oluşturulan tüm yer paylaşımlarını RRO olarak kullanabilir.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

Ayrıntılı bir yapılandırma gerekiyorsa otomatik olarak oluşturulan bir RRO'ya güvenmek yerine manuel olarak tanımlayın. Ayrıntılı bilgi için Çalışma Zamanı Kaynak Katmanları (RRO'lar) başlıklı makaleyi inceleyin. OEM'ler, android:requiredSystemPropertyName ve android:requiredSystemPropertyValue özelliklerini kullanarak sistem özelliklerine bağlı koşullu RRO'lar da tanımlayabilir.

Sık sorulan sorular (SSS)

Birden fazla SSI tanımlayabilir miyim?

Bu, cihazların (veya cihaz grubunun) ortaklığına ve özelliklerine bağlıdır. OEM'ler, Making the system_ext partition common (system_ext bölümünü ortak yapma) başlıklı makalede açıklandığı gibi system_ext bölümünü ortak yapmayı deneyebilir. Bir cihaz grubunda çok fazla fark varsa birden fazla SSI tanımlamak daha iyidir.

Bir OEM GSI için generic_system.mk (mainline_system.mk) dosyasını değiştirebilir miyim?

Hayır. Ancak OEM'ler, generic_system.mk dosyasını devralan bir OEM GSI için yeni bir makefile tanımlayabilir ve bunun yerine yeni makefile'ı kullanabilir. Örnek için Ürün Bölümü Arayüzlerini Zorunlu Kılma başlıklı makaleyi inceleyin.

generic_system.mk dosyasından, uygulamamla çakışan modülleri kaldırabilir miyim?

Hayır. GSI'da minimum sayıda başlatılabilir ve test edilebilir modül bulunur. Bir modülün gerekli olmadığını düşünüyorsanız lütfen AOSP'deki generic_system.mk dosyasını güncellemek için hata bildirin.