Vendor Native Development Kit (VNDK), dlopen için çalışma zamanında satıcı veya ürün bölümündeki diğer kitaplıklar ya da ikili dosyalar tarafından kullanılan bir kitaplıklar kümesidir.
Kullanımdan Kaldırma
Android 8.0'da, çerçeve ve satıcı kodu arasında API'ler sağlamak için satıcı NDK'sı kullanıma sunuldu. VNDK uzun yıllardır başarıyla kullanılsa da bazı dezavantajları vardır:- Depolama
- Tek bir VNDK APEX paketi, cihazda kullanılıp kullanılmadıklarına bakılmaksızın tüm VNDK kitaplıklarını içerir.
- GSI, birden fazla satıcı görüntüsünü desteklemek için VNDK APEX'lerinin birden fazla sürümünü içerir.
- Güncellenebilme durumu
- VNDK APEX'lerini platform güncellemesinden ayrı olarak güncellemek zordur.
- Tedarikçi resimleri kablosuz olarak (OTA) sık sık güncellenir. Bu durum, VNDK'nın sistem resminde paketlenmesinin avantajlarını azaltır.
VNDK desteğinin sonlandırılmasıyla ilgili ayrıntılar
Tüm VNDK kitaplıkları VNDK APEX'e paketlenir ve sistem (-ext) görüntüsüne yüklenir. VNDK desteğinin sonlandırılmasıyla birlikte, eski VNDK kitaplıkları diğer tedarikçi tarafından kullanılabilen kitaplıklar gibi tedarikçi (veya ürün) görüntüsüne yüklenir. Bu özellikler, VNDK desteğinin sonlandırılmasıyla birlikte kaldırılır:- Android 15 için VNDK APEX
- Tedarikçi veya ürün bölümleri Android 15 için oluşturulmuşsa hedef VNDK'nın sürümünü belirten sistem özellikleri kaldırılır:
ro.vndk.versionro.product.vndk.version
- VNDK olmadığı için VNDK optimizasyonları kullanılamaz:
- Android Go cihazlar için
TARGET_VNDK_USING_CORE_VARIANT use_vndk_as_stableTedarikçi APEX'leri için
- Android Go cihazlar için
- VNDK'ya büyük ölçüde bağlı olan tedarikçi anlık görüntüsü
Kullanımdan kaldırma işleminden muaf tutulanlar
VNDK desteğinin sonlandırılmasıyla birlikte bu özelliklerde değişiklik olmayacak:- Mevcut satıcı resimlerini desteklemek için gereken VNDK sürüm 14 veya önceki sürümlere sahip VNDK APEX'leri.
- LL-NDK, VNDK'nın bir parçası değildir.
Neden VNDK?
AOSP, yalnızca çerçeve güncellemelerine izin verir. Bu güncellemelerde sistem bölümü en son çerçeve sürümüne yükseltilirken satıcı bölümü değiştirilmez. Farklı zamanlarda oluşturulmuş olsalar da her bölümdeki ikili dosyalar birbirleriyle çalışabilmelidir.
Yalnızca çerçeve güncellemeleri aşağıdaki zorlukları içerir:
- Çerçeve modülleri ile tedarikçi modülleri arasındaki bağımlılık. Android 8.0'dan önce, tedarikçi ve sistem bölümündeki modüller birbirine bağlanabiliyordu. Ancak tedarikçi modüllerinden gelen bağımlılıklar, çerçeve modüllerinin geliştirilmesine istenmeyen kısıtlamalar getiriyordu.
- AOSP kitaplıklarına yönelik uzantılar. Android, sistem bölümü standart bir Genel Sistem Görüntüsü (GSI) ile değiştirildiğinde tüm Android cihazların CTS'yi geçmesini zorunlu kılar. Ancak tedarikçiler, performansı artırmak veya HIDL uygulamalarına ekstra işlevler eklemek için AOSP kitaplıklarını genişlettikçe sistem bölümünü standart bir GSI ile flaşlamak, tedarikçinin HIDL uygulamasını bozabilir. Bu tür bozulmaları önlemeyle ilgili yönergeler için VNDK uzantıları başlıklı makaleyi inceleyin.
Android, bu zorlukların üstesinden gelmek için VNDK (bu bölümde açıklanmıştır), HIDL, hwbinder, cihaz ağacı yerleşimi ve sepolicy yerleşimi gibi çeşitli özellikler içerir.
VNDK'ye özgü şartlar
VNDK ile ilgili belgelerde aşağıdaki terminoloji kullanılır:- Modüller, paylaşılan kitaplıkları veya yürütülebilir dosyaları ifade eder. Modüller, derleme zamanı bağımlılıkları oluşturur.
- İşlemler, yürütülebilir dosyalardan oluşturulan işletim sistemi görevleridir. İşlemler, çalışma zamanı bağımlılıkları oluşturur.
- Çerçeve ile ilgili şartlar,
systembölümüyle ilgilidir: - Çerçeve yürütülebilir dosyaları,
/system/binveya/system/xbiniçindeki yürütülebilir dosyaları ifade eder. - Çerçeve paylaşılan kitaplıkları,
/system/lib[64]altındaki paylaşılan kitaplıkları ifade eder. - Framework modülleri hem framework paylaşılan kitaplıklarını hem de framework yürütülebilir dosyalarını ifade eder.
- Çerçeve işlemleri,
/system/bin/app_processgibi çerçeve yürütülebilir dosyalarından oluşturulan işlemlerdir. - Tedarikçi nitelikli terimler
vendorbölümleriyle ilgilidir: - Tedarikçi çalıştırılabilir dosyaları,
/vendor/biniçindeki çalıştırılabilir dosyaları ifade eder. - Sağlayıcı tarafından paylaşılan kitaplıklar,
/vendor/lib[64]altındaki paylaşılan kitaplıkları ifade eder. - Tedarikçi modülleri, hem tedarikçi yürütülebilir dosyalarını hem de tedarikçi paylaşılan kitaplıklarını ifade eder.
- Tedarikçi işlemleri,
/vendor/bin/android.hardware.camera.provider@2.4-servicegibi Tedarikçi Yürütülebilir Dosyaları'ndan oluşturulan işlemlerdir.
VNDK kavramları
İdeal bir Android 8.0 ve sonraki sürümler dünyasında, çerçeve süreçleri tedarikçi tarafından paylaşılan kitaplıkları yüklemez, tüm tedarikçi süreçleri yalnızca tedarikçi tarafından paylaşılan kitaplıkları (ve çerçeve tarafından paylaşılan kitaplıkların bir bölümünü) yükler ve çerçeve süreçleri ile tedarikçi süreçleri arasındaki iletişimler HIDL ve donanım bağlayıcı tarafından yönetilir.
Böyle bir dünyada, çerçeve paylaşılan kitaplıklarından gelen kararlı ve herkese açık API'lerin, satıcı modülü geliştiricileri için yeterli olmayabileceği (API'ler Android sürümleri arasında değişebilse de) ve çerçeve paylaşılan kitaplıklarının bir kısmının satıcı süreçlerine erişilebilir olması gerekebilir. Ayrıca, performans koşulları ödünlere yol açabileceğinden, yanıt süresi açısından kritik olan bazı HAL'ler farklı şekilde ele alınmalıdır.
Aşağıdaki bölümlerde, VNDK'nın tedarikçiler için çerçeve paylaşılan kitaplıklarını ve aynı işlemde HAL'leri (SP-HAL'ler) nasıl işlediği ayrıntılı olarak açıklanmaktadır.
Tedarikçi için çerçeve paylaşılan kitaplıkları
Bu bölümde, satıcı süreçlerinin erişebildiği paylaşılan kitaplıkları sınıflandırma ölçütleri açıklanmaktadır. Tedarikçi modüllerinin birden fazla Android sürümünde desteklenmesi için iki yaklaşım vardır:
- Çerçeve paylaşılan kitaplıklarının ABI'lerini/API'lerini dengeleyin. Yeni çerçeve modülleri ve eski tedarikçi modülleri, bellek ayak izini ve depolama alanını azaltmak için aynı paylaşılan kitaplığı kullanabilir. Ayrıca, benzersiz bir paylaşılan kitaplık, birden fazla kez yükleme sorununu da önler. Ancak kararlı ABI'leri/API'leri korumak için gereken geliştirme maliyeti yüksektir ve her çerçeve paylaşılan kitaplığı tarafından dışa aktarılan tüm ABI'leri/API'leri kararlı hale getirmek gerçekçi değildir.
- Eski çerçeve paylaşılan kitaplıklarını kopyalayın. Binder, soket, boru, paylaşılan bellek, paylaşılan dosya ve sistem özellikleri dahil ancak bunlarla sınırlı olmamak üzere, çerçeve modülleri ve satıcı modülleri arasında iletişim kurmak için kullanılan tüm mekanizmalar olarak tanımlanan yan kanallara karşı güçlü bir kısıtlama içerir. İletişim protokolü dondurulup sabitlenmediği sürece (ör. hwbinder üzerinden HIDL) iletişim olmamalıdır. Paylaşılan kitaplıkların iki kez yüklenmesi de sorunlara neden olabilir. Örneğin, yeni kitaplık tarafından oluşturulan bir nesne eski kitaplıktaki işlevlere aktarılırsa bu kitaplıklar nesneyi farklı şekilde yorumlayabileceğinden hata oluşabilir.
Paylaşılan kitaplıkların özelliklerine bağlı olarak farklı yaklaşımlar kullanılır. Bu nedenle, çerçeve paylaşılan kitaplıkları üç alt kategoriye ayrılır:
- LL-NDK Kitaplıkları, kararlı olduğu bilinen Framework Shared Libraries'dir. Geliştiricileri, API/ABI kararlılıklarını korumaya kararlıdır.
- LL-NDK aşağıdaki kitaplıkları içerir:
libEGL.so,libGLESv1_CM.so,libGLESv2.so,libGLESv3.so,libandroid_net.so,libc.so,libdl.so,liblog.so,libm.so,libnativewindow.so,libneuralnetworks.so,libsync.so,libvndksupport.sovelibvulkan.so,
- LL-NDK aşağıdaki kitaplıkları içerir:
- Uygun VNDK Kitaplıkları (VNDK), iki kez kopyalanması güvenli olan Framework Shared Libraries'dir. Framework Modules (Çerçeve Modülleri) ve Vendor Modules (Tedarikçi Modülleri) kendi kopyalarıyla bağlantı oluşturabilir. Paylaşılan bir çerçeve kitaplığı, yalnızca aşağıdaki ölçütleri karşıladığı takdirde uygun bir VNDK kitaplığı olabilir:
- Çerçeveye/çerçeveden IPC göndermez/almaz.
- ART sanal makinesiyle ilgili değildir.
- Kararsız dosya biçimlerine sahip dosyaları/bölümleri okumaz/yazmaz.
- Yasal inceleme gerektiren özel bir yazılım lisansı yoktur.
- Kodun sahibi, tedarikçi kullanımlarına itiraz etmiyor.
- Yalnızca Çerçeve Kitaplıkları (FWK-ONLY), yukarıda belirtilen kategorilere ait olmayan Çerçeve Paylaşımlı Kitaplıklar'dır. Şu
kitaplıklar:
- Çerçevenin dahili uygulama ayrıntıları olarak kabul edilir.
- Tedarikçi modülleri tarafından erişilememelidir.
- Kararsız ABI'lere/API'lere sahip olmak ve API/ABI uyumluluğu garantisi vermemek.
- Kopyalanmaz.
Aynı İşlem HAL'si (SP-HAL)
Aynı Süreç HAL'si (SP-HAL), Vendor Shared Libraries olarak uygulanan ve Framework Processes'e yüklenen bir dizi önceden belirlenmiş HAL'dir. SP-HAL'ler, bağlayıcı ad alanı (paylaşılan kitaplıklara görünür olan kitaplıkları ve sembolleri kontrol eder) tarafından yalıtılır. SP-HAL'ler yalnızca LL-NDK ve VNDK-SP'ye bağlı olmalıdır.
VNDK-SP, uygun VNDK kitaplıklarının önceden tanımlanmış bir alt kümesidir. VNDK-SP kitaplıklarının çerçeve süreçlerine çift yüklenmesinin sorunlara neden olmaması için VNDK-SP kitaplıkları dikkatlice incelenir. Hem SP-HAL'ler hem de VNDK-SP'ler Google tarafından tanımlanır.
Aşağıdaki kitaplıklar onaylı SP-HAL'lerdir:
libGLESv1_CM_${driver}.solibGLESv2_${driver}.solibGLESv3_${driver}.solibEGL_${driver}.sovulkan.${driver}.soandroid.hardware.renderscript@1.0-impl.soandroid.hardware.graphics.mapper@2.0-impl.so
VNDK-SP kitaplıkları, vndk: { support_system_process: true }
Android.bp dosyalarında belirtir. vndk: {private:true} da belirtilmişse bu kitaplıklar VNDK-SP-Private olarak adlandırılır ve SP-HALS için görünmezdir.
Aşağıdakiler RS istisnaları olan yalnızca çerçeve kitaplıklarıdır (FWK-ONLY-RS):
libft2.so(Renderscript)libmediandk.so(Renderscript)
VNDK sürümü oluşturma
VNDK paylaşılan kitaplıkları sürüm oluşturulur:
ro.vndk.versionsistem özelliği,/vendor/default.prop'ye otomatik olarak eklenir.- VNDK ve VNDK-SP paylaşılan kitaplıkları, VNDK apex'i olarak yüklenir
com.android.vndk.v${ro.vndk.version}ve/apex/com.android.vndk.v${ro.vndk.version}konumuna monte edilir.
ro.vndk.version değeri aşağıdaki algoritma tarafından seçilir:
BOARD_VNDK_VERSION,currentdeğerine eşit değilseBOARD_VNDK_VERSIONdeğerini kullanın.BOARD_VNDK_VERSION,current'e eşitse:PLATFORM_VERSION_CODENAME,RELisePLATFORM_SDK_VERSION(ör.28) kullanın.- Aksi takdirde
PLATFORM_VERSION_CODENAMEsimgesini kullanın (ör.P).
Tedarikçi Test Paketi (VTS)
Android Vendor Test Suite (VTS), boş olmayan bir ro.vndk.version özelliği zorunlu kılar. Hem yeni kullanıma sunulan cihazlar hem de yükseltme yapılan cihazlar ro.vndk.version değerini tanımlamalıdır. Bazı VNDK testleri (ör. VtsVndkFilesTest ve VtsVndkDependencyTest), uygun VNDK kitaplıkları veri kümelerini yüklemek için ro.vndk.version özelliğini kullanır.