Eşleştirme Kuralları

Çerçeve ve satıcı uygulamasının birbiriyle çalışabileceğini doğrulamak için iki uyumluluk matrisi ve bildirimi çiftinin uzlaştırılması amaçlanmıştır. Bu doğrulama, çerçeve uyumluluk matrisi ile cihaz bildirimi arasındaki ve ayrıca çerçeve bildirimi ile cihaz uyumluluk matrisi arasındaki bir eşleşmede başarılı olur.

Bu doğrulama, derleme zamanında, OTA güncelleme paketi oluşturma zamanında, önyükleme zamanında ve VTS uyumluluk testlerinde yapılır.

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 cihaz bildirimini bir çerçeve uyumluluk matrisiyle eşleştirmek için manifest.target-level tarafından belirtilen Shipping FCM sürümü, compatibility-matrix.level tarafından belirtilen FCM sürümüne tam olarak eşit olmalıdır. Aksi halde eşleşme olmaz.

libvintf ile çerçeve uyumluluk matrisi istendiğinde, bu eşleşme her zaman başarılıdır çünkü libvintf aygıt bildirimini açar, Gönderi FCM Sürümünü alır ve bu Gönderi FCM Sürümündeki çerçeve uyumluluk matrisini döndürür (artı daha yüksek FCM'deki uyumluluk matrislerinden bazı isteğe bağlı HAL'ler) Sürümler).

HAL maçları

HAL eşleşme kuralı, bir bildirim dosyasındaki ilgili uyumluluk matrisinin sahibi tarafından desteklendiği düşünülen hal öğelerinin sürümlerini tanımlar.

HIDL ve yerel HAL'ler

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

  • Birden çok <hal> öğesi, tek bir AND ilişkisiyle değerlendirilir.
  • <hal> öğeleri, gerekli değil olarak işaretlemek için <hal optional="true"> içerebilir.
  • Aynı <hal> içindeki birden çok <version> öğesi VEYA ilişkisine sahiptir. İki veya daha fazla belirtilirse, sürümlerden yalnızca birinin uygulanması gerekir. (Aşağıdaki DRM örneğine bakın.)
  • Aynı <hal> içindeki birden çok <instance> ve <regex-instance> öğesi, <hal> gerektiğinde tek bir AND ilişkisiyle değerlendirilir. (bkz. Aşağıdaki DRM örneği.)

Ö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 matrisinde 2.5 , 2.5-5 kısaltmasıdır.
2.5-7 2.5-2.∞. Aşağıdakileri gösterir:
  • 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ında sürüm 2.10'da HAL bulunan bir cihaz, uyumluluk matrisinde 2.5-7 belirten bir çerçeve ile uyumlu kalır.

Ö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
tutucu2 VEYA
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'leri için eşleşme kuralları, ana sürümlerin olmaması ve HAL örneği başına tam olarak bir sürüm olması (sürüm belirtilmemişse 1 ) olması dışında HIDL ve yerel HAL'lerinkilere benzer.

  • Birden çok <hal> öğesi, tek bir AND ilişkisiyle değerlendirilir.
  • <hal> öğeleri, gerekli değil olarak işaretlemek için <hal optional="true"> içerebilir.
  • Aynı <hal> içindeki birden çok <instance> ve <regex-instance> öğesi, <hal> gerektiğinde tek bir AND ilişkisiyle değerlendirilir. (bkz. Aşağıdaki vibratör örneği.)

Ö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 matrisinde 5 , 5-5 kısaltmasıdır.
5-7 5-∞. Aşağıdakileri gösterir:
  • 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) sunabilir. . 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.
Bu nedenle, bildirim dosyasında sürüm 10'da HAL bulunan bir aygıt, uyumluluk matrisinde 5-7 belirten bir çerçeve ile uyumlu kalır.

Ö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

Çerçeve uyumluluk matrisinin <kernel> bölümü, çerçevenin aygıttaki Linux çekirdeğinin gereksinimlerini açıklar. Bu bilgilerin, cihazın VINTF nesnesi tarafından raporlanan çekirdek hakkındaki bilgilerle eşleştirilmesi amaçlanmıştır.

Çekirdek dallarını eşleştir

Her bir çekirdek dalı soneki (örneğin, 5.4- r ), benzersiz bir çekirdek FCM sürümüne (örneğin, 5) eşlenir. 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.

VTS testleri, aşağıdakilerden biri doğruysa, aygıtın /vendor/etc/vintf/manifest.xml aygıt bildiriminde çekirdek FCM sürümünü açıkça belirtmesini zorunlu kılar:

  • Çekirdek FCM sürümü, hedef FCM sürümünden farklıdır. Örneğin, yukarıda bahsedilen aygıtın bir hedef FCM sürümü 4 vardır ve çekirdek FCM sürümü 5'tir (çekirdek dalı eki r ).
  • Çekirdek FCM sürümü 5'ten büyük veya 5'e eşit (çekirdek dalı son eki 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

Aygıtın hedef FCM sürüm 4'ü varsa (Android 10'da yayınlandı), ancak çekirdeği 4.19-r dalından çalıştırıyorsa, aygıt bildiriminde aşağıdakiler belirtilmelidir:

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

VINTF nesnesi, FCM sürüm 5'te belirtilen 4.19-r çekirdek dalındaki gereksinimlere karşı çekirdek uyumluluğunu kontrol eder. Bu gereksinimler, Android kaynak ağacında kernel/configs/r/android-4.19 oluşturulur.

Örnek: GKI için çekirdek dalını belirleyin

Aygıt, Genel Çekirdek Görüntüsü'nü (GKI) kullanıyorsa ve /proc/version version'dan çekirdek yayın dizesi aşağıdaki gibidir:

5.4.42-android12-0-00544-ged21d463f856

Ardından, VINTF nesnesi, çekirdek sürümünden Android sürümünü alır ve bunu çekirdek FCM sürümünü belirlemek için kullanır. Bu örnekte android12 , çekirdek FCM sürüm 6 (Android 12'de yayınlandı) anlamına gelir.

Çekirdek yayın dizesinin nasıl ayrıştırıldığına ilişkin ayrıntılar için bkz. GKI sürüm oluşturma.

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

Bir matris, her biri şu biçimi kullanan farklı bir version özniteliğine sahip birden çok <kernel> bölümü içerebilir:

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

VINTF nesnesi, aygıt çekirdeğiyle aynı ${ver} ve ${major_rev} ile eşleşen FCM sürümüne sahip FCM'den yalnızca <kernel> bölümünü dikkate alır (yani, version="${ver}.${major_rev}.${matrix_minor_rev}") ; diğer bölümler dikkate alınmaz. Ek olarak, çekirdekten gelen küçük revizyon, uyumluluk matrisinden bir değer olmalıdır ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Hiçbir <kernel> bölümü bu gereksinimleri karşılamıyorsa, eşleşmez.

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

/system/etc/vintf içindeki FCM'lerin aşağıdaki gereksinimleri bildirdiği aşağıdaki varsayımsal durumu göz önünde bulundurun (üstbilgi ve altbilgi etiketleri atlanır):

<!-- 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)
3 (P) belirtilmemiş 5.4.41 5.4-r (aşağıdaki nota bakın)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 Eşleşme yok ( 4.19-p çekirdek dalı yok)
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) belirtilmemiş 4.4.107 Eşleşme yok ( 4.4-q çekirdek dalı yok)
4 (Q) belirtilmemiş 4.9.165 4.9-q
4 (Q) belirtilmemiş 5.4.41 5.4-r (aşağıdaki nota bakın)
4 (Q) 4 (Q) 4.9.165 4.9-q
4 (Q) 4 (Q) 5.4.41 Eşleşme yok ( 5.4-q çekirdek dalı yok)
4 (Q) 5 (R) 4.14.105 4.14-r
4 (Q) 5 (R) 5.4.41 5.4-r
5 (R) belirtilmemiş hiç VTS başarısız oluyor (Hedef FCM sürüm 5 için çekirdek FCM sürümünü belirtmelidir)
5 (R) 4 (Q) hiç 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

<kernel> bölümü eşleşirse, config öğelerini /proc/config.gz ile eşleştirmeye çalışarak işlem devam eder. Uyumluluk matrisindeki her bir yapılandırma öğesi için, yapılandırmanın mevcut olup olmadığını görmek için /proc/config.gz bakar. Bir yapılandırma öğesi, eşleşen <kernel> bölümü için uyumluluk matrisinde n olarak ayarlandığında, /proc/config.gz olmaması gerekir. Son olarak, uyumluluk matrisinde olmayan bir yapılandırma öğesi /proc/config.gz bulunabilir veya bulunmayabilir.

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

  • <value type="string">bar</value> , "bar" ile eşleşir. Tırnaklar uyumluluk matrisinde atlanmıştır ancak /proc/config.gz .
  • <value type="int">4096</value> , 4096 veya 0x1000 veya 0X1000 .
  • <value type="int">0x1000</value> , 4096 veya 0x1000 veya 0X1000 .
  • <value type="int">0X1000</value> 4096 veya 0x1000 veya 0X1000 .
  • <value type="tristate">y</value> y ile eşleşir.
  • <value type="tristate">m</value> m ile eşleşir.
  • <value type="tristate">n</value> , yapılandırma öğesinin /proc/config.gz içinde OLMAMASI gerektiği anlamına gelir.
  • <value type="range">1-0x3</value> 1 , 2 veya 3 veya onaltılık eşdeğeriyle eşleşir.

Ö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ı, manifest.kernel.target-level içindeki aygıt bildiriminde belirtilir; bu, ilki belirtilmemişse varsayılan olarak manifest.level olur. Aygıttaki çekirdek dalı görünürse:

  • 1'dir, 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. uname() içindeki bir cihaz şunları bildirirse:

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

Uygun <kernel> bölümü seçildikten sonra, n dışında değere sahip her <config> öğesi için, /proc/config.gz içinde karşılık gelen girişin bulunmasını bekleriz; n değerine sahip her <config> öğesi için, karşılık gelen girişin /proc/config.gz içinde olmamasını bekleriz. <value> içeriğinin, eşittir işaretinden sonra (tırnak işaretleri dahil), satırsonu karakterine veya # 'ye kadar, baştaki ve sondaki boşluklar kesilerek metinle tam olarak eşleşmesini bekleriz.

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 ana sürüm için kapalı bir alt sürüm yelpazesi tanımlar. Cihaz tarafından bildirilen sepolicy sürümü, çerçeve ile uyumlu olması için bu aralıklardan birine girmelidir. Maç kuralları HAL sürümlerine benzer; sepolicy sürümünün, aralığın minimum sürümüne eşit veya daha yüksek olması bir eşleşmedir. Maksimum sürüm tamamen bilgi amaçlıdır.
  • <kernel-sepolicy-version> yani policydb versiyonu. Cihaz tarafından bildirilen security_policyvers() değerinden daha az olmalıdır.

Ö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:

  • security_policyvers() tarafından döndürülen değer 30'dan büyük veya buna eşit olmalıdır. Aksi takdirde bu bir eşleşme değildir. Örneğin:
    • Bir cihaz 29 döndürürse, eşleşme değildir.
    • Bir cihaz 31 döndürürse, bu 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. (" 26.0 "dan sonraki " -3 " tamamen bilgi amaçlıdır.)

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. Ayrıntılar için Sürüm Oluşturma ve Uyumluluk bölümüne bakın. AVB sürümü aşağıdaki sistem özelliklerine sahiptir:

  • ro.boot.vbmeta.avb_version , önyükleyicideki libavb sürümüdür
  • ro.boot.avb_version , Android işletim sistemindeki libavb sürümüdür ( init/fs_mgr )

Sistem özelliği, yalnızca ilgili libavb AVB meta verilerini doğrulamak için 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:

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

Önyükleyici veya Android işletim sistemi, yükseltme aygıtları ve başlatma aygıtları için her biri farklı bir MAJOR sürümüne sahip iki libavb kitaplığı kopyası içerebilir. Bu durumda, aynı imzasız sistem görüntüsü paylaşılabilir ancak son imzalı sistem görüntüleri farklıdır (farklı avb.vbmeta-version ile):

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


Şekil 2. AVB sürüm eşleşmeleri (tüm bölümler P'dir).

Ö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 
yer tutucu17 l10n-yer
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 düşük sürümle 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 azaltmak için bir OEM, denetimi geçmek için OTA paketine ( compatibility.zip ) sahte bir AVB sürümü yerleştirebilir. Böyle yaparak:

  1. Android 9 kaynak ağacına aşağıdaki CL'leri kesin olarak seçin:
  2. Cihaz için BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE tanımlayın. 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, BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE otomatik olarak compatibility-matrix.avb.vbmeta-version olarak aşağıdaki dosyalara yerleştirir:

  • cihazda /system/compatibility_matrix.xml (Android 9'da kullanılmaz)
  • OTA paketindeki compatibility.zip system_matrix.xml

Bu değişiklikler, /system/etc/vintf/compatibility_matrix.xml dahil olmak üzere diğer çerçeve uyumluluk matrislerini etkilemez. OTA'dan sonra, bunun yerine uyumluluk kontrolleri için /system/etc/vintf/compatibility_matrix.xml içindeki yeni değer kullanılır.

VNDK sürüm eşleşmeleri

Cihaz uyumluluk matrisi, gerekli VNDK sürümünü compatibility-matrix.vendor-ndk.version içinde bildirir. Cihaz uyumluluk matrisinde bir <vendor-ndk> etiketi yoksa herhangi bir gereksinim uygulanmaz ve bu nedenle her zaman bir eşleşme olarak kabul edilir.

Cihaz uyumluluk matrisinde bir <vendor-ndk> etiketi varsa, çerçeve bildiriminde çerçeve tarafından sağlanan VNDK satıcı anlık görüntülerinden eşleşen bir <version> içeren bir <vendor-ndk> girişi 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ılmamışsa, 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>

Örnek A bir eşleşmedir, çünkü VNDK 27 sürümü çerçeve bildirimindedir ve {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 27 sürümü çerçeve bildiriminde olsa da, libjpeg.so bu anlık görüntüdeki çerçeve tarafından desteklenmez. VNDK sürüm 26 yoksayılır.

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

Cihaz uyumluluk matrisi, compatibility-matrix.system-sdk.version içinde bir dizi gerekli Sistem SDK sürümünü bildirir. Yalnızca küme, çerçeve bildiriminde manifest.system-sdk.version içinde bildirildiği gibi sağlanan Sistem SDK sürümlerinin bir alt kümesiyse bir eşleşme vardır.

  • Ö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ı.