Eşleştirme Kuralları

İki çift uyumluluk matrisi ve bildiriminin, çerçeve ve satıcı uygulamasının birbiriyle çalışabileceğini doğrulamak için uzlaştırılması amaçlanmıştır. Bu doğrulama, çerçeve uyumluluk matrisi ile cihaz bildirimi arasında ve ayrıca çerçeve bildirimi ile cihaz uyumluluk matrisi arasında bir eşleşme üzerine başarılı olur.

Bu doğrulama de, yapı anda yapılır OTA boot zamanında, güncelleme paketi oluşturma zamanında ve VTS uyumluluk testleri.

Aşağıdaki bölümler, çeşitli bileşenler tarafından kullanılan eşleştirme kurallarının ayrıntılarını vermektedir.

Çerçeve uyumluluk matrisi sürümü eşleşmeleri

Bir çerçeve uyumluluk matrisi ile bir aygıt tezahür eşleştirmek için, belirtilen taşıma FCM versiyonu manifest.target-level ile belirtilen FCM sürümüne tam olarak eşit olmalıdır compatibility-matrix.level . Aksi halde eşleşme olmaz.

Çerçeve uyumluluk matrisi ile istendiğinde libvintf , bu maç nedeniyle her zaman başarılı libvintf , cihaz manifestosunu açar Kargo FCM Versiyon alır ve en çerçeve uyumluluk matrisi döndürür Kargo FCM Versiyon (artı yüksek FCM uyumluluk matrisleri bazı opsiyonel HAL'lere Sürümler).

HAL maçları

Sürümleri HAL maç kuralı tanımlar hal kabul edilir bir manifesto dosyasında unsurları tekabül uyumluluk matrisi sahibi tarafından desteklenecek.

HIDL ve yerel HAL'ler

HIDL ve yerel HAL'ler için eşleşme kuralları aşağıdaki gibidir.

  • Birden <hal> elemanlar tek VE ilişkiyle değerlendirilir.
  • Birden <version> aynı bünyesindeki unsurların <hal> varsa veya ilişki. İki veya daha fazla belirtilirse, sürümlerden yalnızca birinin uygulanması gerekir. (Bkz DRM örneği aşağıda).
  • Birden <instance> ve <regex-instance> aynı bünyesindeki unsurların <hal> tek VE ilişkiyle değerlendirilir. (Bkz DRM örneği aşağıda).

Örnek: Bir modül için başarılı HAL eşleşmesi

2.5 sürümündeki bir HAL için eşleşme kuralı aşağıdaki gibidir:

Matris Eşleşen Manifest
2.5 2.5-2.∞. Uyumluluk matriste, 2.5 için kısaltmadır 2.5-5 .
2.5-7 2.5-2.∞. Aşağıdakileri belirtir:
  • 2.5, gereken minimum sürümdür, yani HAL 2.0-2.4 sağlayan bir bildirim uyumlu değildir.
  • 2.7, talep edilebilecek maksimum sürümdür, yani uyumluluk matrisinin (çerçeve veya cihaz) sahibi 2.7'den sonraki sürümleri talep etmeyecektir. Eşleşen bildirimin sahibi, 2.7 istendiğinde hala 2.10 sürümünü (örnek olarak) sunabilir. Uyumluluk matrisi sahibi, yalnızca istenen hizmetin API sürüm 2.7 ile uyumlu olduğunu bilir.
  • -7 yalnızca bilgilendirme amaçlıdır ve OTA güncelleme sürecini etkilemez.
Böylece, bildirim dosyası sürüm 2.10 bir HAL sahip bir cihaz bir çerçeve ile uyumlu kalan bildiren 2.5-7 uygunluğu matris içinde mevcuttur.

Örnek: DRM modülü için başarılı HAL eşleşmesi

Çerçeve uyumluluk matrisi, DRM HAL için aşağıdaki sürüm bilgilerini belirtir:

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

Bir satıcı aşağıdaki durumlardan BİRİNİ uygulamalıdır; herhangi biri

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
YA
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1

VE ayrıca şu örneklerin tümünü uygulamalıdır:

android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

AIDL HAL'leri

Android 11'den sonraki tüm Android sürümleri (Android 11 hariç), VINTF'deki AIDL HAL sürümlerini destekler. AIDL HAL'lere için eşleşme kuralları HIDL ve yerli HAL'lere benzeyen, hiçbir büyük versiyonlarını orada oldukları hariç, HAL örneği başına bir sürümü tam olarak orada ( 1 sürümü belirtilmemiş ise).

  • Birden <hal> elemanlar tek VE ilişkiyle değerlendirilir.
  • Birden <instance> ve <regex-instance> aynı bünyesindeki unsurların <hal> tek VE ilişkiyle değerlendirilir. (Bkz vibratör örneği aşağıda).

Örnek: Bir modül için başarılı HAL eşleşmesi

Sürüm 5'teki bir HAL için eşleşme kuralı aşağıdaki gibidir:

Matris Eşleşen Manifest
5 5-∞. Uyumluluk matriste, 5 için kısaltmadır 5-5 .
5-7 5-∞. Aşağıdakileri belirtir:
  • 5, gereken minimum sürümdür, yani HAL 1-4 sağlayan bir bildirim uyumlu değildir.
  • 7, talep edilebilecek maksimum sürümdür, yani uyumluluk matrisinin (çerçeve veya cihaz) sahibi 7'den sonraki sürümleri talep etmeyecektir. 7 istendiğinde eşleşen bildirimin sahibi, sürüm 10'u (örnek olarak) sunmaya devam edebilir . Uyumluluk matrisi sahibi, yalnızca istenen hizmetin API sürüm 7 ile uyumlu olduğunu bilir.
  • -7 yalnızca bilgilendirme amaçlıdır ve OTA güncelleme sürecini etkilemez.
Böylece, bildirim dosyası sürüm 10 bir HAL sahip bir cihaz bir çerçeve ile uyumlu kalan bildiren 5-7 uygunluğu matris içinde mevcuttur.

Örnek: Birden çok modül için başarılı HAL eşleşmesi

Çerçeve uyumluluk matrisi, vibratör ve kamera HAL'leri için aşağıdaki sürüm bilgilerini belirtir:

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

Bir satıcının tüm bu örnekleri uygulaması gerekir:

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

Çekirdek eşleşmeleri

<kernel> çerçeve uyumluluk matrisi bölüm cihazda Linux çekirdeğinin çerçevenin gerekliliklerini açıklar. Bu bilgiler karşı eşleştirilecek anlamına gelir bilgilere cihazın VINTF nesnesi tarafından bildirilen alır çekirdek hakkında.

Çekirdek dallarını eşleştir

Her çekirdek dal eki (örneğin, 5.4- r ) (örneğin 5), benzersiz bir çekirdek FCM versiyonu ile eşleştirilir. Eşleme, sürüm harfleri (örneğin, R) ve FCM sürümleri (örneğin, 5) arasındaki eşleştirmeyle aynıdır.

Cihaz açıkça cihaz manifest'te çekirdek FCM versiyonunu belirtir VTS testleri uygulamak, /vendor/etc/vintf/manifest.xml , aşağıdakilerden biri doğruysa:

  • Çekirdek FCM sürümü, hedef FCM sürümünden farklıdır. Örneğin, yukarıda sözü edilen cihaz, bir hedef FCM sürüm 4 sahiptir ve çekirdek FCM versiyonu 5 (çekirdek dal sonekidir r ).
  • Çekirdek FCM sürümü daha büyük ya da 5 (çekirdek dal eki eşittir r ).

VTS testleri, çekirdek FCM sürümü belirtilirse, çekirdek FCM sürümünün aygıt bildirimindeki hedef FCM sürümünden büyük veya ona eşit olmasını zorunlu kılar.

Örnek: Çekirdek dalını belirleyin

Cihaz (Android 10'da yayınlandı) hedef FCM sürümü 4 var, ama çalışır gelen çekirdek ise 4.19-r dalı, cihaz tezahür aşağıdaki belirtmelidir:

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

İlgili gereksinimleri karşı VINTF nesne Çekler çekirdek uyumluluk 4.19-r FCM sürüm 5 Bu şartlar belirtilen çekirdek dalı, inşa edilir kernel/configs/r/android-4.19 Android kaynak ağacında.

Çekirdek sürümlerini eşleştirin

Bir matris, çok sayıda içerebilir <kernel> bölümleri, her biri farklı bir version biçimini kullanarak nitelik:

${ver}.${major_rev}.${kernel_minor_rev}

VINTF nesnesi yalnızca dikkate <kernel> aynı FCM versiyonu ile eşleşen FCM olan bölümü ${ver} ve ${major_rev} aygıt çekirdek olarak (diğer bir deyişle, version="${ver}.${major_rev}.${matrix_minor_rev}") ; diğer bölümler dikkate alınmaz. Buna ek olarak, çekirdekten alt sürüm uyumluluk matristen bir değer (olmalıdır ${kernel_minor_rev} >= ${matrix_minor_rev} ). Hayır ise <kernel> bölümü bu gereksinimleri karşılayan, olmayan bir eşleşme.

Örnek: Eşleştirme için gereksinimleri seçin

Aşağıdaki varsayımsal durumda düşünün nerede FCM'ler /system/etc/vintf aşağıdaki şartları (başlık ve alt bilgi etiketler yoksa) beyan:

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

Hedef FCM sürümü, çekirdek FCM sürümü ve çekirdek sürümü birlikte FCM'lerden çekirdek gereksinimlerini seçer:

Hedef FCM sürümü Çekirdek FCM sürümü Çekirdek sürümü Uyuşuyor
3 (P) belirtilmemiş 4.4.106 Eşleşme yok (küçük sürüm uyuşmazlığı)
3 (P) belirtilmemiş 4.4.107 4.4-p
3 (P) belirtilmemiş 4.19.42 4.19-q (aşağıdaki nota bakınız)
3 (P) belirtilmemiş 5.4.41 5.4-r (aşağıdaki nota bakınız)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 Hiçbir maç (hayır 4.19-p çekirdek şubesi)
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) belirtilmemiş 4.4.107 Eşleşme (bir 4.4-q çekirdek dal)
4 (Q) belirtilmemiş 4.9.165 4.9-q
4 (Q) belirtilmemiş 5.4.41 5.4-r (aşağıdaki nota bakınız)
4 (Q) 4 (Q) 4.9.165 4.9-q
4 (Q) 4 (Q) 5.4.41 Hiçbir maç (hayır 5.4-q çekirdek şubesi)
4 (Q) 5 (R) 4.14.105 4.14-r
4 (Q) 5 (R) 5.4.41 5.4-r
5 (R) belirtilmemiş herhangi VTS başarısız (Hedef FCM sürüm 5 için çekirdek FCM sürümünü belirtmelidir)
5 (R) 4 (Q) herhangi VTS başarısız oluyor (çekirdek FCM sürümü < hedef FCM sürümü)
5 (R) 5 (R) 4.14.180 4.14-r

Çekirdek yapılandırmalarını eşleştirin

Eğer <kernel> bölüm eşleşmesinin, süreç maç için çalışarak devam config karşı elemanları /proc/config.gz . Uyumluluk matrisinde Her bir yapılandırma eleman için, bakar /proc/config.gz yapılandırma mevcut olup olmadığını görmek için. Bir yapılandırma madde olarak ayarlandığında n eşleşmesi için uyumluluk matris içinde <kernel> bölümü, bu eksik olması gerekir /proc/config.gz . Son olarak, not uyumluluk matrisi içinde bir yapılandırma madde ya da mevcut olabilir veya olmayabilir /proc/config.gz .

Örnek: Çekirdek yapılandırmalarını eşleştirin

  • <value type="string">bar</value> maçlar "bar" . Tırnaklar uyumluluk matris içinde çıkarılmıştır fakat mevcut olan /proc/config.gz .
  • <value type="int">4096</value> maçları 4096 veya 0x1000 veya 0X1000 .
  • <value type="int">0x1000</value> maçları 4096 veya 0x1000 veya 0X1000 .
  • <value type="int">0X1000</value> maçları 4096 veya 0x1000 veya 0X1000 .
  • <value type="tristate">y</value> eşleşen y .
  • <value type="tristate">m</value> maçları m .
  • <value type="tristate">n</value> araçlar yapılandırma öğesi var OLMAMALI /proc/config.gz .
  • <value type="range">1-0x3</value> eşleşen 1 , 2 ya da 3 ya da onaltılı eşdeğeri.

Örnek: Başarılı çekirdek eşleşmesi

FCM sürüm 1 ile bir çerçeve uyumluluk matrisi aşağıdaki çekirdek bilgilerine sahiptir:

<kernel version="4.14.42">
   <config>
      <key>CONFIG_TRI</key>
      <value type="tristate">y</value>
   </config>
   <config>
      <key>CONFIG_NOEXIST</key>
      <value type="tristate">n</value>
   </config>
   <config>
      <key>CONFIG_DEC</key>
      <value type="int">4096</value>
   </config>
   <config>
      <key>CONFIG_HEX</key>
      <value type="int">0XDEAD</value>
   </config>
   <config>
      <key>CONFIG_STR</key>
      <value type="string">str</value>
   </config>
   <config>
      <key>CONFIG_EMPTY</key>
      <value type="string"></value>
   </config>
</kernel>

Önce çekirdek dalı eşleştirilir. Çekirdek dal aygıt bildiriminde belirtilen manifest.kernel.target-level varsayılan, manifest.level önceki belirtilmemişse. Aygıttaki çekirdek dalı görünürse:

  • 1'dir, bir sonraki adıma geçer ve çekirdek sürümünü kontrol eder.
  • 2, matrisle eşleşme yok. VINTF nesneleri, bunun yerine FCM sürüm 2'deki matristen çekirdek gereksinimlerini okur.

Ardından, çekirdek sürümü eşleştirilir. Eğer bir cihaz uname() raporlar:

  • 4.9.84 (ayrı bir çekirdek bölümü olmadığı sürece matrise eşleşme <kernel version="4.9.x"> , burada x <= 84 )
  • 4.14.41 (matrise eşleşme, daha küçük version )
  • 4.14.42 (matrisle eşleştir)
  • 4.14.43 (matriksle eşleşme)
  • 4.1.22 (ayrı bir çekirdek bölümü olmadığı sürece matrise eşleşme <kernel version="4.1.x"> burada x <= 22 )

Uygun sonra <kernel> bölümü her biri için, seçilmiş <config> dışında bir değere sahip madde n yararlanarak, karşılık gelen giriş mevcut bekliyoruz /proc/config.gz ; Her biri için <config> değerle öğe n , biz karşılık gelen giriş mevcut olmayabilir bekliyoruz /proc/config.gz . Biz içeriğini bekliyoruz <value> tam satır karakteri veya (tırnak işaretleri dahil) eşit işaretinden sonra metin, maç için # baştaki ve sondaki boşluk kesik ile,.

Aşağıdaki çekirdek yapılandırması başarılı bir eşleşme örneğidir:

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

Aşağıdaki çekirdek yapılandırması, başarısız bir eşleşme örneğidir:

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

SE politikası eşleşmeleri

SE politikası aşağıdaki eşleşmeleri gerektirir:

  • <sepolicy-version> her büyük versiyonu için alt sürümleri kapalı aralığını tanımlar. Cihaz tarafından bildirilen sepolicy sürümünün, çerçeve ile uyumlu olması için bu aralıklardan biri içinde olması gerekir. Maç kuralları HAL sürümlerine benzer; sepolicy sürümünün, aralık için minimum sürümden daha yüksek veya ona eşit olması bir eşleşmedir. Maksimum sürüm tamamen bilgi amaçlıdır.
  • <kernel-sepolicy-version> yani policydb sürümü. Az olmalıdır security_policyvers() cihaz tarafından rapor edildi.

Örnek: Başarılı SE politika eşleşmesi

Çerçeve uyumluluk matrisi aşağıdaki sepolicy bilgilerini belirtir:

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

Cihazda:

  • Tarafından döndürülen değeri security_policyvers() ya da 30'a eşit Aksi takdirde bir eşleşme olmayan daha büyük olmalıdır. Örneğin:
    • Bir cihaz 29 döndürürse, eşleşme değildir.
    • Bir cihaz 31 döndürürse, bir eşleşmedir.
  • SE Politikası sürümü 25.0-∞ veya 26.0-∞'den biri olmalıdır. Aksi takdirde bu bir eşleşme değildir. ( " -3 " sonra " 26.0 ", tamamen bilgi).

AVB sürüm eşleşmeleri

AVB sürümü, MAJOR.MINOR biçiminde (örn. 1.0, 2.1) bir MAJOR sürümü ve MINOR sürümü içerir. Detaylar için bakınız Sürüm Oluşturma ve Uyumluluk . AVB sürümü aşağıdaki sistem özelliklerine sahiptir:

  • ro.boot.vbmeta.avb_version olduğu libavb bootloader sürüm
  • ro.boot.avb_version olan libavb Android OS sürümü ( init/fs_mgr )

Sistem özelliği, yalnızca AVB meta verilerini doğrulamak için karşılık gelen libavb kullanıldığında görünür (ve Tamam döndürür). Bir doğrulama hatası oluştuysa (veya hiç doğrulama gerçekleşmediyse) yoktur.

Bir uyumluluk eşleşmesi aşağıdakileri karşılaştırır:

  • sysprop ro.boot.vbmeta.avb_version ile avb.vbmeta-version çerçeve uyumluluk matrisinden;
    • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
  • sysprop ro.boot.avb_version ile avb.vbmeta-version çerçeve uyumluluk matrisinden.
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Bootloader veya Android işletim iki kopyasını içerebilir libavb yükseltme cihazları ve fırlatma cihazları için farklı bir BÜYÜK sürümü ile kütüphaneler, her. Bu durumda, aynı imzasız sistem görüntüsü paylaşılabilir ancak nihai imzalı sistem görüntüleri (farklı olan farklı avb.vbmeta-version ):

Şekil 1. AVB sürümü ile eşleşen ( /system P, tüm diğer bölümleri de O 'dur).


Şekil 2. AVB versiyonu maçları (tüm bölümler P vardır).

Örnek: Başarılı AVB sürüm eşleşmesi

Çerçeve uyumluluk matrisi aşağıdaki AVB bilgilerini belirtir:

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

Cihazda:

ro.boot.avb_version              == 1.0 &&
ro.boot.vbmeta.avb_version       == 2.1  mismatch 
ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 3.0  mismatch 
ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 2.3  match 
ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match 

OTA sırasında eşleşen AVB sürümü

Android 9 veya daha eski sürümlerle başlatılan cihazlar için, Android 10'a güncelleme yapılırken çerçeve uyumluluk matrisindeki AVB sürüm gereksinimleri, cihazdaki mevcut AVB sürümüyle eşleştirilir. AVB sürümünün bir OTA sırasında ana sürüm yükseltmesi varsa (örneğin, 0.0'dan 1.0'a), VINTF OTA'daki uyumluluk denetimi, OTA'dan sonraki uyumluluğu yansıtmaz.

Sorunu hafifletmek için, OEM OTA paketinde sahte AVB sürümü (yerleştirebilirsiniz compatibility.zip kontrolünden geçmek için). Böyle yaparak:

  1. Android 9 kaynak ağacına aşağıdaki CL'leri kesin olarak seçin:
  2. Define BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE cihaz için. Değeri, OTA'dan önceki AVB versiyonuna, yani cihazın piyasaya sürüldüğü andaki AVB versiyonuna eşit olmalıdır.
  3. OTA paketini yeniden oluşturun.

Bu değişiklikler otomatik olarak yerleştirmek BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE olarak compatibility-matrix.avb.vbmeta-version aşağıdaki dosyalardaki:

  • /system/compatibility_matrix.xml cihazında (Android 9'da kullanılan değildir)
  • system_matrix.xml içinde compatibility.zip OTA paketinde

Bu değişiklikler dahil olmak üzere diğer çerçeve uyumluluk matrisinim etkilemez /system/etc/vintf/compatibility_matrix.xml . OTA sonra yeni değer /system/etc/vintf/compatibility_matrix.xml yerine uyumluluk kontrolü için kullanılır.

VNDK sürüm eşleşmeleri

Cihaz uyumluluk matris gerekli VNDK versiyonu ilan compatibility-matrix.vendor-ndk.version . Cihaz uyumluluk matrisi bir yoksa <vendor-ndk> etiketi, hiçbir şartlar empoze edilir ve dolayısıyla her zaman bir maç olarak kabul edilir.

Cihaz uyumluluk matrisi var bir yaparsa <vendor-ndk> etiketi, bir <vendor-ndk> bir eşleme ile giriş <version> çerçeve manifest'te çerçevesinde sağladığının VNDK satıcı anlık kümesinden olarak aranır. Böyle bir giriş yoksa, eşleşme yoktur.

Böyle bir giriş varsa, cihaz uyumluluk matrisinde belirtilen kitaplıklar kümesi, çerçeve bildiriminde belirtilen kitaplıklar kümesinin bir alt kümesi olmalıdır; aksi takdirde, giriş bir eşleşme olarak kabul edilmez.

  • Özel bir durum olarak, cihaz uyumluluk matrisinde hiçbir kitaplık numaralandırılmazsa, boş küme herhangi bir kümenin alt kümesi olduğundan giriş her zaman bir eşleşme olarak kabul edilir.

Örnek: Başarılı VNDK sürüm eşleşmesi

Cihaz uyumluluk matrisi VNDK'da aşağıdaki gereksinimi belirtiyorsa:

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

Çerçeve bildiriminde yalnızca sürüm 27'ye sahip giriş dikkate alınır.

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

VNDK sürümü 27 çerçeve manifest olduğundan ve Örnek A, bir maç {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so} .

<!-- Framework Manifest Example B -->
<vendor-ndk>
    <version>26</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>
<vendor-ndk>
    <version>27</version>
    <library>libbase.so</library>
</vendor-ndk>

Örnek B bir eşleşme değil. VNDK versiyonu 27 çerçeve manifest'te olsa bile, libjpeg.so o anlık framework tarafından desteklenmemektedir. VNDK sürüm 26 yoksayılır.

Sistem SDK sürümü eşleşmeleri

Cihaz uyumluluk matris gerekli sistem SDK sürüm bir dizi bildirir compatibility-matrix.system-sdk.version . Set beyan olarak sağlanan Sistem SDK sürümleri bir alt kümesidir yalnızca bir eşleşme var manifest.system-sdk.version çerçeve manifest'te.

  • Özel bir durum olarak, cihaz uyumluluk matrisinde hiçbir Sistem SDK sürümü numaralandırılmamışsa, boş küme herhangi bir kümenin alt kümesi olduğundan, her zaman bir eşleşme olarak kabul edilir.

Örnek: Başarılı Sistem SDK sürümü eşleşmesi

Cihaz uyumluluk matrisi, Sistem SDK'sında aşağıdaki gereksinimi belirtiyorsa:

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Ardından çerçeve, eşleşmesi için Sistem SDK'sının 26 ve 27 sürümünü sağlamalıdır.

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Örnek A bir eşleşmedir.

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

Örnek B bir eşleşmedir.

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

Örnek C bir eşleşme değil, çünkü Sistem SDK'sı 27 sürümü sağlanmadı.