UICC পরিষেবা প্রদানকারীর বিশেষ সুবিধা

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

Android 7.0 এই ফিচারটিকে আরও উন্নত করেছে যাতে UICC ক্যারিয়ার প্রিভিলেজ নিয়মের জন্য অন্যান্য স্টোরেজ সোর্স কাজ করে। এর ফলে API ব্যবহার করতে পারে এমন ক্যারিয়ারের সংখ্যা নাটকীয়ভাবে বৃদ্ধি পায়। API রেফারেন্সের জন্য, CarrierConfigManager দেখুন; নির্দেশাবলীর জন্য, ক্যারিয়ার কনফিগারেশন দেখুন।

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

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 (২০ বাইট) বা SHA-256 (৩২ বাইট) স্বাক্ষর সেভ করে।
    • PKG-REF-DO (CA) হল ম্যানিফেস্টে উল্লেখ করা সম্পূর্ণ প্যাকেজের নামের স্ট্রিং, ASCII এনকোড করা, সর্বাধিক দৈর্ঘ্য ১২৭ বাইট।
  • AR-DO (E3) বাড়িয়ে PERM-AR-DO (DB) করা হয়েছে, যা হল ৮-বাইট বিট মাস্ক এবং এটি ৬৪টি আলাদা আলাদা অনুমতিকে দেখায়।

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

অ্যাক্সেস রুল ফাইল সাপোর্ট

Android 7.0-এ অ্যাক্সেস রুল ফাইল (ARF) থেকে ক্যারিয়ার প্রিভিলেজ রুল পড়ার সুবিধা যোগ করা হয়েছে।

Android প্ল্যাটফর্ম প্রথমে অ্যাক্সেস রুল অ্যাপ্লিকেশন (ARA) AID A00000015141434C00 বেছে নেওয়ার চেষ্টা করে। UICC-তে AID খুঁজে না পেলে, এটি PKCS15 AID বেছে নিয়ে ARF-এ ফিরে যায় A000000063504B43532D3135। Android তারপর 0x4300-এ অ্যাক্সেস কন্ট্রোল রুল ফাইল (ACRF) পড়ে এবং FFFFFFFFFFFF AID-এর সাথে এন্ট্রি খোঁজে। অন্য 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

Android-এ নিম্নলিখিত API কাজ করে।

TelephonyManager

TelephonyCallback

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

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

SubscriptionManager

SmsManager

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

CarrierConfigManager

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

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

বিল্ড

হার্ডওয়্যার সিরিয়াল নম্বর উপলভ্য থাকলে তা পাওয়ার পদ্ধতি: getSerial

BugreportManager

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

NetworkStatsManager

  • নেটওয়ার্ক ব্যবহারের সারসংক্ষেপ কোয়েরি করার পদ্ধতি: querySummary
  • নেটওয়ার্ক ব্যবহারের ইতিহাস কোয়েরি করার পদ্ধতি: queryDetails
  • নেটওয়ার্ক ব্যবহারের কলব্যাক রেজিস্টার বা আনরেজিস্টার করার পদ্ধতি:

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

উল্লেখ করা সাবস্ক্রিপশনে পরিবর্তন (চালু) করার পদ্ধতি: switchToSubscription

CarrierMessagingService

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

  • ইনবাউন্ড এসএমএস মেসেজ ফিল্টার করার পদ্ধতি: onFilterSms
  • ডিভাইস থেকে পাঠানো টেক্সট এসএমএস মেসেজ ইন্টারসেপ্ট করার পদ্ধতি: onSendTextSms
  • ডিভাইস থেকে পাঠানো বাইনারি এসএমএস মেসেজ ইন্টারসেপ্ট করার পদ্ধতি: onSendDataSms
  • ডিভাইস থেকে পাঠানো বড় এসএমএস মেসেজ ইন্টারসেপ্ট করার পদ্ধতি: onSendMultipartTextSms
  • ডিভাইস থেকে পাঠানো এমএমএস মেসেজ ইন্টারসেপ্ট করার পদ্ধতি: onSendMms
  • প্রাপ্ত এমএমএস মেসেজ ডাউনলোড করার পদ্ধতি: onDownloadMms

CarrierService

পরিষেবা যা সিস্টেমে পরিষেবা প্রদানকারী-নির্দিষ্ট কার্যকারিতা প্রকাশ করে। এই ক্লাসকে আরও বড় করতে, অ্যাপ ম্যানিফেস্ট ফাইলে 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

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

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

Android প্ল্যাটফর্ম

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

যাচাইকরণ

Compatibility Test Suite (CTS)-এর মাধ্যমে প্রয়োগ করা হয়েছে কিনা তা যাচাই করতে CtsCarrierApiTestCases.apk, সঠিক 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।

Android 12-এ CTS ক্যারিয়ার API টেস্ট চালানোর জন্য, ডিভাইসটিকে CTS ক্যারিয়ার প্রিভিলেজ সহ একটি সিম ব্যবহার করতে হবে যা লেটেস্ট ভার্সনের থার্ড-পার্টি GSMA TS.48 টেস্ট প্রোফাইল স্পেসিফিকেশনে নির্দিষ্ট করা প্রয়োজনীয়তা পূরণ করে, যার মধ্যে একটি ফিক্সড ADM1, কী = 55555555 / 0x3535353535353535 থাকতে হবে।

Android 12-এর আগের ভার্সনেও একই সিম ব্যবহার করা যেতে পারে।

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

  1. যোগ করুন: CTS-এর ক্যারিয়ার প্রিভিলেজ অ্যাক্সেস রুল অ্যাপ মাস্টার (ARA-M) বা ARF-এ। দুটি স্বাক্ষরকেই ক্যারিয়ার প্রিভিলেজ নিয়মে এনকোড করা থাকতে হবে:
    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 এলিমেন্টারি ফাইল (EF) যা TS.48-এ নেই এবং CTS-এর জন্য প্রয়োজন:
    1. EF_MBDN (6FC7), রেকর্ড সাইজ: ২৮, রেকর্ড নম্বর: ৪ 
      • কন্টেন্ট
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), রেকর্ড সাইজ:১৩, রেকর্ড নম্বর: ১ 
      • কন্টেন্ট: 00FF…FF
        1. EF_MBI (6FC9), রেকর্ড সাইজ: ৪, রেকর্ড নম্বর: ১
      • কন্টেন্ট: Rec1: 01010101
        1. EF_MWIS (6FCA), রেকর্ড সাইজ: ৫, রেকর্ড নম্বর: ১
      • কন্টেন্ট: 0000000000
  3. পরিবর্তন করুন: USIM পরিষেবা টেবিল: n°47, n°48 পরিষেবা চালু করুন
    1. EF_UST (6F38)
      • কন্টেন্ট: 9EFFBF1DFFFE0083410310010400406E01
  4. পরিবর্তন করুন: DF-5GS এবং DF-SAIP ফাইল
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • কন্টেন্ট: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • কন্টেন্ট: 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 এমন একটি ডিভাইস টোকেন সমর্থন করে যা একই টোকেন দিয়ে কনফিগার করা ডিভাইসগুলিতেই পরীক্ষা চালানোর উপর বিধিনিষেধ আরোপ করে। Carrier API CTS টেস্ট ডিভাইস টোকেন sim-card-with-certs-এ কাজ করে। যেমন, নিচে উল্লেখ করা ডিভাইস টোকেন, ডিভাইস abcd1234-এ রান করার জন্য ক্যারিয়ার API টেস্ট সীমাবদ্ধ করে:

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

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

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

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

উ: আগে থেকে থাকা কার্ড OTA আপডেট মেকানিজম ব্যবহার করুন।

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

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

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

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

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

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

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

উ: না, তবে আমরা পরিষেবা প্রদানকারী-সম্পর্কিত API-এর ক্ষেত্রে স্কোপ সীমিত করি।

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

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

মাল্টি-সিম ফিচারের সাথে এটি কীভাবে কাজ করে?

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

এটি কি অন্য কোনও SE অ্যাক্সেস টেকনোলজির সাথে কোনওভাবে ইন্টার‍্যাক্ট বা ওভারল্যাপ করে, যেমন SEEK?

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

কখন ক্যারিয়ার প্রিভিলেজ চেক করা উচিত?

উত্তর: সিমের স্ট্যাটাস লোড করার ব্রডকাস্টের পরে।

OEM কি ক্যারিয়ার API-এর অংশ বন্ধ করতে পারে?

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

setOperatorBrandOverride কি অপারেটরের নামের স্ট্রিংয়ের অন্য সব ফর্ম ওভাররাইড করে? যেমন, SE13, UICC SPN, বা নেটওয়ার্ক-ভিত্তিক NITZ?

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

injectSmsPdu মেথড কল কী করে?

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

এসএমএস ফিল্টার করার জন্য, onFilterSms কল কি SMS UDH পোর্ট ফিল্টারিংয়ের উপর ভিত্তি করে করা হয়? অথবা, ক্যারিয়ার অ্যাপ কি সব ইনকামিং এসএমএস অ্যাক্সেস করতে পারে?

উ: পরিষেবা প্রদানকারীর কাছে সব এসএমএস ডেটার অ্যাক্সেস থাকে।

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

উত্তর: ভবিষ্যতে যাতে নিরাপত্তা সংক্রান্ত কোনও সমস্যা না হয়, সেই জন্য এই এক্সটেনশন SHA-1-এর পাশাপাশি DeviceAppID-REF-DO-এর জন্য SHA-256 যোগ করে। বর্তমানে GP SEAC স্ট্যান্ডার্ডে এটিই একমাত্র বিকল্প। আমরা SHA-256 ব্যবহার করার জন্য বিশেষভাবে সাজেস্ট করি।

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

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

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

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

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

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

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

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