UICC ক্যারিয়ারের বিশেষাধিকার

অ্যান্ড্রয়েড ৫.১ ইউনিভার্সাল ইন্টিগ্রেটেড সার্কিট কার্ড (UICC) অ্যাপের মালিকদের জন্য প্রাসঙ্গিক API গুলির জন্য বিশেষ সুবিধা প্রদানের একটি ব্যবস্থা চালু করেছে। অ্যান্ড্রয়েড প্ল্যাটফর্মটি UICC-তে সংরক্ষিত সার্টিফিকেট লোড করে এবং এই সার্টিফিকেট দ্বারা স্বাক্ষরিত অ্যাপগুলিকে মুষ্টিমেয় বিশেষ API গুলিতে কল করার অনুমতি দেয়।

অ্যান্ড্রয়েড ৭.০ এই বৈশিষ্ট্যটি UICC ক্যারিয়ার প্রিভিলেজ নিয়মের জন্য অন্যান্য স্টোরেজ উৎসগুলিকে সমর্থন করার জন্য প্রসারিত করেছে, যার ফলে API ব্যবহার করতে পারে এমন ক্যারিয়ারের সংখ্যা নাটকীয়ভাবে বৃদ্ধি পেয়েছে। API রেফারেন্সের জন্য, CarrierConfigManager দেখুন; নির্দেশাবলীর জন্য, Carrier Configuration দেখুন।

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

UICC-এর নিয়মাবলী

UICC-তে স্টোরেজটি GlobalPlatform Secure Element Access Control স্পেসিফিকেশনের সাথে সামঞ্জস্যপূর্ণ। কার্ডে অ্যাপ আইডেন্টিফায়ার (AID) হল A00000015141434C00 , এবং কার্ডে সংরক্ষিত নিয়মগুলি আনতে স্ট্যান্ডার্ড GET DATA কমান্ড ব্যবহার করা হয়। আপনি কার্ড ওভার-দ্য-এয়ার (OTA) আপডেটের মাধ্যমে এই নিয়মগুলি আপডেট করতে পারেন।

ডেটা শ্রেণিবিন্যাস

UICC নিয়মগুলি নিম্নলিখিত ডেটা শ্রেণিবিন্যাস ব্যবহার করে (বন্ধনীতে থাকা দুই-অক্ষরের অক্ষর এবং সংখ্যার সংমিশ্রণ হল অবজেক্ট ট্যাগ)। প্রতিটি নিয়ম হল REF-AR-DO ( E2 ) এবং এতে REF-DO এবং AR-DO এর সংমিশ্রণ থাকে:

  • REF-DO ( E1 ) তে DeviceAppID-REF-DO অথবা DeviceAppID-REF-DO এবং PKG-REF-DO এর একটি সংমিশ্রণ রয়েছে।
    • DeviceAppID-REF-DO ( C1 ) সার্টিফিকেটের SHA-1 (20 বাইট) অথবা SHA-256 (32 বাইট) স্বাক্ষর সংরক্ষণ করে।
    • PKG-REF-DO ( CA ) হল ম্যানিফেস্টে সংজ্ঞায়িত সম্পূর্ণ প্যাকেজ নামের স্ট্রিং, ASCII এনকোডেড, সর্বোচ্চ দৈর্ঘ্য ১২৭ বাইট।
  • AR-DO ( E3 ) কে PERM-AR-DO ( DB ) অন্তর্ভুক্ত করার জন্য প্রসারিত করা হয়েছে, যা একটি 8-বাইট বিট মাস্ক যা 64টি পৃথক অনুমতির প্রতিনিধিত্ব করে।

যদি PKG-REF-DO উপস্থিত না থাকে, তাহলে সার্টিফিকেট দ্বারা স্বাক্ষরিত যেকোনো অ্যাপকে অ্যাক্সেস দেওয়া হবে; অন্যথায় সার্টিফিকেট এবং প্যাকেজের নাম উভয়ই মিলতে হবে।

নিয়মের উদাহরণ

অ্যাপটির নাম com.google.android.apps.myapp এবং হেক্স স্ট্রিং-এ SHA-1 সার্টিফিকেট হল:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

হেক্স স্ট্রিং-এ UICC-এর নিয়ম হল:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

নিয়ম ফাইল সমর্থন অ্যাক্সেস করুন

অ্যান্ড্রয়েড ৭.০ অ্যাক্সেস রুল ফাইল (ARF) থেকে ক্যারিয়ার প্রিভিলেজ রুল পড়ার জন্য সমর্থন যোগ করে।

অ্যান্ড্রয়েড প্ল্যাটফর্ম প্রথমে অ্যাক্সেস রুল অ্যাপ্লিকেশন (ARA) AID A00000015141434C00 নির্বাচন করার চেষ্টা করে। যদি এটি UICC-তে AID খুঁজে না পায়, তাহলে এটি PKCS15 AID A000000063504B43532D3135 নির্বাচন করে ARF-এ ফিরে আসে। অ্যান্ড্রয়েড তারপর 0x4300 এ অ্যাক্সেস কন্ট্রোল রুলস ফাইল (ACRF) পড়ে এবং AID FFFFFFFFFFFF সহ এন্ট্রিগুলি অনুসন্ধান করে। বিভিন্ন AID সহ এন্ট্রিগুলি উপেক্ষা করা হয়, তাই অন্যান্য ব্যবহারের ক্ষেত্রে নিয়মগুলি সহাবস্থান করতে পারে।

হেক্স স্ট্রিং-এ ACRF কন্টেন্টের উদাহরণ:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

অ্যাক্সেস কন্ট্রোল কন্ডিশন ফাইল (ACCF) কন্টেন্টের উদাহরণ:

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

উপরের উদাহরণে, 0x4310 হল ACCF এর ঠিকানা, যেখানে সার্টিফিকেট হ্যাশ 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 । এই সার্টিফিকেট দ্বারা স্বাক্ষরিত অ্যাপগুলিকে ক্যারিয়ারের সুবিধা দেওয়া হয়।

সক্রিয় API গুলি

অ্যান্ড্রয়েড নিম্নলিখিত API গুলি সমর্থন করে।

টেলিফোনি ম্যানেজার

টেলিফোনিকলব্যাক

TelephonyCallback একটি কলব্যাক পদ্ধতির ইন্টারফেস রয়েছে যা নিবন্ধিত অবস্থা পরিবর্তন হলে কলিং অ্যাপকে অবহিত করে:

  • বার্তা অপেক্ষার সূচকটি পরিবর্তিত হয়েছে: onMessageWaitingIndicatorChanged
  • কল ফরওয়ার্ডিং সূচকটি পরিবর্তিত হয়েছে: onCallForwardingIndicatorChanged
  • কলের অবস্থা পরিবর্তিত হয়েছে: onCallStateChanged
  • আইপি মাল্টিমিডিয়া সিস্টেম (আইএমএস) কল সংযোগ বিচ্ছিন্ন করার কারণ পরিবর্তন করা হয়েছে: onImsCallDisconnectCauseChanged
  • টেলিফোনি ডিসপ্লের তথ্য পরিবর্তন করা হয়েছে: onDisplayInfoChanged
  • সঠিক ডেটা সংযোগের অবস্থা পরিবর্তিত হয়েছে: onPreciseDataConnectionStateChanged
  • বর্তমান জরুরি নম্বর তালিকা পরিবর্তন করা হয়েছে: onEmergencyNumberListChanged
  • সক্রিয় ডেটা সাবস্ক্রিপশন আইডি পরিবর্তন করা হয়েছে: onActiveDataSubscriptionIdChanged
  • ক্যারিয়ার নেটওয়ার্ক পরিবর্তন করা হয়েছে: onCarrierNetworkChange
  • নেটওয়ার্ক নিবন্ধন অথবা অবস্থান/রাউটিং/ট্র্যাকিং এরিয়া আপডেট ব্যর্থ হয়েছে: onRegistrationFailed
  • তথ্য বাদ দেওয়ার পরিবর্তন: onBarringInfoChanged
  • সেল তথ্য পরিবর্তন করা হয়েছে: onCellInfoChanged
  • বর্তমান ভৌত চ্যানেল কনফিগারেশন পরিবর্তিত হয়েছে: onPhysicalChannelConfigChanged

সাবস্ক্রিপশন ম্যানেজার

এসএমএস ম্যানেজার

  • কলারকে নতুন ইনকামিং এসএমএস বার্তা তৈরি করতে দেওয়ার পদ্ধতি: injectSmsPdu
  • SMS প্রদানকারীতে না লিখেই টেক্সট ভিত্তিক SMS বার্তা পাঠানোর পদ্ধতি: sendTextMessageWithoutPersisting

CarrierConfigManager সম্পর্কে

  • কনফিগারেশন পরিবর্তন করা হয়েছে তা জানানোর পদ্ধতি: notifyConfigChangedForSubId
  • ডিফল্ট সাবস্ক্রিপশনের জন্য ক্যারিয়ার কনফিগারেশন পাওয়ার পদ্ধতি: getConfig
  • নির্দিষ্ট সাবস্ক্রিপশনের জন্য ক্যারিয়ার কনফিগারেশন পাওয়ার পদ্ধতি: getConfigForSubId

নির্দেশাবলীর জন্য, ক্যারিয়ার কনফিগারেশন দেখুন।

নির্মাণ করুন

হার্ডওয়্যার সিরিয়াল নম্বর পাওয়ার পদ্ধতি, যদি পাওয়া যায়: getSerial

বাগরিপোর্ট ম্যানেজার

সংযোগ বাগ রিপোর্ট শুরু করার পদ্ধতি, যা বাগ রিপোর্টের একটি বিশেষ সংস্করণ যাতে কেবল সংযোগ সম্পর্কিত সমস্যাগুলি ডিবাগ করার তথ্য অন্তর্ভুক্ত থাকে: startConnectivityBugreport

নেটওয়ার্কস্ট্যাটসম্যানেজার

  • নেটওয়ার্ক ব্যবহারের সারাংশ জিজ্ঞাসা করার পদ্ধতি: querySummary
  • নেটওয়ার্ক ব্যবহারের ইতিহাস অনুসন্ধানের পদ্ধতি: queryDetails
  • নেটওয়ার্ক ব্যবহারের কলব্যাক নিবন্ধন বা নিবন্ধনমুক্ত করার পদ্ধতি:

ImsMmTelManager সম্পর্কে

ImsRcsManager সম্পর্কে

প্রোভিশনিং ম্যানেজার

EuiccManager সম্পর্কে

প্রদত্ত সাবস্ক্রিপশনে স্যুইচ (সক্রিয়) করার পদ্ধতি: switchToSubscription

ক্যারিয়ার মেসেজিং সার্ভিস

নতুন SMS এবং MMS পাঠানো বা গ্রহণ করার সময় সিস্টেম থেকে কল গ্রহণকারী পরিষেবা। এই ক্লাসটি প্রসারিত করতে, android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE অনুমতি ব্যবহার করে আপনার ম্যানিফেস্ট ফাইলে পরিষেবাটি ঘোষণা করুন এবং #SERVICE_INTERFACE অ্যাকশন সহ একটি ইন্টেন্ট ফিল্টার অন্তর্ভুক্ত করুন। পদ্ধতিগুলির মধ্যে রয়েছে:

  • ইনবাউন্ড এসএমএস বার্তা ফিল্টার করার পদ্ধতি: onFilterSms
  • ডিভাইস থেকে প্রেরিত টেক্সট এসএমএস বার্তা আটকানোর পদ্ধতি: onSendTextSms
  • ডিভাইস থেকে প্রেরিত বাইনারি এসএমএস বার্তা আটকানোর পদ্ধতি: onSendDataSms
  • ডিভাইস থেকে প্রেরিত দীর্ঘ এসএমএস বার্তা আটকানোর পদ্ধতি: onSendMultipartTextSms
  • ডিভাইস থেকে প্রেরিত MMS বার্তা আটকানোর পদ্ধতি: onSendMms
  • প্রাপ্ত MMS বার্তাগুলি ডাউনলোড করার পদ্ধতি: onDownloadMms

ক্যারিয়ার সার্ভিস

পরিষেবা যা সিস্টেমে ক্যারিয়ার-নির্দিষ্ট কার্যকারিতা প্রকাশ করে। এই শ্রেণীটি প্রসারিত করতে, android.Manifest.permission#BIND_CARRIER_SERVICES অনুমতি সহ অ্যাপ ম্যানিফেস্ট ফাইলে পরিষেবাটি ঘোষণা করুন এবং CARRIER_SERVICE_INTERFACE অ্যাকশন সহ একটি ইন্টেন্ট ফিল্টার অন্তর্ভুক্ত করুন। যদি পরিষেবাটির দীর্ঘস্থায়ী বাইন্ডিং থাকে, তাহলে পরিষেবার মেটাডেটাতে android.service.carrier.LONG_LIVED_BINDING true এ সেট করুন।

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

CarrierService পদ্ধতিগুলির মধ্যে রয়েছে:

  • ক্যারিয়ার নির্দিষ্ট কনফিগারেশনগুলিকে ওভাররাইড এবং সেট করতে: onLoadConfig
  • ক্যারিয়ার অ্যাপের মাধ্যমে ইচ্ছাকৃতভাবে আসন্ন ক্যারিয়ার নেটওয়ার্ক পরিবর্তন সম্পর্কে সিস্টেমকে অবহিত করতে: notifyCarrierNetworkChange

টেলিফোনি প্রদানকারী

টেলিফোনি ডাটাবেসে পরিবর্তন (সন্নিবেশ, মুছে ফেলা, আপডেট, কোয়েরি) করার জন্য কন্টেন্ট প্রদানকারী API। মান ক্ষেত্রগুলি Telephony.Carriers এ সংজ্ঞায়িত করা হয়েছে; আরও বিস্তারিত জানার জন্য, Telephony ক্লাস রেফারেন্স দেখুন।

ওয়াইফাই নেটওয়ার্ক পরামর্শ

WifiNetworkSuggestion অবজেক্ট তৈরি করার সময়, সাবস্ক্রিপশন আইডি বা সাবস্ক্রিপশন গ্রুপ সেট করতে নিম্নলিখিত পদ্ধতিগুলি ব্যবহার করুন:

  • সাবস্ক্রিপশন আইডি সেট করার পদ্ধতি: setSubscriptionId
  • সাবস্ক্রিপশন গ্রুপ সেট করার পদ্ধতি: setSubscriptionGroup

অ্যান্ড্রয়েড প্ল্যাটফর্ম

সনাক্ত করা UICC-তে, প্ল্যাটফর্মটি অভ্যন্তরীণ UICC অবজেক্ট তৈরি করে যার মধ্যে UICC-এর অংশ হিসেবে ক্যারিয়ার প্রিভিলেজ রুলস অন্তর্ভুক্ত থাকে। UiccCarrierPrivilegeRules.java নিয়ম লোড করে, UICC কার্ড থেকে পার্স করে এবং মেমোরিতে ক্যাশে করে। যখন একটি প্রিভিলেজ চেকের প্রয়োজন হয়, তখন UiccCarrierPrivilegeRules কলার সার্টিফিকেটকে তার নিজস্ব নিয়মের সাথে একের পর এক তুলনা করে। যদি UICC সরানো হয়, তাহলে UICC অবজেক্টের সাথে নিয়মগুলিও ধ্বংস হয়ে যায়।

বৈধতা

CtsCarrierApiTestCases.apk ব্যবহার করে কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) এর মাধ্যমে বাস্তবায়ন যাচাই করার জন্য, আপনার সঠিক UICC নিয়ম বা ARF সমর্থন সহ একটি ডেভেলপার UICC থাকতে হবে। আপনার পছন্দের সিম কার্ড বিক্রেতাকে এই বিভাগে বর্ণিত সঠিক ARF সহ একটি ডেভেলপার UICC প্রস্তুত করতে বলুন এবং পরীক্ষাগুলি চালানোর জন্য সেই UICC ব্যবহার করুন। CTS পরীক্ষায় উত্তীর্ণ হওয়ার জন্য UICC-এর সক্রিয় সেলুলার পরিষেবার প্রয়োজন হয় না।

UICC প্রস্তুত করুন

Android 11 এবং তার নিচের ভার্সনের জন্য, CtsCarrierApiTestCases.apk aosp-testkey দ্বারা স্বাক্ষরিত, যার হ্যাশ মান 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81

Android 12 থেকে শুরু করে, CtsCarrierApiTestCases.apk হল cts-uicc-2021-testkey দ্বারা স্বাক্ষরিত, হ্যাশ মান CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0

অ্যান্ড্রয়েড ১২-তে CTS ক্যারিয়ার API পরীক্ষা চালানোর জন্য, ডিভাইসটিকে তৃতীয় পক্ষের GSMA TS.48 টেস্ট প্রোফাইল স্পেসিফিকেশনের সর্বশেষ সংস্করণে উল্লেখিত প্রয়োজনীয়তা পূরণ করে CTS ক্যারিয়ার সুবিধা সহ একটি সিম ব্যবহার করতে হবে।

একই সিমটি অ্যান্ড্রয়েড ১২ এর আগের ভার্সনের জন্যও ব্যবহার করা যেতে পারে।

CTS সিম প্রোফাইল পরিবর্তন করুন

  1. যোগ করুন: অ্যাক্সেস রুল অ্যাপ মাস্টার (ARA-M) অথবা ARF-এ CTS ক্যারিয়ার সুবিধা। উভয় স্বাক্ষরই ক্যারিয়ার সুবিধার নিয়মে এনকোড করা আবশ্যক:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. তৈরি করুন: ADF USIM প্রাথমিক ফাইল (EFs) TS.48 তে উপস্থিত নেই এবং CTS এর জন্য প্রয়োজনীয়:
    1. EF_MBDN (6FC7), রেকর্ডের আকার: 28, রেকর্ড নম্বর: 4
      • কন্টেন্ট
        1. রেক১: ৫৬৬F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: এফএফ...এফএফ
    2. EF_EXT6 (6FC8), রেকর্ডের আকার: ১৩, রেকর্ড নম্বর: ১
      • কন্টেন্ট: 00FF…FF
        1. EF_MBI (6FC9), রেকর্ডের আকার: 4, রেকর্ড নম্বর: 1
      • বিষয়বস্তু: Rec1: 01010101
        1. EF_MWIS (6FCA), রেকর্ড আকার: 5, রেকর্ড নম্বর: 1
      • বিষয়বস্তু: 0000000000
  3. পরিবর্তন করুন: USIM পরিষেবা টেবিল: পরিষেবা n°47, n°48 সক্ষম করুন
    1. EF_UST (6F38)
      • বিষয়বস্তু: 9EFFBF1DFFFE0083410310010400406E01
  4. পরিবর্তন করুন: DF-5GS এবং DF-SAIP ফাইল
    1. ডিএফ-৫জিএস - EF_৫জিএস৩জিপিপিএলওসিআই (ইউএসআইএম/৫এফসি০/৪এফ০১)
      • বিষয়বস্তু: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. ডিএফ-৫জিএস - EF_৫জিএসএন৩জিপিপিএলওসিআই (ইউএসআইএম/৫এফসি০/৪এফ০২)
      • বিষয়বস্তু: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • বিষয়বস্তু: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • বিষয়বস্তু: A0020000FF…FF
  5. পরিবর্তন করুন: এই পদবী ধারণকারী সংশ্লিষ্ট EF-তে ক্যারিয়ার নামের স্ট্রিং Android CTS ব্যবহার করুন:
    1. EF_SPN (USIM/6F46)
      • কন্টেন্ট: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • কন্টেন্ট: Rec1 430B83413759FE4E934143EA14FF..FF

পরীক্ষার প্রোফাইল কাঠামোর সাথে মিল করুন

নিম্নলিখিত জেনেরিক টেস্ট প্রোফাইল স্ট্রাকচারের সর্বশেষ সংস্করণটি ডাউনলোড করে মেলান। এই প্রোফাইলগুলিতে CTS ক্যারিয়ার প্রিভিলেজ নিয়ম ব্যক্তিগতকৃত বা উপরে তালিকাভুক্ত অন্যান্য পরিবর্তন থাকবে না।

পরীক্ষা চালান

সুবিধার জন্য, CTS একটি ডিভাইস টোকেন সমর্থন করে যা শুধুমাত্র একই টোকেন দিয়ে কনফিগার করা ডিভাইসগুলিতে পরীক্ষা চালানোর জন্য সীমাবদ্ধ করে। ক্যারিয়ার API CTS পরীক্ষাগুলি ডিভাইস টোকেন sim-card-with-certs সমর্থন করে। উদাহরণস্বরূপ, নিম্নলিখিত ডিভাইস টোকেন ক্যারিয়ার API পরীক্ষাগুলিকে শুধুমাত্র ডিভাইস abcd1234 তে চালানোর জন্য সীমাবদ্ধ করে:

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

ডিভাইস টোকেন ব্যবহার না করে পরীক্ষা চালানোর সময়, পরীক্ষাটি সমস্ত ডিভাইসে চলে।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

UICC-তে সার্টিফিকেট কিভাবে আপডেট করা যেতে পারে?

A: বিদ্যমান কার্ড OTA আপডেট প্রক্রিয়া ব্যবহার করুন।

UICC কি অন্যান্য নিয়মের সাথে সহাবস্থান করতে পারে?

উত্তর: একই AID-এর অধীনে UICC-তে অন্যান্য নিরাপত্তা নিয়ম থাকা ঠিক আছে; প্ল্যাটফর্মটি স্বয়ংক্রিয়ভাবে সেগুলি ফিল্টার করে।

সার্টিফিকেটের উপর নির্ভর করে এমন একটি অ্যাপের জন্য UICC সরিয়ে ফেলা হলে কী হবে?

উত্তর: UICC অপসারণের সময় UICC-এর সাথে সম্পর্কিত নিয়মগুলি নষ্ট হয়ে যাওয়ার কারণে অ্যাপটি তার বিশেষাধিকার হারায়।

UICC-তে সার্টিফিকেটের সংখ্যার কি কোন সীমা আছে?

উত্তর: প্ল্যাটফর্মটি সার্টিফিকেটের সংখ্যা সীমাবদ্ধ করে না; কিন্তু যেহেতু চেকটি রৈখিক, তাই অনেক নিয়মের কারণে চেকের জন্য বিলম্ব হতে পারে।

এই পদ্ধতিতে আমরা কতগুলি API সমর্থন করতে পারি তার কি কোনও সীমা আছে?

উত্তর: না, কিন্তু আমরা সুযোগটি ক্যারিয়ার-সম্পর্কিত API-এর মধ্যে সীমাবদ্ধ রাখি।

এই পদ্ধতি ব্যবহার করা কি নিষিদ্ধ কিছু API আছে? যদি তাই হয়, তাহলে আপনি কীভাবে সেগুলি প্রয়োগ করবেন? (অর্থাৎ, এই পদ্ধতিতে কোন APIগুলি সমর্থিত তা যাচাই করার জন্য আপনার কি পরীক্ষা আছে?)

উত্তর: অ্যান্ড্রয়েড কম্প্যাটিবিলিটি ডেফিনিশন ডকুমেন্ট (CDD) এর API আচরণগত সামঞ্জস্য বিভাগটি দেখুন। API গুলির অনুমতি মডেল পরিবর্তন না করা হয়েছে তা নিশ্চিত করার জন্য আমাদের কিছু CTS পরীক্ষা রয়েছে।

মাল্টি-সিম বৈশিষ্ট্যের সাথে এটি কীভাবে কাজ করে?

A: ব্যবহারকারীর দ্বারা নির্দিষ্ট করা ডিফল্ট সিমটি ব্যবহার করা হয়।

এটি কি কোনওভাবেই অন্যান্য SE অ্যাক্সেস প্রযুক্তির সাথে ইন্টারঅ্যাক্ট করে বা ওভারল্যাপ করে, উদাহরণস্বরূপ, SEEK?

উ: উদাহরণস্বরূপ, SEEK UICC-তে ব্যবহৃত একই AID ব্যবহার করে। তাই নিয়মগুলি সহাবস্থান করে এবং SEEK অথবা UiccCarrierPrivileges দ্বারা ফিল্টার করা হয়।

ক্যারিয়ারের সুবিধাগুলি পরীক্ষা করার জন্য কখন উপযুক্ত সময়?

A: সিম স্ট্যাটাস লোড হওয়ার পর সম্প্রচার।

OEM কি ক্যারিয়ার API-এর কিছু অংশ অক্ষম করতে পারে?

উ: না। আমরা বিশ্বাস করি যে বর্তমান API গুলি হল ন্যূনতম সেট, এবং ভবিষ্যতে আরও সূক্ষ্ম গ্র্যানুলারিটি নিয়ন্ত্রণের জন্য আমরা বিট মাস্ক ব্যবহার করার পরিকল্পনা করছি।

setOperatorBrandOverride কি অন্য সকল ধরণের অপারেটর নামের স্ট্রিংকে ওভাররাইড করে? উদাহরণস্বরূপ, SE13, UICC SPN, অথবা নেটওয়ার্ক-ভিত্তিক NITZ?

হ্যাঁ, অপারেটর ব্র্যান্ড ওভাররাইডের অগ্রাধিকার সর্বোচ্চ। যখন এটি সেট করা হয়, তখন এটি অপারেটর নামের অন্যান্য সমস্ত স্ট্রিংকে ওভাররাইড করে।

injectSmsPdu পদ্ধতি কল কী করে?

উত্তর: এই পদ্ধতিটি ক্লাউডে SMS ব্যাকআপ/পুনরুদ্ধার সহজতর করে। injectSmsPdu কলটি পুনরুদ্ধার ফাংশন সক্ষম করে।

এসএমএস ফিল্টারিংয়ের ক্ষেত্রে, onFilterSms কল কি এসএমএস ইউডিএইচ পোর্ট ফিল্টারিংয়ের উপর ভিত্তি করে? নাকি ক্যারিয়ার অ্যাপগুলির সমস্ত ইনকামিং এসএমএসে অ্যাক্সেস আছে?

উত্তর: ক্যারিয়ারগুলির সমস্ত এসএমএস ডেটা অ্যাক্সেস আছে।

DeviceAppID-REF-DO এর ৩২ বাইট সাপোর্ট করার এক্সটেনশনটি বর্তমান GP স্পেকের সাথে (যা শুধুমাত্র ০ বা ২০ বাইট সমর্থন করে) বেমানান বলে মনে হচ্ছে, তাহলে আপনি কেন এই পরিবর্তনটি প্রবর্তন করছেন? সংঘর্ষ এড়াতে SHA-1 কি যথেষ্ট নয়? আপনি কি ইতিমধ্যেই GP-তে এই পরিবর্তনটি প্রস্তাব করেছেন, কারণ এটি বিদ্যমান ARA-M/ARF-এর সাথে পিছনের দিকে বেমানান হতে পারে?

উত্তর: ভবিষ্যৎ-প্রমাণ নিরাপত্তা প্রদানের জন্য, এই এক্সটেনশনটি SHA-1 ছাড়াও DeviceAppID-REF-DO জন্য SHA-256 প্রবর্তন করে, যা বর্তমানে GP SEAC স্ট্যান্ডার্ডে একমাত্র বিকল্প। আমরা SHA-256 ব্যবহার করার জন্য দৃঢ়ভাবে সুপারিশ করছি।

যদি DeviceAppID 0 (খালি) হয়, তাহলে আপনি কি নির্দিষ্ট নিয়মের আওতাভুক্ত নয় এমন সমস্ত ডিভাইস অ্যাপের ক্ষেত্রে নিয়মটি প্রয়োগ করবেন?

উত্তর: ক্যারিয়ার API-এর জন্য DeviceAppID-REF-DO পূরণ করা প্রয়োজন। খালি থাকা পরীক্ষার উদ্দেশ্যে করা হয় এবং অপারেশনাল স্থাপনার জন্য সুপারিশ করা হয় না।

আপনার স্পেসিফিকেশন অনুসারে, DeviceAppID-REF-DO PKG-REF-DO শুধুমাত্র নিজে থেকেই ব্যবহৃত হওয়া উচিত নয়। কিন্তু স্পেসিফিকেশনের সারণী 6-4-এ এটি এখনও REF-DO এর সংজ্ঞা প্রসারিত করে বলে বর্ণনা করা হয়েছে। এটি কি ইচ্ছাকৃত? REF-DO তে শুধুমাত্র PKG-REF-DO DO ব্যবহার করা হলে কোডটি কীভাবে আচরণ করে?

A: REF-DO PKG-REF-DO একক মান আইটেম হিসেবে রাখার বিকল্পটি সর্বশেষ সংস্করণে সরিয়ে দেওয়া হয়েছে। PKG-REF-DO শুধুমাত্র DeviceAppID-REF-DO সাথে একত্রে ব্যবহার করা উচিত।

আমরা ধরে নিচ্ছি যে আমরা সমস্ত ক্যারিয়ার-ভিত্তিক অনুমতিগুলিতে অ্যাক্সেস দিতে পারি অথবা আরও সূক্ষ্ম নিয়ন্ত্রণ রাখতে পারি। যদি তাই হয়, তাহলে বিট মাস্ক এবং প্রকৃত অনুমতিগুলির মধ্যে ম্যাপিং কী নির্ধারণ করে? প্রতি ক্লাসে একটি অনুমতি? প্রতি পদ্ধতিতে একটি অনুমতি? দীর্ঘমেয়াদে কি 64টি পৃথক অনুমতি যথেষ্ট?

উত্তর: এটি ভবিষ্যতের জন্য সংরক্ষিত, এবং আমরা পরামর্শ স্বাগত জানাই।

আপনি কি Android এর জন্য DeviceAppID আরও নির্দিষ্টভাবে সংজ্ঞায়িত করতে পারেন? এটি হল SHA-1 (20 বাইট) হ্যাশ মান যা প্রকাশক সার্টিফিকেটটি প্রদত্ত অ্যাপটিতে স্বাক্ষর করার জন্য ব্যবহৃত হয়, তাই নামটি কি সেই উদ্দেশ্য প্রতিফলিত করে না? (নামটি অনেক পাঠকের কাছে বিভ্রান্তিকর হতে পারে কারণ নিয়মটি তখন একই প্রকাশক সার্টিফিকেট দিয়ে স্বাক্ষরিত সমস্ত অ্যাপের ক্ষেত্রে প্রযোজ্য।)

উত্তর: DeviceAppID সার্টিফিকেট সংরক্ষণের ক্ষেত্রে বিদ্যমান স্পেক ব্যবহার করা হয়। আমরা স্পেক পরিবর্তন কমিয়ে আনার চেষ্টা করেছি যাতে গ্রহণের ক্ষেত্রে বাধা কম হয়। বিস্তারিত জানার জন্য, UICC-এর নিয়মাবলী দেখুন।

,

অ্যান্ড্রয়েড ৫.১ ইউনিভার্সাল ইন্টিগ্রেটেড সার্কিট কার্ড (UICC) অ্যাপের মালিকদের জন্য প্রাসঙ্গিক API গুলির জন্য বিশেষ সুবিধা প্রদানের একটি ব্যবস্থা চালু করেছে। অ্যান্ড্রয়েড প্ল্যাটফর্মটি UICC-তে সংরক্ষিত সার্টিফিকেট লোড করে এবং এই সার্টিফিকেট দ্বারা স্বাক্ষরিত অ্যাপগুলিকে মুষ্টিমেয় বিশেষ API গুলিতে কল করার অনুমতি দেয়।

অ্যান্ড্রয়েড ৭.০ এই বৈশিষ্ট্যটি UICC ক্যারিয়ার প্রিভিলেজ নিয়মের জন্য অন্যান্য স্টোরেজ উৎসগুলিকে সমর্থন করার জন্য প্রসারিত করেছে, যার ফলে API ব্যবহার করতে পারে এমন ক্যারিয়ারের সংখ্যা নাটকীয়ভাবে বৃদ্ধি পেয়েছে। API রেফারেন্সের জন্য, CarrierConfigManager দেখুন; নির্দেশাবলীর জন্য, Carrier Configuration দেখুন।

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

UICC-এর নিয়মাবলী

UICC-তে স্টোরেজটি GlobalPlatform Secure Element Access Control স্পেসিফিকেশনের সাথে সামঞ্জস্যপূর্ণ। কার্ডে অ্যাপ আইডেন্টিফায়ার (AID) হল A00000015141434C00 , এবং কার্ডে সংরক্ষিত নিয়মগুলি আনতে স্ট্যান্ডার্ড GET DATA কমান্ড ব্যবহার করা হয়। আপনি কার্ড ওভার-দ্য-এয়ার (OTA) আপডেটের মাধ্যমে এই নিয়মগুলি আপডেট করতে পারেন।

ডেটা শ্রেণিবিন্যাস

UICC নিয়মগুলি নিম্নলিখিত ডেটা শ্রেণিবিন্যাস ব্যবহার করে (বন্ধনীতে থাকা দুই-অক্ষরের অক্ষর এবং সংখ্যার সংমিশ্রণ হল অবজেক্ট ট্যাগ)। প্রতিটি নিয়ম হল REF-AR-DO ( E2 ) এবং এতে REF-DO এবং AR-DO এর সংমিশ্রণ থাকে:

  • REF-DO ( E1 ) তে DeviceAppID-REF-DO অথবা DeviceAppID-REF-DO এবং PKG-REF-DO এর একটি সংমিশ্রণ রয়েছে।
    • DeviceAppID-REF-DO ( C1 ) সার্টিফিকেটের SHA-1 (20 বাইট) অথবা SHA-256 (32 বাইট) স্বাক্ষর সংরক্ষণ করে।
    • PKG-REF-DO ( CA ) হল ম্যানিফেস্টে সংজ্ঞায়িত সম্পূর্ণ প্যাকেজ নামের স্ট্রিং, ASCII এনকোডেড, সর্বোচ্চ দৈর্ঘ্য ১২৭ বাইট।
  • AR-DO ( E3 ) কে PERM-AR-DO ( DB ) অন্তর্ভুক্ত করার জন্য প্রসারিত করা হয়েছে, যা একটি 8-বাইট বিট মাস্ক যা 64টি পৃথক অনুমতির প্রতিনিধিত্ব করে।

যদি PKG-REF-DO উপস্থিত না থাকে, তাহলে সার্টিফিকেট দ্বারা স্বাক্ষরিত যেকোনো অ্যাপকে অ্যাক্সেস দেওয়া হবে; অন্যথায় সার্টিফিকেট এবং প্যাকেজের নাম উভয়ই মিলতে হবে।

নিয়মের উদাহরণ

অ্যাপটির নাম com.google.android.apps.myapp এবং হেক্স স্ট্রিং-এ SHA-1 সার্টিফিকেট হল:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

হেক্স স্ট্রিং-এ UICC-এর নিয়ম হল:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

নিয়ম ফাইল সমর্থন অ্যাক্সেস করুন

অ্যান্ড্রয়েড ৭.০ অ্যাক্সেস রুল ফাইল (ARF) থেকে ক্যারিয়ার প্রিভিলেজ রুল পড়ার জন্য সমর্থন যোগ করে।

অ্যান্ড্রয়েড প্ল্যাটফর্ম প্রথমে অ্যাক্সেস রুল অ্যাপ্লিকেশন (ARA) AID A00000015141434C00 নির্বাচন করার চেষ্টা করে। যদি এটি UICC-তে AID খুঁজে না পায়, তাহলে এটি PKCS15 AID A000000063504B43532D3135 নির্বাচন করে ARF-এ ফিরে আসে। অ্যান্ড্রয়েড তারপর 0x4300 এ অ্যাক্সেস কন্ট্রোল রুলস ফাইল (ACRF) পড়ে এবং AID FFFFFFFFFFFF সহ এন্ট্রিগুলি অনুসন্ধান করে। বিভিন্ন AID সহ এন্ট্রিগুলি উপেক্ষা করা হয়, তাই অন্যান্য ব্যবহারের ক্ষেত্রে নিয়মগুলি সহাবস্থান করতে পারে।

হেক্স স্ট্রিং-এ ACRF কন্টেন্টের উদাহরণ:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

অ্যাক্সেস কন্ট্রোল কন্ডিশন ফাইল (ACCF) কন্টেন্টের উদাহরণ:

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

উপরের উদাহরণে, 0x4310 হল ACCF এর ঠিকানা, যেখানে সার্টিফিকেট হ্যাশ 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 । এই সার্টিফিকেট দ্বারা স্বাক্ষরিত অ্যাপগুলিকে ক্যারিয়ারের সুবিধা দেওয়া হয়।

সক্রিয় API গুলি

অ্যান্ড্রয়েড নিম্নলিখিত API গুলি সমর্থন করে।

টেলিফোনি ম্যানেজার

টেলিফোনিকলব্যাক

TelephonyCallback একটি কলব্যাক পদ্ধতির ইন্টারফেস রয়েছে যা নিবন্ধিত অবস্থা পরিবর্তন হলে কলিং অ্যাপকে অবহিত করে:

  • বার্তা অপেক্ষার সূচকটি পরিবর্তিত হয়েছে: onMessageWaitingIndicatorChanged
  • কল ফরওয়ার্ডিং সূচকটি পরিবর্তিত হয়েছে: onCallForwardingIndicatorChanged
  • কলের অবস্থা পরিবর্তিত হয়েছে: onCallStateChanged
  • আইপি মাল্টিমিডিয়া সিস্টেম (আইএমএস) কল সংযোগ বিচ্ছিন্ন করার কারণ পরিবর্তন করা হয়েছে: onImsCallDisconnectCauseChanged
  • টেলিফোনি ডিসপ্লের তথ্য পরিবর্তন করা হয়েছে: onDisplayInfoChanged
  • সঠিক ডেটা সংযোগের অবস্থা পরিবর্তিত হয়েছে: onPreciseDataConnectionStateChanged
  • বর্তমান জরুরি নম্বর তালিকা পরিবর্তন করা হয়েছে: onEmergencyNumberListChanged
  • সক্রিয় ডেটা সাবস্ক্রিপশন আইডি পরিবর্তন করা হয়েছে: onActiveDataSubscriptionIdChanged
  • ক্যারিয়ার নেটওয়ার্ক পরিবর্তন করা হয়েছে: onCarrierNetworkChange
  • নেটওয়ার্ক নিবন্ধন অথবা অবস্থান/রাউটিং/ট্র্যাকিং এরিয়া আপডেট ব্যর্থ হয়েছে: onRegistrationFailed
  • তথ্য বাদ দেওয়ার পরিবর্তন: onBarringInfoChanged
  • সেল তথ্য পরিবর্তন করা হয়েছে: onCellInfoChanged
  • বর্তমান ভৌত চ্যানেল কনফিগারেশন পরিবর্তিত হয়েছে: onPhysicalChannelConfigChanged

সাবস্ক্রিপশন ম্যানেজার

এসএমএস ম্যানেজার

  • কলারকে নতুন ইনকামিং এসএমএস বার্তা তৈরি করতে দেওয়ার পদ্ধতি: injectSmsPdu
  • SMS প্রদানকারীতে না লিখেই টেক্সট ভিত্তিক SMS বার্তা পাঠানোর পদ্ধতি: sendTextMessageWithoutPersisting

CarrierConfigManager সম্পর্কে

  • কনফিগারেশন পরিবর্তন করা হয়েছে তা জানানোর পদ্ধতি: notifyConfigChangedForSubId
  • ডিফল্ট সাবস্ক্রিপশনের জন্য ক্যারিয়ার কনফিগারেশন পাওয়ার পদ্ধতি: getConfig
  • নির্দিষ্ট সাবস্ক্রিপশনের জন্য ক্যারিয়ার কনফিগারেশন পাওয়ার পদ্ধতি: getConfigForSubId

নির্দেশাবলীর জন্য, ক্যারিয়ার কনফিগারেশন দেখুন।

নির্মাণ করুন

হার্ডওয়্যার সিরিয়াল নম্বর পাওয়ার পদ্ধতি, যদি পাওয়া যায়: getSerial

বাগরিপোর্ট ম্যানেজার

সংযোগ বাগ রিপোর্ট শুরু করার পদ্ধতি, যা বাগ রিপোর্টের একটি বিশেষ সংস্করণ যাতে কেবল সংযোগ সম্পর্কিত সমস্যাগুলি ডিবাগ করার তথ্য অন্তর্ভুক্ত থাকে: startConnectivityBugreport

নেটওয়ার্কস্ট্যাটসম্যানেজার

  • নেটওয়ার্ক ব্যবহারের সারাংশ জিজ্ঞাসা করার পদ্ধতি: querySummary
  • নেটওয়ার্ক ব্যবহারের ইতিহাস অনুসন্ধানের পদ্ধতি: queryDetails
  • নেটওয়ার্ক ব্যবহারের কলব্যাক নিবন্ধন বা নিবন্ধনমুক্ত করার পদ্ধতি:

ImsMmTelManager সম্পর্কে

ImsRcsManager সম্পর্কে

প্রোভিশনিং ম্যানেজার

EuiccManager সম্পর্কে

প্রদত্ত সাবস্ক্রিপশনে স্যুইচ (সক্রিয়) করার পদ্ধতি: switchToSubscription

ক্যারিয়ার মেসেজিং সার্ভিস

নতুন SMS এবং MMS পাঠানো বা গ্রহণ করার সময় সিস্টেম থেকে কল গ্রহণকারী পরিষেবা। এই ক্লাসটি প্রসারিত করতে, android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE অনুমতি ব্যবহার করে আপনার ম্যানিফেস্ট ফাইলে পরিষেবাটি ঘোষণা করুন এবং #SERVICE_INTERFACE অ্যাকশন সহ একটি ইন্টেন্ট ফিল্টার অন্তর্ভুক্ত করুন। পদ্ধতিগুলির মধ্যে রয়েছে:

  • ইনবাউন্ড এসএমএস বার্তা ফিল্টার করার পদ্ধতি: onFilterSms
  • ডিভাইস থেকে প্রেরিত টেক্সট এসএমএস বার্তা আটকানোর পদ্ধতি: onSendTextSms
  • ডিভাইস থেকে প্রেরিত বাইনারি এসএমএস বার্তা আটকানোর পদ্ধতি: onSendDataSms
  • ডিভাইস থেকে প্রেরিত দীর্ঘ এসএমএস বার্তা আটকানোর পদ্ধতি: onSendMultipartTextSms
  • ডিভাইস থেকে প্রেরিত MMS বার্তা আটকানোর পদ্ধতি: onSendMms
  • প্রাপ্ত MMS বার্তাগুলি ডাউনলোড করার পদ্ধতি: onDownloadMms

ক্যারিয়ার সার্ভিস

পরিষেবা যা সিস্টেমে ক্যারিয়ার-নির্দিষ্ট কার্যকারিতা প্রকাশ করে। এই শ্রেণীটি প্রসারিত করতে, android.Manifest.permission#BIND_CARRIER_SERVICES অনুমতি সহ অ্যাপ ম্যানিফেস্ট ফাইলে পরিষেবাটি ঘোষণা করুন এবং CARRIER_SERVICE_INTERFACE অ্যাকশন সহ একটি ইন্টেন্ট ফিল্টার অন্তর্ভুক্ত করুন। যদি পরিষেবাটির দীর্ঘস্থায়ী বাইন্ডিং থাকে, তাহলে পরিষেবার মেটাডেটাতে android.service.carrier.LONG_LIVED_BINDING কে true এ সেট করুন।

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

CarrierService পদ্ধতিগুলির মধ্যে রয়েছে:

  • ক্যারিয়ার নির্দিষ্ট কনফিগারেশনগুলিকে ওভাররাইড এবং সেট করতে: onLoadConfig
  • ক্যারিয়ার অ্যাপের মাধ্যমে ইচ্ছাকৃতভাবে আসন্ন ক্যারিয়ার নেটওয়ার্ক পরিবর্তন সম্পর্কে সিস্টেমকে অবহিত করতে: notifyCarrierNetworkChange

টেলিফোনি প্রদানকারী

টেলিফোনি ডাটাবেসে পরিবর্তন (সন্নিবেশ, মুছে ফেলা, আপডেট, কোয়েরি) করার জন্য কন্টেন্ট প্রদানকারী API। মান ক্ষেত্রগুলি Telephony.Carriers এ সংজ্ঞায়িত করা হয়েছে; আরও বিস্তারিত জানার জন্য, Telephony ক্লাস রেফারেন্স দেখুন।

ওয়াইফাই নেটওয়ার্ক পরামর্শ

WifiNetworkSuggestion অবজেক্ট তৈরি করার সময়, সাবস্ক্রিপশন আইডি বা সাবস্ক্রিপশন গ্রুপ সেট করতে নিম্নলিখিত পদ্ধতিগুলি ব্যবহার করুন:

  • সাবস্ক্রিপশন আইডি সেট করার পদ্ধতি: setSubscriptionId
  • সাবস্ক্রিপশন গ্রুপ সেট করার পদ্ধতি: setSubscriptionGroup

অ্যান্ড্রয়েড প্ল্যাটফর্ম

সনাক্ত করা UICC-তে, প্ল্যাটফর্মটি অভ্যন্তরীণ UICC অবজেক্ট তৈরি করে যার মধ্যে UICC-এর অংশ হিসেবে ক্যারিয়ার প্রিভিলেজ রুলস অন্তর্ভুক্ত থাকে। UiccCarrierPrivilegeRules.java নিয়ম লোড করে, UICC কার্ড থেকে পার্স করে এবং মেমোরিতে ক্যাশে করে। যখন একটি প্রিভিলেজ চেকের প্রয়োজন হয়, তখন UiccCarrierPrivilegeRules কলার সার্টিফিকেটকে তার নিজস্ব নিয়মের সাথে একের পর এক তুলনা করে। যদি UICC সরানো হয়, তাহলে UICC অবজেক্টের সাথে নিয়মগুলিও ধ্বংস হয়ে যায়।

বৈধতা

CtsCarrierApiTestCases.apk ব্যবহার করে কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) এর মাধ্যমে বাস্তবায়ন যাচাই করার জন্য, আপনার সঠিক UICC নিয়ম বা ARF সমর্থন সহ একটি ডেভেলপার UICC থাকতে হবে। আপনার পছন্দের সিম কার্ড বিক্রেতাকে এই বিভাগে বর্ণিত সঠিক ARF সহ একটি ডেভেলপার UICC প্রস্তুত করতে বলুন এবং পরীক্ষাগুলি চালানোর জন্য সেই UICC ব্যবহার করুন। CTS পরীক্ষায় উত্তীর্ণ হওয়ার জন্য UICC-এর সক্রিয় সেলুলার পরিষেবার প্রয়োজন হয় না।

UICC প্রস্তুত করুন

For Android 11 and lower, CtsCarrierApiTestCases.apk is signed by aosp-testkey , with hash value 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Starting in Android 12, CtsCarrierApiTestCases.apk is signed by cts-uicc-2021-testkey , hash value CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0 .

To run CTS carrier API tests in Android 12, the device needs to use a SIM with CTS carrier privileges meeting the requirements specified in the latest version of the third-party GSMA TS.48 Test Profile specification.

The same SIM can also be used for versions prior to Android 12.

Modify the CTS SIM profile

  1. Add: CTS carrier privileges in access rule app master (ARA-M) or ARF. Both signatures must be encoded in the carrier privilege rules:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. Create: ADF USIM elementary files (EFs) not present in TS.48 and needed for CTS:
    1. EF_MBDN (6FC7), record size: 28, record number: 4
      • কন্টেন্ট
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), record size:13, record number: 1
      • Content: 00FF…FF
        1. EF_MBI (6FC9), record size: 4, record number: 1
      • Content: Rec1: 01010101
        1. EF_MWIS (6FCA), record size: 5, record number: 1
      • Content: 0000000000
  3. Modify: USIM service table: Enable services n°47, n°48
    1. EF_UST (6F38)
      • Content: 9EFFBF1DFFFE0083410310010400406E01
  4. Modify: DF-5GS and DF-SAIP files
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Content: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Content: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Content: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Content: A0020000FF…FF
  5. Modify: Use the carrier name string Android CTS in respective EFs containing this designation:
    1. EF_SPN (USIM/6F46)
      • Content: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Content: Rec1 430B83413759FE4E934143EA14FF..FF

Match the test profile structure

Download and match the latest version of the following generic test profile structures. These profiles won't have the CTS Carrier Privilege rule personalized or other modifications listed above.

Run tests

For convenience, CTS supports a device token that restricts tests to run only on devices configured with the same token. Carrier API CTS tests support the device token sim-card-with-certs . For example, the following device token restricts carrier API tests to run only on device abcd1234 :

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

When running a test without using a device token, the test runs on all devices.

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

How can certificates be updated on the UICC?

A: Use the existing card OTA update mechanism.

Can UICC coexist with other rules?

A: It's fine to have other security rules on the UICC under the same AID; the platform filters them out automatically.

What happens when the UICC is removed for an app that relies on the certificates on it?

A: The app loses its privileges because the rules associated with the UICC are destroyed on UICC removal.

Is there a limit on the number of certificates on the UICC?

A: The platform doesn't limit the number of certificates; but because the check is linear, too many rules may incur a latency for check.

Is there a limit to the number of APIs that we can support with this method?

A: No, but we limit the scope to carrier-related APIs.

Are there some APIs prohibited from using this method? If so, how do you enforce them? (that is, do you have tests to validate which APIs are supported with this method?)

A: See the API Behavioral Compatibility section of the Android Compatibility Definition Document (CDD). We have some CTS tests to make sure that the permission model of the APIs isn't changed.

How does this work with the multi-SIM feature?

A: The default SIM specified by the user is used.

Does this in any way interact or overlap with other SE access technologies, for example, SEEK?

A: As an example, SEEK uses the same AID as on the UICC. So the rules coexist and are filtered by either SEEK or UiccCarrierPrivileges .

When is it a good time to check carrier privileges?

A: After the SIM state loaded broadcast.

Can OEMs disable part of carrier APIs?

A: No. We believe that the current APIs are the minimal set, and we plan to use the bit mask for finer granularity control in the future.

Does setOperatorBrandOverride override ALL other forms of operator name strings? For example, SE13, UICC SPN, or network-based NITZ?

Yes, the operator brand override has the highest priority. When it's set, it overrides ALL other forms of operator name strings.

What does the injectSmsPdu method call do?

A: This method facilitates SMS backup/restore in the cloud. The injectSmsPdu call enables the restore function.

For SMS filtering, is the onFilterSms call based on SMS UDH port filtering? Or do carrier apps have access to ALL incoming SMS?

A: Carriers have access to all SMS data.

The extension of DeviceAppID-REF-DO to support 32 bytes appears to be incompatible with the current GP spec (which allows 0 or 20 bytes only), so why are you introducing this change? Isn't SHA-1 sufficient to avoid collisions? Have you proposed this change to GP already, as this could be backward incompatible with existing ARA-M/ARF?

A: For providing future-proof security, this extension introduces SHA-256 for DeviceAppID-REF-DO in addition to SHA-1, which is currently the only option in the GP SEAC standard. We highly recommend using SHA-256.

If DeviceAppID is 0 (empty), do you apply the rule to all device apps not covered by a specific rule?

A: Carrier APIs require DeviceAppID-REF-DO be populated. Being empty is intended for test purposes and isn't recommended for operational deployments.

According to your spec, PKG-REF-DO used just by itself, without DeviceAppID-REF-DO , shouldn't be accepted. But it's still described in Table 6-4 of the specification as extending the definition of REF-DO . Is this on purpose? How does the code behave when only PKG-REF-DO is used in REF-DO ?

A: The option of having PKG-REF-DO as a single value item in REF-DO was removed in the latest version. PKG-REF-DO should occur only in combination with DeviceAppID-REF-DO .

We assume that we can grant access to all carrier-based permissions or have finer-grained control. If so, what defines the mapping between the bit mask and the actual permissions? One permission per class? One permission per method? Are 64 separate permissions enough in the long run?

A: This is reserved for the future, and we welcome suggestions.

Can you further define DeviceAppID for Android specifically? This is the SHA-1 (20 bytes) hash value of the Publisher certificate used to sign the given app, so shouldn't the name reflect that purpose? (The name could be confusing to many readers as the rule is then applicable to all apps signed with that same Publisher certificate.)

A: The DeviceAppID storing certificates is supported by the existing spec. We tried to minimize spec changes to lower the barrier for adoption. For details, see Rules on UICC .