Android cihaz üreticileri, çeşitli nedenlerle AOSP kitaplıklarının kaynak kodunu değiştirir. 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
Tüm değiştirilmiş paylaşılan kitaplıklar, AOSP muadillerinin ikili uyumlu , drop-in değiştirmeleri 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 ifade eder:
- AOSP işlevleri kaldırılmamalıdır.
- Bu tür yapılar kullanıcılarına maruz kalırsa, yapılar değiştirilmemelidir.
- Fonksiyonların ön koşulları 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 : Burada API / ABI yerine işlevler kullanılır çünkü herhangi bir API / ABI değiştirmeden işlevsellik eklemek mümkündür.
Bir modülde tanımlanan işlevlere bağlı olarak, modüller DA Modülü ve DX Modülü olarak sınıflandırılabilir:
- Yalnızca AOSP Modüllerinin Tanımlanması (DA Modülü) , AOSP muadili 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.soiçindeki işlevleri SIMD yönergeleriyle (yeni işlevler eklemeden) yeniden
libcrypto.so, değiştirilmiş
libcrypto.sobir DA Modülü olacaktır.
- Genişletme Modüllerini Tanımlama (DX Modülü) ya yeni işlevleri tanımlar ya da bir AOSP karşılığı yoktur.
- Örnek 1. Bir satıcı, bazı dahili verilere erişmek için
libjpeg.sobir yardımcı işlev eklerse, değiştirilmiş
libjpeg.sobir DX-Lib ve yeni eklenen işlev, kitaplığın genişletilmiş kısmı olacaktır.
- Örnek 2. Bir satıcı,
libfoo.soadında AOSP olmayan bir kitaplık tanımlarsa,
libfoo.sobir DX-Lib olacaktır.
- Örnek 1. Bir satıcı, bazı dahili verilere erişmek için
Bir modül tarafından kullanılan işlevlere bağlı olarak, modüller UA Modülü ve UX Modülü olarak sınıflandırılabilir.
- Yalnızca AOSP Modüllerini (UA Modülü) kullanma, uygulamalarında yalnızca AOSP işlevlerini kullanır. AOSP olmayan herhangi bir uzantıya güvenmiyorlar.
- Ö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.soyalnızca diğer AOSP API'lerine dayanıyorsa, bu bir UA Modülü olacaktır.
- Genişletme Modüllerini Kullanma (UX Modülü) , uygulamalarında bazı AOSP dışı işlevlere dayanır.
- Örnek 1. Bir modifiye ederse
libjpeg.soadında olmayan başka AOSP kütüphanesine güvenir
libjpeg_turbo2.so, daha sonra değiştirilmiş
libjpeg.sobir UX-Modülü olacak.
- Örnek 2. Bir satıcı kendi değiştirilmiş yeni bir işlev ekler
libexif.sove modifiye
libjpeg.sogelen kullanımlar yeni eklenen fonksiyonu
libexif.sodaha sonra modifiye edilmiş,
libjpeg.sobir UX-modülü olacaktır.
- Örnek 1. Bir modifiye ederse
Tanımlar ve kullanımlar birbirinden bağımsızdır:
|Kullanılan İşlevler|
|Sadece AOSP (UA)||Genişletilmiş (UX)|
|Tanımlı İşlevsellikler||Sadece AOSP (DA)||DAUA||DAUX|
|Genişletilmiş (DX)||DXUA||DXUX|
VNDK uzatma mekanizması
Genişletilmiş işlevlere dayanan satıcı modülleri, aynı ada sahip AOSP kitaplığının genişletilmiş işlevselliğe sahip olmaması nedeniyle çalışmayacaktır. 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ı işlemleri 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ı, karşılık gelen AOSP kitaplığı aynı işlevselliği sağlayabiliyorsa ve sistem bölümünün üzerine 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.
Bırakma değişimi önemlidir çünkü GSI'daki değiştirilmemiş VNDK kitaplıkları, ad çakışması durumunda değiştirilmiş paylaşılan kitaplıklarla bağlantı kuracaktır. AOSP kitaplıkları API / ABI uyumsuz bir şekilde değiştirilirse, GSI'daki AOSP kitaplıkları bağlanamayabilir veya tanımlanmamış davranışlara neden olabilir.