অ্যান্ড্রয়েড ৭.০, রেডিও ইন্টারফেস লেয়ার (RIL)-এর কার্যকারিতা উন্নত করার জন্য একগুচ্ছ ফিচার ব্যবহার করে এটিকে রিফ্যাক্টর করেছে। এই ফিচারগুলো বাস্তবায়নের জন্য পার্টনার কোডে পরিবর্তন আনা প্রয়োজন, যা ঐচ্ছিক হলেও উৎসাহিত করা হয়। রিফ্যাক্টরিং পরিবর্তনগুলো ব্যাকওয়ার্ড কম্প্যাটিবল, ফলে রিফ্যাক্টর করা ফিচারগুলোর পূর্ববর্তী ইমপ্লিমেন্টেশনগুলো কাজ করতে থাকবে।
RIL রিফ্যাক্টরিং-এ নিম্নলিখিত উন্নতিগুলো অন্তর্ভুক্ত রয়েছে:
- RIL ত্রুটি কোডসমূহ। বিদ্যমান
GENERIC_FAILUREকোডের পাশাপাশি নির্দিষ্ট ত্রুটি কোডসমূহ সক্রিয় করে। এটি ত্রুটির কারণ সম্পর্কে আরও সুনির্দিষ্ট তথ্য প্রদান করে ত্রুটি সমাধানে সহায়তা করে। - RIL ভার্সনিং। এটি আরও নির্ভুল এবং সহজে কনফিগারযোগ্য ভার্সন তথ্য প্রদান করে।
- ওয়েক-লক ব্যবহার করে RIL যোগাযোগ। ডিভাইসের ব্যাটারির কার্যক্ষমতা উন্নত করে।
আপনি উপরের যেকোনো একটি বা সমস্ত উন্নতি বাস্তবায়ন করতে পারেন। আরও বিস্তারিত জানতে, https://android.googlesource.com/platform/hardware/ril/+/android17-release/include/telephony/ril.h -এ RIL ভার্সনিং সম্পর্কিত কোড কমেন্টগুলো দেখুন।
উন্নত RIL ত্রুটি কোড প্রয়োগ করুন
প্রায় সমস্ত RIL রিকোয়েস্ট কল কোনো ত্রুটির প্রতিক্রিয়ায় GENERIC_FAILURE এরর কোডটি ফেরত দিতে পারে। OEM-দের দ্বারা ফেরত দেওয়া সমস্ত সলিসিটেড রেসপন্সের ক্ষেত্রেই এটি একটি সমস্যা, যার ফলে বাগ রিপোর্ট থেকে কোনো সমস্যা ডিবাগ করা কঠিন হয়ে পড়ে, যদি বিভিন্ন কারণে RIL কলগুলো একই GENERIC_FAILURE এরর কোড ফেরত দেয়। ভেন্ডরদের পক্ষে কোডের কোন অংশটি GENERIC_FAILURE কোডটি ফেরত দিয়েছে, তা শনাক্ত করতেই যথেষ্ট সময় লেগে যেতে পারে।
অ্যান্ড্রয়েড 7.x এবং তার পরবর্তী সংস্করণগুলিতে, OEM-রা প্রতিটি ভিন্ন ত্রুটির জন্য একটি স্বতন্ত্র ত্রুটি কোড মান ফেরত দিতে পারে, যা বর্তমানে GENERIC_FAILURE হিসাবে শ্রেণীবদ্ধ করা হয়েছে। যে OEM-রা তাদের নিজস্ব ত্রুটি কোডগুলি প্রকাশ্যে প্রকাশ করতে চায় না, OEM_ERROR_1 থেকে OEM_ERROR_X হিসাবে ম্যাপ করা পূর্ণসংখ্যার একটি স্বতন্ত্র সেট (যেমন 1 থেকে x) হিসাবে ত্রুটিগুলি ফেরত দিতে পারে। বিক্রেতাদের নিশ্চিত করা উচিত যে ফেরত দেওয়া এই ধরনের প্রতিটি মাস্কড ত্রুটি কোড, কোডের মধ্যে একটি অনন্য ত্রুটির কারণের সাথে ম্যাপ করা থাকে। যখন OEM দ্বারা জেনেরিক ত্রুটি ফেরত দেওয়া হয়, তখন নির্দিষ্ট ত্রুটি কোড ব্যবহার করলে RIL ডিবাগিং দ্রুততর হতে পারে, কারণ একটি GENERIC_FAILURE ত্রুটি কোডের সঠিক কারণ সনাক্ত করতে প্রায়শই অনেক বেশি সময় লাগে (এবং কখনও কখনও তা বের করা অসম্ভব হয়ে পড়ে)।
এছাড়াও, ril.h RIL_LastCallFailCause এবং RIL_DataCallFailCause enum-গুলোর জন্য আরও কিছু এরর কোড যোগ করে, যাতে ভেন্ডর কোড CALL_FAIL_ERROR_UNSPECIFIED এবং PDP_FAIL_ERROR_UNSPECIFIED মতো জেনেরিক এররগুলো রিটার্ন করা এড়াতে পারে।
উন্নত RIL ত্রুটি কোডগুলি যাচাই করুন
GENERIC_FAILURE কোডটি প্রতিস্থাপন করার জন্য নতুন এরর কোড যোগ করার পর, যাচাই করুন যে RIL কলটি GENERIC_FAILURE এর পরিবর্তে নতুন এরর কোডগুলো রিটার্ন করছে।
উন্নত RIL ভার্সনিং বাস্তবায়ন করুন
পুরোনো অ্যান্ড্রয়েড রিলিজগুলোতে RIL ভার্সনিং সমস্যাযুক্ত ছিল: ভার্সনটি নিজেই নির্ভুল ছিল না, RIL ভার্সন জানানোর প্রক্রিয়াটি অস্পষ্ট ছিল (যার ফলে কিছু ভেন্ডর ভুল ভার্সন জানাতো), এবং ভার্সন অনুমান করার বিকল্প পদ্ধতিটিও ভুল হওয়ার প্রবণতাযুক্ত ছিল।
Android 7.x এবং তার পরবর্তী সংস্করণগুলিতে, ril.h ফাইলে সমস্ত RIL ভার্সনের মান নথিভুক্ত করা থাকে, সংশ্লিষ্ট RIL ভার্সনটির বর্ণনা দেওয়া থাকে এবং সেই ভার্সনের সমস্ত পরিবর্তন তালিকাভুক্ত করা থাকে। কোনো RIL ভার্সনের সাথে সামঞ্জস্যপূর্ণ পরিবর্তন করার সময়, ভেন্ডরদের অবশ্যই কোডে তাদের ভার্সন আপডেট করতে হবে এবং RIL_REGISTER এ সেই ভার্সনটি রিটার্ন করতে হবে।
উন্নত RIL সংস্করণ যাচাই করুন
যাচাই করুন যে RIL_REGISTER চলাকালীন আপনার RIL কোডের সাথে সঙ্গতিপূর্ণ RIL সংস্করণটি ফেরত আসছে ( ril.h এ সংজ্ঞায়িত RIL_VERSION পরিবর্তে)।
ওয়েক-লক ব্যবহার করে RIL কমিউনিকেশন বাস্তবায়ন করুন
RIL কমিউনিকেশনে টাইমড ওয়েক-লকগুলো অনির্দিষ্টভাবে ব্যবহৃত হয়, যা ব্যাটারির কার্যক্ষমতাকে নেতিবাচকভাবে প্রভাবিত করে। অ্যান্ড্রয়েড 7.x এবং তার পরবর্তী সংস্করণগুলোতে, RIL রিকোয়েস্টগুলোকে শ্রেণীবদ্ধ করে এবং বিভিন্ন ধরনের রিকোয়েস্টের জন্য ওয়েক-লকগুলোকে ভিন্নভাবে পরিচালনা করার জন্য কোড আপডেট করার মাধ্যমে আপনি পারফরম্যান্স উন্নত করতে পারেন।
RIL অনুরোধগুলি শ্রেণীবদ্ধ করুন
RIL অনুরোধগুলি অনুরোধকৃত বা অননুরোধকৃত হতে পারে। বিক্রেতাদের উচিত অনুরোধকৃত অনুরোধগুলিকে নিম্নলিখিতগুলির মধ্যে একটি হিসাবে আরও শ্রেণীবদ্ধ করা:
- সিঙ্ক্রোনাস । যে অনুরোধগুলোর প্রতিক্রিয়া জানাতে উল্লেখযোগ্য সময় লাগে না। উদাহরণস্বরূপ,
RIL_REQUEST_GET_SIM_STATUS। - অ্যাসিঙ্ক্রোনাস । যে অনুরোধগুলোর প্রতিক্রিয়া জানাতে যথেষ্ট সময় লাগে। উদাহরণস্বরূপ,
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS।
অ্যাসিঙ্ক্রোনাসভাবে অনুরোধ করা RIL রিকোয়েস্টগুলো সম্পন্ন হতে বেশ কিছুটা সময় লাগতে পারে। ভেন্ডর কোড থেকে অ্যাক (ack) পাওয়ার পর, RIL Java ওয়েক-লকটি ছেড়ে দেয়, যার ফলে অ্যাপ প্রসেসরটি আইডল অবস্থা থেকে সাসপেন্ড অবস্থায় চলে যেতে পারে। ভেন্ডর কোড থেকে রেসপন্স পাওয়া গেলে, RIL Java (অ্যাপ প্রসেসর) পুনরায় ওয়েক-লকটি গ্রহণ করে, রেসপন্সটি প্রসেস করে এবং তারপর আবার আইডল অবস্থায় ফিরে আসে। আইডল থেকে সাসপেন্ড এবং পুনরায় আইডল অবস্থায় যাওয়ার এই প্রক্রিয়াটি প্রচুর শক্তি খরচ করতে পারে।
যদি প্রতিক্রিয়ার সময় যথেষ্ট দীর্ঘ না হয়, তবে ওয়েক-লক ছেড়ে দিয়ে সাসপেন্ড অবস্থায় গিয়ে প্রতিক্রিয়া আসার পর জেগে ওঠার চেয়ে, ওয়েক-লক ধরে রেখে প্রতিক্রিয়া জানাতে যে পুরো সময়টা লাগে সেই সময়টুকু আইডল অবস্থায় থাকাটা বেশি শক্তি-সাশ্রয়ী হতে পারে। বিক্রেতাদের প্ল্যাটফর্ম-নির্দিষ্ট শক্তি পরিমাপ ব্যবহার করে সময় T এর সেই প্রান্তিক মান নির্ধারণ করা উচিত, যখন পুরো সময় T আইডল অবস্থায় থাকার ফলে খরচ হওয়া শক্তি, একই সময় T এর মধ্যে আইডল থেকে সাসপেন্ড এবং আবার আইডলে ফিরে যাওয়ার ফলে খরচ হওয়া শক্তির চেয়ে বেশি হয়। যখন সময় T জানা থাকে, তখন যে RIL কমান্ডগুলো T সময়ের চেয়ে বেশি সময় নেয় সেগুলোকে অ্যাসিঙ্ক্রোনাস এবং বাকি কমান্ডগুলোকে সিঙ্ক্রোনাস হিসেবে শ্রেণীবদ্ধ করা যেতে পারে।
আরআইএল যোগাযোগের পরিস্থিতি
নিম্নলিখিত ডায়াগ্রামগুলি সাধারণ RIL কমিউনিকেশন পরিস্থিতিগুলি তুলে ধরে এবং RIL-এর স্বতঃপ্রণোদিত ও অননুরোধিত অনুরোধগুলি পরিচালনা করার জন্য কোড পরিবর্তনের সমাধান প্রদান করে।
দ্রষ্টব্য: নিম্নলিখিত ডায়াগ্রামগুলিতে ব্যবহৃত ফাংশনগুলির বাস্তবায়নের বিশদ বিবরণের জন্য, ril.cpp ফাইলে থাকা acquireWakeLock() , decrementWakeLock() , এবং clearWakeLock( ) পদ্ধতিগুলি দেখুন।
দৃশ্যকল্প: RIL অনুরোধ এবং অনুরোধকৃত অ্যাসিঙ্ক্রোনাস প্রতিক্রিয়া
এই পরিস্থিতিতে, যদি RIL-এর অনুরোধে সাড়া দিতে উল্লেখযোগ্য সময় লাগার সম্ভাবনা থাকে (যেমন RIL_REQUEST_GET_AVAILABLE_NETWORKS এর সাড়া), তাহলে অ্যাপ প্রসেসরের দিকে ওয়েক-লকটি দীর্ঘ সময়ের জন্য ধরে রাখা হয়। মডেমের সমস্যার কারণেও দীর্ঘ অপেক্ষা হতে পারে।
সমাধান ১: মোডেমটি RIL অনুরোধ এবং অ্যাসিঙ্ক্রোনাস প্রতিক্রিয়ার জন্য ওয়েক-লক ধরে রাখে।
- RIL অনুরোধ পাঠানো হয় এবং সেই অনুরোধটি প্রক্রিয়া করার জন্য মোডেমটি ওয়েক-লক অর্জন করে।
- মোডেম একটি স্বীকৃতি বার্তা পাঠায়, যার ফলে জাভা সাইড ওয়েক-লক কাউন্টারের মান এক ধাপ করে কমিয়ে দেয় এবং কাউন্টারের মান ০ হয়ে গেলে তা মুক্ত করে দেয়।
দ্রষ্টব্য: রিকোয়েস্ট-অ্যাক সিকোয়েন্সের জন্য ওয়েক-লক টাইমআউটের সময়কাল বর্তমানে ব্যবহৃত টাইমআউটের সময়কালের চেয়ে কম হবে, কারণ অ্যাকটি বেশ দ্রুত পাওয়া উচিত।
- অনুরোধটি প্রক্রিয়া করার পর, মোডেমটি ভেন্ডর কোডে একটি ইন্টারাপ্ট পাঠায়, যা ওয়েক-লক অর্জন করে এবং ril.cpp-তে একটি প্রতিক্রিয়া পাঠায়, যা আবার ওয়েক-লক অর্জন করে এবং জাভা সাইডে একটি প্রতিক্রিয়া পাঠায়।
- যখন প্রতিক্রিয়াটি জাভা প্রান্তে পৌঁছায়, তখন ওয়েক-লক অর্জিত হয় এবং আহ্বানকারীকে একটি প্রতিক্রিয়া ফেরত পাঠানো হয়।
- সমস্ত মডিউল দ্বারা প্রতিক্রিয়াটি প্রক্রিয়া করার পরে,
ril.cppতে (সকেটের মাধ্যমে) একটি স্বীকৃতি বার্তা ফেরত পাঠানো হয়, যা তখন ধাপ ৩-এ অর্জিত ওয়েক-লকটি মুক্ত করে দেয়।
সমাধান ২: মোডেমটি ওয়েক-লক ধরে রাখে না এবং প্রতিক্রিয়া দ্রুত হয় (সিঙ্ক্রোনাস RIL অনুরোধ এবং প্রতিক্রিয়া)। একটি নির্দিষ্ট RIL কমান্ডের জন্য সিঙ্ক্রোনাস বনাম অ্যাসিঙ্ক্রোনাস আচরণ হার্ডকোড করা থাকে এবং প্রতিটি কলের ভিত্তিতে সিদ্ধান্ত নেওয়া হয়।
- জাভা সাইডে
acquireWakeLock()কল করার মাধ্যমে RIL রিকোয়েস্ট পাঠানো হয়। - ভেন্ডর কোডের ওয়েক-লক অ্যাকোয়ার করার প্রয়োজন হয় না এবং এটি অনুরোধটি প্রসেস করে দ্রুত সাড়া দিতে পারে।
- জাভা প্রান্তে প্রতিক্রিয়া প্রাপ্ত হলে
decrementWakeLock()কল করা হয়, যা ওয়েকলক কাউন্টার হ্রাস করে এবং কাউন্টারের মান ০ হলে ওয়েকলকটি মুক্ত করে দেয়।
দৃশ্যকল্প: RIL-এর অযাচিত প্রতিক্রিয়া
এই ক্ষেত্রে, RIL-এর অযাচিত প্রতিক্রিয়াগুলিতে একটি ওয়েক-লক টাইপ ফ্ল্যাগ থাকে, যা নির্দেশ করে যে ভেন্ডর প্রতিক্রিয়ার জন্য একটি ওয়েক-লক অধিগ্রহণ করার প্রয়োজন আছে কিনা। যদি ফ্ল্যাগটি সেট করা থাকে, তাহলে একটি টাইমড ওয়েক-লক সেট করা হয় এবং প্রতিক্রিয়াটি একটি সকেটের মাধ্যমে জাভা সাইডে পাঠানো হয়। টাইমারের মেয়াদ শেষ হলে, ওয়েক-লকটি মুক্ত হয়ে যায়। বিভিন্ন RIL অযাচিত প্রতিক্রিয়ার জন্য এই টাইমড ওয়েক-লকটি খুব দীর্ঘ বা খুব সংক্ষিপ্ত হতে পারে।
সমাধান: অযাচিত প্রতিক্রিয়া পাঠানোর সময় নেটিভ সাইডে একটি টাইমড ওয়েক-লক ধরে রাখার পরিবর্তে, জাভা কোড থেকে নেটিভ সাইডে ( ril.cpp ) একটি অ্যাকনলেজমেন্ট পাঠানো হয়।
পুনরায় ডিজাইন করা ওয়েক-লকগুলি যাচাই করুন
RIL কলগুলো সিনক্রোনাস নাকি অ্যাসিনক্রোনাস হিসেবে চিহ্নিত হচ্ছে, তা যাচাই করুন। যেহেতু ব্যাটারির শক্তি খরচ হার্ডওয়্যার/প্ল্যাটফর্মের উপর নির্ভরশীল হতে পারে, তাই বিক্রেতাদের অভ্যন্তরীণভাবে পরীক্ষা করে দেখা উচিত যে অ্যাসিনক্রোনাস কলের জন্য নতুন ওয়েক-লক সিম্যান্টিকস ব্যবহার করলে ব্যাটারির শক্তি সাশ্রয় হয় কি না।