Android cihaz üreticileri çeşitli nedenlerden dolayı AOSP kütüphanelerinin 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ümde AOSP kitaplıklarının CTS/VTS'yi bozmayacak şekilde genişletilmesine yönelik yönergeler sağlanmaktadır.
Yerleşik değiştirme
Değiştirilen tüm paylaşılan kitaplıklar, AOSP karşılıklarının ikili uyumlu , anında değiştirilebilen kopyaları olmalıdır. Mevcut tüm AOSP kullanıcılarının, değiştirilen paylaşılan kitaplığı yeniden derleme olmadan kullanabilmesi gerekir. Bu gereklilik aşağıdakileri ifade eder:
- AOSP işlevleri kaldırılmamalıdır.
- Bu tür yapıların kullanıcılarının kullanımına açık olması halinde 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şlevsellikler kullanılmıştı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 Tanımlayıcı AOSP Modülleri (DA Modülü), AOSP muadilinde 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şlevleri SIMD talimatlarıyla (yeni işlevler eklemeden) yeniden yazarsa, değiştirilenlibcrypto.so
bir DA Modülü olacaktır.
- Tanımlama Uzatma Modülleri (DX Modülü) ya yeni işlevler tanımlar ya da bir AOSP karşılığı yoktur.
- Örnek 1. Bir satıcı, bazı dahili verilere erişmek için
libjpeg.so
bir yardımcı işlev eklerse, o zaman değiştirilenlibjpeg.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.
- Örnek 1. Bir satıcı, bazı dahili verilere erişmek için
Bir modülün kullandığı işlevlere bağlı olarak modüller UA Modülü ve UX Modülü olarak sınıflandırılabilir.
- Yalnızca AOSP Kullanan Modüller (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üllerinin Kullanımı (UX Modülü), uygulamalarında AOSP olmayan bazı işlevlere dayanır.
- Örnek 1. Değiştirilmiş bir
libjpeg.so
libjpeg_turbo2.so
adlı başka bir AOSP olmayan kitaplığa dayanıyorsa, değiştirilmişlibjpeg.so
bir UX Modülü olacaktır. - Örnek 2. Bir satıcı, değiştirilen
libexif.so
yeni bir işlev eklerse ve değiştirilenlibjpeg.so
,libexif.so
yeni eklenen işlevi kullanırsa, değiştirilenlibjpeg.so
bir UX Modülü olacaktır.
- Örnek 1. Değiştirilmiş bir
Tanımlar ve kullanımlar birbirinden bağımsızdır:
Kullanılan İşlevler | |||
---|---|---|---|
Yalnızca AOSP (UA) | Genişletilmiş (UX) | ||
Tanımlanmış İşlevsellikler | Yalnızca AOSP (DA) | DAUA | DAUX |
Genişletilmiş (DX) | DXUA | DXUX |
VNDK uzatma mekanizması
Genişletilmiş işlevlere dayanan satıcı modülleri, aynı adı taşıyan AOSP kitaplığının genişletilmiş işlevselliğe sahip olmaması nedeniyle ç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ı işlemleri her zaman önce satıcı bölümündeki 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.
İlgili AOSP kitaplığı aynı işlevselliği sağlayabilirse ve satıcı modülleri, bir Genel Sistem Görüntüsü (GSI) tarafından sistem bölümünün üzerine yazıldığında çalışmaya devam ederse, DAUA paylaşılan kitaplıkları sistem bölümünde kalabilir.
GSI'daki değiştirilmemiş VNDK kitaplıkları, ad çakışması durumunda değiştirilmiş paylaşılan kitaplıklara bağlanacağından, doğrudan değiştirme önemlidir. AOSP kitaplıkları API/ABI ile uyumsuz bir şekilde değiştirilirse, GSI'daki AOSP kitaplıkları bağlantı kuramayabilir veya tanımsız davranışlarla sonuçlanabilir.