আরআইএল রিফ্যাক্টরিং

Android 7.0 RIL কার্যকারিতা উন্নত করতে বৈশিষ্ট্যগুলির একটি সেট ব্যবহার করে রেডিও ইন্টারফেস লেয়ার (RIL) রিফ্যাক্টর করেছে। এই বৈশিষ্ট্যগুলি বাস্তবায়নের জন্য অংশীদার কোড পরিবর্তন প্রয়োজন, যা ঐচ্ছিক কিন্তু উৎসাহিত৷ রিফ্যাক্টরিং পরিবর্তনগুলি পশ্চাদমুখী সামঞ্জস্যপূর্ণ, তাই রিফ্যাক্টর বৈশিষ্ট্যগুলির পূর্বে বাস্তবায়ন কাজ চালিয়ে যাচ্ছে।

RIL রিফ্যাক্টরিং নিম্নলিখিত উন্নতিগুলি অন্তর্ভুক্ত করে:

  • RIL ত্রুটি কোড। বিদ্যমান GENERIC_FAILURE কোড ছাড়াও নির্দিষ্ট ত্রুটি কোড সক্ষম করে৷ এটি ত্রুটির কারণ সম্পর্কে আরও নির্দিষ্ট তথ্য প্রদান করে ত্রুটির সমস্যা সমাধানে সহায়তা করে।
  • RIL সংস্করণ। সংস্করণ তথ্য কনফিগার করার জন্য আরো সঠিক এবং সহজ প্রদান করে।
  • wakelocks ব্যবহার করে RIL যোগাযোগ. ডিভাইসের ব্যাটারির কর্মক্ষমতা উন্নত করে।

আপনি উপরের যে কোনো বা সমস্ত উন্নতি বাস্তবায়ন করতে পারেন। আরও বিশদ বিবরণের জন্য, https://android.googlesource.com/platform/hardware/ril/+/main/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 হিসাবে ম্যাপ করা পূর্ণসংখ্যাগুলির একটি স্বতন্ত্র সেট (যেমন 1 থেকে x) হিসাবে ত্রুটিগুলি ফেরত দিতে পারে। বিক্রেতাদের নিশ্চিত করা উচিত যে এই জাতীয় প্রতিটি মুখোশযুক্ত ত্রুটি কোড কোডে একটি অনন্য ত্রুটির কারণে মানচিত্র ফেরত দিয়েছে। নির্দিষ্ট ত্রুটি কোডগুলি ব্যবহার করে যখনই OEM দ্বারা জেনেরিক ত্রুটিগুলি ফেরত দেওয়া হয় তখন RIL ডিবাগিংয়ের গতি বাড়িয়ে তুলতে পারে, কারণ এটি প্রায়শই একটি GENERIC_FAILURE ত্রুটি কোডের সঠিক কারণ সনাক্ত করতে খুব বেশি সময় নিতে পারে (এবং কখনও কখনও এটি বের করা অসম্ভব)।

উপরন্তু, ril.h enums RIL_LastCallFailCause এবং RIL_DataCallFailCause এর জন্য আরও ত্রুটি কোড যোগ করে যাতে বিক্রেতা কোড CALL_FAIL_ERROR_UNSPECIFIED এবং PDP_FAIL_ERROR_UNSPECIFIED এর মতো জেনেরিক ত্রুটিগুলি এড়াতে পারে৷

উন্নত RIL ত্রুটি কোড যাচাই করা হচ্ছে

GENERIC_FAILURE কোড প্রতিস্থাপন করতে নতুন ত্রুটি কোড যোগ করার পরে, GENERIC_FAILURE এর পরিবর্তে RIL কল দ্বারা নতুন ত্রুটি কোডগুলি ফেরত দেওয়া হয়েছে তা যাচাই করুন।

উন্নত RIL সংস্করণ বাস্তবায়ন করা

পুরানো অ্যান্ড্রয়েড রিলিজে RIL সংস্করণ সমস্যাযুক্ত ছিল: সংস্করণটি নিজেই ভুল ছিল, একটি RIL সংস্করণ প্রতিবেদন করার পদ্ধতিটি অস্পষ্ট ছিল (কিছু বিক্রেতারা একটি ভুল সংস্করণের প্রতিবেদন করতে পারে), এবং সংস্করণটি অনুমান করার জন্য সমাধানটি ভুল হওয়ার ঝুঁকিপূর্ণ ছিল।

Android 7.x এবং উচ্চতর সংস্করণে, ril.h সমস্ত RIL সংস্করণের মান নথিভুক্ত করে, সংশ্লিষ্ট RIL সংস্করণ বর্ণনা করে এবং সেই সংস্করণের জন্য সমস্ত পরিবর্তন তালিকাভুক্ত করে। RIL সংস্করণের সাথে সামঞ্জস্যপূর্ণ পরিবর্তনগুলি করার সময়, বিক্রেতাদের অবশ্যই কোডে তাদের সংস্করণ আপডেট করতে হবে এবং RIL_REGISTER এ সেই সংস্করণটি ফেরত দিতে হবে।

উন্নত RIL সংস্করণ যাচাই করা হচ্ছে

যাচাই করুন যে আপনার RIL কোডের সাথে সম্পর্কিত RIL সংস্করণটি RIL_REGISTER এর সময় ফেরত দেওয়া হয়েছে ( ril.h এ সংজ্ঞায়িত RIL_VERSION এর পরিবর্তে)।

wakelocks ব্যবহার করে RIL যোগাযোগ বাস্তবায়ন

RIL কমিউনিকেশনে টাইমড ওয়াকলক ব্যবহার করা হয়, যা ব্যাটারির কর্মক্ষমতাকে নেতিবাচকভাবে প্রভাবিত করে। Android 7.x এবং উচ্চতর সংস্করণে, আপনি RIL অনুরোধগুলিকে শ্রেণীবদ্ধ করে এবং বিভিন্ন ধরনের অনুরোধের জন্য ভিন্নভাবে wakelocks পরিচালনা করার জন্য কোড আপডেট করে কর্মক্ষমতা উন্নত করতে পারেন৷

RIL অনুরোধ শ্রেণীবদ্ধ করা

RIL অনুরোধগুলি হয় অপ্রত্যাশিত বা অযাচিত হতে পারে৷ বিক্রেতাদের অনুরোধ করা অনুরোধগুলিকে নিম্নলিখিতগুলির মধ্যে একটি হিসাবে আরও শ্রেণীবদ্ধ করা উচিত:

  • সিঙ্ক্রোনাস রিকুয়েস্ট যেগুলোর উত্তর দিতে যথেষ্ট সময় লাগে না। উদাহরণস্বরূপ, RIL_REQUEST_GET_SIM_STATUS ।
  • অ্যাসিঙ্ক্রোনাস রিকুয়েস্ট যেগুলোর উত্তর দিতে যথেষ্ট সময় লাগে। উদাহরণস্বরূপ, RIL_REQUEST_QUERY_AVAILABLE_NETWORKS ।

অ্যাসিঙ্ক্রোনাস সলিসিটেড RIL অনুরোধগুলি যথেষ্ট সময় নিতে পারে। বিক্রেতা কোড থেকে একটি ack পাওয়ার পর, RIL Java wakelock প্রকাশ করে, যার ফলে অ্যাপ্লিকেশন প্রসেসর নিষ্ক্রিয় থেকে সাসপেন্ড অবস্থায় যেতে পারে। বিক্রেতা কোড থেকে প্রতিক্রিয়া পাওয়া গেলে, RIL জাভা (অ্যাপ্লিকেশন প্রসেসর) ওয়েকলক পুনরায় অর্জন করে, প্রতিক্রিয়া প্রক্রিয়া করে, তারপর নিষ্ক্রিয় অবস্থায় ফিরে আসে। এই ধরনের নিষ্ক্রিয় থেকে স্থগিত থেকে নিষ্ক্রিয় হয়ে যাওয়া অনেক শক্তি খরচ করতে পারে।

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

RIL যোগাযোগের পরিস্থিতি

নিম্নলিখিত চিত্রগুলি সাধারণ RIL যোগাযোগের পরিস্থিতিগুলিকে চিত্রিত করে এবং RIL চাওয়া এবং অযাচিত অনুরোধগুলি পরিচালনা করার জন্য কোড সংশোধন করার সমাধান প্রদান করে৷

দ্রষ্টব্য: নিম্নলিখিত ডায়াগ্রামে ব্যবহৃত ফাংশনগুলির বাস্তবায়নের বিবরণের জন্য, ril.cpp এ acquireWakeLock() , decrementWakeLock() , এবং clearWakeLock( ) পদ্ধতিগুলি পড়ুন।

দৃশ্যকল্প: RIL অনুরোধ এবং অনুরোধ করা অসিঙ্ক্রোনাস প্রতিক্রিয়া

এই পরিস্থিতিতে, যদি RIL চাওয়া প্রতিক্রিয়া যথেষ্ট সময় নেবে বলে আশা করা হয় (যেমন RIL_REQUEST_GET_AVAILABLE_NETWORKS এর প্রতিক্রিয়া), অ্যাপ্লিকেশন প্রসেসরের দিকে ওয়েকলকটি দীর্ঘ সময়ের জন্য ধরে রাখা হয়। মডেমের সমস্যাও দীর্ঘ অপেক্ষার কারণ হতে পারে।

চিত্র 1. RIL অসিঙ্ক্রোনাস প্রতিক্রিয়া চেয়েছে।

সমাধান 1: মডেম RIL অনুরোধ এবং অ্যাসিঙ্ক্রোনাস প্রতিক্রিয়ার জন্য ওয়েকলক ধারণ করে।

চিত্র 2. মডেম দ্বারা রাখা Wakelock.
  1. RIL অনুরোধ পাঠানো হয় এবং মডেম সেই অনুরোধটি প্রক্রিয়া করার জন্য wakelock অর্জন করে।
  2. মডেম স্বীকারোক্তি পাঠায় যার ফলে জাভা সাইড ওয়েকলক কাউন্টার কমিয়ে দেয় এবং কাউন্টারের মান 0 হলে এটি ছেড়ে দেয়।

    দ্রষ্টব্য: অনুরোধ-অ্যাক সিকোয়েন্সের জন্য wakelock টাইমআউট সময়কাল বর্তমানে ব্যবহৃত টাইমআউট সময়কালের চেয়ে ছোট হবে কারণ ack মোটামুটি দ্রুত গ্রহণ করা উচিত।

  3. অনুরোধটি প্রক্রিয়া করার পর, মডেম ভেন্ডর কোডে একটি ইন্টারাপ্ট পাঠায় যা wakelock অর্জন করে এবং ril.cpp-এ একটি প্রতিক্রিয়া পাঠায়, যা ওয়েকলক অর্জন করে এবং জাভা সাইডে একটি প্রতিক্রিয়া পাঠায়।
  4. প্রতিক্রিয়া জাভা দিকে পৌঁছালে, ওয়েকলক অর্জিত হয় এবং কলারের কাছে একটি প্রতিক্রিয়া ফেরত দেওয়া হয়।
  5. সমস্ত মডিউল দ্বারা প্রতিক্রিয়া প্রক্রিয়া করার পরে, স্বীকৃতিটি (সকেটের মাধ্যমে) ril.cpp এ ফেরত পাঠানো হয়, যা তারপর ধাপ 3-এ অর্জিত ওয়েকলক প্রকাশ করে।

সমাধান 2: মডেম ওয়েকলক ধরে রাখে না এবং প্রতিক্রিয়া দ্রুত হয় (সিঙ্ক্রোনাস RIL অনুরোধ এবং প্রতিক্রিয়া)। সিঙ্ক্রোনাস বনাম অ্যাসিঙ্ক্রোনাস আচরণ একটি নির্দিষ্ট RIL কমান্ডের জন্য হার্ডকোড করা হয় এবং কল-বাই-কলবেসিসের উপর সিদ্ধান্ত নেওয়া হয়।

চিত্র 3. Wakelock মডেম দ্বারা ধারণ করা হয় না.
  1. জাভা পাশে acquireWakeLock() কল করে RIL অনুরোধ পাঠানো হয়।
  2. ভেন্ডর কোডের wakelock অর্জন করার প্রয়োজন নেই এবং অনুরোধটি প্রক্রিয়া করতে পারে এবং দ্রুত প্রতিক্রিয়া জানাতে পারে।
  3. যখন জাভা পক্ষ থেকে প্রতিক্রিয়া পাওয়া যায়, তখন decrementWakeLock() বলা হয়, যা ওয়েকলক কাউন্টার হ্রাস করে এবং কাউন্টার মান 0 হলে wakelock প্রকাশ করে।

দৃশ্যকল্প: RIL অযাচিত প্রতিক্রিয়া

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

চিত্র 4. RIL অযাচিত প্রতিক্রিয়া।

সমাধান: জাভা কোড থেকে একটি অনাকাঙ্ক্ষিত প্রতিক্রিয়া পাঠানোর সময় নেটিভ সাইডে একটি টাইমড ওয়েকলক রাখার পরিবর্তে নেটিভ সাইডে ( ril.cpp ) একটি স্বীকৃতি পাঠানো হয়।

চিত্র 5. টাইমড ওয়াকলকের পরিবর্তে ack ব্যবহার করা।

পুনরায় ডিজাইন করা wakelocks যাচাই করা হচ্ছে

RIL কলগুলি সিঙ্ক্রোনাস বা অ্যাসিঙ্ক্রোনাস হিসাবে চিহ্নিত করা হয়েছে তা যাচাই করুন৷ যেহেতু ব্যাটারি পাওয়ার খরচ হার্ডওয়্যার/প্ল্যাটফর্ম নির্ভর হতে পারে, তাই বিক্রেতাদের কিছু অভ্যন্তরীণ পরীক্ষা করা উচিত যাতে অ্যাসিঙ্ক্রোনাস কলের জন্য নতুন ওয়েকলক শব্দার্থবিদ্যা ব্যবহার করলে ব্যাটারি পাওয়ার সাশ্রয় হয়।