Paylaşılan sistem görüntüsü

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

Arka plan

Android Açık Kaynak Projesi (AOSP) çerçevesi, eski tedarikçi uygulamalarıyla geriye dönük uyumluluğu korumak için Mainline mimarisine uygundur. Örneğin, Android 10 AOSP kaynaklarından oluşturulan genel sistem görüntüsü (GSI), Android 8 veya sonraki sürümleri çalıştıran Treble uyumlu tüm cihazlarda çalıştırılabilir.

Mainline, Android'i iki ayrı bölüme ayırarak bunu başarır: donanıma özel tedarikçi uygulaması ve genel Android OS çerçevesi. Her bileşen ayrı bir bölüme yüklenir. Donanıma özel yazılımlar için tedarikçi bölümü, genel işletim sistemi için ise sistem bölümü kullanılır. Bunlar arasında, satıcı arayüzü (VINTF) adı verilen sürüm oluşturulmuş bir arayüz uygulanır. Bu bölümlendirme sistemi, OEM'lerin sistem bölümünü tedarikçi bölümüne dokunmadan değiştirmesine ve bunun tersine olanak tanır.

Geçmişte, SoC tedarikçileri ve OEM'ler, tüketici cihazlarında gönderilen Android çerçeve sürümünü büyük ölçüde değiştiriyordu (ayrıntılar için Android sürümünün yaşam döngüsü başlıklı makaleyi inceleyin). Bu çerçeve uzantıları nadiren geriye dönük uyumluluk göz önünde bulundurularak tasarlandığından cihaza özel değişiklikler, sonraki işletim sistemi yükseltmelerinin karmaşıklığını ve maliyetini önemli ölçüde artırdı. Android 10 (API düzeyi 29) ve önceki sürümlerde, ekosistemde iş ortaklarının Android çerçevesi için modüler uzantılar oluşturmasına olanak tanıyan net ve standartlaştırılmış bir mimari yoktu.

Bu sayfada, SoC tedarikçilerinin ve OEM'lerin nasıl paylaşılan bir sistem görüntüsü (SSI) oluşturabileceği açıklanmaktadır. SSI, Android OS kaynaklarından oluşturulan ve birden fazla cihazda yeniden kullanılabilen birleşik bir çerçeve görüntüsüdür. Bu bölümlenmiş mimari sayesinde satıcı uygulamalarıyla temiz bir geriye dönük uyumluluk sağlayarak SSI, Android OS yükseltmelerinin maliyetini ve karmaşıklığını önemli ölçüde azaltır.

Uygulama ayrıntıları için GSI tabanlı SSI için önerilen adımlar başlıklı makaleyi inceleyin. Adımlar modülerdir. Mimarınıza bağlı olarak tüm aşamaları değil, belirli aşamaları (ör. 1. Adım: OEM sistem görüntüsü (OEM GSI) için generic_system.mk'yı devralın) uygulamayı seçebilirsiniz.

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 OS 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 SSI'ları yeniden kullanabilir.

OEM'ler ve SoC tedarikçileri, özel özellikler ve değişiklikler içeren SSI'ler oluşturabilir. Bu sayfada sağlanan mekanizmalar ve en iyi uygulamalar, OEM'lerin şu 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 daha kolay hale getirmek için Android sistemini modüler uzantılarla güncelleyin.

Ürüne özel bileşenleri ürün bölümüne ayırma fikri, Mainline'ın SoC'ye özel bileşenleri satıcı bölümüne ayırmasına 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 terimi, bölümler haline gelen görüntülere yüklenen tüm kaynakları, ikili dosyaları, metinleri ve kitaplıkları tanımlar.

SSI ile ilgili bölümler

Şekil 1'de SSI'nin etrafındaki bölümler, bölümler arasındaki sürüm oluşturulmuş arayüzler ve arayüzlerdeki politikalar gösterilmektedir. Bu bölümde, her bölüm ve arayüz 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 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: Bir OEM'ye özgü olan ve birden fazla cihazda bulunabilen bir resim. 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, tek bir /system resmi veya /system ve /system_ext bölümlerinden oluşur.

• Ürün resmi: Android OS'te OEM özelleştirmelerini ve uzantılarını temsil eden, ürüne veya cihaza özel bileşenler koleksiyonu. SoC'ye özel 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.

• Tedarikçi resmi: SoC'ye özgü bileşenlerden oluşan bir koleksiyon.

• ODM resmi: Çip üzerinde sistem tarafından sağlanmayan, karta özel bileşenler koleksiyonu. Genellikle satıcı resmi, çip üzerinde sistem satıcısına aittir. ODM resmi ise cihaz üreticisine aittir. Ayrı bir /odm bölümü olmadığında hem çip üzerinde sistem satıcısı hem de ODM resimleri /vendor bölümünde birleştirilir.

/system_ext bölümü

/system_ext bölümü isteğe bağlıdır. Bu bölümü, AOSP tabanlı bileşenlerle sıkı bir şekilde bağlı olan özel özellikler ve uzantılar için kullanın. Bu bölümün, iki bölüm arasında tanımlanmış bir arayüz olmadan /system bölümünün OEM'e özel 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. /system bölümündeki bileşenler ise /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 bir /system_ext bölümünün, 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ünün orijinal tasarım amacı, 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ı bağlantılı olduğundan hepsini aynı anda taşımak mümkün değildi. Sıkıca bağlı bir bileşeni /product bölümüne taşımak için ürün arayüzü genişletilmelidir. Bu durum genellikle bileşenin kendisinin kapsamlı bir şekilde yeniden düzenlenmesini gerektiriyordu. Bu da çok fazla zaman ve çaba gerektiriyordu. /system_ext bölümü, /system_ext bölümüne taşınmaya hazır olmayan bileşenleri geçici olarak barındırmak için oluşturuldu./product 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 yararlı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.

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 tedarikçi 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, görüntüleri sistem ve satıcı bölümlerine ayıran Treble mimarisinde (artık daha geniş olan Mainline mimarisinin bir parçası) tanımlanır. Arayüz, aşağıdaki mekanizmalar kullanılarak açıklanır:

  • HIDL (Passthrough HAL yalnızca system ve system_ext modü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ığı

• Ü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'daki sistem bileşenlerinden ayırır.

SSI'yı etkinleştirme

Bu bölümde, Android 11 ve sonraki sürümlerde SSI'nin nasıl destekleneceği açıklanmaktadır.

Bileşenlerin paketini çözme

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

• Yerleşik arayüzler: /product bölümündeki yerleşik 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.

Ürün arayüzlerini zorunlu kılma

OEM'ler, /product bölümünün paketlenmediğinden emin olmak için cihazlarında yerleşik modüller için PRODUCT_PRODUCT_VNDK_VERSION:= current, Java modülleri için PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true ayarını yaparak ürün arayüzlerini zorunlu kılabilir. Bu değişkenler, cihazın PRODUCT_SHIPPING_API_LEVEL değeri 30 değerine eşit veya bu değerden büyükse 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.

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. 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'lerini 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'lere yönelik yönergeler verilmektedir. 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) hemen ulaşması gerekmez.

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

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) öğesini devralarak sistem görüntüsü (OEM GSI), 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.

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

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

OEM GSI'sinde bu aşamada ek dosyalar bulunamaz. Bu nedenle, OEM'e özel dosyaları system_ext veya product bölümlerine taşıyın.

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

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

OEM'ler, değiştirilen dosyaları kontrol etmek için compare_images aracını kullanabilir ve AOSP GSI ile OEM GSI'yi karşılaştırabilir. AOSP GSI'yi AOSP lunch hedefinden generic_system_* 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'sinde ek değişiklik yapılmasını engeller.

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

4. adım: OEM GSI'nin, AOSP GSI ile aynı ikili dosyalara sahip olmasını sağlayın

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

Şekil 6. OEM GSI'nin, AOSP GSI ile aynı ikili dosyalara sahip olmasını sağlayın.

SSI'yı tanımlama

OEM'ler, SSI'lerini tanımlamak için aşağıdaki kılavuzdan yararlanabilir.

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

/system bölümünde ürüne özel değişikliklerden kaçınmak 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. 1. adım: Makefile oluşturun ve yapay nesne yolu kontrolünü etkinleştirin bölümündeki örneğe bakın.

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.

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

/system_ext bölümü, cihaza özel ve sistemle birlikte gelen modüller içerebileceğ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ını oluşturabilir ve farklılıkları kaldırıp /system_ext bölümünü ortak hale getirerek bu SSI'yı birden fazla cihazda 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 özel 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. Bu kitaplık, 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.

SKU'ya özgü uygulama devre dışı bırakma özelliğinin yerine geçme

Android 16, çerçeve kaynağı katmanlarını kullanarak donanım SKU'suna göre APK'ları seçmeli olarak devre dışı bırakmaya yönelik eski mekanizmayı kullanımdan kaldırdı ve kaldırdı (config_disableApksUnlessMatchedSku_apk_list ve config_disableApkUnlessMatchedSku_skus_list). Ayrıntılar için aosp/3444399 adresine bakın.

Önerilen alternatif, SKU'ya özel dizinlerde install-in-user-type sistem yapılandırmasını kullanmaktır. Bu yaklaşım, paketin yalnızca yükleme sonrası devre dışı bırakılması yerine belirli bir SKU'daki herhangi bir kullanıcı için yüklenmesini engeller.

1. Tüm APK'ları (sistem görüntünüzdeki tüm SKU'lar için olası tüm uygulamaların üst kümesi) genellikle /product bölümünde olmak üzere görüntüye dahil edin.

2. Cihaz SKU'sunun, ro.boot.hardware.sku system property (sistem tarafından önyükleme sırasında cihaz SKU'sunu tanımlamak için kullanılır) içinde doğru şekilde ayarlandığından emin olun.

3. /product/etc/sysconfig/ altında, sku_<SKU_NAME> adlandırma kuralını kullanarak SKU'ya özel sysconfig alt dizinleri oluşturun. Sistem, ro.boot.hardware.sku özelliğiyle eşleşen dizindeki yapılandırmaları otomatik olarak yükler. Örnek yol: /product/etc/sysconfig/sku_basic_model/.

4. Uygulama yükleme önleme özelliğini yapılandırın. SKU'ya özel dizinde, bir XML yapılandırma dosyası (örneğin, disabled_apps.xml) oluşturun ve belirli paketleri hariç tutmak için <do-not-install-in> etiketini kullanın.

XML örneği (/product/etc/sysconfig/sku_basic_model/disabled_apps.xml):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

İki yöntemin karşılaştırması aşağıda verilmiştir:

Daha ayrıntılı kontrol gerektiren durumlarda (ör. normalde tüm SKU'larda varsayılan olarak yüklenen bir uygulamayı devre dışı bırakma) Android, sysconfig'de disabled-in-sku ve enabled-in-sku-override etiketlerini de destekler:

• <disabled-in-sku package="com.example.app" />, uygulamayı dünya genelinde devre dışı bırakır.

• <enabled-in-sku-override package="com.example.app" />, ilgili sku_<name> dizinine yerleştirildiğinde belirli bir SKU için uygulamayı yeniden etkinleştirir.

Statik kaynak yer paylaşımı kullanmak yerine RRO 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 bir RRO tanımlayın. Ayrıntılı bilgi için Uygulama kaynaklarının değerini çalışma zamanında değiştirme 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)

Aşağıda, SSI hakkında sık sorulan sorular yer almaktadır.

Birden fazla SSI tanımlayabilir miyim?

Bu, cihazların (veya cihaz grubunun) ortaklığına ve özelliklerine bağlıdır. OEM'ler, Make 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.

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 generic_system.mk dosyasını güncellemek için hata kaydı oluşturun.