İki uyumluluk matrisi ve manifest çiftinin, çerçeve ile tedarikçi uygulamasının birlikte çalışabileceğini doğrulamak için uyumlulaştırılacağı varsayılır. Bu doğrulama, çerçeve uyumluluk matrisi ile cihaz manifesti ve çerçeve manifesti ile cihaz uyumluluk matrisi arasında eşleşme olduğunda başarılı olur.
Bu doğrulama, derleme sırasında, OTA güncelleme paketi oluşturma sırasında, önyükleme sırasında ve VTS uyumluluk testlerinde yapılır.
Aşağıdaki bölümlerde, çeşitli bileşenler tarafından kullanılan eşleştirme kuralları ayrıntılı olarak açıklanmıştır.
Çerçeve uyumluluk matrisi sürüm eşleşmeleri
Bir cihaz manifest'inin bir çerçeve uyumluluk matrisiyle eşleşmesi için manifest.target-level
tarafından belirtilen kargo FCM sürümü, compatibility-matrix.level
tarafından belirtilen FCM sürümüne tam olarak eşit olmalıdır. Aksi takdirde eşleşme olmaz.
Çerçeve uyumluluk matrisi libvintf
ile istendiğinde bu eşleşme her zaman başarılı olur. Bunun nedeni, libvintf
'ün cihaz manifestini açması, gönderim FCM sürümünü alması ve bu gönderim FCM sürümündeki çerçeve uyumluluk matrisini (veya daha yüksek FCM sürümlerindeki uyumluluk matrislerinden bazı isteğe bağlı HAL'leri) döndürmesidir.
HAL eşleşmeleri
HAL-eşleşme kuralı, bir manifest dosyasında ilgili uyumluluk matrisinin sahibi tarafından desteklendikleri kabul edilen 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ğıda verilmiştir.
- Birden fazla
<hal>
öğesi tek bir VE ilişkisiyle değerlendirilir. <hal>
öğeleri, zorunlu değil olarak işaretlemek için<hal optional="true">
içerebilir. Uyarı: Buoptional
, Android 15'ten sonra artık desteklenmiyor- Aynı
<hal>
içinde birden fazla<version>
öğesi varsa VEYA ilişkisi vardır. İki veya daha fazla sürüm belirtilirse sürümlerden yalnızca birinin uygulanması gerekir. (Aşağıdaki DRM örneğine bakın.) - Aynı
<hal>
içinde birden fazla<instance>
ve<regex-instance>
öğesi varsa<hal>
gerekli olduğunda bu öğeler tek bir VE ilişkisiyle değerlendirilir. (<ahref="#drm">Aşağıdaki DRM örneğine</ahref="#drm"> bakın.)
Ö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ı şu şekildedir:
Matris | Eşleşen Manifest |
---|---|
2.5 |
2,5-2,∞. Uyumluluk matrisinde 2.5 , 2.5-5 ifadesinin kısaltmasıdır. |
2.5-7 |
2,5-2,∞. Aşağıdakileri gösterir:
2.5-7 belirten bir çerçeveyle uyumlu olmaya devam eder. |
Örnek: DRM modülü için başarılı HAL eşleşmesi
Çerçeve uyumluluk matrisinde, DRM HAL için aşağıdaki sürüm bilgileri belirtilmiştir:
<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>
Tedarikçi firma aşağıdaki örneklerden BİRİNİ uygulamalıdır:
android.hardware.drm@1.x::IDrmFactory/default // where x >= 0 android.hardware.drm@1.x::IDrmFactory/specific // where x >= 0
android.hardware.drm@3.y::IDrmFactory/default // where y >= 1 android.hardware.drm@3.y::IDrmFactory/specific // where y >= 1
VE aşağıdaki örneklerin tümünü de 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'leri için sürümleri destekler.
AIDL HAL'leri için eşleme kuralları, HIDL ve yerel HAL'lerin kurallarına benzer. Bununla birlikte, büyük sürümler yoktur ve HAL örneği başına tam olarak bir sürüm vardır (sürüm belirtilmezse 1
).
- Birden fazla
<hal>
öğesi tek bir VE ilişkisiyle değerlendirilir. <hal>
öğeleri, gerekli değil olarak işaretlemek için<hal optional="true">
içerebilir. Uyarı: Buoptional
, Android 15'ten sonra artık desteklenmiyor- Aynı
<hal>
içinde birden fazla<instance>
ve<regex-instance>
öğesi varsa<hal>
gerekli olduğunda bu öğeler tek bir VE ilişkisiyle değerlendirilir. (<ahref="#vibrator">Titreşimli vibratör örneğine</ahref="#vibrator"> bakın.)
Örnek: Bir modül için başarılı HAL eşleşmesi
5 sürümüne sahip bir HAL için eşleme kuralı şu şekildedir:
Matris | Eşleşen Manifest |
---|---|
5 |
5-∞. Uyumluluk matrisinde 5 , 5-5 ifadesinin kısaltmasıdır. |
5-7 |
5-∞. Aşağıdakileri gösterir:
5-7 belirten bir çerçeveyle uyumlu olmaya devam eder. |
Örnek: Birden çok modül için başarılı HAL eşleşmesi
Çerçeve uyumluluk matrisinde, titreşim ve kamera HAL'leri için aşağıdaki sürüm bilgileri belirtilmiştir:
<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>
Tedarikçi firma, aşağıdaki örneklerin tümünü uygulamalıdır:
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ünde, çerçevenin cihazdaki Linux çekirdeğiyle ilgili koşulları açıklanır. Bu bilgilerin, cihazın VINTF nesnesi tarafından raporlanan çekirdekle ilgili bilgilerle eşleştirilmesi amaçlanmıştır.
Çekirdek dallarını eşleme
Her çekirdek dalı son eki (örneğin, 5.4-r
), benzersiz bir çekirdek FCM sürümüyle (örneğin, 5) eşlenir. Eşleme, sürüm harfleri (ör. R) ile FCM sürümleri (ör. 5) arasındaki eşlemeyle aynıdır.
VTS testleri, aşağıdakilerden biri doğruysa cihazın çekirdek FCM sürümünü cihaz manifest dosyasında (/vendor/etc/vintf/manifest.xml
) 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 cihazın hedef FCM sürümü 4, çekirdek FCM sürümü ise 5'tir (çekirdek dal soneki
r
). -
Çekirdek FCM sürümü 5 veya daha yeni olmalıdır (çekirdek dal soneki
r
).
VTS testleri, çekirdek FCM sürümü belirtilmişse çekirdek FCM sürümünün cihaz manifest'indeki hedef FCM sürümünden büyük veya eşit olmasını zorunlu kılar.
Örnek: Çekirdek dalını belirleme
Cihaz, hedef FCM sürümü 4'e (Android 10'da kullanıma sunuldu) sahipse ancak 4.19-r
dalındaki çekirdeği çalıştırıyorsa cihaz manifesti aşağıdakileri belirtmelidir:
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
VINTF nesnesi, çekirdek uyumluluğunu FCM 5 sürümünde belirtilen 4.19-r
çekirdek dalındaki koşullara göre kontrol eder. Bu şartlar, Android kaynak ağacındaki
kernel/configs/r/android-4.19
kullanılarak oluşturulur.
Örnek: GKI için çekirdek dalını belirleme
Cihazda Genel Çekirdek Görüntüsü (GKI) kullanılıyorsa ve /proc/version
kaynağındaki çekirdek sürüm dizesi aşağıdaki gibiyse:
5.4.42-android12-0-00544-ged21d463f856
Ardından VINTF nesnesi, Android sürümünü çekirdek sürümünden alır ve çekirdek FCM sürümünü belirlemek için kullanır. Bu örnekte android12
, çekirdek FCM sürümü 6'yı (Android 12'de kullanıma sunulmuştur) ifade eder.
Çekirdek sürüm dizesinin nasıl ayrıştırıldığıyla ilgili ayrıntılar için GKI sürümlendirme başlıklı makaleyi inceleyin.
Çekirdek sürümlerini eşleme
Bir matris, her biri farklı bir version
özelliğine sahip birden fazla <kernel>
bölümü içerebilir. Bu bölümler şu biçimi kullanır:
${ver}.${major_rev}.${kernel_minor_rev}
VINTF nesnesi, yalnızca cihaz çekirdeğiyle aynı ${ver}
ve ${major_rev}
ile eşleşen FCM sürümüne sahip FCM'deki <kernel>
bölümünü dikkate alır (ör.
version="${ver}.${major_rev}.${matrix_minor_rev}")
; diğer bölümler yoksayılır. Ayrıca, çekirdekteki küçük düzeltme, uyumluluk matrisinden (${kernel_minor_rev} >=
${matrix_minor_rev}
) bir değer olmalıdır. Hiçbir <kernel>
bölümü bu koşulları karşılamıyorsa eşleşme yoktur.
Örnek: Eşleştirme için koşulları seçme
/system/etc/vintf
alanındaki FCM'lerin aşağıdaki koşulları beyan ettiği aşağıdaki varsayımsal durumu düşünün (başlık ve altbilgi etiketleri atlanmıştı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 şartlarını seçer:
Hedef FCM sürümü | Çekirdek FCM sürümü | Çekirdek sürümü | Eşleşme |
---|---|---|---|
3 (P) | belirtilmedi | 4.4.106 | Eşleşme yok (küçük sürüm uyuşmazlığı) |
3 (P) | belirtilmedi | 4.4.107 | 4.4-p |
3 (P) | belirtilmedi | 4.19.42 | 4.19-q (aşağıdaki nota bakın) |
3 (P) | belirtilmedi | 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 (S) | 4.19.42 | 4.19-q |
4 (S) | belirtilmedi | 4.4.107 | Eşleşme yok (4.4-q çekirdek dalı yok) |
4 (S) | belirtilmedi | 4.9.165 | 4.9-q |
4 (S) | belirtilmedi | 5.4.41 | 5.4-r (aşağıdaki nota bakın) |
4 (S) | 4 (S) | 4.9.165 | 4.9-q |
4 (S) | 4 (S) | 5.4.41 | Eşleşme yok (5.4-q çekirdek dalı yok) |
4 (S) | 5 (R) | 4.14.105 | 4.14-r |
4 (S) | 5 (R) | 5.4.41 | 5.4-r |
5 (R) | belirtilmedi | herhangi | VTS başarısız (Hedef FCM sürümü 5 için çekirdek FCM sürümü belirtilmelidir) |
5 (R) | 4 (S) | herhangi | VTS başarısız (ç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şleme
<kernel>
bölümü eşleşirse işlem, config
öğelerini /proc/config.gz
ile eşleştirmeye çalışarak devam eder. Uyumluluk matrisindeki her yapılandırma öğesi için yapılandırma mevcut olup olmadığını görmek üzere /proc/config.gz
değerine bakar. Eşleşen <kernel>
bölümü için uyumluluk matrisinde bir yapılandırma öğesi n
olarak ayarlandığında, /proc/config.gz
bölümünde bulunmamalıdır. Son olarak, uyumluluk matrisinde bulunmayan bir yapılandırma öğesi /proc/config.gz
'te bulunabilir veya bulunmayabilir.
Örnek: Çekirdek yapılandırmalarını eşleştirme
<value type="string">bar</value>
eşleşme meydana geldi"bar"
. Tırnak işaretleri uyumluluk matrisinde atlanır ancak/proc/config.gz
içinde bulunur.<value type="int">4096</value>
,4096
veya0x1000
ya da0X1000
ile eşleşiyor.<value type="int">0x1000</value>
,4096
veya0x1000
ya da0X1000
ile eşleşiyor.<value type="int">0X1000</value>
,4096
veya0x1000
ya da0X1000
ile eşleşiyor.<value type="tristate">y</value>
eşleşme meydana geldiy
.<value type="tristate">m</value>
eşleşme meydana geldim
.<value type="tristate">n</value>
, yapılandırma öğesinin/proc/config.gz
içinde BULUNMAMASI gerektiği anlamına gelir.<value type="range">1-0x3</value>
,1
,2
veya3
ile eşleşir ya da onaltılık eşdeğeridir.
Örnek: Çekirdek eşleşmesi başarılı
FCM 1. sürümüne sahip bir çerçeve uyumluluk matrisinde aşağıdaki çekirdek bilgileri bulunur:
<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>
İlk olarak çekirdek dalı eşleştirilir. Çekirdek dalı, cihaz manifestinde manifest.kernel.target-level
olarak belirtilir. Bu belirtilmezse varsayılan olarak manifest.level
olur. Cihaz manifest'indeki çekirdek dalı:
- ise bir sonraki adıma geçip çekirdek sürümünü kontrol eder.
- 2 ise matrisle eşleşme yoktur. VINTF nesneleri, bunun yerine FCM sürüm 2'de matristeki çekirdek koşullarını okur.
Ardından, çekirdek sürümü eşleştirilir. uname()
alanındaki bir cihaz aşağıdakileri bildirirse:
- 4.9.84 (
<kernel version="4.9.x">
içeren ayrı bir çekirdek bölümü olmadığı sürece matrisle eşleşme olmaz. Buradax <= 84
) - 4.14.41 (matrisle eşleşme yok,
version
'ten küçük) - 4.14.42 (matrisle eşleşme)
- 4.14.43 (matrisle eşleştirme)
- 4.1.22 (
x <= 22
olduğunda<kernel version="4.1.x">
içeren ayrı bir çekirdek bölümü olmadığı sürece matrisle eşleşme yok)
Uygun <kernel>
bölümü seçildikten sonra, n
dışında bir değere sahip her <config>
öğesi için ilgili girişin /proc/config.gz
'da bulunmasını bekleriz. n
değerine sahip her <config>
öğesi için ise ilgili girişin /proc/config.gz
'da bulunmamasını bekleriz. <value>
içeriğinin, eşit işaretinden sonraki metinle (tırnak işaretleri dahil) yeni satır karakterine veya #
'a kadar tam olarak eşleşmesi, başlangıç ve bitiş boşluklarının ise kısaltılması gerekir.
Aşağıdaki çekirdek yapılandırması başarılı bir eşlemeye örnektir:
# 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şlemeye örnektir:
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 zorunlu kılar:
<sepolicy-version>
, her ana sürüm için kapalı bir küçük sürüm aralığı tanımlar. Cihaz tarafından bildirilen sepolicy sürümü, çerçeveyle uyumlu olmak için bu aralıklardan birine girmelidir. Eşleşme kuralları, HAL sürümlerine benzer. sepolicy sürümü, aralık için minimum sürümden yüksek veya ona eşitse eşleşme gerçekleşir. Maksimum sürüm tamamen bilgilendirme amaçlıdır.<kernel-sepolicy-version>
ör. policydb sürümü. Cihaz tarafından bildirilensecurity_policyvers()
değerinden az olmalıdır.
Örnek: Başarılı SE politikası eşleşmesi
Çerçeve uyumluluk matrisinde aşağıdaki güvenlik politikası bilgileri belirtilir:
<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 eşleşme olmaz. Örneğin:- Bir cihaz 29 döndürüyorsa eşleşme yoktur.
- Bir cihaz 31 döndürüyorsa eşleşme vardır.
- SE Politikası sürümü 25.0-∞ veya 26.0-∞ arasında olmalıdır. Aksi takdirde eşleşme olmaz. ("
26.0
"den sonra gelen "-3
" tamamen bilgilendirme amaçlıdır.)
AVB sürümü eşleşmeleri
AVB sürümü, ANASÜRÜM.ALTSÜRÜM biçiminde bir ANASÜRÜM sürümü ve ALTSÜRÜM sürümü içerir (ör. 1.0, 2.1). Ayrıntılar için Sürümlendirme ve Uyumluluk başlıklı makaleyi inceleyin. AVB sürümünde aşağıdaki sistem özellikleri bulunur:
ro.boot.vbmeta.avb_version
, bootloader'ınlibavb
sürümüro.boot.avb_version
, Android OS'teki (init/fs_mgr
)libavb
sürümüdür
Sistem özelliği yalnızca AVB meta verilerini doğrulamak için ilgili libavb kullanıldığında (ve OK döndürüldüğünde) görünür. Doğrulama hatası oluştuysa (veya hiç doğrulama yapılmadıysa) bu değer yoktur.
Uyumluluk eşleşmesinde aşağıdakiler karşılaştırılır:
- Çerçeve uyumluluk matrisinden
avb.vbmeta-version
ile syspropro.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 syspropro.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 OS, libavb
kitaplıklarının iki kopyasını içerebilir. Bu kopyaların her biri, cihazları yükseltme ve cihazları başlatma için farklı bir BÜYÜK sürüme sahiptir. Bu durumda, aynı imzasız sistem görüntüsü paylaşılabilir ancak nihai imzalı sistem görüntüleri farklıdır (farklı avb.vbmeta-version
ile):
![](https://source.android.google.cn/docs/core/architecture/images/treble_vintf_avb_o_p.png?authuser=19&hl=tr)
Şekil 1. AVB sürümü eşleşmelidir (/system P, diğer tüm bölümler O olmalıdır).
![](https://source.android.google.cn/docs/core/architecture/images/treble_vintf_avb_p.png?authuser=19&hl=tr)
Şekil 2. AVB sürümü eşleşmeleri (tüm bölümler P).
Örnek: Başarılı AVB sürümü eşleşmesi
Çerçeve uyumluluk matrisinde aşağıdaki AVB bilgileri belirtilir:
<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 AVB sürümünü eşleştirme
Android 9 veya daha eski bir sürümle kullanıma sunulan cihazlar Android 10'a güncellenirken çerçeve uyumluluk matrisindeki AVB sürüm koşulları, cihazdaki mevcut AVB sürümüyle eşleştirilir. OTA sırasında AVB sürümünde büyük bir sürüm yükseltmesi varsa (örneğin, 0,0'dan 1,0'a) OTA'daki uyumluluk için VINTF kontrolü, OTA'dan sonraki uyumluluğu yansıtmaz.
OEM'ler, sorunu azaltmak için OTA paketine (compatibility.zip
) sahte bir AVB sürümü yerleştirerek kontrolü geçebilir. Bunu yapmak için:
- Android 9 kaynak ağacına aşağıdaki CL'leri ekleyin:
- Cihaz için
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
değerini tanımlayın. Değeri, OTA'dan önceki AVB sürümüne, yani cihazın kullanıma sunulduğundaki AVB sürümüne eşit olmalıdır. - OTA paketini yeniden oluşturun.
Bu değişiklikler, BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
'ü aşağıdaki dosyalarda otomatik olarak compatibility-matrix.avb.vbmeta-version
olarak yerleştirir:
/system/compatibility_matrix.xml
(Android 9'da kullanılmaz)- OTA paketinde
compatibility.zip
konumundakisystem_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 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 matrisinde, compatibility-matrix.vendor-ndk.version
içinde gerekli VNDK sürümü belirtilir. Cihaz uyumluluk matrisinde <vendor-ndk>
etiketi yoksa herhangi bir koşul uygulanmaz ve bu nedenle her zaman eşleşme olarak kabul edilir.
Cihaz uyumluluk matrisinde <vendor-ndk>
etiketi varsa çerçeve manifestinde çerçeve tarafından sağlanan VNDK tedarikçisi anlık görüntüleri grubundan eşleşen bir <version>
içeren <vendor-ndk>
girişi aranacaktır. Böyle bir giriş yoksa eşleşme olmaz.
Böyle bir giriş varsa cihaz uyumluluk matrisinde listelenen kitaplık grubu, çerçeve manifestinde belirtilen kitaplık grubunun alt kümesi olmalıdır. Aksi takdirde giriş eşleşme olarak kabul edilmez.
- Özel bir durum olarak, cihaz uyumluluk matrisinde hiçbir kitaplık sayılmazsa boş küme herhangi bir kümenin alt kümesi olduğundan giriş her zaman eşleşme olarak kabul edilir.
Örnek: VNDK sürümü eşleşmesi başarılı
Cihaz uyumluluk matrisinde VNDK ile ilgili aşağıdaki şart belirtiliyorsa:
<!-- Example Device Compatibility Matrix --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk>
Çerçeve manifestinde yalnızca 27 numaralı sürüme 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 27 sürümü, çerçeve manifest'inde olduğu ve {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}
olduğu için A örneği eşleşmelidir.
<!-- 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 eşleşmez. VNDK 27 sürümü çerçeve manifestinde olsa bile libjpeg.so
, bu anlık görüntüdeki çerçeve tarafından desteklenmiyor. VNDK 26 sürümü yoksayılır.
Sistem SDK sürümü eşleşmeleri
Cihaz uyumluluk matrisi, compatibility-matrix.system-sdk.version
içinde gerekli bir dizi sistem SDK sürümü tanımlar. Eşleşme yalnızca, çerçeve manifestinde manifest.system-sdk.version
içinde belirtildiği gibi sağlanan sistem SDK sürümlerinin alt kümesiyse gerçekleşir.
- Özel bir durum olarak, cihaz uyumluluk matrisinde sistem SDK sürümü listelenmemişse boş küme herhangi bir kümenin alt kümesi olduğundan bu durum her zaman eşleşme olarak kabul edilir.
Örnek: Sistem SDK sürümü eşleşmesi başarılı
Cihaz uyumluluk matrisinde, System SDK'sı için aşağıdaki şart belirtiliyorsa:
<!-- Example Device Compatibility Matrix --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
Ardından, çerçevenin eşleşmesi için Sistem SDK'sı 26 ve 27 sürümünü sağlaması gerekir.
<!-- Framework Manifest Example A --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
A örneği eşleşmedir.
<!-- Framework Manifest Example B --> <system-sdk> <version>26</version> <version>27</version> <version>28</version> </system-sdk>
Örnek B eşleşmedir.
<!-- Framework Manifest Example C --> <system-sdk> <version>26</version> </system-sdk>
Sistem SDK'sı 27 sürümü sağlanmadığı için C örneği eşleşmez.