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

Bu sayfada, Android cihaz OEM'lerinin ürün serileri genelinde kendi paylaşılan sistem imajlarına (SSI) sahip olmak için kullanabileceği çeşitli mekanizmalar sunulmaktadır. Ayrıca, OEM'e ait bir SSI'yi AOSP tarafından oluşturulan genel sistem görüntüsüne (GSI) dayalı bir prosedür de önerir.

Arka plan

Project Treble ile monolitik Android iki bölüme ayrıldı: donanıma özel bölüm (tedarikçi firma uygulaması) ve genel işletim sistemi bölümü (Android OS ç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ü ve genel işletim sistemi yazılımı için sistem bölümü. Tedarikçi arayüzü (VINTF) olarak adlandırılan sürümlü bir arayüz tanımlanır ve iki bölümde zorunlu kılınır. Bu bölümleme sistemini kullanarak tedarikçi bölümünü değiştirmeden sistem bölümünü değiştirebilir ve bunun tam tersini yapabilirsiniz.

Motivasyon

AOSP'de yayınlanan çerçeve kodu, Treble mimarisiyle uyumludur ve eski tedarikçi uygulamalarıyla geriye dönük uyumluluğu korumuştur. Örneğin, Android 10 AOSP kaynaklarından oluşturulan genel bir sistem görüntüsü, Android 8 veya sonraki sürümleri çalıştıran Treble uyumlu tüm cihazlarda çalışabilir. Tüketici cihazlarında gönderilen Android sürümü, SoC tedarikçileri ve OEM'ler tarafından değiştirilir. (Bir Android Sürümünün Ömrü sayfasına göz atın.) Çerçevede yapılan bu değişiklikler ve uzantılar, geriye dönük uyumluluğu korumak için yazılmamıştı. Bu da işletim sistemi yükseltme işleminde karmaşıklığın artmasına ve maliyetin yükselmesine neden oldu. Cihazlara ö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ını sağlayan net bir mimari yoktu. Bu dokümanda, SoC tedarikçilerinin ve OEM'lerin SSI oluşturmak için uygulayabileceği adımlar açıklanmaktadır. Bu, tedarikçi firma uygulamalarıyla geriye dönük uyumluluğu sürdürmek ve Android OS yükseltmelerinin karmaşıklığını ve maliyetini önemli ölçüde azaltmak için, birden fazla cihazda yeniden kullanım amacıyla Android OS çerçeve kaynaklarından oluşturulan bir görüntü anlamına gelir. SSI oluştururken uygulamanız gereken belirli adımlar için GSI tabanlı SSI için önerilen adımlar bölümüne bakın ve dört adımın tümünü kullanmanı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'ye 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ılacak az sayıda SSI'ye sahip olmayı seçebilir. Android OS'in yeni bir sürümü yayınlandığında OEM'ler, SSI'lerini en son Android sürümüne güncellemek için yalnızca bir kez yatırım yapar. /product bölümünü güncellemeden birden fazla cihazı güncellemek için SSI'leri yeniden kullanabilirler.

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

• SSI'yi birden fazla cihaz SKU'sunda yeniden kullanabilirsiniz.
• İş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 tedarikçi bölümüne ayırma fikrine benzer. Ürün arayüzü (VINTF'ye benzer), SSI ile ürün bölümü arasında iletişime izin verir. SSI ile ilgili olarak "bileşenler" terimiyle, temelde bölüm haline gelen resimlere yüklenen tüm kaynakların, ikili dosyaların, metinlerin, kitaplıkların vb. kastedildiğini unutmayın.

SSI'nin etrafındaki bölümler

Şekil 1'de SSI ile ilgili bölümler ve arayüzlerdeki bölümler ile politikalardaki sürüm oluşturulmuş arayüzler gösterilmektedir. Bu bölümde, bölümlerin ve arayüzlerin her biri ayrıntılı olarak açıklanmaktadır.

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

Resimler ve bölümler

Bu bölümdeki bilgilerde görüntü ve bölüm terimleri arasındaki fark açıklanmaktadır.

• Resim, 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 alanıdır.

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

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

  • /system bölümü AOSP tabanlı bileşenler içerirken /system_ext, uygulandığında OEM ve SoC tedarikçisi uzantılarını ve AOSP bileşenleriyle sıkı bir şekilde bağlı bileşenleri içerir. Örneğin, OEM'nin kendi uygulamaları için özel API'ler sağlayan bir OEM Java çerçevesi kitaplığı, /system_ext platformunda /system bölümüne göre daha uygundur. Hem /system hem de /system_ext bölümlerinin içeriği, 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ğlı olan özel özellikler ve uzantılar için kullanılması faydalıdır. Bu ayrım, bu tür bileşenleri bir süre boyunca /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: OEM özelleştirmelerini ve Android OS'deki uzantıları 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ğlarsa (ü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 özel bileşenlerden oluşan bir koleksiyon.

• ODM: SoC tarafından sağlanmayan, kart özelinde bileşenlerden oluşan bir koleksiyondur. Genellikle tedarikçi firma görüntüsü tedarikçi firmaya, ODM görüntüsü ise cihaz üreticisine aittir. Ayrı bir /odm bölümü yoksa hem SoC tedarikçisi hem de ODM resimleri /vendor bölümünde birleştirilir.

Resimler arasındaki arayüzler

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

• Tedarikçi firma arayüzü (VINTF): VINTF, tedarikçi firma ve ODM resimlerinde bulunan bileşenlerin arayüzüdür. Ürün ve sistem resimlerindeki bileşenler yalnızca bu arayüz üzerinden tedarikçi ve ODM resimleriyle etkileşim kurabilir. Örneğin, tedarikçi görüntüsü sistem görüntüsünün özel bir kısmına bağlı olamaz. Bunun tersi de geçerlidir. Bu, başlangıçta resimleri sistem ve tedarikçi bölümlerine ayıran Project Treble'da tanımlanır. Arayüz aşağıdaki mekanizmalar kullanılarak açıklanır:

  • HIDL (Geçiş HAL'i yalnızca system ve system_ext modülleri için kullanılabilir)
  • Kararlı AIDL
  • Yapılandırmalar
    • System properties API
    • Yapılandırma dosyası şeması API'si
  • VNDK
  • Android SDK API'leri
  • Java SDK kitaplığı

• Ürün arayüzleri: Ürün arayüzü, SSI ve ü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ınmıştır.

Android 11'de SSI'yı etkinleştirme

Bu bölümde, Android 11'de SSI'yi desteklemek için mevcut 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 sunulmuştur. (/system bölümündeki AOSP tarafından tanımlanan bileşenlerle sıkı bir bağlantısı olan AOSP dışı bileşenlerin bulunduğu yerdir.) /system_ext bölümünün, iki bölümde tanımlanmış bir arayüz olmadan /system bölümüne OEM'ye özgü bir uzantı 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 birbiriyle sıkı sıkıya bağlantılı olduğundan, yeni bir Android sürümü yayınlandığında her iki bölüm birlikte yükseltilir. Android'in önceki sürümü için oluşturulan bir /system_ext bölümünün, sonraki Android sürümündeki /system bölümü ile uyumlu olması gerekmez.

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

Geçmiş

/system_ext bölümünün geçmişi hakkında bazı bilgileri aşağıda bulabilirsiniz. Tasarım hedefi, ortak olup olmadıklarından bağımsız olarak tüm OEM'ye özgü bileşenleri /product bölümüne yerleştirmekti. Ancak bunların hepsini aynı anda taşımak mümkün değildi. Özellikle bazı bileşenlerin /system bölümünde sıkı bir bağlantısı olduğunda bu durum geçerliydi. 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 genellikle bileşenin kapsamlı bir şekilde yeniden yapılandırılmasını gerektiriyordu. Bu da çok fazla zaman ve çaba gerektiriyordu. /system_ext bölümü, /product bölümüne taşınmaya hazır olmayan bileşenlerin geçici olarak barındırılacağı bir yer olarak başladı. SSI'nin amacı, /system_ext bölümünü zaman içinde 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 yararlıdır. SSI ile yükseltme çalışmasının büyük kısmı /system ve /system_ext bölümlerindeki bileşenler için harcanır. Sistem görüntüsü, AOSP'dekilere mümkün olduğunca benzer kaynaklardan oluşturulduğunda, yükseltme işlemini system_ext görüntüsüne odaklayabilirsiniz.

/system ve /system_ext bölümlerindeki bileşenlerin paketini /product bölümüne ayırma

Android 9, /system bölümünü kullanan bir /product bölümü kullanıma sundu. /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'yi mümkün kılmak için ürün bileşenleri /system_ext ve /product bölümlerine ayrılır. /system_ext bölümünün, Android 9'da /product bölümünün uyduğu sistem bileşenlerini kullanma kısıtlamalarına uyması gerekmez. Android 10'dan itibaren /product bölümünün /system bölümünden ayrılması ve /system ile /system_ext bölümlerindeki kararlı arayüzleri kullanması gerekir.

/system_ext bölümünün birincil amacı, /system_ext partition bölümünde açıklandığı gibi paketlenmiş ürün modüllerini yüklemek yerine sistem özelliklerini genişletmektir. Bunu yapmak için ürüne özel modülleri gruptan ayırın ve /product bölümüne taşıyın. Ürüne özgü modüllerin paketinden çıkarılması, /system_ext'ü cihazlar için ortak hale getirir. (Daha fazla bilgi için /system_ext bölümünü ortak hale getirme bölümüne bakın.)

/product bölümünün sistem bileşenlerinden ayrılması için /product bölümünün, Project Treble ile ayrılmış olan /vendor bölümüyle aynı yaptırım politikasına sahip olması gerekir.

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

• Yerel arayüzler: /product bölümündeki yerel modüllerin grubu diğer bölümlerden ayrılmalıdır. Ürün modüllerinden izin verilen tek bağımlılık, /system bölümündeki bazı VNDK kitaplıklarıdır (LLNDK dahil). Ürün uygulamalarının bağımlı olduğu JNI kitaplıkları NDK kitaplıkları olmalıdır.
• Java arayüzleri: /product bölümündeki Java (uygulama) modülleri kararlı olmadığından gizli API'leri kullanamaz. Bu modüller yalnızca /system bölümündeki herkese açık API'leri ve sistem API'lerini ve /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 uyumluluk testleri (ör. GSI'de CTS) için ve uygulama geliştiricilerin, gerekli Android sürümünü çalıştıran 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'lerini oluşturmak için GSI'yi de kullanabilir. Görüntüler 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 resminden oluşur. system resmi olarak GSI kullanıldığında OEM, yükseltme için system_ext resmine odaklanabilir.

Bu bölümde, AOSP veya AOSP benzeri bir sistem görüntüsü kullanırken özelleştirmelerini /system_ext ve /product bölümlerinde modülerleştirmek isteyen OEM'lere yönelik bir kılavuz sağlanmaktadı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ştirebilirler. Bununla birlikte, OEM'lerin son adıma aynı anda ulaşması gerekmez (GSI'yı olduğu gibi kullanarak).

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

Sistem görüntüsü (OEM GSI), generic_system.mk'yi (Android 11'de mainline_system.mk olarak adlandırılan ve AOSP'de generic_system.mk olarak yeniden adlandırılan) devralarak 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'ye ait dosyaları da içerebilir. Ancak OEM'lerin generic_system.mk dosyasını değiştirmesine izin verilmez.

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

2. Adım. OEM GSI'nin AOSP GSI ile aynı dosya listesine sahip olmasını sağlayın

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

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

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

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

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

Şekil 5. OEM GSI'da değiştirilmiş dosyalar listesini azaltmak için bir izin verilenler listesi tanımlayın

4. Adım. OEM GSI'nin AOSP GSI ile aynı ikili dosyaları olmasını sağlayın

İzin verilenler listesini temizlediğinizde OEM'ler, kendi ürünleri için sistem görüntüsü olarak AOSP GSI'yı kullanabilir. OEM'ler, izin verilenler listesini temizlemek için OEM GSI'deki değişikliklerini bırakabilir veya AOSP GSI'nin değişiklikleri içermesi için değişikliklerini AOSP'ye aktarabilir.

Şekil 6. OEM GSI'nin AOSP GSI ile aynı ikili dosyaları olmasını sağlama

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

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

OEM'ler, /system bölümünde ürüne özgü değişiklikleri önlemek ve OEM GSI'yi tanımlamak için require-artifacts-in-path adlı bir makefile makrosu kullanabilir. Bu makro, çağrıldıktan sonra sistem modüllerinin tanımlanmasını önler. Makefile oluşturma ve yapı yolu kontrolünü etkinleştirme örneğine bakın.

OEM'ler, ürüne özgü 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 paketten çıkarılmasını garanti etmek için yerel modüller için PRODUCT_PRODUCT_VNDK_VERSION:= current, Java modülleri için ise PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true ayarlayarak cihazlarının ürün arayüzlerini zorunlu kılmasını sağlayabilir. Bu değişkenler, cihazın PRODUCT_SHIPPING_API_LEVEL değeri 30 değerinden büyükse veya buna eşitse otomatik olarak ayarlanır. Ayrıntılı bilgi için Ürün Bölme Arayüzlerini Zorunlu Kılma başlıklı makaleyi inceleyin.

/system_ext bölümünü ortak yapın

/system_ext bölümü, cihaza özel, sisteme göre gruplandırılmış modüllere sahip olabileceğinden 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'larına sahip olabilir ve farklılıkları kaldırıp /system_ext bölümünü ortak hale getirerek bu SSI'yı birden fazla cihaz arasında paylaşabilir.

Bu bölümde, /system_ext bölümünü ortak hale getirmeyle ilgili öneriler verilmektedir.

Sistem bölümünde gizli API'leri göster

Ürüne özgü birçok uygulama, ürün bölümünde yasak olan gizli API'ler kullandığı için ürün bölümüne yüklenemez. Cihazlara ö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ın yerini alacak alternatif herkese açık API'leri veya sistem API'lerini bulmaktır. Gizli API'leri değiştirecek API 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ığını oluşturarak özel API'ler tanımlayabilir. Sistem bölümündeki gizli API'leri kullanabilir ve API'leri ürün veya tedarikçi 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 süper kümesini dahil edin ve her cihaz için bazı paket yüklemelerini atlayın

Sistemle birlikte paket halinde sunulan belirli paketler cihazlar arasında ortak değildir. Bu APK modüllerini ürüne veya tedarikçiye ait bölüme taşımak için paketten çıkarmak zor olabilir. OEM'ler geçici bir çözüm olarak SSI'nin tüm modülleri içermesini sağlayabilir, ardından SKU mülkü (ro.boot.hardware.sku) kullanarak istenmeyenleri filtreleyebilir. OEM'ler filtreyi kullanmak için config_disableApkUnlessMatchedSku_skus_list ve config_disableApksUnlessMatchedSku_apk_list çerçeve kaynaklarını üst üste getirir.

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

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

Statik kaynak yer paylaşımı, yer paylaşımlı paketleri manipüle eder. Ancak bu, SSI'nin tanımlanmasını engelleyebilir. Bu nedenle, RRO özelliklerinin etkinleştirildiğinden ve doğru şekilde ayarlandığından emin olun. OEM'ler, mülkleri aşağıdaki gibi ayarlayarak tüm otomatik olarak oluşturulan 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 yerine manuel olarak bir RRO tanımlayın. Ayrıntılı bilgi için Çalışma zamanında kaynak yer paylaşımları (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) ortak özelliklerine ve özelliklerine bağlıdır. OEM'ler, system_ext bölümünü ortak hale getirme bölümünde açıklandığı gibi system_ext bölümünü ortak hale getirmeyi deneyebilir. Bir cihaz grubunda çok fazla fark varsa birden fazla SSI tanımlamak daha iyidir.

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

Hayır. Ancak OEM'ler, OEM GSI için generic_system.mk dosyasını devralan yeni bir makefile tanımlayabilir ve bunun yerine yeni makefile'i kullanabilir. Bir örnek için Ürün Bölümlendirme Arayüzlerini Zorunlu Kılma konusuna bakın.

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

Hayır. GSI, minimum sayıda önyüklenebilir ve test edilebilir modüle sahiptir. Bir modülün gerekli olmadığını düşünüyorsanız lütfen AOSP'deki generic_system.mk dosyasını güncellemek için bir hata kaydı gönderin.