RenderScript, Android पर ज़्यादा कंप्यूटेशनल पावर वाले टास्क को बेहतर परफ़ॉर्मेंस के साथ चलाने के लिए एक फ़्रेमवर्क है. इसे डेटा-पैरलल कंप्यूटेशन के साथ इस्तेमाल करने के लिए डिज़ाइन किया गया है. हालांकि, सीरियल वर्कलोड से भी फ़ायदा मिल सकता है. RenderScript रनटाइम, डिवाइस पर उपलब्ध प्रोसेसर के बीच काम को बांट देता है. जैसे, मल्टी-कोर सीपीयू और जीपीयू. इससे डेवलपर, काम को शेड्यूल करने के बजाय एल्गोरिदम पर फ़ोकस कर पाते हैं. RenderScript खास तौर पर उन ऐप्लिकेशन के लिए काम का है जो इमेज प्रोसेसिंग, कंप्यूटेशनल फ़ोटोग्राफ़ी या कंप्यूटर विज़न का काम करते हैं.
Android 8.0 और इसके बाद के वर्शन पर काम करने वाले डिवाइस, RenderScript फ़्रेमवर्क और वेंडर HAL का इस्तेमाल करते हैं:

पहली इमेज. वेंडर कोड, इंटरनल लाइब्रेरी से लिंक हो रहा है.
Android 7.x और इससे पहले के वर्शन में, RenderScript से जुड़े ये अंतर शामिल हैं:
- किसी प्रोसेस में RenderScript की इंटरनल लाइब्रेरी के दो इंस्टेंस. एक सेट, सीपीयू फ़ॉलबैक पाथ के लिए है और यह सीधे
/system/lib
से है. दूसरा सेट, जीपीयू पाथ के लिए है और यह/system/lib/vndk-sp
से है. /system/lib
में मौजूद आरएस इंटरनल लाइब्रेरी, प्लैटफ़ॉर्म के हिस्से के तौर पर बनाई गई हैं. साथ ही,system.img
को अपग्रेड करने पर इन्हें भी अपडेट किया जाता है. हालांकि,/system/lib/vndk-sp
में मौजूद लाइब्रेरी, वेंडर के लिए बनाई गई हैं. साथ ही,system.img
को अपग्रेड करने पर ये अपडेट नहीं होती हैं. हालांकि, सुरक्षा से जुड़ी समस्या को ठीक करने के लिए इन्हें अपडेट किया जा सकता है, लेकिन इनका ABI एक जैसा रहता है.- वेंडर कोड (RS HAL, RS ड्राइवर, और
bcc plugin
) कोbcc plugin
पर मौजूद RenderScript की इंटरनल लाइब्रेरी से लिंक किया जाता है./system/lib/vndk-sp
वे/system/lib
में मौजूद लाइब्रेरी से लिंक नहीं हो सकते, क्योंकि उस डायरेक्ट्री में मौजूद लाइब्रेरी, प्लैटफ़ॉर्म के लिए बनाई गई हैं.इसलिए, हो सकता है कि वे वेंडर कोड के साथ काम न करें. जैसे, सिंबल हटाए जा सकते हैं. ऐसा करने से, सिर्फ़ फ़्रेमवर्क वाले ओटीए को लागू नहीं किया जा सकेगा.
डिज़ाइन
यहां दिए गए सेक्शन में, Android 8.0 और इसके बाद के वर्शन में RenderScript के डिज़ाइन के बारे में बताया गया है.
वेंडर के लिए उपलब्ध RenderScript लाइब्रेरी
इस सेक्शन में, RenderScript libs (इन्हें Same-Process HALs या VNDK-SP के लिए वेंडर एनडीके कहा जाता है) की सूची दी गई है. ये लाइब्रेरी, वेंडर कोड के लिए उपलब्ध हैं और इन्हें लिंक किया जा सकता है. इसमें ऐसी अन्य लाइब्रेरी के बारे में भी जानकारी दी गई है जो RenderScript से जुड़ी नहीं हैं, लेकिन वेंडर कोड को भी उपलब्ध कराई जाती हैं.
Android के अलग-अलग वर्शन में, यहां दी गई लाइब्रेरी की सूची अलग-अलग हो सकती है. हालांकि, Android के किसी वर्शन के लिए यह सूची नहीं बदलती. उपलब्ध लाइब्रेरी की नई सूची देखने के लिए, /system/etc/ld.config.txt
पर जाएं.
RenderScript Libs | Non-RenderScript Libs |
---|---|
|
|
लिंकर के नेमस्पेस का कॉन्फ़िगरेशन
लिंक करने से जुड़ी पाबंदी, VNDK-SP में शामिल नहीं की गई लाइब्रेरी को वेंडर कोड से इस्तेमाल करने से रोकती है. इसे रनटाइम के दौरान, लिंकर नेमस्पेस का इस्तेमाल करके लागू किया जाता है. (ज़्यादा जानकारी के लिए, VNDK डिज़ाइन प्रज़ेंटेशन देखें.)
Android 8.0 और उसके बाद के वर्शन वाले डिवाइस पर, सभी सेम-प्रोसेस एचएएल (एसपी-एचएएल) RenderScript को छोड़कर, लिंकर नेमस्पेस sphal
में लोड किए जाते हैं. RenderScript को RenderScript के लिए खास तौर पर बनाए गए नेमस्पेस rs
में लोड किया जाता है. यह एक ऐसी जगह है जहां RenderScript लाइब्रेरी के लिए, नियमों को थोड़ा कम सख्ती से लागू किया जाता है. आरएस को लागू करने के लिए, कंपाइल किए गए बिटकोड को लोड करना ज़रूरी होता है. इसलिए, /data/*/*.so
को rs
नेमस्पेस के पाथ में जोड़ा जाता है. अन्य एसपी-एचएएल को डेटा पार्टिशन से लाइब्रेरी लोड करने की अनुमति नहीं है.
इसके अलावा, rs
नेमस्पेस में, अन्य नेमस्पेस की तुलना में ज़्यादा लाइब्रेरी इस्तेमाल की जा सकती हैं. libmediandk.so
और libft2.so
को rs
नेमस्पेस में दिखाया जाता है, क्योंकि libRS_internal.so
की इन लाइब्रेरी पर इंटरनल डिपेंडेंसी है.

दूसरी इमेज. लिंकर के लिए नेमस्पेस कॉन्फ़िगरेशन.
ड्राइवर लोड करें
सीपीयू फ़ॉलबैक पाथ
आरएस कॉन्टेक्स्ट बनाते समय, RS_CONTEXT_LOW_LATENCY
बिट मौजूद है या नहीं, इसके आधार पर सीपीयू या जीपीयू पाथ चुना जाता है. सीपीयू पाथ चुने जाने पर, libRS_internal.so
(आरएस फ़्रेमवर्क का मुख्य इंप्लीमेंटेशन) को डिफ़ॉल्ट लिंकर नेमस्पेस से सीधे तौर पर dlopen
किया जाता है. इस नेमस्पेस में, आरएस लाइब्रेरी का प्लैटफ़ॉर्म वर्शन उपलब्ध कराया जाता है.
सीपीयू फ़ॉलबैक पाथ का इस्तेमाल करने पर, वेंडर के आरएस एचएएल को लागू नहीं किया जाता है. साथ ही, RsContext
ऑब्जेक्ट को null mVendorDriverName
के साथ बनाया जाता है. libRSDriver.so
को (डिफ़ॉल्ट रूप से) dlopen
किया जाता है. साथ ही, ड्राइवर लाइब्रेरी को default
नेमस्पेस से लोड किया जाता है. ऐसा इसलिए होता है, क्योंकि कॉलर (libRS_internal.so
) को भी default
नेमस्पेस में लोड किया जाता है.

तीसरी इमेज. सीपीयू फ़ॉलबैक पाथ.
जीपीयू पाथ
जीपीयू पाथ के लिए, libRS_internal.so
को अलग तरीके से लोड किया जाता है.
सबसे पहले, libRS.so
, android.hardware.renderscript@1.0.so
(और इसके नीचे मौजूद libhidltransport.so
) का इस्तेमाल करके, android.hardware.renderscript@1.0-impl.so
(आरएस एचएएल का वेंडर इंप्लीमेंटेशन) को sphal
नाम के किसी दूसरे लिंकर नेमस्पेस में लोड करता है. इसके बाद, RS HAL, dlopen
s libRS_internal.so
को rs
नाम के दूसरे लिंकर नेमस्पेस में भेजता है.
वेंडर, आरएस ड्राइवर उपलब्ध करा सकते हैं. इसके लिए, उन्हें बिल्ड टाइम फ़्लैग OVERRIDE_RS_DRIVER
सेट करना होगा. यह आरएस एचएएल hardware/interfaces/renderscript/1.0/default/Context.cpp
में एम्बेड किया जाता है. इसके बाद, इस ड्राइवर के नाम को आरएस कॉन्टेक्स्ट के लिए dlopen
किया जाता है.
RsContext
ऑब्जेक्ट बनाने का काम, आरएस एचएएल को सौंपा जाता है. HAL, RS फ़्रेमवर्क को वापस कॉल करता है. इसके लिए, वह rsContextCreateVendor()
फ़ंक्शन का इस्तेमाल करता है. इसमें ड्राइवर का नाम, आर्ग्युमेंट के तौर पर इस्तेमाल किया जाता है. इसके बाद, आरएस फ़्रेमवर्क, RsContext
के शुरू होने पर तय किए गए ड्राइवर को लोड करता है. इस मामले में, ड्राइवर लाइब्रेरी को rs
नेमस्पेस में लोड किया जाता है, क्योंकि RsContext
ऑब्जेक्ट को rs
नेमस्पेस में बनाया जाता है और /vendor/lib
, नेमस्पेस के खोज पाथ में होता है.

चौथी इमेज. जीपीयू फ़ॉलबैक पाथ.
default
नेमस्पेस से sphal
नेमस्पेस पर ट्रांज़िशन करते समय, libhidltransport.so
, android_load_sphal_library()
फ़ंक्शन का इस्तेमाल करता है. इससे डाइनैमिक लिंकर को sphal
नेमस्पेस से -impl.so
लाइब्रेरी लोड करने का साफ़ तौर पर निर्देश मिलता है.
sphal
नेमस्पेस से rs
नेमस्पेस पर ट्रांज़िशन करते समय, /system/etc/ld.config.txt
में मौजूद इस लाइन के ज़रिए लोडिंग परोक्ष रूप से की जाती है:
namespace.sphal.link.rs.shared_libs = libRS_internal.so
इस लाइन से पता चलता है कि डाइनैमिक लिंकर को libRS_internal.so
को rs
नेमस्पेस से लोड करना चाहिए. ऐसा तब होता है, जब lib को sphal
नेमस्पेस से नहीं ढूंढा/लोड किया जा सकता. ऐसा हमेशा इसलिए होता है, क्योंकि sphal
नेमस्पेस, /system/lib/vndk-sp
को खोजता नहीं है. /system/lib/vndk-sp
में libRS_internal.so
मौजूद होता है. इस कॉन्फ़िगरेशन के साथ, नेमस्पेस को ट्रांज़िशन करने के लिए, libRS_internal.so
को dlopen()
कॉल करना काफ़ी है.
गुप्त कॉपी प्लगिन लोड करें
bcc plugin
, वेंडर की ओर से उपलब्ध कराई गई लाइब्रेरी है. इसे bcc
कंपाइलर में लोड किया जाता है. bcc
, /system/bin
डायरेक्ट्री में मौजूद एक सिस्टम प्रोसेस है. इसलिए, bcc plugin
लाइब्रेरी को एसपी-एचएएल माना जा सकता है. इसका मतलब है कि यह एक वेंडर एचएएल है, जिसे सीधे तौर पर सिस्टम प्रोसेस में लोड किया जा सकता है. इसके लिए, इसे बाइंडर में शामिल करने की ज़रूरत नहीं होती. एसपी-एचएएल के तौर पर, bcc-plugin
लाइब्रेरी:
- सिर्फ़ फ़्रेमवर्क वाली लाइब्रेरी, जैसे कि
libLLVM.so
के साथ लिंक नहीं किया जा सकता. - सिर्फ़ उन VNDK-SP लाइब्रेरी से लिंक किया जा सकता है जो वेंडर के लिए उपलब्ध हैं.
यह पाबंदी, android_sphal_load_library()
फ़ंक्शन का इस्तेमाल करके bcc plugin
को sphal
नेमस्पेस में लोड करने से लागू होती है. Android के पिछले वर्शन में, प्लगिन का नाम -load
विकल्प का इस्तेमाल करके तय किया जाता था. साथ ही, lib को libLLVM.so
की मदद से, सामान्य dlopen()
का इस्तेमाल करके लोड किया जाता था. Android 8.0 और इसके बाद के वर्शन में, इसे -plugin
विकल्प में बताया गया है. साथ ही, lib को सीधे -plugin
से लोड किया जाता है.bcc
इस विकल्प से, Android के अलावा किसी अन्य प्लैटफ़ॉर्म पर ओपन सोर्स LLVM प्रोजेक्ट का इस्तेमाल किया जा सकता है.

पांचवीं इमेज. Android 7.x और इससे पहले के वर्शन पर, bcc प्लगिन लोड हो रहा है.

छठी इमेज. bcc प्लगिन लोड हो रहा है. इसके लिए, Android 8.0 और उसके बाद के वर्शन की ज़रूरत होती है.
ld.mc के लिए खोज पाथ
ld.mc
को लागू करते समय, कुछ आरएस रनटाइम लाइब्रेरी को लिंकर को इनपुट के तौर पर दिया जाता है. ऐप्लिकेशन के आरएस बिटकोड को रनटाइम लाइब्रेरी से लिंक किया जाता है. साथ ही, जब बदले गए बिटकोड को किसी ऐप्लिकेशन प्रोसेस में लोड किया जाता है, तब रनटाइम लाइब्रेरी को बदले गए बिटकोड से फिर से डाइनैमिक तरीके से लिंक किया जाता है.
रनटाइम लाइब्रेरी में ये शामिल हैं:
libcompiler_rt.so
libm.so
libc.so
- RS ड्राइवर (
libRSDriver.so
याOVERRIDE_RS_DRIVER
)
ऐप्लिकेशन प्रोसेस में कंपाइल किए गए बिटकोड को लोड करते समय, वही लाइब्रेरी उपलब्ध कराएं जिसका इस्तेमाल ld.mc
ने किया था. ऐसा न करने पर, हो सकता है कि कंपाइल किए गए बिटकोड को ऐसा सिंबल न मिले जो लिंक करते समय उपलब्ध था.
इसके लिए, RS फ़्रेमवर्क, ld.mc
को एक्ज़ीक्यूट करते समय, रनटाइम लाइब्रेरी के लिए अलग-अलग सर्च पाथ का इस्तेमाल करता है. यह इस बात पर निर्भर करता है कि RS फ़्रेमवर्क को /system/lib
से लोड किया गया है या /system/lib/vndk-sp
से.
इसे आरएस फ़्रेमवर्क lib के किसी भी सिंबल का पता पढ़कर तय किया जा सकता है. साथ ही, dladdr()
का इस्तेमाल करके, पते पर मैप किए गए फ़ाइल पाथ को पाया जा सकता है.
SELinux नीति
Android 8.0 और इसके बाद के वर्शन में SELinux नीति में हुए बदलावों की वजह से, आपको vendor
पार्टीशन में अतिरिक्त फ़ाइलों को लेबल करते समय, कुछ खास नियमों का पालन करना होगा. ये नियम neverallows
के ज़रिए लागू किए जाते हैं:
vendor_file
,vendor
पार्टीशन में मौजूद सभी फ़ाइलों के लिए डिफ़ॉल्ट लेबल होना चाहिए. पासथ्रू एचएएल लागू करने की सुविधा को ऐक्सेस करने के लिए, प्लैटफ़ॉर्म की नीति के तहत यह ज़रूरी है.- वेंडर के SEPolicy के ज़रिए
vendor
पार्टीशन में जोड़े गए सभी नएexec_types
मेंvendor_file_type
एट्रिब्यूट होना चाहिए. इसेneverallows
के ज़रिए लागू किया जाता है. - आने वाले समय में प्लैटफ़ॉर्म/फ़्रेमवर्क के अपडेट से जुड़ी समस्याओं से बचने के लिए,
vendor
पार्टीशन मेंexec_types
के अलावा अन्य फ़ाइलों को लेबल न करें. - AOSP के लिए, एक ही प्रोसेस वाले HAL की सभी लाइब्रेरी डिपेंडेंसी को
same_process_hal_file
के तौर पर लेबल किया जाना चाहिए.
SELinux नीति के बारे में जानकारी के लिए, Android में Security-Enhanced Linux लेख पढ़ें.
बिटकोड के लिए ABI के साथ काम करने की सुविधा
अगर कोई नया एपीआई नहीं जोड़ा जाता है, तो इसका मतलब है कि HAL वर्शन में कोई बदलाव नहीं हुआ है. ऐसे में, आरएस फ़्रेमवर्क मौजूदा जीपीयू (HAL 1.0) ड्राइवर का इस्तेमाल करते रहेंगे.
अगर HAL में मामूली बदलाव (HAL 1.1) किए गए हैं और इससे बिटकोड पर कोई असर नहीं पड़ता है, तो फ़्रेमवर्क को इन नए एपीआई के लिए सीपीयू का इस्तेमाल करना चाहिए. साथ ही, अन्य जगहों पर जीपीयू (HAL 1.0) ड्राइवर का इस्तेमाल जारी रखना चाहिए.
बिटकोड कंपाइल करने/लिंक करने पर असर डालने वाले एचएएल 2.0 में हुए बड़े बदलावों के लिए, आरएस फ़्रेमवर्क को वेंडर के दिए गए जीपीयू ड्राइवर लोड नहीं करने चाहिए. इसके बजाय, उन्हें ऐक्सलरेशन के लिए सीपीयू या वल्कन पाथ का इस्तेमाल करना चाहिए.
RenderScript बिटकोड का इस्तेमाल तीन चरणों में किया जाता है:
स्टेज | जानकारी |
---|---|
कंपाइल करें |
|
लिंक |
|
लोड करें |
|
एचएएल के अलावा, रनटाइम एपीआई और एक्सपोर्ट किए गए सिंबल भी इंटरफ़ेस होते हैं. Android 7.0 (API 24) के बाद से, दोनों इंटरफ़ेस में कोई बदलाव नहीं हुआ है. साथ ही, Android 8.0 और इसके बाद के वर्शन में भी इसे बदलने का कोई प्लान नहीं है. हालांकि, अगर इंटरफ़ेस में बदलाव होता है, तो एचएएल वर्शन भी बढ़ जाएगा.
वेंडर के लागू किए गए सिस्टम
Android 8.0 और उसके बाद के वर्शन पर, जीपीयू ड्राइवर को ठीक से काम करने के लिए, जीपीयू ड्राइवर में कुछ बदलाव करने पड़ते हैं.
ड्राइवर मॉड्यूल
- ड्राइवर मॉड्यूल, ऐसी किसी भी सिस्टम लाइब्रेरी पर निर्भर नहीं होने चाहिए जो इस सूची में शामिल नहीं है.
- ड्राइवर को अपना
android.hardware.renderscript@1.0-impl_{NAME}
देना होगा या डिफ़ॉल्ट तौर पर लागू किए गएandroid.hardware.renderscript@1.0-impl
को अपनी डिपेंडेंसी के तौर पर घोषित करना होगा. - सीपीयू को लागू करने का तरीका
libRSDriver.so
, यह दिखाता है कि नॉन-वीएनडीके-एसपी डिपेंडेंसी को कैसे हटाया जाता है.
बिटकोड कंपाइलर
वेंडर ड्राइवर के लिए RenderScript बिटकोड को दो तरीकों से कंपाइल किया जा सकता है:
/vendor/bin/
में वेंडर के हिसाब से RenderScript कंपाइलर को शुरू करें (जीपीयू कंपाइलेशन का पसंदीदा तरीका). अन्य ड्राइवर मॉड्यूल की तरह, वेंडर कंपाइलर बाइनरी किसी ऐसी सिस्टम लाइब्रेरी पर निर्भर नहीं हो सकती जो वेंडर के लिए उपलब्ध RenderScript लाइब्रेरी की सूची में शामिल नहीं है.- सिस्टम bcc:
/system/bin/bcc
को वेंडर के दिए गएbcc plugin
के साथ कॉल करें; यह प्लगिन, किसी ऐसी सिस्टम लाइब्रेरी पर निर्भर नहीं हो सकता जो वेंडर के लिए उपलब्ध RenderScript लाइब्रेरी की सूची में शामिल नहीं है.
अगर वेंडर bcc plugin
को सीपीयू कंपाइलेशन में दखल देना है और libLLVM.so
पर इसकी निर्भरता को आसानी से हटाया नहीं जा सकता, तो वेंडर को bcc
(और libLLVM.so
, libbcc.so
सहित सभी नॉन-एलएल-एनडीके डिपेंडेंसी) को /vendor
पार्टीशन में कॉपी करना चाहिए.
इसके अलावा, वेंडर को ये बदलाव करने होंगे:

सातवीं इमेज. वेंडर के ड्राइवर में बदलाव.
libclcore.bc
को/vendor
पार्टीशन में कॉपी करें. इससे यह पक्का होता है किlibclcore.bc
,libLLVM.so
, औरlibbcc.so
सिंक हो रहे हैं.- RS HAL के लागू करने वाले हिस्से से
RsdCpuScriptImpl::BCC_EXE_PATH
को सेट करके,bcc
की एक्ज़िक्यूट की जा सकने वाली फ़ाइल का पाथ बदलें.
SELinux नीति
SELinux नीति का असर, ड्राइवर और कंपाइलर, दोनों के एक्सीक्यूटेबल पर पड़ता है. सभी ड्राइवर मॉड्यूल को डिवाइस के file_contexts
में same_process_hal_file
के तौर पर लेबल किया जाना चाहिए. उदाहरण के लिए:
/vendor/lib(64)?/libRSDriver_EXAMPLE\.so u:object_r:same_process_hal_file:s0
कंपाइलर एक्ज़ीक्यूटेबल को ऐप्लिकेशन प्रोसेस से शुरू किया जा सकता है. साथ ही, बीसीसी (/vendor/bin/bcc
) की वेंडर कॉपी को भी शुरू किया जा सकता है. उदाहरण के लिए:
device/vendor_foo/device_bar/sepolicy/file_contexts: /vendor/bin/bcc u:object_r:same_process_hal_file:s0
लेगसी डिवाइस
लेगसी डिवाइस वे होते हैं जो इन शर्तों को पूरा करते हैं:
- PRODUCT_SHIPPING_API_LEVEL 26 से कम है.
- PRODUCT_FULL_TREBLE_OVERRIDE को सेट नहीं किया गया है.
लेगसी डिवाइसों के लिए, Android 8.0 और इसके बाद के वर्शन पर अपग्रेड करने पर पाबंदियां लागू नहीं होती हैं. इसका मतलब है कि ड्राइवर, /system/lib[64]
में मौजूद लाइब्रेरी से लिंक करना जारी रख सकते हैं. हालांकि, OVERRIDE_RS_DRIVER
से जुड़े आर्किटेक्चर में बदलाव की वजह से, /vendor
पार्टीशन में android.hardware.renderscript@1.0-impl
इंस्टॉल करना ज़रूरी है. ऐसा न करने पर, RenderScript रनटाइम को सीपीयू पाथ पर फ़ॉलबैक करना पड़ता है.
Renderscript को बंद करने की वजह के बारे में जानने के लिए, Android Developers ब्लॉग पर जाएं: Android GPU Compute Going Forward. इस सुविधा के बंद होने से जुड़ी जानकारी में ये चीज़ें शामिल हैं:
- Renderscript से माइग्रेट करना
- RenderScriptMigration Sample
- इंट्रिंसिक फ़ंक्शन बदलने से जुड़ी टूलकिट README
- इंट्रिंसिक फ़ंक्शन को बदलने वाला Toolkit.kt