Android डिवाइस बनाने वाली कंपनियां, कई वजहों से AOSP लाइब्रेरी के सोर्स कोड में बदलाव करती हैं. कुछ वेंडर, परफ़ॉर्मेंस को बेहतर बनाने के लिए AOSP लाइब्रेरी में फ़ंक्शन फिर से लागू करते हैं. वहीं, दूसरे वेंडर AOSP लाइब्रेरी में नए हुक, नए एपीआई या नई सुविधाएं जोड़ते हैं. इस सेक्शन में, AOSP लाइब्रेरी को इस तरह से बढ़ाने के दिशा-निर्देश दिए गए हैं कि CTS/VTS का उल्लंघन न हो.
ड्रॉप-इन रिप्लेसमेंट
बदली गई सभी शेयर की गई लाइब्रेरी, AOSP के अपने वर्शन के साथ बाइनरी के साथ काम करने वाली और ड्रॉप-इन रिप्लेसमेंट होनी चाहिए. AOSP के सभी मौजूदा उपयोगकर्ताओं को, फिर से कॉम्पाइल किए बिना, बदली गई शेयर की गई लाइब्रेरी का इस्तेमाल करना चाहिए. इस ज़रूरी शर्त का मतलब है कि:
- AOSP फ़ंक्शन नहीं हटाए जाने चाहिए.
- अगर ऐसे स्ट्रक्चर, उपयोगकर्ताओं को दिखते हैं, तो उनमें बदलाव नहीं किया जाना चाहिए.
- फ़ंक्शन की शर्तों को ज़्यादा सख्त नहीं किया जाना चाहिए.
- फ़ंक्शन एक जैसे काम करने चाहिए.
- फ़ंक्शन की पोस्ट-कंडीशन को कम नहीं किया जाना चाहिए.
मॉड्यूल के लिए अलग-अलग कैटगरी
मॉड्यूल को उन फ़ंक्शन के आधार पर बांटें जिन्हें वे तय और इस्तेमाल करते हैं.
ध्यान दें: यहां एपीआई/एबीआई के बजाय, फ़ंक्शन का इस्तेमाल किया गया है, क्योंकि किसी भी एपीआई/एबीआई में बदलाव किए बिना फ़ंक्शन जोड़ा जा सकता है.
मॉड्यूल में दी गई सुविधाओं के आधार पर, मॉड्यूल को DA-मॉड्यूल और DX-मॉड्यूल में बांटा जा सकता है:
-
सिर्फ़ AOSP मॉड्यूल तय करने वाले (DA-Module), नई सुविधाओं को तय नहीं करते हैं. ये सुविधाएं, AOSP के वर्शन में नहीं थीं.
- पहला उदाहरण. बिना बदलाव वाली AOSP लाइब्रेरी, एक DA-मॉड्यूल है.
- दूसरा उदाहरण. अगर कोई वेंडर,
libcrypto.soमें मौजूद फ़ंक्शन को SIMD निर्देशों के साथ फिर से लिखता है (नए फ़ंक्शन जोड़े बिना), तो बदला गयाlibcrypto.soएक डीए-मॉड्यूल होगा.
-
डेफ़ाइनिंग-एक्सटेंशन मॉड्यूल (DX-मॉड्यूल), नई सुविधाओं को तय करते हैं या उनका कोई AOSP वर्शन नहीं होता.
- पहला उदाहरण. अगर कोई वेंडर कुछ इंटरनल डेटा ऐक्सेस करने के लिए,
libjpeg.soमें कोई हेल्पर फ़ंक्शन जोड़ता है, तो बदला गयाlibjpeg.soएक DX-Lib होगा और जोड़ा गया नया फ़ंक्शन, लाइब्रेरी का एक्सटेंड किया गया हिस्सा होगा. - दूसरा उदाहरण. अगर कोई वेंडर,
libfoo.soनाम की ऐसी लाइब्रेरी तय करता है जो AOSP लाइब्रेरी नहीं है, तोlibfoo.soएक DX-Lib होगी.
- पहला उदाहरण. अगर कोई वेंडर कुछ इंटरनल डेटा ऐक्सेस करने के लिए,
मॉड्यूल में इस्तेमाल की गई सुविधाओं के आधार पर, मॉड्यूल को UA-मॉड्यूल और UX-मॉड्यूल में बांटा जा सकता है.
-
सिर्फ़ AOSP मॉड्यूल का इस्तेमाल करने वाले (UA-Module), अपने लागू करने के तरीके में सिर्फ़ AOSP की सुविधाओं का इस्तेमाल करते हैं. ये AOSP से बाहर के किसी भी एक्सटेंशन पर निर्भर नहीं होते.
- पहला उदाहरण. बिना बदलाव वाली AOSP लाइब्रेरी, एक UA-मॉड्यूल है.
- दूसरा उदाहरण. अगर बदली गई शेयर की गई लाइब्रेरी
libjpeg.soसिर्फ़ अन्य AOSP एपीआई पर निर्भर करती है, तो यह UA-मॉड्यूल होगी.
-
Using-Extension Modules (UX-Module), लागू करने के लिए, AOSP के अलावा, कुछ अन्य सुविधाओं पर निर्भर करते हैं.
- पहला उदाहरण. अगर बदला गया
libjpeg.so,libjpeg_turbo2.soनाम की ऐसी लाइब्रेरी पर निर्भर करता है जो AOSP लाइब्रेरी नहीं है, तो बदला गयाlibjpeg.soएक UX-मॉड्यूल होगा. - दूसरा उदाहरण. अगर कोई वेंडर, बदले गए
libexif.soमें नया फ़ंक्शन जोड़ता है और बदला गयाlibjpeg.so,libexif.soमें जोड़े गए नए फ़ंक्शन का इस्तेमाल करता है, तो बदला गयाlibjpeg.soएक UX-मॉड्यूल होगा.
- पहला उदाहरण. अगर बदला गया
परिभाषाएं और इस्तेमाल एक-दूसरे से अलग होते हैं:
| इस्तेमाल की गई सुविधाएं | |||
|---|---|---|---|
| सिर्फ़ AOSP (UA) | एक्सटेंडेड (यूएक्स) | ||
| तय की गई सुविधाएं | सिर्फ़ AOSP (DA) | DAUA | DAUX |
| एक्सटेंडेड (DX) | DXUA | DXUX | |
VNDK एक्सटेंशन का तरीका
वेंडर के ऐसे मॉड्यूल काम नहीं करेंगे जो बेहतर सुविधाओं पर निर्भर हैं. ऐसा इसलिए, क्योंकि इसी नाम वाली AOSP लाइब्रेरी में बेहतर सुविधाएं नहीं हैं. अगर वेंडर मॉड्यूल सीधे या किसी दूसरे तरीके से, एक्सटेंडेड फ़ंक्शन पर निर्भर हैं, तो वेंडर को DAUX, DXUA, और DXUX शेयर की गई लाइब्रेरी को वेंडर सेक्शन में कॉपी करना चाहिए. वेंडर प्रोसेस हमेशा वेंडर सेक्शन में शेयर की गई लाइब्रेरी को पहले खोजती हैं. हालांकि, LL-NDK लाइब्रेरी को कॉपी नहीं किया जाना चाहिए. इसलिए, वेंडर के मॉड्यूल, बदली गई LL-NDK लाइब्रेरी से तय की गई एक्सटेंडेड सुविधाओं पर निर्भर नहीं होने चाहिए.
DAUA की शेयर की गई लाइब्रेरी, सिस्टम पार्टीशन में तब तक रह सकती हैं, जब तक कि उनसे मिलती-जुलती सुविधाएं देने वाली AOSP लाइब्रेरी उपलब्ध हो. साथ ही, सिस्टम पार्टीशन को जनरेटिक सिस्टम इमेज (जीएसआई) से ओवरराइट करने पर, वेंडर मॉड्यूल काम करते रहें.
ड्रॉप-इन रिप्लेसमेंट ज़रूरी है, क्योंकि GSI में मौजूद ऐसी VNDK लाइब्रेरी जो नाम के मेल खाने पर बदली गई शेयर की गई लाइब्रेरी से लिंक हो जाएंगी जिनमें बदलाव नहीं किया गया है. अगर AOSP लाइब्रेरी में एपीआई/एबीआई के साथ काम न करने वाले तरीके से बदलाव किया जाता है, तो हो सकता है कि GSI में AOSP लाइब्रेरी लिंक न हो पाएं या उनका काम ठीक से न हो.