VNDK Uzantıları

Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

Android cihaz üreticileri, çeşitli nedenlerle AOSP kitaplıklarının kaynak kodunu değiştirmektedir. Bazı satıcılar, performansı artırmak için AOSP kitaplıklarındaki işlevleri yeniden uygularken, diğer satıcılar AOSP kitaplıklarına yeni kancalar, yeni API'ler veya yeni işlevler ekler. Bu bölüm, AOSP kitaplıklarını CTS/VTS'yi bozmayacak şekilde genişletmek için yönergeler sağlar.

Drop-in değiştirme

Değiştirilen tüm paylaşılan kitaplıklar, AOSP karşılıklarının ikili olarak uyumlu , açılan yedekleri olmalıdır. Mevcut tüm AOSP kullanıcıları, değiştirilmiş paylaşılan kitaplığı yeniden derleme olmadan kullanabilmelidir. Bu gereklilik aşağıdakileri ima eder:

  • AOSP işlevleri kaldırılmamalıdır.
  • Bu tür yapılar kullanıcılarına açıksa, yapılar değiştirilmemelidir.
  • Fonksiyonların ön koşulu güçlendirilmemelidir.
  • İşlevler, eşdeğer işlevler sağlamalıdır.
  • Fonksiyonların son durumu zayıflatılmamalıdır.

Genişletilmiş modül sınıflandırmaları

Modülleri tanımladıkları ve kullandıkları işlevlere göre sınıflandırın.

Not : Herhangi bir API/ABI'yi değiştirmeden işlevsellik eklemek mümkün olduğundan burada API/ABI yerine işlevler kullanılmıştır.

Bir modülde tanımlanan işlevlere bağlı olarak, modüller DA-Module ve DX-Module olarak sınıflandırılabilir:

  • Yalnızca AOSP Modüllerinin tanımlanması (DA-Modülü) , AOSP karşılığı olmayan yeni işlevleri tanımlamaz.
    • Örnek 1. Bozulmamış, değiştirilmemiş bir AOSP kitaplığı, bir DA-Modülüdür.
    • Örnek 2. Bir satıcı libcrypto.so içindeki işlevleri SIMD talimatlarıyla (yeni işlevler eklemeden) yeniden yazarsa, değiştirilmiş libcrypto.so bir DA-Modülü olacaktır.
  • Tanımlama-Uzantı Modülleri (DX-Modülü) ya yeni işlevler tanımlar ya da bir AOSP karşılığına sahip değildir.
    • Örnek 1. Bir satıcı, bazı dahili verilere erişmek için libjpeg.so bir yardımcı işlev eklerse, değiştirilmiş libjpeg.so bir DX-Lib olacak ve yeni eklenen işlev kitaplığın genişletilmiş kısmı olacaktır.
    • Örnek 2. Bir satıcı libfoo.so adında AOSP olmayan bir kitaplık tanımlarsa, libfoo.so bir DX-Lib olacaktır.

Modüller tarafından kullanılan işlevlere bağlı olarak modüller UA-Module ve UX-Module olarak sınıflandırılabilir.

  • Yalnızca AOSP Modüllerini Kullanma (UA Modülü) , uygulamalarında yalnızca AOSP işlevlerini kullanır. AOSP olmayan uzantılara güvenmezler.
    • Örnek 1. Bozulmamış, değiştirilmemiş bir AOSP kitaplığı, bir UA-Modülüdür.
    • Örnek 2. Değiştirilmiş bir paylaşılan kitaplık libjpeg.so yalnızca diğer AOSP API'lerine dayanıyorsa, bu bir UA-Modülü olacaktır.
  • Uzantı Modüllerini Kullanma (UX Modülü) , uygulamalarında AOSP dışı bazı işlevlere dayanır.
    • Örnek 1. Değiştirilmiş bir libjpeg_turbo2.so , libjpeg.so adlı AOSP olmayan başka bir kitaplığa dayanıyorsa, değiştirilmiş libjpeg.so bir UX Modülü olacaktır.
    • Örnek 2. Bir satıcı, değiştirilmiş libjpeg.so yeni bir işlev ekler ve değiştirilmiş libexif.so , libjpeg.so yeni eklenen işlevi kullanırsa, değiştirilmiş libexif.so , bir UX-Modülü olacaktır.

Tanımlar ve kullanımlar birbirinden bağımsızdır:

Kullanılan İşlevler
Yalnızca AOSP (UA) Genişletilmiş (UX)
Tanımlanmış İşlevler Yalnızca AOSP (DA) DAUA DAUX
Genişletilmiş (DX) DXUA DXUX

VNDK uzatma mekanizması

Aynı ada sahip AOSP kitaplığı genişletilmiş işlevselliğe sahip olmadığı için, genişletilmiş işlevlere dayanan satıcı modülleri çalışmaz. Satıcı modülleri doğrudan veya dolaylı olarak genişletilmiş işlevlere bağlıysa, satıcılar DAUX, DXUA ve DXUX paylaşılan kitaplıklarını satıcı bölümüne kopyalamalıdır (satıcı süreçleri her zaman önce satıcı bölümünde paylaşılan kitaplıkları arar). Ancak, LL-NDK kitaplıkları kopyalanmamalıdır, bu nedenle satıcı modülleri, değiştirilmiş LL-NDK kitaplıkları tarafından tanımlanan genişletilmiş işlevlere dayanmamalıdır.

DAUA paylaşılan kitaplıkları, ilgili AOSP kitaplığı aynı işlevselliği sağlayabiliyorsa ve sistem bölümünün üzerine bir Genel Sistem Görüntüsü (GSI) tarafından yazıldığında satıcı modülleri çalışmaya devam ederse, sistem bölümünde kalabilir.

GSI'deki değiştirilmemiş VNDK kitaplıkları, ad çakışması durumunda değiştirilmiş paylaşılan kitaplıklarla bağlantı kuracağından, ekleme değiştirme önemlidir. AOSP kitaplıkları API/ABI uyumsuz bir şekilde değiştirilirse, GSI'deki AOSP kitaplıkları bağlanamayabilir veya tanımsız davranışlarla sonuçlanabilir.