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