RenderScript

RenderScript হল Android-এ হাই পারফর্ম্যান্সে কম্পিউটেশনাল ইনটেনসিভ টাস্ক রান করানোর একটি ফ্রেমওয়ার্ক। এটি ডেটা-প্যারালাল কম্পিউটেশনের সাথে ব্যবহার করার জন্য ডিজাইন করা হয়েছে, যদিও সিরিয়াল ওয়ার্কলোডও এর থেকে সুবিধা পেতে পারে। RenderScript রানটাইম ডিভাইসে উপলভ্য প্রসেসর জুড়ে কাজকে প্যারালাইজ করে, যেমন মাল্টি-কোর CPU এবং GPU, যা ডেভেলপারদের কাজ শিডিউল করার পরিবর্তে অ্যালগরিদম প্রকাশ করার উপর ফোকাস করতে সাহায্য করে। RenderScript বিশেষ করে সেইসব অ্যাপের জন্য উপযোগী যেগুলি ইমেজ প্রসেসিং, কম্পিউটেশনাল ফটোগ্রাফি বা কম্পিউটার ভিশন পারফর্ম করে।

Android 8.0 এবং তার পরবর্তী যেকোনও ভার্সনে চলা ডিভাইস নিম্নলিখিত RenderScript ফ্রেমওয়ার্ক এবং ভেন্ডর HAL ব্যবহার করে:

ছবি ১. ইন্টার্নাল লাইব্রেরির সাথে লিঙ্ক করা ভেন্ডর কোড।

Android 7.x ও এর আগের ভার্সনে RenderScript-এর সাথে পার্থক্য:

  • একটি প্রসেসে RenderScript ইন্টার্নাল লাইব্রেরির দুটি ইনস্ট্যান্স। একটি সেট হল সিপিইউ ফলব্যাক পাথের জন্য এবং এটি সরাসরি /system/lib থেকে নেওয়া হয়েছে; অন্য সেটটি হল জিপিইউ পাথের জন্য এবং এটি /system/lib/vndk-sp থেকে নেওয়া হয়েছে।
  • /system/lib-এ RS ইন্টার্নাল লাইব্রেরি প্ল্যাটফর্মের অংশ হিসেবে তৈরি করা হয় এবং system.img আপগ্রেড করার সময় আপডেট করা হয়। তবে, /system/lib/vndk-sp-এ libs ভেন্ডরের জন্য তৈরি করা হয় এবং system.img আপগ্রেড করা হলে আপডেট করা হয় না (যদিও নিরাপত্তা সংক্রান্ত সমস্যার সমাধানের জন্য সেগুলি আপডেট করা যেতে পারে, তবে তাদের ABI একই থাকে)।
  • ভেন্ডর কোড (RS HAL, RS ড্রাইভার এবং bcc plugin) /system/lib/vndk-sp-এ অবস্থিত RenderScript ইন্টার্নাল লাইব্রেরির সাথে লিঙ্ক করা আছে। সেগুলি /system/lib-এ থাকা লিবের সাথে লিঙ্ক করা যাবে না, কারণ ওই ডিরেক্টরিতে থাকা লিবগুলি প্ল্যাটফর্মের জন্য তৈরি করা হয়েছে এবং তাই সেগুলি ভেন্ডর কোডের সাথে মানানসই নাও হতে পারে (যেমন, সিম্বল সরিয়ে দেওয়া হতে পারে)। এটি করলে, ফ্রেমওয়ার্ক-অনলি OTA অসম্ভব হয়ে যাবে।

ডিজাইন

নিচের বিভাগে Android 8.0 ও তার পরবর্তী যেকোনও ভার্সনে RenderScript ডিজাইন সম্পর্কে বিস্তারিত তথ্য দেওয়া আছে।

ভেন্ডরদের জন্য উপলভ্য RenderScript লাইব্রেরি

এই বিভাগে RenderScript লাইব্রেরির (একই-প্রসেস HAL-এর জন্য ভেন্ডর NDK বা VNDK-SP নামে পরিচিত) তালিকা দেওয়া আছে যা ভেন্ডর কোডের জন্য উপলভ্য এবং যার সাথে লিঙ্ক করা যেতে পারে। এছাড়াও, এটি RenderScript-এর সাথে সম্পর্কিত নয় এমন অতিরিক্ত লাইব্রেরি সম্পর্কেও বিস্তারিত তথ্য দেয়, তবে সেগুলিও ভেন্ডর কোডে প্রদান করা হয়।

Android রিলিজের মধ্যে নিম্নলিখিত লাইব্রেরির তালিকা আলাদা হতে পারে, তবে নির্দিষ্ট Android রিলিজের জন্য এটি অপরিবর্তনীয়; উপলভ্য লাইব্রেরির আপ-টু-ডেট তালিকা পেতে, /system/etc/ld.config.txt দেখুন।

RenderScript Libs নন-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-তে নেই এমন লাইব্রেরি ভেন্ডর কোড ব্যবহার করতে পারে না। (বিস্তারিত জানতে, VNDK ডিজাইন প্রেজেন্টেশন দেখুন।)

Android 8.0 এবং তার পরবর্তী যেকোনও ভার্সন চলছে এমন ডিভাইসে, RenderScript ছাড়া সব সেম-প্রসেস HAL (SP-HAL) লিঙ্কার নেমস্পেস sphal-এর মধ্যে লোড করা হয়। RenderScript-নির্দিষ্ট নেমস্পেস rs-এ RenderScript লোড করা হয়, এটি এমন একটি লোকেশন যা RenderScript লাইব্রেরির জন্য কিছুটা কম কঠোর এনফোর্সমেন্ট চালু করে। কারণ RS ইমপ্লিমেন্টেশনের জন্য কম্পাইল করা বিটকোড লোড করতে হবে, /data/*/*.so rs নেমস্পেসের পাথে যোগ করা হয়েছে (অন্যান্য SP-HAL-কে ডেটা পার্টিশন থেকে লাইব্রেরি লোড করার অনুমতি দেওয়া হয় না)।

এছাড়াও, rs নেমস্পেস অন্যান্য নেমস্পেসের তুলনায় আরও বেশি লাইব্রেরি ব্যবহার করার অনুমতি দেয়। libmediandk.so এবং libft2.so rs নেমস্পেসে এক্সপোজ করা হয়েছে কারণ libRS_internal.so-এর এইসব লাইব্রেরির উপর ইন্টার্নাল ডিপেন্ডেন্সি আছে।

ছবি ২. লিঙ্কার জন্য নেমস্পেস কনফিগারেশন।

ড্রাইভার লোড করা

সিপিইউ ফলব্যাক পাথ

RS কনটেক্সট তৈরি করার সময় RS_CONTEXT_LOW_LATENCY বিটের উপস্থিতির উপর নির্ভর করে CPU বা GPU পাথ বেছে নেওয়া হয়। সিপিইউ পাথ বেছে নেওয়া হলে, libRS_internal.so (RS ফ্রেমওয়ার্কের প্রধান ইমপ্লিমেন্টেশন) সরাসরি ডিফল্ট লিঙ্কার নেমস্পেস থেকে dlopen করা হয় যেখানে RS লাইব্রেরির প্ল্যাটফর্ম ভার্সন প্রদান করা হয়।

CPU ফলব্যাক পাথ নেওয়া হলে, ভেন্ডরের RS HAL ইমপ্লিমেন্টেশন একেবারেই ব্যবহার করা হয় না এবং একটি RsContext অবজেক্ট নাল mVendorDriverName দিয়ে তৈরি করা হয়। libRSDriver.so (ডিফল্ট হিসেবে) dlopen করা হয়েছে এবং ড্রাইভার lib default নেমস্পেস থেকে লোড করা হয়েছে কারণ কলার (libRS_internal.so) default নেমস্পেসেও লোড করা হয়েছে।

ছবি ৩. CPU ফলব্যাক পাথ।

GPU পাথ

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 তারপরে dlopens libRS_internal.so অন্য একটি লিঙ্কার নেমস্পেসে থাকে যাকে rs বলা হয়।

RS ড্রাইভারের বিল্ড টাইম ফ্ল্যাগ OVERRIDE_RS_DRIVER সেট করে ভেন্ডররা নিজস্ব RS ড্রাইভার প্রদান করতে পারে, যা RS HAL ইমপ্লিমেন্টেশন (hardware/interfaces/renderscript/1.0/default/Context.cpp)-এ এম্বেড করা থাকে। এই ড্রাইভারের নাম তারপরে GPU পাথের জন্য RS কনটেক্সটে dlopen করা হয়।

RsContext অবজেক্ট তৈরি করার দায়িত্ব RS HAL ইমপ্লিমেন্টেশনের উপর ন্যস্ত করা হয়। HAL, RS ফ্রেমওয়ার্কে কল ব্যাক করে এবং rsContextCreateVendor() ফাংশন ব্যবহার করে। ড্রাইভারের নাম আর্গুমেন্ট হিসেবে ব্যবহার করা হয়। RsContext শুরু করার সময় RS ফ্রেমওয়ার্ক নির্দিষ্ট ড্রাইভার লোড করে। এই ক্ষেত্রে, ড্রাইভার লাইব্রেরিটি rs নেমস্পেসে লোড করা হয় কারণ RsContext অবজেক্টটি rs নেমস্পেসের মধ্যে তৈরি করা হয় এবং /vendor/lib নেমস্পেসের সার্চ পাথে থাকে।

ছবি ৪. GPU ফলব্যাক পাথ।

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

এই লাইনটি নির্দিষ্ট করে যে, sphal নেমস্পেস থেকে lib খুঁজে পাওয়া/লোড করা না গেলে (যা সবসময়ই হয় কারণ sphal নেমস্পেস /system/lib/vndk-sp-এ সার্চ করে না যেখানে libRS_internal.so থাকে), ডায়নামিক লিঙ্কারকে rs নেমস্পেস থেকে libRS_internal.so লোড করতে হবে। এই কনফিগারেশনের সাহায্যে, নেমস্পেস ট্রানজিশন করার জন্য dlopen()-এ libRS_internal.so-এ কল করলেই যথেষ্ট।

bcc প্লাগ-ইন লোড করা

bcc plugin হল ভেন্ডর-প্রদানিত লাইব্রেরি যা bcc কম্পাইলারে লোড করা হয়। bcc হল /system/bin ডিরেক্টরির একটি সিস্টেম প্রসেস, তাই bcc plugin লাইব্রেরিকে SP-HAL (অর্থাৎ, বাইন্ডারাইজ না করেই সরাসরি সিস্টেম প্রসেসে লোড করা যায় এমন ভেন্ডর HAL) হিসেবে বিবেচনা করা যেতে পারে। SP-HAL হিসেবে, bcc-plugin লাইব্রেরি:

  • শুধুমাত্র ফ্রেমওয়ার্ক লাইব্রেরির সাথে লিঙ্ক করা যাবে না, যেমন libLLVM.so।
  • ভেন্ডরের কাছে উপলভ্য VNDK-SP লাইব্রেরির সাথে লিঙ্ক করা যাবে।

android_sphal_load_library() ফাংশন ব্যবহার করে bcc plugin-কে sphal নেমস্পেসে লোড করার মাধ্যমে এই বিধিনিষেধ প্রয়োগ করা হয়। Android-এর আগের ভার্সনে, -load বিকল্প ব্যবহার করে প্লাগ-ইনের নাম নির্দিষ্ট করা হত এবং libLLVM.so-এর মাধ্যমে সাধারণ dlopen() ব্যবহার করে lib লোড করা হত। Android 8.0 ও তার পরবর্তী যেকোনও ভার্সনে, এটি -plugin বিকল্পে উল্লেখ করা থাকে এবং bcc নিজেই লাইব্রেরি সরাসরি লোড করে। এই বিকল্পটি ওপেন সোর্স LLVM প্রোজেক্টের জন্য Android-নির্দিষ্ট নয় এমন পাথ চালু করে।

ছবি ৫. bcc প্লাগ-ইন লোড হচ্ছে, Android 7.x ও তার আগের যেকোনও ভার্সন।



ছবি ৬. bcc প্লাগ-ইন লোড করা, Android 8.0 ও এর পরের যেকোনও ভার্সন।

ld.mc-এর জন্য সার্চ পাথ

ld.mc চালানোর সময়, কিছু RS রানটাইম লাইব্রেরি লিঙ্কারকে ইনপুট হিসেবে দেওয়া হয়। অ্যাপ থেকে RS বিটকোড রানটাইম লাইব্রেরির সাথে লিঙ্ক করা হয় এবং কনভার্ট করা বিটকোড অ্যাপ প্রসেসে লোড করা হলে, রানটাইম লাইব্রেরি আবার কনভার্ট করা বিটকোড থেকে ডায়নামিকালি লিঙ্ক করা হয়।

রানটাইম লাইব্রেরিতে এগুলি অন্তর্ভুক্ত:

  • 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 থেকে। এটি RS ফ্রেমওয়ার্ক লাইব্রেরির একটি অনির্দিষ্ট প্রতীকের ঠিকানা পড়ে এবং dladdr() ব্যবহার করে ঠিকানাটির সাথে ম্যাপ করা ফাইল পাথ পাওয়ার মাধ্যমে নির্ধারণ করা যেতে পারে।

SELinux নীতি

Android 8.0 ও তার পরবর্তী যেকোনও ভার্সনে SELinux নীতিতে পরিবর্তনের ফলে, আপনাকে অবশ্যই vendor পার্টিশনে অতিরিক্ত ফাইল লেবেল করার সময় নির্দিষ্ট নিয়ম (neverallows-এর মাধ্যমে এনফোর্স করা) মেনে চলতে হবে:

  • vendor_file লেবেলটি vendor পার্টিশনের সব ফাইলের ডিফল্ট লেবেল হতে হবে। পাসথ্রু HAL ইমপ্লিমেন্টেশন অ্যাক্সেস করার জন্য প্ল্যাটফর্ম নীতি অনুযায়ী এটি প্রয়োজন।
  • ভেন্ডর SEPolicy-এর মাধ্যমে vendor পার্টিশনে যোগ করা সব নতুন exec_types-এ vendor_file_type অ্যাট্রিবিউট থাকতে হবে। neverallows-এর মাধ্যমে এটি প্রয়োগ করা হয়।
  • ভবিষ্যতে প্ল্যাটফর্ম/ফ্রেমওয়ার্ক আপডেটের সাথে কোনও সমস্যা এড়াতে, vendor পার্টিশনে exec_types ছাড়া অন্য কোনও ফাইলকে লেবেল দেবেন না।
  • AOSP-শনাক্ত করা একই প্রসেস HAL-এর জন্য সব লাইব্রেরি ডিপেন্ডেন্সি অবশ্যই same_process_hal_file হিসেবে লেবেল করা থাকতে হবে।

SELinux নীতি সম্পর্কে আরও জানতে, দেখুন Android-এ নিরাপত্তা-বর্ধিত Linux.

বিটকোডের জন্য ABI কম্প্যাটিবিলিটি

কোনও নতুন API যোগ করা না হলে, যার অর্থ কোনও HAL ভার্সন বাম্প নেই, RS ফ্রেমওয়ার্ক আগে থেকেই থাকা GPU (HAL 1.0) ড্রাইভার ব্যবহার করা চালিয়ে যাবে।

বিটকোডকে প্রভাবিত করে না এমন মাইনর HAL পরিবর্তনের (HAL 1.1) ক্ষেত্রে, ফ্রেমওয়ার্ককে এইসব নতুন যোগ করা API-এর জন্য CPU-তে ফলব্যাক করতে হবে এবং অন্য কোথাও GPU (HAL 1.0) ড্রাইভার ব্যবহার করা চালিয়ে যেতে হবে। অন্যথায়,

বিটকোড কম্পাইলেশন/লিঙ্কিংকে প্রভাবিত করে এমন বড় HAL পরিবর্তন (HAL 2.0)-এর জন্য, RS ফ্রেমওয়ার্ককে ভেন্ডর-প্রদানকৃত GPU ড্রাইভার লোড না করার বিকল্প বেছে নিতে হবে এবং পরিবর্তে অ্যাক্সিলারেশনের জন্য CPU বা Vulkan পাথ ব্যবহার করতে হবে।

RenderScript বিটকোড ব্যবহার করার প্রক্রিয়া তিনটি ধাপে সম্পন্ন হয়:

স্টেজ বিবরণ
কম্পাইল করা
  • bcc-এর জন্য ইনপুট বিটকোড (.bc) অবশ্যই LLVM 3.2 বিটকোড ফর্ম্যাটে হতে হবে এবং bcc অবশ্যই বিদ্যমান (লিগ্যাসি) অ্যাপের সাথে ব্যাকওয়ার্ড কম্প্যাটিবল হতে হবে।
  • তবে, .bc-এর মেটা-ডেটা পরিবর্তন হতে পারে (নতুন রানটাইম ফাংশন থাকতে পারে, যেমন, অ্যালোকেশন সেটার ও গেটার, গাণিতিক ফাংশন ইত্যাদি)। পার্ট অফ রানটাইম ফাংশন libclcore.bc-এ থাকে, পার্ট অফ দেম LibRSDriver বা ভেন্ডর ইকুইভ্যালেন্টে থাকে।
  • নতুন রানটাইম ফাংশন বা মেটা-ডেটা পরিবর্তন করার জন্য বিটকোড API লেভেল বাড়াতে হয়। যেহেতু ভেন্ডর ড্রাইভার এটি ব্যবহার করতে পারবে না, তাই HAL ভার্সনও অবশ্যই বাড়াতে হবে।
  • ভেন্ডরদের নিজস্ব কম্পাইলার থাকতে পারে, তবে bcc-এর জন্য সিদ্ধান্ত/প্রয়োজনীয়তা সেই কম্পাইলারের ক্ষেত্রেও প্রযোজ্য।
লিঙ্ক
  • কম্পাইল করা .o ভেন্ডর ড্রাইভারের সাথে লিঙ্ক করা হবে, যেমন, libRSDriver_foo.so এবং libcompiler_rt.so। CPU পাথ libRSDriver.so-এর সাথে লিঙ্ক করা হবে।
  • .o-এর libRSDriver_foo থেকে নতুন রানটাইম API প্রয়োজন হলে, ভেন্ডর ড্রাইভারকে সেটি যাতে কাজ করে সেই জন্য আপডেট করতে হবে।
  • নির্দিষ্ট কিছু ভেন্ডরের নিজস্ব লিঙ্কার থাকতে পারে, কিন্তু ld.mc-এর যুক্তি তাদের ক্ষেত্রেও প্রযোজ্য।
লোড করুন
  • libRSCpuRef শেয়ার করা অবজেক্ট লোড করে। এই ইন্টারফেসে পরিবর্তন করা হলে, HAL ভার্সন বাম্প করতে হবে।
  • শেয়ার করা অবজেক্ট লোড করার জন্য ভেন্ডররা libRSCpuRef-এর উপর নির্ভর করবে অথবা নিজস্ব অবজেক্ট প্রয়োগ করবে।

HAL ছাড়াও, রানটাইম API এবং এক্সপোর্ট করা সিম্বলও ইন্টারফেস। Android 7.0 (API 24) থেকে কোনও ইন্টারফেসই পরিবর্তন করা হয়নি এবং Android 8.0 ও তার পরবর্তী ভার্সনে এটি পরিবর্তন করার কোনও তাৎক্ষণিক পরিকল্পনা নেই। তবে, ইন্টারফেস পরিবর্তন হলে, HAL ভার্সনও বাড়বে।

ভেন্ডর প্রয়োগ

Android 8.0 ও তার পরবর্তী যেকোনও ভার্সনে GPU ড্রাইভার সঠিকভাবে কাজ করার জন্য কিছু GPU ড্রাইভার পরিবর্তন করতে হয়।

ড্রাইভার মডিউল

  • ড্রাইভার মডিউলকে এমন কোনও সিস্টেম লাইব্রেরির উপর নির্ভর করলে চলবে না যা তালিকায় নেই।
  • ড্রাইভারকে নিজের android.hardware.renderscript@1.0-impl_{NAME} প্রদান করতে হবে অথবা ডিফল্ট ইমপ্লিমেন্টেশনকে android.hardware.renderscript@1.0-impl নিজের ডিপেন্ডেন্সি হিসেবে ঘোষণা করতে হবে।
  • CPU প্রয়োগ libRSDriver.so হল কীভাবে নন-VNDK-SP ডিপেন্ডেন্সি সরানো যায় তার একটি ভালো উদাহরণ।

বিটকোড কম্পাইলার

আপনি দুটি উপায়ে ভেন্ডর ড্রাইভারের জন্য RenderScript বিটকোড কম্পাইল করতে পারবেন:

  1. /vendor/bin/ -এ ভেন্ডর-নির্দিষ্ট RenderScript কম্পাইলার ইনভোক করুন (GPU কম্পাইলেশনের পছন্দের পদ্ধতি)। অন্যান্য ড্রাইভার মডিউলের মতো, ভেন্ডর কম্পাইলার বাইনারি ভেন্ডরদের জন্য উপলভ্য RenderScript লাইব্রেরির তালিকায় নেই এমন কোনও সিস্টেম লাইব্রেরির উপর নির্ভর করতে পারে না।
  2. সিস্টেম bcc: /system/bin/bcc ভেন্ডর-প্রদত্ত bcc plugin ব্যবহার করে ইনভোক করুন; এই প্লাগ-ইন কোনও সিস্টেম লাইব্রেরির উপর নির্ভর করতে পারে না যা ভেন্ডরদের জন্য উপলভ্য RenderScript লাইব্রেরির তালিকায় নেই।

ভেন্ডরকে যদি bcc plugin CPU-এর সাথে ইন্টারফেয়ার করতে হয় এবং libLLVM.so-এর উপর এর নির্ভরতা সহজে সরানো না যায়, তাহলে ভেন্ডরকে bcc (এবং libLLVM.so, libbcc.so সহ LL-NDK নয় এমন সব নির্ভরতা) /vendor পার্টিশনে কপি করতে হবে।

এছাড়াও, ভেন্ডরদের নিম্নলিখিত পরিবর্তন করতে হবে:

ছবি ৭. ভেন্ডর ড্রাইভারের ক্ষেত্রে পরিবর্তন।

  1. /vendor পার্টিশনে libclcore.bc কপি করুন। এটি libclcore.bc, libLLVM.so এবং libbcc.so সিঙ্ক করা আছে তা নিশ্চিত করে।
  2. 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

কম্পাইলার এক্সিকিউটেবলকে অবশ্যই কোনও অ্যাপ প্রসেস দ্বারা ইনভোক করা যেতে হবে, যেমন 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-এর লেভেল ২৬-এর থেকে কম।
  2. PRODUCT_FULL_TREBLE_OVERRIDE নির্দিষ্ট করা নেই।

পুরনো ডিভাইসের ক্ষেত্রে, Android 8.0 এবং তার পরবর্তী ভার্সনে আপগ্রেড করার সময় বিধিনিষেধ এনফোর্স করা হয় না, যার অর্থ হল ড্রাইভাররা /system/lib[64]-এ লাইব্রেরির সাথে লিঙ্ক করা চালিয়ে যেতে পারে। তবে, OVERRIDE_RS_DRIVER সংক্রান্ত আর্কিটেকচারে পরিবর্তনের কারণে, /vendor পার্টিশনে android.hardware.renderscript@1.0-impl ইনস্টল করতে হবে; তা না করলে, RenderScript রানটাইম CPU পাথে ফলব্যাক করতে বাধ্য হবে।

Renderscript বন্ধ করার কারণ সম্পর্কে জানতে, Android Developers ব্লগ দেখুন: Android GPU Compute Going Forward। এই বন্ধ হয়ে যাওয়া সংক্রান্ত রিসোর্স তথ্যের মধ্যে নিম্নলিখিত বিষয়গুলি অন্তর্ভুক্ত: