Bu sayfada, Android cihaz OEM'lerinin ürün grupları genelinde kendi paylaşılan sistem görüntüsüne (SSI) sahip olmak için kullanabileceği çeşitli mekanizmalar sunulmaktadır. Ayrıca, OEM'e ait bir SSI'nın AOSP tarafından oluşturulmuş genel sistem görüntüsüne (GSI) dayandırılmasına yönelik bir prosedür de önerir.
Arka plan
Project Treble ile 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 kurulur: donanıma özel yazılım için satıcı bölümü ve genel işletim sistemi yazılımı için sistem bölümü. Satıcı arayüzü ( VINTF ) adı verilen sürümlü bir arayüz, iki bölüm boyunca tanımlanır ve uygulanır. Bu bölümleme sistemini kullanarak, satıcı bölümünü değiştirmeden sistem bölümünü değiştirebilirsiniz veya bunun tersi de geçerlidir.
Motivasyon
AOSP'de yayınlanan çerçeve kodu, Treble mimarisiyle uyumluydu ve eski satıcı uygulamalarıyla geriye dönük uyumluluğu korudu. Örneğin, Android 10 AOSP kaynaklarından oluşturulan genel bir sistem görüntüsü, Android 8 veya sonraki sürümlerde çalışan Treble uyumlu herhangi bir cihazda çalışabilir. Tüketici cihazlarında gönderilen Android sürümü SoC satıcıları ve OEM'ler tarafından değiştirilmektedir. (Bkz . Android Sürümünün Ömrü .) Çerçevede yapılan bu değişiklikler ve uzantılar geriye dönük uyumluluğu korumak için yazılmadı; bu da işletim sistemi yükseltmesinde artan karmaşıklık ve daha yüksek maliyet anlamına geliyordu. 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 işletim sistemi çerçevesine modüler uzantılar oluşturmasına olanak tanıyan net bir mimari yoktu. Bu belge, SoC satıcılarının ve OEM'lerin bir SSI oluşturmak için atabilecekleri adımları açıklamaktadır. Bu, satıcı uygulamalarıyla geriye dönük uyumluluğu korumak ve Android işletim sistemi yükseltmelerinin karmaşıklığında ve maliyetinde önemli bir azalma sağlamak için birden fazla cihazda yeniden kullanılmak üzere Android işletim sistemi çerçeve kaynaklarından oluşturulan tek bir görüntü anlamına gelir. Bir SSI oluşturmak için ihtiyaç duyduğunuz belirli adımlar için GSI tabanlı SSI için önerilen adımlar bölümüne bakın ve dört adımı da kullanmak zorunda olmadığınızı 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şimde bulunmak için iyi tanımlanmış, 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'ya sahip olmayı seçebilir. Android işletim sisteminin 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'ları yeniden kullanabilirler.
OEM'lerin ve SoC satıcılarının, bir OEM'in ihtiyaç duyduğu tüm özel özellikleri ve değişiklikleri içeren SSI'ler 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ına yöneliktir:
- 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 özgü bileşenleri ürün bölümüne ayırmanın temel fikri, Treble'ın SoC'ye özgü bileşenleri satıcı bölümüne ayırma fikrine benzer. Bir ürün arayüzü ( VINTF'e benzer), SSI ile ürün bölümü arasında iletişime izin verir. SSI açısından "bileşenler" teriminin, esasen bölümler haline gelen, görüntülere yüklenen tüm kaynakları, ikili dosyaları, metinleri, kitaplıkları vb. tanımladığını unutmayın.
SGK etrafındaki bölümler
Şekil 1, SSI etrafındaki bölümleri ve bölümler arasındaki sürümlendirilmiş arayüzleri ve arayüzlerdeki ilkeleri göstermektedir. Bu bölümde her bir bölüm ve arayüz ayrıntılı olarak açıklanmaktadır.
Şekil 1. SGK çevresindeki bölümler ve arayüzler
Görüntüler ve bölümler
Bu bölümdeki bilgiler görüntü ve bölüm terimleri arasındaki farkı açıklamaktadır.
- Görüntü , 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 gibi tanımlanmıştır:
SSI: SSI , bir OEM için ortak olan ve birden fazla cihazda bulunabilen görüntüdür. Donanıma özgü veya ürüne özgü herhangi bir bileşeni yoktur. Belirli bir SSI'daki her şey, tanım gereği, o SSI'yı kullanan tüm cihazlar arasında paylaşılır. SSI, Şekil 1'de görüldüğü gibi tek bir
/systemgörüntüsünden veya/systemve/system_extbölümlerinden oluşur./systembölümü AOSP tabanlı bileşenleri içerirken,/system_extuygulandığında OEM ve SoC satıcı uzantılarını ve AOSP bileşenleriyle sıkı bir şekilde birleştirilmiş bileşenleri içerir. Örneğin, OEM'in kendi uygulamaları için özel API'ler sağlayan bir OEM Java çerçeve kitaplığı,/system_ext/systembölümünden daha iyi uyum sağlar. Hem/systemhem de/system_extbölümlerinin içeriği, OEM tarafından değiştirilmiş Android kaynaklarından oluşturulmuştur./system_extbölümü isteğe bağlıdır, ancak bunu AOSP tabanlı bileşenlerle sıkı bir şekilde birleştirilmiş tüm özel özellikler ve uzantılar için kullanmak faydalıdır. Bu ayrım, yapmanız gereken değişiklikleri tanımlamanıza ve söz konusu bileşenleri belirli bir süre içinde/system_extbölümünden/productbölümüne taşımanıza yardımcı olur.
Ürün: Android işletim sistemine yönelik OEM özelleştirmelerini ve uzantılarını temsil eden, ürüne veya cihaza özgü bileşenlerden oluşan bir koleksiyon. SoC'ye özgü bileşenleri
/vendorbölümüne yerleştirin. SoC satıcıları, SoC'den bağımsız bileşenler gibi uygun bileşenler için/productbölümünü de kullanabilir. Örneğin, bir SoC satıcısı OEM müşterilerine SoC'den bağımsız bir bileşen sağlıyorsa (bunun ürünle birlikte gönderilmesi isteğe bağlıdır), SoC satıcısı bu bileşeni ürün görüntüsüne yerleştirebilir. Bir bileşenin konumu, mülkiyetine göre belirlenmez, amacına göre belirlenir.Satıcı : SoC'ye özgü bileşenlerden oluşan bir koleksiyon.
ODM: SoC tarafından sağlanmayan, karta özgü bileşenlerden oluşan bir koleksiyon. Tipik olarak SoC satıcısı satıcı imajının sahibiyken, cihaz üreticisi ODM imajının sahibidir. Ayrı bir
/odmbölümü olmadığında, hem SoC satıcısı hem de ODM görüntüleri/vendorbölümünde birleştirilir.
Görüntüler arasındaki arayüzler
SSI'da satıcı ve ürün görselleri için iki ana arayüz mevcuttur:
Satıcı Arayüzü (VINTF) : VINTF, satıcıda ve ODM görüntülerinde bulunan bileşenlerin arayüzüdür. Ürün ve sistem görsellerindeki bileşenler bu arayüz üzerinden yalnızca satıcı ve ODM görselleri ile etkileşime girebilir. Örneğin, bir satıcı görüntüsü, sistem görüntüsünün özel bir kısmına bağlı olamaz (veya bunun tersi de geçerlidir). Bu, başlangıçta görüntüleri sistem ve satıcı bölümlerine ayıran Project Treble'da tanımlanmıştır. Arayüz aşağıdaki mekanizmalar kullanılarak açıklanmaktadır:
- HIDL (Geçit HAL yalnızca
systemvesystem_extmodülleri için 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ığı
- HIDL (Geçit HAL yalnızca
Ürün Arayüzleri : Ürün arayüzü, SSI ile ürün görseli arasındaki arayüzdür. Kararlı bir arayüz tanımlamak, bir SSI'daki ürün bileşenlerini sistem bileşenlerinden ayırır. Ürün Arayüzü, VINTF ile aynı kararlı arayüzleri gerektirir. Ancak Android 11 (ve üzeri) ile başlatılan cihazlar için yalnızca VNDK ve Android SDK API'leri uygulanır.
Android 11'de SSI'yi 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 tanıtıldı. (Bu, /system bölümündeki AOSP tanımlı bileşenlerle sıkı bağlantısı olan, AOSP olmayan bileşenlerin yeridir.) /system_ext bölümünün /system bölümünün OEM'e özgü uzantısı olduğu ve genelinde tanımlanmış bir arayüz olmadığı varsayılır. iki bölüm. /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, sonraki Android sürümündeki /system bölümüyle uyumlu olması gerekmez.
/system_ext bölümüne bir modül yüklemek için Android.bp dosyasına system_ext_specific: true ekleyin. /system_ext bölümü olmayan cihazlar için, bu tür modülleri /system bölümündeki ./system_ext alt dizinine yükleyin.
Tarih
İşte /system_ext bölümüyle ilgili bazı tarihler. Tasarımın amacı, OEM'e özgü tüm bileşenleri, ortak olup olmadıklarına bakılmaksızın /product bölümüne yerleştirmekti. Ancak hepsini bir kerede taşımak mümkün değildi, özellikle de bazı bileşenlerin /system bölümüyle sıkı bir bağlantısı varsa. Sıkıca bağlanmış 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 kendisinin kapsamlı bir şekilde yeniden düzenlenmesini gerektiriyordu ve bu da çok fazla zaman ve çaba harcıyordu. /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ı 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'dekilere mümkün olduğunca benzer kaynaklardan oluşturulduğunda, yükseltme çabasını system_ext görüntüsüne odaklayabilirsiniz.
/system ve /system_ext bölümlerindeki bileşenleri /product bölümüne ayırma
Android 9, /system bölümüyle birleştirilmiş bir /product bölümünü 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ılmıştır. /system_ext bölümünün, /product bölümünün Android 9'da yaptığı sistem bileşenlerini kullanma kısıtlamalarına uyması gerekmez. Android 10'dan başlayarak, /product bölümünün /system bölümünden ayrılması ve kararlı arayüzler kullanması gerekir. /system ve /system_ext bölümleri.
/system_ext bölümünün birincil amacı, /system_ext partition bölümünde açıklandığı gibi birlikte verilen ürün modüllerini kurmak yerine sistem özelliklerini genişletmektir. Bunu yapmak için ürüne özel modülleri ayırın ve bunları /product bölümüne taşıyın. Ürüne özel modüllerin ayrıştırılması /system_ext cihazlar için ortak hale getirir. (Daha fazla ayrıntı için bkz. /system_ext bölümünü ortak hale getirme .)
/product bölümünü sistem bileşenlerinden ayırmak için, /product bölümünün Project Treble ile zaten ayrıştırılmış olan /vendor bölümüyle aynı uygulama politikasına sahip olması gerekir.
Android 11'den başlayarak, /product bölümü için yerel arayüzler ve Java arayüzleri aşağıda açıklandığı şekilde uygulanır. Daha fazla bilgi için bkz. Ürün Bölümü Arayüzlerini Zorunlu Hale Getirme .
- Yerel arayüzler :
/productbölümündeki yerel modüllerin diğer bölümlerden ayrılması gerekir. Ürün modüllerinden izin verilen tek bağımlılıklar/systembölümündeki bazı VNDK kitaplıklarıdır (LLNDK dahil). Ürün uygulamalarının bağlı olduğu JNI kitaplıkları NDK kitaplıkları olmalıdır. - Java arayüzleri :
/productbölümündeki Java (app) modülleri, kararsız olduklarından gizli API'leri kullanamaz. Bu modüller yalnızca/systembölümündeki genel API'leri ve sistem API'lerini ve/systemveya/system_extbölümündeki Java SDK kitaplıklarını kullanmalıdır. Özel API'ler için Java SDK kitaplıklarını 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 için (örneğin, CTS-on-GSI) ve uygulama geliştiricilerinin, gerekli Android sürümünü çalıştıran gerçek bir cihaza sahip olmadıklarında uygulamalarının uyumluluğunu test etmek için kullanabileceği bir referans platformu olarak kullanılır.
OEM'ler ayrıca SSI'larını oluşturmak için GSI'yı kullanabilirler. Görüntüler ve bölümler bölümünde açıklandığı gibi SSI, AOSP tanımlı bileşenler için sistem görüntüsünden ve OEM tanımlı bileşenler için system_ext görüntüsünden oluşur. system görüntüsü olarak GSI kullanıldığında OEM, yükseltme için system_ext görüntüsüne odaklanabilir.
Bu bölüm, AOSP veya AOSP'ye yakın sistem görüntüsü kullanırken özelleştirmelerini /system_ext ve /product bölümleri halinde modülerleştirmek isteyen OEM'ler için bir kılavuz sağlar. 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. Ancak OEM'lerin son adıma (GSI'yı olduğu gibi kullanarak) bir anda ulaşması gerekmez.
1. Adım. OEM'in sistem görüntüsü için general_system.mk'nin devralınması (OEM GSI)
generic_system.mk dosyasını (Android 11'de mainline_system.mk olarak adlandırılmış ve AOSP'de generic_system.mk olarak yeniden adlandırılmıştır) devralarak sistem görüntüsü (OEM GSI), AOSP GSI'nın 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 ait özel dosyaları da içerebilir. Ancak OEM'lerin generic_system.mk dosyasının kendisini değiştirmesine izin verilmez.
Şekil 3. OEM'in sistem görüntüsü için generic_system.mk dosyasını devralma
2. Adım. OEM GSI'nın AOSP GSI ile aynı dosya listesine sahip olmasını sağlama
OEM GSI'nın bu aşamada ek dosyaları olamaz. OEM'in özel dosyaları system_ext veya product bölümlerine taşınmalıdır.
Şekil 4. Eklenen dosyaları OEM GSI'nın dışına taşıma
3. Adım. OEM GSI'da değiştirilen dosyaları sınırlamak için bir izin verilenler listesi tanımlama
Değiştirilen dosyaları kontrol etmek için OEM'ler, compare_images aracını kullanabilir ve AOSP GSI'yi OEM GSI ile karşılaştırabilir. AOSP GSI'yi AOSP öğle yemeği hedefi generic_system_* dan edinin.
compare_images aracını allowlist parametresiyle periyodik olarak çalıştırarak izin verilenler listesi dışındaki farkları izleyebilirsiniz. Bu, OEM GSI'da ek değişiklikler yapılmasını önler.
Şekil 5. OEM GSI'da değiştirilen dosyalar listesini azaltmak için bir izin verilenler listesi tanımlayın
4. Adım. OEM GSI'nın AOSP GSI ile aynı ikili dosyalara sahip olmasını sağlama
İzin verilenler listesinin temizlenmesi, OEM'lerin AOSP GSI'yi kendi ürünleri için sistem görüntüsü olarak kullanmasına olanak tanır. İzin verilenler listesini temizlemek için OEM'ler, OEM GSI'daki değişikliklerinden vazgeçebilir veya değişikliklerini AOSP GSI'nın içermesi için AOSP'ye aktarabilir.
Şekil 6. OEM GSI'nın AOSP GSI ile aynı ikili dosyalara sahip olmasını sağlama
OEM'ler için SSI'nın tanımlanması
Derleme sırasında /system bölümünü koruyun
/system bölümünde ürüne özgü herhangi bir değişikliği önlemek ve OEM GSI'yi tanımlamak için OEM'ler, makro çağrıldıktan sonra sistem modüllerinin herhangi bir bildirimini önlemek amacıyla require-artifacts-in-path adı verilen bir makefile makrosu kullanabilir. Makefile oluşturma ve yapıt yolu denetimini etkinleştirme örneğine bakın.
OEM'ler, ürüne özel modüllerin /system bölümüne geçici olarak kurulmasına izin vermek için bir liste tanımlayabilir. Ancak, OEM GSI'nın tüm OEM ürünleri için ortak olması için listenin boş olması gerekir. Bu süreç, OEM GSI'yi tanımlamak içindir ve AOSP GSI adımlarından bağımsız olabilir.
Ürün arayüzlerini zorunlu kılın
/product bölümünün ayrıştırıldığını garanti etmek için OEM'ler, yerel modüller için PRODUCT_PRODUCT_VNDK_VERSION:= current ve Java modülleri için PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true ayarını yaparak cihazlarının ürün arayüzlerini zorunlu kılmasını sağlayabilir. Bu değişkenler, cihazın PRODUCT_SHIPPING_API_LEVEL 30 büyük veya ona eşitse otomatik olarak ayarlanır. Ayrıntılı bilgi için bkz. Ürün Bölümü Arayüzlerini Zorunlu Hale Getirme .
/system_ext bölümünü ortak hale getirme
/system_ext bölümü, aygıta özgü, sistemle birlikte gelen modüllere sahip olabileceğinden aygıtlar arasında farklılık gösterebilir. SSI, /system ve /system_ext bölümlerinden oluştuğundan, /system_ext bölümündeki farklılıklar, OEM'lerin bir SSI tanımlamasını engeller. OEM'ler kendi SSI'larına sahip olabilir ve tüm farklılıkları ortadan kaldırarak ve /system_ext bölümünü ortak hale getirerek bu SSI'yi birden fazla cihaz arasında paylaşabilirler.
Bu bölümde /system_ext bölümünü ortak hale getirmeye yönelik öneriler verilmektedir.
Sistem bölümündeki gizli API'leri açığa çıkarın
Birçok ürüne özgü uygulama, ürün bölümünde yasaklanan gizli API'leri kullandıklarından ü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ın yerini alacak alternatif genel veya sistem API'lerini bulmaktır. Gizli API'lerin yerini alacak 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 satıcı bölümündeki uygulamalara sağlayabilir. OEM'lerin geriye dönük uyumluluk için ürüne yönelik API'leri dondurması gerekir.
Tüm APK'ların üst kümesini ekleyin 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üne veya satıcı bölümüne taşımak için ayrıştırmak zor olabilir. Geçici bir çözüm olarak OEM'ler, SSI'nın tüm modülleri içermesini sağlayabilir ve ardından bir SKU özelliğini ( ro.boot.hardware.sku ) kullanarak istenmeyenleri filtreleyebilir. Filtreyi kullanmak için OEM'ler config_disableApkUnlessMatchedSku_skus_list ve config_disableApksUnlessMatchedSku_apk_list çerçeve kaynaklarını kaplar.
Daha kesin 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 çağırır.
Statik kaynak yer paylaşımı kullanmak yerine RRO'yu tanımlayın
Statik bir kaynak yer paylaşımı, yer paylaşımlı paketleri yönetir. Ancak bir SSI tanımlamayı engelleyebilir, bu nedenle RRO özelliklerinin açıldığından ve düzgün şekilde ayarlandığından emin olun. Özellikleri aşağıdaki gibi ayarlayarak, OEM'ler otomatik olarak oluşturulan tüm kaplamalara RRO olarak sahip olabilir.
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 bir RRO tanımlayın. Ayrıntılı bilgi için bkz. Çalışma Zamanı Kaynak Katmanları (RRO'lar) . OEM'ler ayrıca android:requiredSystemPropertyName ve android:requiredSystemPropertyValue niteliklerini kullanarak sistem özelliklerine bağlı koşullu RRO'ları tanımlayabilir.
Sık Sorulan Sorular (SSS)
Birden fazla SGK tanımlayabilir miyim?
Cihazların (veya cihaz grubunun) ortak noktalarına 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 getirmeye çalışabilir. Bir cihaz grubunun birçok farklılığı varsa birden fazla SSI tanımlamak daha iyidir.
Bir OEM GSI için generic_system.mk ( mainline_system.mk ) değiştirebilir miyim?
Hayır. Ancak OEM'ler, bir OEM GSI için generic_system.mk dosyasını devralan yeni bir makefile tanımlayabilir ve bunun yerine yeni makefile'ı kullanabilir. Örnek için bkz. Ürün Bölümü Arayüzlerini Zorunlu Hale Getirme .
Uygulamamla çakışan modülleri generic_system.mk kaldırabilir miyim?
Hayır. GSI'da minimum önyüklenebilir ve test edilebilir modül seti 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 bir hata bildirin.