RIL-এর কার্যকারিতা উন্নত করতে, Android 7.0, ফিচারগুলির একটি সেট ব্যবহার করে রেডিও ইন্টারফেস লেয়ার (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 কোড রিটার্ন করা হতে পারে তা শনাক্ত করতেও ভেন্ডরদের যথেষ্ট সময়
লাগতে পারে।
Android 7.x ও তার পরবর্তী যেকোনও ভার্সনে, OEM, বর্তমানে
GENERIC_FAILURE হিসেবে শ্রেণীবদ্ধ করা প্রতিটি আলাদা আলাদা সমস্যার সাথে যুক্ত একটি স্বতন্ত্র সমস্যা কোড ভ্যালু
রিটার্ন করতে পারে। যেসব OEM তাদের কাস্টম ত্রুটি কোড সর্বজনীনভাবে প্রকাশ করতে চায় না, তারা OEM_ERROR_1 থেকে OEM_ERROR_X হিসেবে ম্যাপ করা পূর্ণসংখ্যার একটি স্বতন্ত্র সেট (যেমন ১ থেকে x) হিসেবে ত্রুটি দেখাতে পারে। কোডে
এই ধরনের প্রতিটি মাস্ক করা সমস্যার কোড যেন একটি অনন্য সমস্যার কারণের সাথে ম্যাপ করে
তা বিক্রেতাদের নিশ্চিত করতে হবে। OEM-এর থেকে সাধারণ সমস্যা সংক্রান্ত মেসেজ ফেরত এলে, নির্দিষ্ট সমস্যা কোড ব্যবহার করে RIL ডিবাগ করার প্রসেস দ্রুত করা যেতে পারে, কারণ GENERIC_FAILURE সমস্যা কোডের (এবং
কখনও কখনও এটি খুঁজে বের করা অসম্ভব) সঠিক কারণ শনাক্ত করতে
প্রায়শই অনেক সময় লাগতে পারে।
এছাড়াও, ril.h, RIL_LastCallFailCause এবং RIL_DataCallFailCause এনামের জন্য আরও ত্রুটি কোড যোগ করে যাতে
ভেন্ডর কোড
CALL_FAIL_ERROR_UNSPECIFIED এবং
PDP_FAIL_ERROR_UNSPECIFIED-এর মতো সাধারণ ত্রুটি দেখানো এড়াতে পারে।
উন্নত RIL সমস্যার কোড যাচাই করা
GENERIC_FAILURE কোডটি প্রতিস্থাপন করার জন্য নতুন ত্রুটি কোড যোগ করার পরে, যাচাই করুন যে নতুন ত্রুটি কোডগুলি GENERIC_FAILURE-এর পরিবর্তে RIL কলের মাধ্যমে ফেরত দেওয়া হয়েছে।
উন্নত RIL ভার্সনিং প্রয়োগ করুন
পুরনো Android রিলিজের RIL ভার্সনিংয়ে সমস্যা ছিল: ভার্সনটি অনিশ্চিত ছিল, RIL ভার্সন রিপোর্ট করার মেকানিজম অস্পষ্ট ছিল (এর ফলে কিছু ভেন্ডর ভুল ভার্সন রিপোর্ট করত) এবং ভার্সন অনুমান করার ওয়ার্কঅ্যারাউন্ডে ভুল হওয়ার সম্ভাবনা থাকত।
Android 7.x ও তার পরবর্তী যেকোনও ভার্সনে, ril.h সব RIL ভার্সন
ভ্যালু ডকুমেন্ট করে, সংশ্লিষ্ট RIL ভার্সনের বিবরণ দেয় এবং সেই
ভার্সনের জন্য সব পরিবর্তন তালিকাভুক্ত করে। RIL ভার্সনের সাথে সামঞ্জস্যপূর্ণ পরিবর্তন করার সময়, ভেন্ডরদের অবশ্যই
কোডে তাদের ভার্সন আপডেট করতে হবে এবং সেই ভার্সনটি
RIL_REGISTER-এ ফেরত দিতে হবে।
উন্নত RIL ভার্সনিং যাচাই করুন
যাচাই করে দেখুন যে আপনার RIL কোডের সাথে সম্পর্কিত RIL ভার্সন RIL_REGISTER-এর সময় (RIL_VERSION-এর পরিবর্তে
ril.h-এ সংজ্ঞায়িত করা হয়েছে) রিটার্ন করা হয়েছে কিনা।
ওয়েকলক ব্যবহার করে RIL কমিউনিকেশন প্রয়োগ করা
RIL কমিউনিকেশনে টাইমড ওয়েক লকগুলি ভুলভাবে ব্যবহার করা হয়, যা ব্যাটারির পারফর্ম্যান্সের উপর নেতিবাচক প্রভাব ফেলে। Android 7.x ও তার পরের যেকোনও ভার্সনে, আপনি RIL অনুরোধকে শ্রেণীবদ্ধ করে এবং বিভিন্ন ধরনের অনুরোধের জন্য আলাদাভাবে ওয়েকলক হ্যান্ডেল করার জন্য কোড আপডেট করে পারফর্ম্যান্স উন্নত করতে পারবেন।
RIL অনুরোধের শ্রেণীবিভাগ করা
RIL অনুরোধগুলি অনুরোধ করা বা অনুরোধ না করা হতে পারে। ভেন্ডরদের আরও অনুরোধ করা অনুরোধগুলিকে নিম্নলিখিত বিভাগগুলির মধ্যে একটি হিসেবে শ্রেণীবদ্ধ করতে হবে:
- সিঙ্ক্রোনাস। উত্তর দিতে বেশি সময় লাগে না এমন অনুরোধ।
যেমন,
RIL_REQUEST_GET_SIM_STATUS। - অ্যাসিঙ্ক্রোনাস। উত্তর দিতে অনেক সময় লাগে, এমন অনুরোধ।
যেমন,
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.
অ্যাসিঙ্ক্রোনাস সলিসিটেড RIL অনুরোধে যথেষ্ট সময় লাগতে পারে। ভেন্ডর কোড থেকে অ্যাকনলেজমেন্ট পাওয়ার পরে, RIL Java ওয়েকলক রিলিজ করে, এর ফলে অ্যাপ প্রসেসর আইডল থেকে সাসপেন্ড স্টেটে চলে যেতে পারে। ভেনডর কোড থেকে উত্তর পাওয়া গেলে, RIL Java (অ্যাপ প্রসেসর) আবার ওয়েকলক নেয়, উত্তর প্রসেস করে, তারপর আইডল অবস্থায় ফিরে যায়। এইভাবে আইডল থেকে সাসপেন্ড এবং সাসপেন্ড থেকে আইডল মোডে পরিবর্তন করলে অনেক পাওয়ার খরচ হতে পারে।
যদি উত্তর দেওয়ার সময় যথেষ্ট দীর্ঘ না হয়, তাহলে উত্তর দিতে যতটা সময় লাগে সেই পুরো সময়টা wakelock ধরে রাখা এবং আইডল অবস্থায় থাকা, wakelock রিলিজ করে সাসপেন্ড অবস্থায় যাওয়া এবং উত্তর এলে জেগে ওঠার চেয়ে বেশি পাওয়ার এফিশিয়েন্ট হতে পারে। ভেনডরদের প্ল্যাটফর্ম-নির্দিষ্ট পাওয়ার পরিমাপ ব্যবহার করে সময়ের থ্রেশহোল্ড ভ্যালু T নির্ধারণ করতে হবে, যখন সম্পূর্ণ সময় T ধরে আইডল অবস্থায় থাকার ফলে বিদ্যুৎ খরচ, একই সময়ে T আইডল থেকে সাসপেন্ড এবং আবার আইডল অবস্থায় ফিরে আসার ফলে বিদ্যুৎ খরচের চেয়ে বেশি হয়। সময় T জানা থাকলে, RIL কমান্ড যা সময় T-এর চেয়ে বেশি সময় নেয়, তা অ্যাসিঙ্ক্রোনাস হিসেবে শ্রেণীবদ্ধ করা যেতে পারে এবং বাকি কমান্ড সিঙ্ক্রোনাস হিসেবে শ্রেণীবদ্ধ করা যেতে পারে।
RIL কমিউনিকেশন পরিস্থিতি
নিচের ডায়াগ্রামগুলি সাধারণ RIL কমিউনিকেশন পরিস্থিতিকে ব্যাখ্যা করে এবং RIL-এর অনুরোধ করা ও না করা অনুরোধগুলি ম্যানেজ করার জন্য কোড পরিবর্তন করার সমাধান প্রদান করে।
মনে রাখবেন: নিম্নলিখিত ডায়াগ্রামে ব্যবহৃত ফাংশন
প্রয়োগ করার ব্যাপারে বিস্তারিত জানতে, ril.cpp-এ
acquireWakeLock(), decrementWakeLock() এবং clearWakeLock() পদ্ধতি
দেখুন।
পরিস্থিতি: RIL অনুরোধ ও অনাকাঙ্ক্ষিত অ্যাসিঙ্ক্রোনাস উত্তর
এই পরিস্থিতিতে, RIL-এর অনুরোধ করা উত্তর পেতে যদি
অনেক সময় লাগে (যেমন,
RIL_REQUEST_GET_AVAILABLE_NETWORKS-এর উত্তর), তাহলে অ্যাপ প্রসেসর
সাইডে অনেকক্ষণ ধরে ওয়েকলক হোল্ড করা হয়। মোডেমের সমস্যার কারণেও
অনেকক্ষণ অপেক্ষা করতে হতে পারে।
সমাধান ১: RIL অনুরোধ এবং অ্যাসিঙ্ক্রোনাস উত্তরের জন্য মডেম wakelock ধরে রাখে।
- RIL অনুরোধ পাঠানো হয়েছে এবং সেই অনুরোধ প্রসেস করার জন্য মডেম wakelock অ্যাকোয়ার করে।
- মডেম স্বীকৃতি পাঠায় যার ফলে জাভা সাইড ওয়েকলক কাউন্টারকে
ডিক্রিমেন্ট করে এবং কাউন্টারের ভ্যালু ০ হলে সেটি রিলিজ করে দেয়।
মনে রাখবেন: অনুরোধ-উত্তর সিকোয়েন্সের জন্য ওয়েকলক টাইমআউটের সময়সীমা বর্তমানে ব্যবহৃত টাইমআউটের সময়সীমার চেয়ে কম হবে কারণ উত্তরটি বেশ দ্রুত পাওয়া উচিত।
- অনুরোধ প্রসেস করার পরে, মডেম ভেন্ডর কোডে একটি ইন্টারাপ্ট পাঠায় যা ওয়েক-লক অ্যাকোয়ার করে এবং ril.cpp-তে একটি উত্তর পাঠায়, যা পরিবর্তে ওয়েক-লক অ্যাকোয়ার করে এবং Java সাইডে একটি উত্তর পাঠায়।
- উত্তরটি Java সাইডে পৌঁছালে, wakelock অ্যাকোয়ার করা হয় এবং কলারকে উত্তর ফেরত পাঠানো হয়।
- সব মডিউল উত্তর প্রসেস করার পরে, স্বীকৃতি
ril.cpp-এ (সকেটের মাধ্যমে) ফেরত পাঠানো হয়, যা ধাপ ৩-এ পাওয়া ওয়েক-লক রিলিজ করে।
সমাধান ২: মডেমটি ওয়েকলক হোল্ড করে না এবং উত্তরটি দ্রুত (সিনক্রোনাস RIL অনুরোধ ও উত্তর)। নির্দিষ্ট RIL কমান্ডের জন্য সিঙ্ক্রোনাস বনাম অ্যাসিঙ্ক্রোনাস আচরণ হার্ডকোড করা হয় এবং কল-বাই-কল ভিত্তিতে সিদ্ধান্ত নেওয়া হয়।
- Java সাইডে
acquireWakeLock()-এ কল করে RIL অনুরোধ পাঠানো হয়। - ভেন্ডর কোডের ওয়াকালক পাওয়ার প্রয়োজন নেই এবং এটি অনুরোধ প্রসেস করতে এবং দ্রুত উত্তর দিতে পারে।
- Java-এর দিক থেকে উত্তর পাওয়া গেলে,
decrementWakeLock()কল করা হয়, যা ওয়েকলক কাউন্টার কমিয়ে দেয় এবং কাউন্টারের ভ্যালু ০ হলে ওয়েকলক রিলিজ করে দেয়।
পরিস্থিতি: RIL-এর থেকে অনাকাঙ্ক্ষিত উত্তর
এই পরিস্থিতিতে, RIL-এর অবাঞ্ছিত উত্তরে একটি ওয়েক-লক টাইপ ফ্ল্যাগ থাকে যা নির্দেশ করে যে ভেন্ডরের উত্তরের জন্য ওয়েক-লক প্রয়োজন কিনা। ফ্ল্যাগ সেট করা থাকলে, একটি টাইমড ওয়েক লক সেট করা হয় এবং জাভা সাইডে সকেটের মাধ্যমে উত্তর পাঠানো হয়। টাইমারের মেয়াদ শেষ হয়ে গেলে, ওয়েক লক রিলিজ হয়ে যায়। বিভিন্ন RIL অননুমোদিত উত্তরের জন্য টাইমড ওয়েক লক খুব বেশি বা খুব কম হতে পারে।
সমাধান: কোনও অনাকাঙ্ক্ষিত উত্তর পাঠানোর সময় নেটিভ সাইডে টাইমড ওয়েক লক হোল্ড করে না রেখে
জাভা কোড থেকে নেটিভ সাইডে (ril.cpp) একটি স্বীকৃতি পাঠানো হয়।
নতুন করে ডিজাইন করা ওয়েকিলক যাচাই করা
RIL কল সিঙ্ক্রোনাস বা অ্যাসিঙ্ক্রোনাস হিসেবে শনাক্ত করা হয়েছে কিনা তা যাচাই করুন। কারণ, ব্যাটারির পাওয়ার কনসাম্পশন হার্ডওয়্যার/প্ল্যাটফর্মের উপর নির্ভরশীল হতে পারে, তাই ভেন্ডরদের কিছু ইন্টার্নাল টেস্টিং করে দেখতে হবে যে অ্যাসিঙ্ক্রোনাস কলের জন্য নতুন ওয়েক লক সিম্যান্টিক্স ব্যবহার করলে ব্যাটারির পাওয়ার সাশ্রয় হয় কিনা।