কনটেক্সট হাব রানটাইম এনভায়রনমেন্ট (CHRE)

স্মার্টফোনে একাধিক প্রসেসর থাকে, যার প্রতিটি ভিন্ন ভিন্ন কাজ সম্পাদনের জন্য বিশেষভাবে তৈরি। তবে, অ্যান্ড্রয়েড শুধুমাত্র একটি প্রসেসরে চলে: অ্যাপ্লিকেশন প্রসেসর (AP)। AP-কে গেমিং-এর মতো স্ক্রিন চালু থাকা অবস্থায় ব্যবহারের জন্য দুর্দান্ত পারফরম্যান্স দেওয়ার উপযোগী করে তৈরি করা হয়েছে, কিন্তু এটি এতটাই শক্তি-ক্ষয়কারী যে, স্ক্রিন বন্ধ থাকা অবস্থাতেও এমন ফিচারগুলোকে সমর্থন করতে পারে না যেগুলোর জন্য সারাক্ষণ ঘন ঘন ও অল্প সময়ের জন্য প্রসেসিংয়ের প্রয়োজন হয়। ছোট প্রসেসরগুলো এই ধরনের কাজ আরও দক্ষতার সাথে সামলাতে পারে এবং ব্যাটারির আয়ুতে উল্লেখযোগ্য প্রভাব না ফেলেই তাদের কাজ সম্পন্ন করে। তবে, এই কম-শক্তিসম্পন্ন প্রসেসরগুলোর সফটওয়্যার পরিবেশ আরও সীমিত এবং এতে ব্যাপক ভিন্নতা থাকতে পারে, যা ক্রস-প্ল্যাটফর্ম ডেভেলপমেন্টকে কঠিন করে তোলে।

কন্টেক্সট হাব রানটাইম এনভায়রনমেন্ট (CHRE) একটি সহজ, মানসম্মত এবং এমবেডেড-বান্ধব এপিআই (API) সহ কম শক্তি-ব্যয়ী প্রসেসরে অ্যাপ চালানোর জন্য একটি সাধারণ প্ল্যাটফর্ম প্রদান করে। CHRE ডিভাইস প্রস্তুতকারক (OEM) এবং তাদের বিশ্বস্ত অংশীদারদের জন্য অ্যাক্সেস পয়েন্ট (AP) থেকে প্রসেসিংয়ের ভার সরিয়ে নেওয়া সহজ করে তোলে, যার ফলে ব্যাটারি সাশ্রয় হয়, ব্যবহারকারীর অভিজ্ঞতার বিভিন্ন দিক উন্নত হয় এবং এটি এক ধরনের সর্বদা-সক্রিয় ও প্রাসঙ্গিকভাবে সচেতন ফিচারগুলো সক্ষম করে, বিশেষ করে যেগুলো অ্যাম্বিয়েন্ট সেন্সিং-এ মেশিন লার্নিংয়ের প্রয়োগের সাথে জড়িত।

মূল ধারণা

CHRE হলো এমন একটি সফটওয়্যার পরিবেশ যেখানে ন্যানোঅ্যাপস নামক ছোট নেটিভ অ্যাপগুলো একটি কম-শক্তিসম্পন্ন প্রসেসরে চলে এবং সাধারণ CHRE API-এর মাধ্যমে অন্তর্নিহিত সিস্টেমের সাথে যোগাযোগ করে। CHRE API-গুলোর সঠিক বাস্তবায়নকে ত্বরান্বিত করার জন্য, AOSP-তে CHRE-এর একটি ক্রস-প্ল্যাটফর্ম রেফারেন্স ইমপ্লিমেন্টেশন অন্তর্ভুক্ত করা হয়েছে। এই রেফারেন্স ইমপ্লিমেন্টেশনে একাধিক প্ল্যাটফর্ম অ্যাবস্ট্রাকশন লেয়ার (PALs)-এর মাধ্যমে অন্তর্নিহিত হার্ডওয়্যার এবং সফটওয়্যারের জন্য সাধারণ কোড ও অ্যাবস্ট্রাকশন অন্তর্ভুক্ত থাকে। ন্যানোঅ্যাপগুলো প্রায় সবসময়ই অ্যান্ড্রয়েডে চলমান এক বা একাধিক ক্লায়েন্ট অ্যাপের সাথে যুক্ত থাকে, যেগুলো সীমিত-অ্যাক্সেস ContextHubManager সিস্টেম API-এর মাধ্যমে CHRE এবং ন্যানোঅ্যাপগুলোর সাথে যোগাযোগ করে।

মোটামুটিভাবে, CHRE-এর স্থাপত্য এবং সামগ্রিকভাবে অ্যান্ড্রয়েডের মধ্যে সাদৃশ্য টানা যেতে পারে। তবে, কয়েকটি গুরুত্বপূর্ণ পার্থক্য রয়েছে:

• CHRE শুধুমাত্র নেটিভ কোডে (C বা C++) তৈরি ন্যানোঅ্যাপ চালাতে সমর্থন করে; জাভা সমর্থিত নয়।
• সম্পদের সীমাবদ্ধতা এবং নিরাপত্তা বিধিনিষেধের কারণে, CHRE যথেচ্ছ তৃতীয় পক্ষের অ্যান্ড্রয়েড অ্যাপের ব্যবহারের জন্য উন্মুক্ত নয়। শুধুমাত্র সিস্টেম-বিশ্বস্ত অ্যাপগুলোই এটি অ্যাক্সেস করতে পারে।

CHRE এবং সেন্সর হাবের ধারণার মধ্যে একটি গুরুত্বপূর্ণ পার্থক্য রয়েছে। যদিও সেন্সর হাব এবং CHRE বাস্তবায়নের জন্য একই হার্ডওয়্যার ব্যবহার করা সাধারণ, CHRE নিজে অ্যান্ড্রয়েড সেন্সরস HAL- এর জন্য প্রয়োজনীয় সেন্সর সক্ষমতা প্রদান করে না। CHRE, কনটেক্সট হাব HAL-এর সাথে সংযুক্ত থাকে এবং এটি AP-কে জড়িত না করে সেন্সর ডেটা গ্রহণ করার জন্য একটি ডিভাইস-নির্দিষ্ট সেন্সর ফ্রেমওয়ার্কের ক্লায়েন্ট হিসেবে কাজ করে।

চিত্র ১. CHRE ফ্রেমওয়ার্ক স্থাপত্য

কন্টেক্সট হাব এইচএএল

কন্টেক্সট হাব হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) হলো অ্যান্ড্রয়েড ফ্রেমওয়ার্ক এবং ডিভাইসের CHRE ইমপ্লিমেন্টেশনের মধ্যকার ইন্টারফেস, যা hardware/interfaces/contexthub এ সংজ্ঞায়িত। কন্টেক্সট হাব HAL সেইসব API সংজ্ঞায়িত করে, যার মাধ্যমে অ্যান্ড্রয়েড ফ্রেমওয়ার্ক উপলব্ধ কন্টেক্সট হাব এবং তাদের ন্যানোঅ্যাপগুলো খুঁজে বের করে, মেসেজ পাসিংয়ের মাধ্যমে সেই ন্যানোঅ্যাপগুলোর সাথে যোগাযোগ স্থাপন করে এবং ন্যানোঅ্যাপ লোড ও আনলোড করার সুযোগ দেয়। কন্টেক্সট হাব HAL-এর একটি রেফারেন্স ইমপ্লিমেন্টেশন, যা CHRE-এর রেফারেন্স ইমপ্লিমেন্টেশনের সাথে কাজ করে system/chre/host এ উপলব্ধ।

এই ডকুমেন্টেশন এবং HAL সংজ্ঞার মধ্যে কোনো বিরোধ দেখা দিলে, HAL সংজ্ঞাটিই প্রাধান্য পাবে।

প্রারম্ভিকীকরণ

অ্যান্ড্রয়েড বুট আপ হওয়ার সময়, ডিভাইসে কোনো কনটেক্সট হাব উপলব্ধ আছে কিনা তা নির্ধারণ করতে ContextHubService, getHubs() HAL ফাংশনটিকে কল করে। এটি একটি ব্লকিং ও এককালীন কল, তাই বুট বিলম্ব এড়াতে এটিকে দ্রুত সম্পন্ন হতে হবে এবং একটি সঠিক ফলাফল প্রদান করতে হবে, কারণ এর পরে নতুন কনটেক্সট হাব যুক্ত করা যায় না।

ন্যানোঅ্যাপ লোড এবং আনলোড করুন

একটি কনটেক্সট হাবে একগুচ্ছ ন্যানোঅ্যাপ অন্তর্ভুক্ত থাকতে পারে, যেগুলো ডিভাইস ইমেজে অন্তর্ভুক্ত থাকে এবং CHRE চালু হওয়ার সময় লোড হয়। এগুলো প্রি-লোডেড ন্যানোঅ্যাপ নামে পরিচিত, এবং queryApps() -এর প্রথম সম্ভাব্য রেসপন্সেই এগুলো অন্তর্ভুক্ত থাকা উচিত।

Context Hub HAL, loadNanoApp() এবং unloadNanoApp() ফাংশনগুলোর মাধ্যমে রানটাইমে ডাইনামিকভাবে ন্যানোঅ্যাপ লোড ও আনলোড করাও সমর্থন করে। ডিভাইসটির CHRE হার্ডওয়্যার এবং সফটওয়্যার ইমপ্লিমেন্টেশনের জন্য নির্দিষ্ট একটি বাইনারি ফরম্যাটে ন্যানোঅ্যাপগুলো HAL-কে সরবরাহ করা হয়।

যদি কোনো ন্যানোঅ্যাপ লোড করার বাস্তবায়নে সেটিকে নন-ভোলাটাইল মেমরিতে (যেমন CHRE চালনাকারী প্রসেসরের সাথে সংযুক্ত ফ্ল্যাশ স্টোরেজ) লেখার প্রয়োজন হয়, তাহলে CHRE বাস্তবায়নটিকে অবশ্যই এই ডাইনামিক ন্যানোঅ্যাপগুলোকে ডিজেবলড অবস্থায় রেখে বুট আপ করতে হবে। এর অর্থ হলো, HAL-এর মাধ্যমে একটি enableNanoapp() অনুরোধ না পাওয়া পর্যন্ত ন্যানোঅ্যাপটির কোনো কোডই এক্সিকিউট হয় না। প্রি-লোডেড ন্যানোঅ্যাপগুলো এনাবল্ড অবস্থায় ইনিশিয়ালাইজ হতে পারে।

কন্টেক্সট হাব পুনরায় চালু হয়

যদিও স্বাভাবিক কার্যক্রম চলাকালীন CHRE রিস্টার্ট হওয়ার কথা নয়, তবে অপ্রত্যাশিত পরিস্থিতি, যেমন একটি আনম্যাপড মেমরি অ্যাড্রেস অ্যাক্সেস করার চেষ্টার মতো অবস্থা থেকে পুনরুদ্ধারের জন্য এটি প্রয়োজনীয় হতে পারে। এই পরিস্থিতিতে, CHRE অ্যান্ড্রয়েড থেকে স্বাধীনভাবে রিস্টার্ট হয়। HAL, RESTARTED ইভেন্টের মাধ্যমে অ্যান্ড্রয়েডকে এই বিষয়ে অবহিত করে, যা তাকে অবশ্যই তখনই পাঠাতে হবে যখন CHRE পুনরায় এমন পর্যায়ে ইনিশিয়ালাইজড হয় যে এটি queryApps() এর মতো নতুন অনুরোধ গ্রহণ করতে পারে।

CHRE সিস্টেমের সংক্ষিপ্ত বিবরণ

CHRE একটি ইভেন্ট-চালিত আর্কিটেকচারের উপর ভিত্তি করে ডিজাইন করা হয়েছে, যেখানে গণনার প্রাথমিক একক হলো একটি ইভেন্ট যা একটি ন্যানোঅ্যাপের ইভেন্ট হ্যান্ডলিং এন্ট্রি পয়েন্টে পাঠানো হয়। যদিও CHRE ফ্রেমওয়ার্কটি মাল্টিথ্রেডেড হতে পারে, একটি নির্দিষ্ট ন্যানোঅ্যাপ কখনোই সমান্তরালভাবে একাধিক থ্রেড থেকে এক্সিকিউট করা হয় না। CHRE ফ্রেমওয়ার্কটি তিনটি ন্যানোঅ্যাপ এন্ট্রি পয়েন্টের ( nanoappStart() , nanoappHandleEvent() , এবং nanoappEnd() ) যেকোনো একটির মাধ্যমে অথবা পূর্ববর্তী CHRE API কলে প্রদত্ত একটি কলব্যাকের মাধ্যমে একটি নির্দিষ্ট ন্যানোঅ্যাপের সাথে ইন্টারঅ্যাক্ট করে, এবং ন্যানোঅ্যাপগুলো CHRE API-এর মাধ্যমে CHRE ফ্রেমওয়ার্ক এবং অন্তর্নিহিত সিস্টেমের সাথে ইন্টারঅ্যাক্ট করে। CHRE API কিছু মৌলিক সক্ষমতার পাশাপাশি সেন্সর, GNSS, Wi-Fi, WWAN, এবং অডিও সহ প্রাসঙ্গিক সিগন্যাল অ্যাক্সেস করার সুবিধা প্রদান করে, এবং এটি বিক্রেতা-নির্দিষ্ট ন্যানোঅ্যাপগুলোর ব্যবহারের জন্য অতিরিক্ত বিক্রেতা-নির্দিষ্ট সক্ষমতা দিয়ে সম্প্রসারিত করা যেতে পারে।

বিল্ড সিস্টেম

যদিও কনটেক্সট হাব এইচএএল এবং অন্যান্য প্রয়োজনীয় এপি-সাইড কম্পোনেন্টগুলো অ্যান্ড্রয়েডের পাশাপাশি বিল্ড করা হয়, CHRE-এর মধ্যে চালিত কোডের এমন কিছু প্রয়োজনীয়তা থাকতে পারে যা এটিকে অ্যান্ড্রয়েড বিল্ড সিস্টেমের সাথে বেমানান করে তোলে, যেমন একটি বিশেষায়িত টুলচেইনের প্রয়োজন। তাই, AOSP-তে থাকা CHRE প্রজেক্টটি ন্যানোঅ্যাপ কম্পাইল করার জন্য GNU Make-এর উপর ভিত্তি করে একটি সরলীকৃত বিল্ড সিস্টেম প্রদান করে এবং ঐচ্ছিকভাবে, CHRE ফ্রেমওয়ার্ককে লাইব্রেরিতে রূপান্তর করে যা সিস্টেমের সাথে ইন্টিগ্রেট করা যায়। যেসব ডিভাইস নির্মাতা CHRE-এর জন্য সাপোর্ট যোগ করতে চান, তাদের উচিত নিজেদের টার্গেট ডিভাইসের জন্য বিল্ড সিস্টেম সাপোর্ট AOSP-এর মধ্যে ইন্টিগ্রেট করা।

CHRE API-টি C99 ল্যাঙ্গুয়েজ স্ট্যান্ডার্ড অনুযায়ী লেখা হয়েছে, এবং এর রেফারেন্স ইমপ্লিমেন্টেশনে C++11-এর একটি সীমাবদ্ধ সাবসেট ব্যবহার করা হয়েছে যা সীমিত রিসোর্সের অ্যাপের জন্য উপযুক্ত।

CHRE API

CHRE API হলো C হেডার ফাইলগুলির একটি সংগ্রহ যা একটি ন্যানোঅ্যাপ এবং সিস্টেমের মধ্যে সফটওয়্যার ইন্টারফেস নির্ধারণ করে। এটি এমনভাবে ডিজাইন করা হয়েছে যাতে ন্যানোঅ্যাপের কোড CHRE সমর্থনকারী সমস্ত ডিভাইসে সামঞ্জস্যপূর্ণ থাকে। এর মানে হলো, একটি নতুন ধরনের ডিভাইস সমর্থন করার জন্য ন্যানোঅ্যাপের সোর্স কোড পরিবর্তন করার প্রয়োজন হয় না, যদিও টার্গেট ডিভাইসের প্রসেসর ইন্সট্রাকশন সেট বা অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABI)-এর জন্য এটিকে বিশেষভাবে রিকম্পাইল করার প্রয়োজন হতে পারে। CHRE আর্কিটেকচার এবং API ডিজাইন এটাও নিশ্চিত করে যে ন্যানোঅ্যাপগুলো CHRE API-এর বিভিন্ন সংস্করণের মধ্যে বাইনারিভাবে সামঞ্জস্যপূর্ণ থাকে। এর মানে হলো, ন্যানোঅ্যাপটি যে টার্গেট API-এর জন্য কম্পাইল করা হয়েছে, তার থেকে ভিন্ন কোনো CHRE API সংস্করণ ব্যবহারকারী সিস্টেমে চালানোর জন্য ন্যানোঅ্যাপটিকে রিকম্পাইল করার প্রয়োজন হয় না। অন্য কথায়, যদি একটি ন্যানোঅ্যাপ বাইনারি CHRE API v1.3 সমর্থনকারী কোনো ডিভাইসে চলে এবং সেই ডিভাইসটিকে CHRE API v1.4 সমর্থন করার জন্য আপগ্রেড করা হয়, তাহলেও একই ন্যানোঅ্যাপ বাইনারিটি কাজ করতে থাকবে। একইভাবে, ন্যানোঅ্যাপটি CHRE API v1.2-এ চলতে পারে এবং রানটাইমে নির্ধারণ করতে পারে যে এর ব্যবহারের জন্য API v1.3-এর সক্ষমতা প্রয়োজন, নাকি এটি সম্ভাব্য মার্জিত বৈশিষ্ট্য অবনমনের সাথে কাজ করতে পারবে।

CHRE API-এর নতুন সংস্করণগুলো অ্যান্ড্রয়েডের পাশাপাশিই প্রকাশ করা হয়, তবে যেহেতু CHRE বাস্তবায়নটি বিক্রেতার বাস্তবায়নেরই একটি অংশ, তাই কোনো ডিভাইসে সমর্থিত CHRE API সংস্করণটি আবশ্যিকভাবে অ্যান্ড্রয়েড সংস্করণের সাথে সংযুক্ত থাকে না।

সংস্করণ সারাংশ

অ্যান্ড্রয়েড HIDL ভার্সনিং স্কিমের মতো, CHRE API-ও সিম্যান্টিক ভার্সনিং অনুসরণ করে। মেজর ভার্সন বাইনারি সামঞ্জস্যতা নির্দেশ করে, অন্যদিকে যখন ব্যাকওয়ার্ড-কম্প্যাটিবল ফিচার যুক্ত করা হয়, তখন মাইনর ভার্সন বাড়ানো হয়। CHRE API-তে সোর্স কোড অ্যানোটেশন অন্তর্ভুক্ত রয়েছে, যা দিয়ে শনাক্ত করা যায় কোন ভার্সনে কোনো ফাংশন বা প্যারামিটার চালু করা হয়েছে; উদাহরণস্বরূপ @since v1.1 ।

CHRE ইমপ্লিমেন্টেশনটি chreGetVersion() এর মাধ্যমে একটি প্ল্যাটফর্ম-নির্দিষ্ট প্যাচ ভার্সনও প্রকাশ করে, যা নির্দেশ করে কখন ইমপ্লিমেন্টেশনটিতে বাগ ফিক্স বা ছোটখাটো আপডেট করা হয়।

প্রতিটি সংস্করণের সারসংক্ষেপের জন্য version.h দেখুন।

বাধ্যতামূলক সিস্টেম বৈশিষ্ট্য

যদিও সেন্সরের মতো প্রাসঙ্গিক সংকেতের উৎসগুলোকে ঐচ্ছিক বৈশিষ্ট্য ক্ষেত্রে শ্রেণীবদ্ধ করা হয়েছে, সমস্ত CHRE বাস্তবায়নে কয়েকটি মূল ফাংশন আবশ্যক। এর মধ্যে রয়েছে মূল সিস্টেম এপিআই, যেমন টাইমার সেট করা, অ্যাপ্লিকেশন প্রসেসরের ক্লায়েন্টদের কাছে বার্তা পাঠানো ও গ্রহণ করা, লগিং এবং অন্যান্য। সম্পূর্ণ বিবরণের জন্য, এপিআই হেডারগুলো দেখুন।

CHRE API-তে বিধিবদ্ধ মূল সিস্টেম বৈশিষ্ট্যগুলো ছাড়াও, Context Hub HAL স্তরে কিছু বাধ্যতামূলক CHRE সিস্টেম-স্তরের বৈশিষ্ট্যও নির্দিষ্ট করা আছে। এগুলোর মধ্যে সবচেয়ে গুরুত্বপূর্ণ হলো ন্যানোঅ্যাপগুলোকে গতিশীলভাবে লোড এবং আনলোড করার ক্ষমতা।

C/C++ স্ট্যান্ডার্ড লাইব্রেরি

মেমরি ব্যবহার এবং সিস্টেমের জটিলতা কমাতে, CHRE ইমপ্লিমেন্টেশনগুলোকে শুধুমাত্র স্ট্যান্ডার্ড C এবং C++ লাইব্রেরি ও রানটাইম সাপোর্টের প্রয়োজন এমন ল্যাঙ্গুয়েজ ফিচারগুলোর একটি উপসেট সমর্থন করতে হয়। এই নীতিগুলো অনুসরণ করে, কিছু ফিচার তাদের মেমরি এবং ব্যাপক OS-স্তরের নির্ভরতার কারণে স্পষ্টভাবে বাদ দেওয়া হয়, এবং অন্যগুলো বাদ দেওয়া হয় কারণ সেগুলোকে আরও উপযুক্ত CHRE-নির্দিষ্ট API দ্বারা প্রতিস্থাপন করা হয়। যদিও এটি একটি সম্পূর্ণ তালিকা নয়, নিম্নলিখিত সক্ষমতাগুলো ন্যানোঅ্যাপের জন্য উপলব্ধ করার উদ্দেশ্যে তৈরি করা হয়নি:

• C++ ব্যতিক্রম এবং রানটাইম টাইপ তথ্য (RTTI)
• স্ট্যান্ডার্ড লাইব্রেরির মাল্টিথ্রেডিং সমর্থন, যার মধ্যে C++11 হেডার <thread> , <mutex> , <atomic> , <future> অন্তর্ভুক্ত।
• C এবং C++ স্ট্যান্ডার্ড ইনপুট/আউটপুট লাইব্রেরি
• সি++ স্ট্যান্ডার্ড টেমপ্লেট লাইব্রেরি (এসটিএল)
• C++ স্ট্যান্ডার্ড রেগুলার এক্সপ্রেশন লাইব্রেরি
• স্ট্যান্ডার্ড ফাংশন (যেমন, malloc , calloc , realloc , free , operator new ) এবং std::unique_ptr মতো অন্যান্য স্ট্যান্ডার্ড লাইব্রেরি ফাংশন, যেগুলো স্বাভাবিকভাবেই ডাইনামিক অ্যালোকেশন ব্যবহার করে, সেগুলোর মাধ্যমে ডাইনামিক মেমরি অ্যালোকেশন।
• স্থানীয়করণ এবং ইউনিকোড অক্ষর সমর্থন
• তারিখ এবং সময় লাইব্রেরি
• যেসব ফাংশন প্রোগ্রামের স্বাভাবিক প্রবাহ পরিবর্তন করে, সেগুলোর মধ্যে রয়েছে <setjmp.h> , <signal.h> , abort , std::terminate
• হোস্ট এনভায়রনমেন্ট অ্যাক্সেস করা, যার মধ্যে system , getenv অন্তর্ভুক্ত।
• POSIX এবং অন্যান্য লাইব্রেরি যা C99 বা C++11 ভাষার স্ট্যান্ডার্ডে অন্তর্ভুক্ত নয়

অনেক ক্ষেত্রে, CHRE API ফাংশন এবং ইউটিলিটি লাইব্রেরি থেকে সমতুল্য ক্ষমতা পাওয়া যায়। উদাহরণস্বরূপ, অ্যান্ড্রয়েড লগক্যাট সিস্টেমকে লক্ষ্য করে ডিবাগ লগিংয়ের জন্য chreLog ব্যবহার করা যেতে পারে, যেখানে একটি প্রচলিত প্রোগ্রাম printf বা std::cout ব্যবহার করতে পারে।

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

• স্ট্রিং এবং অ্যারে ইউটিলিটি: memcmp , memcpy , memmove , memset , strlen

• গণিত লাইব্রেরি: সচরাচর ব্যবহৃত একক-প্রিসিশন ফ্লোটিং-পয়েন্ট ফাংশনসমূহ:

  • মৌলিক অপারেশনসমূহ: ceilf , fabsf , floorf , fmaxf , fminf , fmodf , roundf , lroundf , remainderf
  • সূচকীয় এবং ঘাত ফাংশন: expf , log2f , powf , sqrtf
  • ত্রিকোণমিতিক ও অধিবৃত্তীয় ফাংশন: sinf , cosf , tanf , asinf , acosf , atan2f , tanhf

যদিও কিছু অন্তর্নিহিত প্ল্যাটফর্ম অতিরিক্ত সক্ষমতা সমর্থন করে, একটি ন্যানোঅ্যাপকে CHRE ইমপ্লিমেন্টেশন জুড়ে পোর্টেবল বলে গণ্য করা হয় না, যদি না এটি তার বাহ্যিক নির্ভরতাগুলোকে CHRE API ফাংশন এবং অনুমোদিত স্ট্যান্ডার্ড লাইব্রেরি ফাংশনগুলোর মধ্যে সীমাবদ্ধ রাখে।

ঐচ্ছিক বৈশিষ্ট্য

হার্ডওয়্যার এবং সফটওয়্যারকে সমর্থন করার জন্য, CHRE API-কে বিভিন্ন ফিচার এরিয়াতে বিভক্ত করা হয়েছে, যেগুলোকে API-এর দৃষ্টিকোণ থেকে ঐচ্ছিক বলে গণ্য করা হয়। যদিও একটি সামঞ্জস্যপূর্ণ CHRE ইমপ্লিমেন্টেশনকে সমর্থন করার জন্য এই ফিচারগুলোর প্রয়োজন নাও হতে পারে, তবে একটি নির্দিষ্ট ন্যানোঅ্যাপকে সমর্থন করার জন্য এগুলোর প্রয়োজন হতে পারে। এমনকি যদি কোনো প্ল্যাটফর্ম একটি নির্দিষ্ট API সেট সমর্থন না-ও করে, তবুও যে ন্যানোঅ্যাপগুলো সেই ফাংশনগুলোকে রেফারেন্স করে, সেগুলোকে অবশ্যই বিল্ড এবং লোড করতে সক্ষম হতে হবে।

সেন্সর

CHRE API অ্যাক্সেলেরোমিটার, জাইরোস্কোপ, ম্যাগনেটোমিটার, অ্যাম্বিয়েন্ট লাইট সেন্সর এবং প্রক্সিমিটি সহ বিভিন্ন সেন্সর থেকে ডেটা অনুরোধ করার সুবিধা প্রদান করে। এই API-গুলো অ্যান্ড্রয়েড সেন্সর API-এর মতো ফিচার সেট প্রদানের জন্য তৈরি করা হয়েছে, যার মধ্যে বিদ্যুৎ খরচ কমাতে সেন্সর স্যাম্পল ব্যাচিং করার সুবিধাও রয়েছে। AP-তে চালানোর তুলনায় CHRE-এর মধ্যে সেন্সর ডেটা প্রসেস করলে মোশন সিগন্যাল অনেক কম শক্তি খরচ করে এবং ল্যাটেন্সিতে প্রসেস করা যায়।

জিএনএসএস

CHRE, GPS এবং অন্যান্য স্যাটেলাইট কনস্টেলেশন সহ গ্লোবাল নেভিগেশন স্যাটেলাইট সিস্টেম (GNSS) থেকে অবস্থানের ডেটা অনুরোধ করার জন্য API সরবরাহ করে। এর মধ্যে পর্যায়ক্রমিক পজিশন ফিক্সের জন্য অনুরোধ, সেইসাথে কাঁচা পরিমাপ ডেটাও অন্তর্ভুক্ত, যদিও উভয়ই স্বাধীন সক্ষমতা। যেহেতু CHRE-এর GNSS সাবসিস্টেমের সাথে একটি সরাসরি সংযোগ রয়েছে, তাই AP-ভিত্তিক GNSS অনুরোধের তুলনায় শক্তি কম খরচ হয়, কারণ একটি লোকেশন সেশনের সম্পূর্ণ জীবনচক্র জুড়ে AP স্লিপ মোডে থাকতে পারে।

ওয়াই-ফাই

CHRE মূলত অবস্থান নির্ণয়ের উদ্দেশ্যে ওয়াই-ফাই চিপের সাথে সংযোগ স্থাপনের ক্ষমতা প্রদান করে। যদিও GNSS বাইরের অবস্থানের জন্য ভালোভাবে কাজ করে, ওয়াই-ফাই স্ক্যানের ফলাফল বাড়ির ভেতরে এবং উন্নত এলাকায় সঠিক অবস্থানের তথ্য দিতে পারে। স্ক্যানের জন্য AP-কে জাগিয়ে তোলার খরচ এড়ানোর পাশাপাশি, CHRE সংযোগের উদ্দেশ্যে ওয়াই-ফাই ফার্মওয়্যার দ্বারা সম্পাদিত ওয়াই-ফাই স্ক্যানের ফলাফল শুনতে পারে, যা সাধারণত বিদ্যুৎ খরচের কারণে AP-তে পাঠানো হয় না। প্রাসঙ্গিক উদ্দেশ্যে সংযোগ স্ক্যান ব্যবহার করা হলে মোট ওয়াই-ফাই স্ক্যানের সংখ্যা কমে আসে, ফলে বিদ্যুৎ সাশ্রয় হয়।

CHRE API v1.1-এ Wi-Fi-এর জন্য সমর্থন যোগ করা হয়েছিল, যার মধ্যে স্ক্যানের ফলাফল নিরীক্ষণ করা এবং চাহিদা অনুযায়ী স্ক্যান শুরু করার ক্ষমতা অন্তর্ভুক্ত ছিল। v1.2-এ এই ক্ষমতাগুলিকে আরও প্রসারিত করা হয় এবং এতে সেইসব অ্যাক্সেস পয়েন্টের জন্য রাউন্ড-ট্রিপ টাইম (RTT) পরিমাপ করার সুবিধা যুক্ত করা হয়, যেগুলো এই বৈশিষ্ট্যটি সমর্থন করে এবং যা সঠিক আপেক্ষিক অবস্থান নির্ধারণে সক্ষম করে।

WWAN

CHRE API-এর মাধ্যমে সার্ভিং সেল এবং তার প্রতিবেশী সেলগুলোর সেল শনাক্তকরণ তথ্য পুনরুদ্ধার করা যায়, যা সাধারণত স্থূল-স্তরের অবস্থান নির্ণয়ের উদ্দেশ্যে ব্যবহৃত হয়।

অডিও

CHRE একটি কম-পাওয়ারের মাইক্রোফোন থেকে অডিও ডেটার ব্যাচ প্রসেস করতে পারে, যার জন্য সাধারণত SoundTrigger HAL বাস্তবায়নে ব্যবহৃত হার্ডওয়্যার কাজে লাগানো হয়। CHRE-তে অডিও ডেটা প্রসেস করার মাধ্যমে এটিকে অন্যান্য ডেটার, যেমন মোশন সেন্সরের, সাথে ফিউজ করা সম্ভব হয়।

ব্লুটুথ

CHRE এমন API প্রদান করে যা ব্লুটুথ কার্যকারিতার একটি উপসেটকে সমর্থন করে এবং যা স্বল্প-শক্তি অফলোডিং থেকে সুবিধা লাভ করে। CHRE ন্যানোঅ্যাপগুলিকে AP-কে জাগিয়ে না তুলেই BLE স্ক্যান করতে, RSSI নিরীক্ষণ করতে এবং BLE বিজ্ঞাপন ডেটা প্রক্রিয়া করতে দেয়। এছাড়াও, একটি প্রতিষ্ঠিত ব্লুটুথ সকেট সংযোগের মালিকানা অফলোড ডোমেনে স্থানান্তর করা যেতে পারে, যার জন্য রক্ষণাবেক্ষণে কম শক্তির প্রয়োজন হয় এবং ন্যানোঅ্যাপগুলিকে অফলোড করা BLE সকেট সংযোগের মাধ্যমে যোগাযোগ করতে দেয়।

রেফারেন্স বাস্তবায়ন

CHRE ফ্রেমওয়ার্কের রেফারেন্স কোড AOSP-এর system/chre প্রোজেক্টে অন্তর্ভুক্ত রয়েছে, যা C++11-এ ইমপ্লিমেন্ট করা হয়েছে। যদিও এটি কঠোরভাবে বাধ্যতামূলক নয়, সামঞ্জস্যতা নিশ্চিত করতে এবং নতুন সক্ষমতাগুলোর ব্যবহার ত্বরান্বিত করার জন্য সমস্ত CHRE ইমপ্লিমেন্টেশনকে এই কোডবেসের উপর ভিত্তি করে তৈরি করার পরামর্শ দেওয়া হয়। এই কোডটিকে কোর অ্যান্ড্রয়েড ফ্রেমওয়ার্কের একটি প্রতিরূপ হিসেবে দেখা যেতে পারে, কারণ এটি অ্যাপস দ্বারা ব্যবহৃত API-গুলোর একটি ওপেন-সোর্স ইমপ্লিমেন্টেশন, যা সামঞ্জস্যতার জন্য একটি ভিত্তি এবং মান হিসেবে কাজ করে। যদিও এটিকে ভেন্ডর-নির্দিষ্ট সক্ষমতা দিয়ে কাস্টমাইজ এবং এক্সটেন্ড করা যায়, তবে সাধারণ কোডটিকে রেফারেন্সের যতটা সম্ভব কাছাকাছি রাখার পরামর্শ দেওয়া হয়। অ্যান্ড্রয়েডের HAL-গুলোর মতোই, CHRE রেফারেন্স ইমপ্লিমেন্টেশনটি বিভিন্ন প্ল্যাটফর্ম অ্যাবস্ট্রাকশন ব্যবহার করে, যাতে এটিকে ন্যূনতম প্রয়োজনীয়তা পূরণকারী যেকোনো ডিভাইসের সাথে খাপ খাইয়ে নেওয়া যায়।

প্রযুক্তিগত বিবরণ এবং পোর্টিং গাইডের জন্য, system/chre প্রজেক্টের সাথে অন্তর্ভুক্ত README দেখুন।