रेंडरस्क्रिप्ट

रेंडरस्क्रिप्ट एंड्रॉइड पर उच्च प्रदर्शन पर कम्प्यूटेशनल रूप से गहन कार्यों को चलाने के लिए एक रूपरेखा है। इसे डेटा-समानांतर गणना के साथ उपयोग के लिए डिज़ाइन किया गया है, हालांकि सीरियल वर्कलोड से भी लाभ हो सकता है। रेंडरस्क्रिप्ट रनटाइम एक डिवाइस पर उपलब्ध प्रोसेसर जैसे मल्टी-कोर सीपीयू और जीपीयू में काम को समानांतर करता है, जिससे डेवलपर्स काम को शेड्यूल करने के बजाय व्यक्त एल्गोरिदम पर ध्यान केंद्रित करने में सक्षम होते हैं। रेंडरस्क्रिप्ट विशेष रूप से इमेज प्रोसेसिंग, कम्प्यूटेशनल फोटोग्राफी या कंप्यूटर विज़न करने वाले अनुप्रयोगों के लिए उपयोगी है।

एंड्रॉइड 8.0 और उच्चतर चलाने वाले डिवाइस निम्नलिखित रेंडरस्क्रिप्ट फ्रेमवर्क और विक्रेता एचएएल का उपयोग करते हैं:

चित्र 1. आंतरिक कार्यों से लिंक करने वाला विक्रेता कोड

एंड्रॉइड 7.x और उससे निचले संस्करण में रेंडरस्क्रिप्ट से अंतर में शामिल हैं:

  • एक प्रक्रिया में रेंडरस्क्रिप्ट आंतरिक libs के दो उदाहरण। एक सेट सीपीयू फ़ॉलबैक पथ के लिए है और सीधे /system/lib से है; दूसरा सेट GPU पथ के लिए है और /system/lib/vndk-sp से है।
  • /system/lib में RS आंतरिक libs प्लेटफ़ॉर्म के भाग के रूप में बनाए गए हैं और system.img के अपग्रेड होने पर अपडेट किए जाते हैं। हालाँकि, /system/lib/vndk-sp में libs विक्रेता के लिए बनाए गए हैं और system.img अपग्रेड होने पर अपडेट नहीं किए जाते हैं (जबकि उन्हें सुरक्षा सुधार के लिए अपडेट किया जा सकता है, उनका ABI वही रहता है)।
  • विक्रेता कोड (आरएस एचएएल, आरएस ड्राइवर और bcc plugin ) /system/lib/vndk-sp पर स्थित रेंडरस्क्रिप्ट आंतरिक libs से जुड़े हुए हैं। वे /system/lib में libs के विरुद्ध लिंक नहीं कर सकते क्योंकि उस निर्देशिका में libs प्लेटफ़ॉर्म के लिए बनाए गए हैं और इस प्रकार विक्रेता कोड के साथ संगत नहीं हो सकते हैं (यानी, प्रतीकों को हटाया जा सकता है)। ऐसा करने से केवल रूपरेखा वाला ओटीए असंभव हो जाएगा।

डिज़ाइन

निम्नलिखित अनुभाग एंड्रॉइड 8.0 और उच्चतर में रेंडरस्क्रिप्ट डिज़ाइन का विवरण देते हैं।

रेंडरस्क्रिप्ट लिबास विक्रेताओं के लिए उपलब्ध है

यह अनुभाग रेंडरस्क्रिप्ट लिब्ज़ (समान-प्रक्रिया एचएएल या वीएनडीके-एसपी के लिए विक्रेता एनडीके के रूप में जाना जाता है) को सूचीबद्ध करता है जो विक्रेता कोड के लिए उपलब्ध हैं और जिनके विरुद्ध लिंक किया जा सकता है। यह अतिरिक्त पुस्तकालयों का भी विवरण देता है जो रेंडरस्क्रिप्ट से असंबंधित हैं लेकिन जो विक्रेता कोड को भी प्रदान किए जाते हैं।

हालाँकि एंड्रॉइड रिलीज़ के बीच लाइब्रेरी की निम्नलिखित सूची भिन्न हो सकती है, यह एक विशिष्ट एंड्रॉइड रिलीज़ के लिए अपरिवर्तनीय है; उपलब्ध पुस्तकालयों की अद्यतन सूची के लिए, /system/etc/ld.config.txt देखें।

रेंडरस्क्रिप्ट लिब्स नॉन-रेंडरस्क्रिप्ट लिब्स
  • 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

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

लिंकिंग प्रतिबंध जो वीएनडीके-एसपी में नहीं मौजूद libs को विक्रेता कोड द्वारा उपयोग किए जाने से रोकता है, लिंकर नेमस्पेस का उपयोग करके रनटाइम पर लागू किया जाता है। (विवरण के लिए, VNDK डिज़ाइन प्रस्तुति देखें।)

एंड्रॉइड 8.0 और उच्चतर चलाने वाले डिवाइस पर, रेंडरस्क्रिप्ट को छोड़कर सभी समान-प्रक्रिया एचएएल (एसपी-एचएएल) लिंकर नेमस्पेस sphal के अंदर लोड किए जाते हैं। रेंडरस्क्रिप्ट को रेंडरस्क्रिप्ट-विशिष्ट नेमस्पेस rs में लोड किया गया है, एक ऐसा स्थान जो रेंडरस्क्रिप्ट लिब के लिए थोड़ा ढीला प्रवर्तन सक्षम करता है। क्योंकि आरएस कार्यान्वयन को संकलित बिटकोड को लोड करने की आवश्यकता होती है, /data/*/*.so को rs नेमस्पेस के पथ में जोड़ा जाता है (अन्य एसपी-एचएएल को डेटा विभाजन से लिब लोड करने की अनुमति नहीं है)।

इसके अलावा, rs नेमस्पेस अन्य नेमस्पेस द्वारा प्रदान की गई तुलना में अधिक libs की अनुमति देता है। libmediandk.so और libft2.so rs नेमस्पेस के संपर्क में हैं क्योंकि libRS_internal.so की इन पुस्तकालयों पर आंतरिक निर्भरता है।

चित्र 2. लिंकर के लिए नेमस्पेस कॉन्फ़िगरेशन

ड्राइवर लोड हो रहे हैं

सीपीयू फ़ॉलबैक पथ

RS संदर्भ बनाते समय RS_CONTEXT_LOW_LATENCY बिट के अस्तित्व के आधार पर, CPU या GPU पथ का चयन किया जाता है। जब सीपीयू पथ का चयन किया जाता है, libRS_internal.so (RS फ्रेमवर्क का मुख्य कार्यान्वयन) सीधे डिफ़ॉल्ट लिंकर नेमस्पेस से dlopen ed होता है जहां RS libs का प्लेटफ़ॉर्म संस्करण प्रदान किया जाता है।

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

चित्र 4. सीपीयू फ़ॉलबैक पथ

जीपीयू पथ

GPU पथ के लिए, libRS_internal.so अलग तरीके से लोड किया गया है। सबसे पहले, libRS.so android.hardware.renderscript@1.0.so (और इसके अंतर्निहित libhidltransport.so ) का उपयोग android.hardware.renderscript@1.0-impl.so (RS HAL का एक विक्रेता कार्यान्वयन) को एक अलग लिंकर नेमस्पेस में लोड करने के लिए करता है जिसे कहा जाता है sphal । RS HAL फिर s libRS_internal.so rs नामक एक अन्य लिंकर नेमस्पेस में dlopen ।

विक्रेता बिल्ड टाइम फ़्लैग OVERRIDE_RS_DRIVER सेट करके अपना स्वयं का RS ड्राइवर प्रदान कर सकते हैं, जो RS HAL कार्यान्वयन ( hardware/interfaces/renderscript/1.0/default/Context.cpp ) में एम्बेडेड है। यह ड्राइवर नाम GPU पथ के लिए RS संदर्भ के लिए dlopen ed है।

RsContext ऑब्जेक्ट का निर्माण RS HAL कार्यान्वयन को सौंपा गया है। HAL एक तर्क के रूप में उपयोग करने के लिए ड्राइवर के नाम के साथ rsContextCreateVendor() फ़ंक्शन का उपयोग करके RS फ्रेमवर्क पर वापस कॉल करता है। जब RsContext प्रारंभ होता है तो RS फ्रेमवर्क निर्दिष्ट ड्राइवर को लोड करता है। इस मामले में, ड्राइवर लाइब्रेरी को rs नेमस्पेस में लोड किया जाता है क्योंकि RsContext ऑब्जेक्ट rs नेमस्पेस के अंदर बनाया जाता है और /vendor/lib नेमस्पेस के खोज पथ में होता है।

चित्र 5. जीपीयू फ़ॉलबैक पथ

default नेमस्पेस से sphal नेमस्पेस में संक्रमण करते समय, libhidltransport.so डायनेमिक लिंकर को sphal नेमस्पेस से -impl.so लाइब्रेरी को लोड करने के लिए स्पष्ट रूप से ऑर्डर करने के लिए android_load_sphal_library() फ़ंक्शन का उपयोग करता है।

sphal नेमस्पेस से rs नेमस्पेस में संक्रमण करते समय, लोडिंग अप्रत्यक्ष रूप से /system/etc/ld.config.txt में निम्न पंक्ति द्वारा की जाती है:

namespace.sphal.link.rs.shared_libs = libRS_internal.so

यह पंक्ति निर्दिष्ट करती है कि डायनेमिक लिंकर को rs नेमस्पेस से libRS_internal.so लोड करना चाहिए, जब lib को sphal नेमस्पेस से नहीं पाया/लोड किया जा सकता है (जो हमेशा होता है क्योंकि sphal नेमस्पेस /system/lib/vndk-sp को कहां नहीं खोजता है) libRS_internal.so रहता है)। इस कॉन्फ़िगरेशन के साथ, libRS_internal.so पर एक साधारण dlopen() कॉल नेमस्पेस परिवर्तन करने के लिए पर्याप्त है।

गुप्त प्रतिलिपि प्लगइन लोड हो रहा है

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

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

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

चित्र 6. बीसीसी प्लगइन लोड हो रहा है, एंड्रॉइड 7.x और निचला संस्करण


चित्र 7. बीसीसी प्लगइन लोड हो रहा है, एंड्रॉइड 8.0 और उच्चतर

Ld.mc के लिए पथ खोजें

ld.mc निष्पादित करते समय, कुछ RS रनटाइम libs लिंकर को इनपुट के रूप में दिए जाते हैं। ऐप से आरएस बिटकोड को रनटाइम लिब के विरुद्ध जोड़ा जाता है और जब परिवर्तित बिटकोड को ऐप प्रक्रिया में लोड किया जाता है, तो रनटाइम लिब को फिर से परिवर्तित बिटकोड से गतिशील रूप से लिंक किया जाता है।

रनटाइम libs में शामिल हैं:

  • libcompiler_rt.so
  • libm.so
  • libc.so
  • RS ड्राइवर (या तो libRSDriver.so या OVERRIDE_RS_DRIVER )

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

ऐसा करने के लिए, आरएस फ्रेमवर्क ld.mc को निष्पादित करते समय रनटाइम लिब के लिए अलग-अलग खोज पथों का उपयोग करता है, यह इस पर निर्भर करता है कि आरएस फ्रेमवर्क स्वयं /system/lib से लोड किया गया है या /system/lib/vndk-sp से। इसे आरएस फ्रेमवर्क लिब के एक मनमाने प्रतीक के पते को पढ़कर और फ़ाइल पथ को पते पर मैप करने के लिए dladdr() उपयोग करके निर्धारित किया जा सकता है।

SELinux नीति

एंड्रॉइड 8.0 और उच्चतर में SELinux नीति में बदलाव के परिणामस्वरूप, vendor विभाजन में अतिरिक्त फ़ाइलों को लेबल करते समय आपको विशिष्ट नियमों का पालन करना होगा ( neverallows के माध्यम से लागू):

  • vendor विभाजन में सभी फ़ाइलों के लिए vendor_file डिफ़ॉल्ट लेबल होना चाहिए। प्लेटफ़ॉर्म नीति को पासथ्रू एचएएल कार्यान्वयन तक पहुंचने के लिए इसकी आवश्यकता होती है।
  • विक्रेता SEPolicy के माध्यम से vendor विभाजन में जोड़े गए सभी नए exec_types में vendor_file_type विशेषता होनी चाहिए। इसे neverallows के माध्यम से लागू किया जाता है।
  • भविष्य के प्लेटफ़ॉर्म/फ़्रेमवर्क अपडेट के साथ टकराव से बचने के लिए, vendor विभाजन में exec_types के अलावा अन्य फ़ाइलों को लेबल करने से बचें।
  • AOSP द्वारा पहचानी गई समान प्रक्रिया HAL के लिए सभी लाइब्रेरी निर्भरताओं को same_process_hal_file के रूप में लेबल किया जाना चाहिए।

SELinux नीति के विवरण के लिए, Android में सुरक्षा-उन्नत Linux देखें।

बिटकोड के लिए एबीआई अनुकूलता

यदि कोई नया एपीआई नहीं जोड़ा जाता है, जिसका अर्थ है कि कोई एचएएल संस्करण बम्प नहीं है, तो आरएस फ्रेमवर्क मौजूदा जीपीयू (एचएएल 1.0) ड्राइवर का उपयोग करना जारी रखेगा।

बिटकोड को प्रभावित नहीं करने वाले छोटे एचएएल परिवर्तनों (एचएएल 1.1) के लिए, फ्रेमवर्क को इन नए जोड़े गए एपीआई के लिए सीपीयू पर वापस आना चाहिए और कहीं और जीपीयू (एचएएल 1.0) ड्राइवर का उपयोग करना जारी रखना चाहिए।

बिटकोड संकलन/लिंकिंग को प्रभावित करने वाले प्रमुख एचएएल परिवर्तनों (एचएएल 2.0) के लिए, आरएस फ्रेमवर्क को विक्रेता द्वारा प्रदत्त जीपीयू ड्राइवरों को लोड नहीं करने का विकल्प चुनना चाहिए और इसके बजाय त्वरण के लिए सीपीयू या वल्कन पथ का उपयोग करना चाहिए।

रेंडरस्क्रिप्ट बिटकोड का उपभोग तीन चरणों में होता है:

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

एचएएल के अलावा, रनटाइम एपीआई और निर्यात किए गए प्रतीक भी इंटरफेस हैं। एंड्रॉइड 7.0 (एपीआई 24) के बाद से कोई भी इंटरफ़ेस नहीं बदला है और एंड्रॉइड 8.0 और उसके बाद इसे बदलने की कोई तत्काल योजना नहीं है। हालाँकि, यदि इंटरफ़ेस बदलता है, तो HAL संस्करण भी बढ़ जाएगा।

विक्रेता कार्यान्वयन

Android 8.0 और उच्चतर संस्करण में GPU ड्राइवर को सही ढंग से काम करने के लिए कुछ GPU ड्राइवर परिवर्तनों की आवश्यकता होती है।

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

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

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

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

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

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

इसके अलावा, विक्रेताओं को निम्नलिखित परिवर्तन करने होंगे:

चित्र 8. विक्रेता ड्राइवर में परिवर्तन
  1. libclcore.bc को /vendor विभाजन में कॉपी करें। यह सुनिश्चित करता है कि libclcore.bc , libLLVM.so , और libbcc.so सिंक में हैं।
  2. आरएस एचएएल कार्यान्वयन से 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

विरासती उपकरण

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

  1. PRODUCT_SHIPPING_API_LEVEL 26 से कम है।
  2. PRODUCT_FULL_TREBLE_OVERRIDE परिभाषित नहीं है।

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

रेंडरस्क्रिप्ट बहिष्करण की प्रेरणा के बारे में जानकारी के लिए, एंड्रॉइड डेवलपर्स ब्लॉग देखें: एंड्रॉइड जीपीयू कंप्यूट गोइंग फॉरवर्ड । इस बहिष्करण के लिए संसाधन जानकारी में निम्नलिखित शामिल हैं: