RenderScript

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 को अपग्रेड करने पर ये अपडेट नहीं होती हैं. हालांकि, सुरक्षा से जुड़ी समस्या को ठीक करने के लिए इन्हें अपडेट किया जा सकता है. इनका एबीआई एक जैसा रहता है.
  • वेंडर कोड (RS HAL, RS ड्राइवर, और bcc plugin) को /system/lib/vndk-sp पर मौजूद RenderScript की इंटरनल लाइब्रेरी से लिंक किया जाता है. वे /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
  • android.hardware.graphics.renderscript@1.0.so
  • libRS_internal.so
  • libRSCpuRef.so
  • libblas.so
  • libbcinfo.so
  • libcompiler_rt.so
  • libRSDriver.so
  • libc.so
  • libm.so
  • libdl.so
  • libstdc++.so
  • liblog.so
  • libnativewindow.so
  • libsync.so
  • libvndksupport.so
  • libbase.so
  • libc++.so
  • libcutils.so
  • libutils.so
  • libhardware.so
  • libhidlbase.so
  • libhidltransport.so
  • libhwbinder.so
  • liblzma.so
  • libz.so
  • libEGL.so
  • libGLESv1_CM.so
  • libGLESv2.so

लिंकर नेमस्पेस कॉन्फ़िगरेशन

लिंक करने से जुड़ी पाबंदी, VNDK-SP में शामिल नहीं की गई लाइब्रेरी को वेंडर कोड से इस्तेमाल करने से रोकती है. यह पाबंदी, लिंकर नेमस्पेस का इस्तेमाल करके रनटाइम में लागू की जाती है. (ज़्यादा जानकारी के लिए, वीएनडीके डिज़ाइन प्रज़ेंटेशन देखें.)

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 ऑब्जेक्ट को शून्य 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, rs नाम के दूसरे लिंकर नेमस्पेस में dlopen libRS_internal.so करता है.

वेंडर, बिल्ड प्रोसेस में लगने वाला समय फ़्लैग 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 को नहीं खोजता है. libRS_internal.so, /system/lib/vndk-sp में मौजूद होता है. इस कॉन्फ़िगरेशन के साथ, नेमस्पेस को ट्रांज़िशन करने के लिए, dlopen() को libRS_internal.so पर कॉल करना काफ़ी है.

गुप्त कॉपी प्लगिन लोड करें

bcc plugin, वेंडर की ओर से उपलब्ध कराई गई लाइब्रेरी है. इसे bcc कंपाइलर में लोड किया जाता है. bcc, /system/bin डायरेक्ट्री में मौजूद एक सिस्टम प्रोसेस है. इसलिए, bcc plugin लाइब्रेरी को एसपी-एचएएल माना जा सकता है. इसका मतलब है कि यह एक वेंडर एचएएल है, जिसे सीधे तौर पर सिस्टम प्रोसेस में लोड किया जा सकता है. इसके लिए, इसे बाइंडर में शामिल करने की ज़रूरत नहीं होती. एसपी-एचएएल के तौर पर, bcc-plugin लाइब्रेरी:

  • सिर्फ़ फ़्रेमवर्क वाली लाइब्रेरी, जैसे कि libLLVM.so के साथ लिंक नहीं किया जा सकता.
  • वेंडर के लिए उपलब्ध VNDK-SP लाइब्रेरी के साथ ही लिंक किया जा सकता है.

इस पाबंदी को लागू करने के लिए, bcc plugin को android_sphal_load_library() फ़ंक्शन का इस्तेमाल करके sphal नेमस्पेस में लोड किया जाता है. Android के पिछले वर्शन में, प्लगिन का नाम -load विकल्प का इस्तेमाल करके तय किया जाता था. साथ ही, lib को libLLVM.so की मदद से, dlopen() का इस्तेमाल करके लोड किया जाता था. Android 8.0 और इसके बाद के वर्शन में, इसे -plugin विकल्प में बताया गया है. साथ ही, lib को सीधे bcc लोड करता है. इस विकल्प से, Android के अलावा किसी अन्य प्लैटफ़ॉर्म पर ओपन सोर्स LLVM प्रोजेक्ट का इस्तेमाल किया जा सकता है.

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



छठी इमेज. bcc प्लगिन लोड हो रहा है. इसके लिए, Android 8.0 और इसके बाद के वर्शन की ज़रूरत होती है.

ld.mc के लिए खोज पाथ

ld.mc को लागू करते समय, कुछ आरएस रनटाइम लाइब्रेरी को लिंकर को इनपुट के तौर पर दिया जाता है. ऐप्लिकेशन के आरएस बिटकोड को रनटाइम लाइब्रेरी के साथ लिंक किया जाता है. साथ ही, जब बदले गए बिटकोड को किसी ऐप्लिकेशन प्रोसेस में लोड किया जाता है, तब रनटाइम लाइब्रेरी को बदले गए बिटकोड से फिर से डाइनैमिक रूप से लिंक किया जाता है.

रनटाइम लाइब्रेरी में ये शामिल हैं:

  • libcompiler_rt.so
  • libm.so
  • libc.so
  • आरएस ड्राइवर (libRSDriver.so या OVERRIDE_RS_DRIVER)

ऐप्लिकेशन प्रोसेस में कंपाइल किए गए बिटकोड को लोड करते समय, वही लाइब्रेरी उपलब्ध कराएं जिसका इस्तेमाल ld.mc ने किया था. ऐसा न करने पर, हो सकता है कि कंपाइल किए गए बिटकोड को ऐसा सिंबल न मिले जो लिंक करते समय उपलब्ध था.

इसके लिए, आरएस फ़्रेमवर्क, रनटाइम लाइब्रेरी के लिए अलग-अलग खोज पाथ का इस्तेमाल करता है. ऐसा ld.mc को एक्ज़ीक्यूट करते समय किया जाता है. यह इस बात पर निर्भर करता है कि आरएस फ़्रेमवर्क को /system/lib से लोड किया गया है या /system/lib/vndk-sp से. इसे आरएस फ़्रेमवर्क की किसी भी लाइब्रेरी के सिंबल का पता पढ़कर तय किया जा सकता है. साथ ही, 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 बिटकोड का इस्तेमाल तीन चरणों में किया जाता है:

स्टेज जानकारी
कंपाइल करें
  • bcc के लिए इनपुट बिटकोड (.bc), LLVM 3.2 बिटकोड फ़ॉर्मैट में होना चाहिए. साथ ही, bcc मौजूदा (लेगसी) ऐप्लिकेशन के साथ काम करना चाहिए.
  • हालांकि, .bc में मौजूद मेटा-डेटा बदल सकता है. इसमें नए रनटाइम फ़ंक्शन हो सकते हैं. जैसे, ऐलोकेशन सेटर और गेटर, गणित के फ़ंक्शन वगैरह. रनटाइम फ़ंक्शन का कुछ हिस्सा libclcore.bc में होता है. वहीं, कुछ हिस्सा LibRSDriver या वेंडर के बराबर होता है.
  • नए रनटाइम फ़ंक्शन या मेटा-डेटा में बड़े बदलावों के लिए, बिटकोड एपीआई लेवल को बढ़ाना ज़रूरी है. वेंडर ड्राइवर इसका इस्तेमाल नहीं कर पाएंगे. इसलिए, HAL वर्शन को भी बढ़ाना होगा.
  • ऐसा हो सकता है कि वेंडर के पास अपने कंपाइलर हों. हालांकि, bcc के लिए तय किए गए निष्कर्ष/ज़रूरतें उन कंपाइलर पर भी लागू होती हैं.
लिंक
  • कंपाइल की गई .o फ़ाइल, वेंडर ड्राइवर के साथ लिंक की जाएगी. उदाहरण के लिए, libRSDriver_foo.so और libcompiler_rt.so. सीपीयू पाथ, libRSDriver.so से लिंक हो जाएगा.
  • अगर .o को libRSDriver_foo से नए रनटाइम एपीआई की ज़रूरत है, तो इसे सपोर्ट करने के लिए वेंडर ड्राइवर को अपडेट करना होगा.
  • कुछ वेंडर के पास अपने लिंक करने वाले हो सकते हैं, लेकिन ld.mc के लिए तर्क उन पर भी लागू होता है.
लोड करें
  • libRSCpuRef शेयर किए गए ऑब्जेक्ट को लोड करता है. अगर इस इंटरफ़ेस में कोई बदलाव होता है, तो एचएएल के वर्शन को अपग्रेड करना ज़रूरी है.
  • वेंडर, शेयर किए गए ऑब्जेक्ट को लोड करने के लिए libRSCpuRef पर भरोसा करेंगे या खुद का ऑब्जेक्ट लागू करेंगे.

एचएएल के अलावा, रनटाइम एपीआई और एक्सपोर्ट किए गए सिंबल भी इंटरफ़ेस होते हैं. Android 7.0 (एपीआई 24) के बाद से, दोनों इंटरफ़ेस में कोई बदलाव नहीं हुआ है. साथ ही, Android 8.0 और इसके बाद के वर्शन में भी इसे बदलने का कोई प्लान नहीं है. हालांकि, अगर इंटरफ़ेस में बदलाव होता है, तो एचएएल वर्शन भी बढ़ जाएगा.

वेंडर के लागू करने के तरीके

Android 8.0 और इसके बाद के वर्शन पर, जीपीयू ड्राइवर को सही तरीके से काम करने के लिए, जीपीयू ड्राइवर में कुछ बदलाव करने पड़ते हैं.

ड्राइवर मॉड्यूल

  • ड्राइवर मॉड्यूल, ऐसी किसी भी सिस्टम लाइब्रेरी पर निर्भर नहीं होने चाहिए जो इस सूची में शामिल नहीं है.
  • ड्राइवर को अपना android.hardware.renderscript@1.0-impl_{NAME} देना होगा या डिफ़ॉल्ट तौर पर लागू किए गए android.hardware.renderscript@1.0-impl को अपनी डिपेंडेंसी के तौर पर घोषित करना होगा.
  • सीपीयू को लागू करने का तरीका libRSDriver.so, यह दिखाता है कि VNDK-SP पर निर्भर न रहने वाली डिपेंडेंसी को कैसे हटाया जाता है.

बिटकोड कंपाइलर

वेंडर ड्राइवर के लिए RenderScript बिटकोड को दो तरीकों से कंपाइल किया जा सकता है:

  1. /vendor/bin/ में वेंडर के हिसाब से RenderScript कंपाइलर को लागू करें (जीपीयू कंपाइलेशन का पसंदीदा तरीका). अन्य ड्राइवर मॉड्यूल की तरह, वेंडर कंपाइलर बाइनरी किसी ऐसी सिस्टम लाइब्रेरी पर निर्भर नहीं हो सकती जो वेंडर के लिए उपलब्ध RenderScript लाइब्रेरी की सूची में शामिल न हो.
  2. वेंडर की ओर से उपलब्ध कराए गए bcc plugin के साथ, सिस्टम bcc: /system/bin/bcc को शुरू करें; यह प्लगिन, किसी ऐसी सिस्टम लाइब्रेरी पर निर्भर नहीं हो सकता जो वेंडर के लिए उपलब्ध RenderScript लाइब्रेरी की सूची में शामिल नहीं है.

अगर वेंडर bcc plugin को सीपीयू कंपाइलेशन में दखल देना है और libLLVM.so पर इसकी निर्भरता को आसानी से हटाया नहीं जा सकता, तो वेंडर को bcc (और libLLVM.so, libbcc.so सहित सभी नॉन-एलएल-एनडीके डिपेंडेंसी) को /vendor पार्टीशन में कॉपी करना चाहिए.

इसके अलावा, वेंडर को ये बदलाव करने होंगे:

सातवीं इमेज. वेंडर ड्राइवर में बदलाव.

  1. libclcore.bc को /vendor पार्टीशन में कॉपी करें. इससे यह पक्का होता है कि libclcore.bc, libLLVM.so, और libbcc.so सिंक हो रहे हैं.
  2. RS HAL implementation से 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

कंपाइलर एक्ज़ीक्यूटेबल को ऐप्लिकेशन प्रोसेस से शुरू किया जा सकता है. साथ ही, bcc (/vendor/bin/bcc) की वेंडर कॉपी को भी शुरू किया जा सकता है. उदाहरण के लिए: 

device/vendor_foo/device_bar/sepolicy/file_contexts:
/vendor/bin/bcc                    u:object_r:same_process_hal_file:s0

लेगसी डिवाइस

लेगसी डिवाइस वे होते हैं जो इन शर्तों को पूरा करते हैं:

  1. PRODUCT_SHIPPING_API_LEVEL, 26 से कम है.
  2. PRODUCT_FULL_TREBLE_OVERRIDE को सेट नहीं किया गया है.

लेगसी डिवाइसों के लिए, Android 8.0 और इसके बाद के वर्शन पर अपग्रेड करने पर पाबंदियां लागू नहीं होती हैं. इसका मतलब है कि ड्राइवर, /system/lib[64] में मौजूद लाइब्रेरी से लिंक करना जारी रख सकते हैं. हालांकि, OVERRIDE_RS_DRIVER से जुड़े आर्किटेक्चर में बदलाव की वजह से, /vendor पार्टीशन के लिए android.hardware.renderscript@1.0-impl को इंस्टॉल करना ज़रूरी है. ऐसा न करने पर, RenderScript रनटाइम को सीपीयू पाथ पर फ़ॉलबैक करना पड़ता है.

Renderscript को बंद करने की वजह जानने के लिए, Android Developers Blog: Android GPU Compute Going Forward लेख पढ़ें. इस सुविधा के बंद होने से जुड़े संसाधन में यह जानकारी शामिल है: