यूज़र इंटरफ़ेस (यूआईसीसी) मोबाइल और इंटरनेट सेवा देने वाली कंपनी के खास अधिकार

Android 5.1 में, यूनिवर्सल इंटिग्रेटेड सर्किट कार्ड (यूआईसीसी) ऐप्लिकेशन के मालिकों के लिए, एपीआई को खास सुविधाएं देने का एक तरीका शुरू किया गया था. Android प्लैटफ़ॉर्म, यूआईसीसी में सेव किए गए सर्टिफ़िकेट लोड करता है. साथ ही, इन सर्टिफ़िकेट पर हस्ताक्षर किए गए ऐप्लिकेशन को कुछ खास एपीआई को कॉल करने की अनुमति देता है.

Android 7.0 ने इस सुविधा को बढ़ाकर, यूआईसीसी के लिए अन्य स्टोरेज सोर्स के साथ काम करने की सुविधा दी है. इससे, एपीआई का इस्तेमाल करने वाले कैरियर की संख्या में काफ़ी बढ़ोतरी हुई है. एपीआई का रेफ़रंस पाने के लिए, CarrierConfigManager देखें. निर्देशों के लिए, Carrier कॉन्फ़िगरेशन देखें.

मोबाइल और इंटरनेट सेवा देने वाली कंपनियों के पास यूआईसीसी का पूरा कंट्रोल होता है. इसलिए, यह तरीका, डिवाइसों पर खास सुविधाओं को बनाए रखते हुए, सामान्य ऐप्लिकेशन डिस्ट्रिब्यूशन चैनलों (जैसे, Google Play) पर होस्ट किए गए मोबाइल नेटवर्क ऑपरेटर (एमएनओ) के ऐप्लिकेशन को मैनेज करने का सुरक्षित और आसान तरीका उपलब्ध कराता है. इसके लिए, हर डिवाइस के लिए प्लैटफ़ॉर्म सर्टिफ़िकेट के साथ ऐप्लिकेशन पर हस्ताक्षर करने या सिस्टम ऐप्लिकेशन के तौर पर पहले से इंस्टॉल करने की ज़रूरत नहीं होती.

यूज़र इंटरफ़ेस (यूआईसीसी) पर नियम

UICC का स्टोरेज, GlobalPlatform के सुरक्षित एलिमेंट ऐक्सेस कंट्रोल स्पेसिफ़िकेशन के साथ काम करता है. कार्ड पर मौजूद ऐप्लिकेशन आइडेंटिफ़ायर (एआईडी) A00000015141434C00 है. कार्ड पर सेव किए गए नियमों को फ़ेच करने के लिए, स्टैंडर्ड GET DATA कमांड का इस्तेमाल किया जाता है. कार्ड ओवर-द-एयर (ओटीए) अपडेट की मदद से, इन नियमों को अपडेट किया जा सकता है.

डेटा हैरारकी

यूआईसीसी के नियम, यहां दी गई डेटा हैरारकी का इस्तेमाल करते हैं. ब्रैकेट में मौजूद दो वर्णों वाला अक्षर और संख्या का कॉम्बिनेशन, ऑब्जेक्ट टैग होता है. हर नियम एक 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 कोड में बदली गई है और इसकी लंबाई 127 बाइट से ज़्यादा नहीं होनी चाहिए.
  • 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

फ़ाइल ऐक्सेस करने के नियम से जुड़ी सहायता

Android 7.0 में, ऐक्सेस के नियम वाली फ़ाइल (एआरएफ़) से, मोबाइल और इंटरनेट सेवा देने वाली कंपनी के खास अधिकारों के नियमों को पढ़ने की सुविधा जोड़ी गई है.

Android प्लैटफ़ॉर्म सबसे पहले ऐक्सेस नियम ऐप्लिकेशन (ARA) AID A00000015141434C00 चुनने की कोशिश करता है. अगर इसे यूज़र इंटरफ़ेस (यूआईसीसी) पर AID नहीं मिलता है, तो PKCS15 AID A000000063504B43532D3135 को चुनकर यह ARF पर वापस चला जाता है. इसके बाद, Android 0x4300 पर ऐक्सेस कंट्रोल रूल फ़ाइल (ACRF) को पढ़ता है और AID FFFFFFFFFFFF वाली एंट्री खोजता है. अलग-अलग AID वाली एंट्री को अनदेखा कर दिया जाता है, ताकि इस्तेमाल के अन्य उदाहरणों के नियम एक साथ काम कर सकें.

हेक्स स्ट्रिंग में ACRF कॉन्टेंट का उदाहरण:

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

ऐक्सेस कंट्रोल कंडीशन फ़ाइल (एसीसीएफ़) कॉन्टेंट का उदाहरण:

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 शामिल है. इस सर्टिफ़िकेट से साइन किए गए ऐप्लिकेशन को मोबाइल और इंटरनेट सेवा देने वाली कंपनी से जुड़ी खास सुविधाएं मिलती हैं.

चालू किए गए एपीआई

Android, इन एपीआई के साथ काम करता है.

टेलीफ़ोनीमैनेजर

टेलीफ़ोनी कॉलबैक

TelephonyCallback में, रजिस्टर की गई स्थितियों में बदलाव होने पर, कॉलिंग ऐप्लिकेशन को इसकी सूचना देने के लिए, कॉलबैक वाले तरीके वाला इंटरफ़ेस होता है:

  • मैसेज भेजने के लिए इंतज़ार करने का इंडिकेटर बदल गया है: onMessageWaitingIndicatorChanged
  • कॉल फ़ॉरवर्ड करने की सुविधा का इंडिकेटर बदल गया है: onCallForwardingIndicatorChanged
  • आईपी मल्टीमीडिया सिस्टम (IMS) की कॉल डिसकनेक्ट होने की वजह में बदलाव हुआ है: onImsCallDisconnectCauseChanged
  • डेटा कनेक्शन की सटीक स्थिति बदल गई: onPreciseDataConnectionStateChanged
  • आपातकालीन नंबर की मौजूदा सूची बदल गई है: onEmergencyNumberListChanged
  • डेटा की चालू सदस्यता का आईडी बदल गया है: onActiveDataSubscriptionIdChanged
  • मोबाइल और इंटरनेट सेवा देने वाली कंपनी का नेटवर्क बदल गया है: onCarrierNetworkChange
  • नेटवर्क रजिस्ट्रेशन या जगह/रास्ते/ट्रैकिंग के इलाके का अपडेट नहीं हो सका: onRegistrationFailed
  • रोक लगाने वाली जानकारी में बदलाव किया गया है: onBarringInfoChanged
  • फ़िज़िकल चैनल का मौजूदा कॉन्फ़िगरेशन बदल गया है: onPhysicalChannelConfigChanged

SubscriptionManager

  • सदस्यता की अलग-अलग जानकारी पाने के तरीके:
  • चालू सदस्यताओं की संख्या देखने का तरीका: getActiveSubscriptionInfoCount
  • सदस्यता ग्रुप मैनेज करने के तरीके:
  • मोबाइल और इंटरनेट सेवा देने वाली कंपनी और किसी खास सदस्य के बीच के बिलिंग रिलेशनशिप प्लान की जानकारी पाने या सेट करने के तरीके:
  • किसी कैरियर और किसी खास ग्राहक के बीच बिलिंग रिलेशनशिप प्लान को कुछ समय के लिए बदलने का तरीका, ताकि उसे बिना मेज़र किए डेटा इस्तेमाल करने की सुविधा दी जा सके: setSubscriptionOverrideUnmetered
  • किसी कैरियर और किसी खास ग्राहक के बीच, बिलिंग रिलेशनशिप प्लान को कुछ समय के लिए बदलने का तरीका, ताकि उसे 'कॉन्जेंस्ड' माना जा सके: setSubscriptionOverrideCongested
  • यह देखने का तरीका कि दिए गए कॉन्टेक्स्ट वाले ऐप्लिकेशन के पास, मेटाडेटा के हिसाब से दी गई सदस्यता को मैनेज करने की अनुमति है या नहीं: canManageSubscription

SmsManager

  • कॉल करने वाले को इनकमिंग एसएमएस मैसेज बनाने की अनुमति देने का तरीका: injectSmsPdu.
  • एसएमएस सेवा देने वाली कंपनी को मैसेज लिखे बिना, टेक्स्ट वाला एसएमएस भेजने का तरीका: sendTextMessageWithoutPersisting

CarrierConfigManager

  • कॉन्फ़िगरेशन में बदलाव होने की सूचना देने का तरीका बदला गया: notifyConfigChangedForSubId.
  • डिफ़ॉल्ट सदस्यता के लिए, मोबाइल और इंटरनेट सेवा देने वाली कंपनी का कॉन्फ़िगरेशन पाने का तरीका: getConfig
  • किसी सदस्यता के लिए, मोबाइल और इंटरनेट सेवा देने वाली कंपनी का कॉन्फ़िगरेशन पाने का तरीका: getConfigForSubId

निर्देशों के लिए, मोबाइल और इंटरनेट सेवा देने वाली कंपनी का कॉन्फ़िगरेशन देखें.

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

टेलीफ़ोनी सेवा देने वाली कंपनी

कॉन्टेंट देने वाले के एपीआई, टेलीफ़ोनी के डेटाबेस में बदलाव (शामिल करें, मिटाएं, अपडेट करें, क्वेरी करें) की अनुमति दें. वैल्यू वाले फ़ील्ड की जानकारी Telephony.Carriers पर दी गई है. ज़्यादा जानकारी के लिए, Telephony क्लास का रेफ़रंस देखें

WifiNetworkSuggestion

WifiNetworkSuggestion ऑब्जेक्ट बनाते समय, सदस्यता आईडी या सदस्यता ग्रुप सेट करने के लिए, इन तरीकों का इस्तेमाल करें:

  • सदस्यता आईडी सेट करने का तरीका: setSubscriptionId
  • सदस्यों का ग्रुप सेट करने के लिए Metohd: setSubscriptionGroup

Android प्लैटफ़ॉर्म

पहचाने गए UICC पर, प्लैटफ़ॉर्म इंटरनल UICC ऑब्जेक्ट बनाता है. इनमें, UICC के हिस्से के तौर पर कैरियर की खास सुविधाओं के नियम शामिल होते हैं. UiccCarrierPrivilegeRules.java नियमों को लोड करता है, उन्हें UICC कार्ड से पार्स करता है, और उन्हें मेमोरी में कैश मेमोरी में सेव करता है. जब किसी विशेष सुविधा के ऐक्सेस की पुष्टि की ज़रूरत होती है, तो UiccCarrierPrivilegeRules कॉलर के सर्टिफ़िकेट की तुलना अपने नियमों से एक-एक करके करता है. अगर यूआईसीसी को हटाया जाता है, तो नियमों को यूआईसीसी ऑब्जेक्ट के साथ खत्म कर दिया जाता है.

पुष्टि करें

CtsCarrierApiTestCases.apk का इस्तेमाल करके, काम करने की जांच करने वाले टूल (सीटीएस) की मदद से, लागू होने की पुष्टि करने के लिए, आपके पास सही यूआईसीसी नियमों या एआरएफ़ के साथ काम करने वाला डेवलपर यूआईसीसी होना चाहिए. अपने पसंदीदा सिम कार्ड वेंडर से, इस सेक्शन में बताए गए सही एआरएफ़ के साथ डेवलपर यूआईसीसी तैयार करने के लिए कहें. साथ ही, टेस्ट चलाने के लिए उस यूआईसीसी का इस्तेमाल करें. सीटीएस टेस्ट को पास करने के लिए, यूआईसीसी को चालू सेल्युलर सेवा की ज़रूरत नहीं होती.

यूआईसीसी तैयार करना

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 में सीटीएस कैरियर एपीआई टेस्ट चलाने के लिए, डिवाइस में ऐसे सिम का इस्तेमाल करना ज़रूरी है जिसमें सीटीएस कैरियर की सुविधाएं हों. साथ ही, यह सिम तीसरे पक्ष की जीएसएमए टीएस.48 टेस्ट प्रोफ़ाइल के नए वर्शन में बताई गई ज़रूरी शर्तों को पूरा करता हो.

उसी सिम का इस्तेमाल, Android 12 से पहले के वर्शन के लिए भी किया जा सकता है.

सीटीएस सिम प्रोफ़ाइल में बदलाव करें

  1. जोड़ें: ऐक्सेस के नियम वाले ऐप्लिकेशन मास्टर (ARA-M) या ARF में सीटीएस मोबाइल और इंटरनेट सेवा देने वाली कंपनी के खास अधिकार. दोनों हस्ताक्षरों को, कैरियर के विशेषाधिकार के नियमों में एन्क्रिप्ट किया जाना चाहिए:
    1. हैश1(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 की बुनियादी फ़ाइलें (ईएफ़), जो TS.48 में मौजूद नहीं हैं और जिन्हें सीटीएस के लिए ज़रूरत है:
    1. EF_MBDN (6FC7), रिकॉर्ड का साइज़: 28, रिकॉर्ड नंबर: 4 
      • कॉन्टेंट
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), रिकॉर्ड का साइज़:13, रिकॉर्ड नंबर: 1 
      • कॉन्टेंट: 00FF…FF
        1. EF_MBI (6FC9), रिकॉर्ड का साइज़: 4, रिकॉर्ड नंबर: 1
      • कॉन्टेंट: Rec1: 01010101
        1. EF_MWIS (6FCA), रिकॉर्ड साइज़: 5, रिकॉर्ड संख्या: 1
      • कॉन्टेंट: 0000000000
  3. बदलाव करें: यूएसआईएम सेवा टेबल: सेवाएं 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. बदलाव करना: मोबाइल और इंटरनेट सेवा देने वाली कंपनी के नाम वाली स्ट्रिंग Android CTS का इस्तेमाल उन EF में करें जिनमें यह कैटगरी शामिल है:
    1. EF_SPN (USIM/6F46)
      • कॉन्टेंट: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • कॉन्टेंट: Rec1 430B83413759FE4E934143EA14FF..FF

टेस्ट प्रोफ़ाइल स्ट्रक्चर का मिलान करें

यहां दिए गए, सामान्य टेस्ट प्रोफ़ाइल स्ट्रक्चर के नए वर्शन को डाउनलोड करें और उनसे मैच करें. इन प्रोफ़ाइलों में, सीटीएस कैरियर प्रिविलेज नियम को मनमुताबिक नहीं बनाया जाएगा. इसके अलावा, इनमें ऊपर बताए गए अन्य बदलाव भी नहीं किए जाएंगे.

टेस्ट चलाना

सुविधा के लिए, CTS में डिवाइस टोकन का इस्तेमाल किया जा सकता है. इससे, जांच सिर्फ़ उसी टोकन से कॉन्फ़िगर किए गए डिवाइसों पर की जा सकती है. मोबाइल और इंटरनेट सेवा देने वाली कंपनी के एपीआई के सीटीएस टेस्ट, डिवाइस टोकन sim-card-with-certs के साथ काम करते हैं. उदाहरण के लिए, नीचे दिया गया डिवाइस टोकन, कैरियर एपीआई के टेस्ट को सिर्फ़ डिवाइस पर चलाने से रोकता है abcd1234:

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

डिवाइस टोकन का इस्तेमाल किए बिना टेस्ट चलाने पर, वह सभी डिवाइसों पर चलता है.

अक्सर पूछे जाने वाले सवाल

यूआईसीसी पर सर्टिफ़िकेट कैसे अपडेट किए जा सकते हैं?

जवाब: कार्ड के ओटीए अपडेट करने के मौजूदा तरीके का इस्तेमाल करें.

क्या यूआईसीसी को अन्य नियमों के साथ इस्तेमाल किया जा सकता है?

जवाब: एक ही AID के तहत, यूआईसीसी पर सुरक्षा से जुड़े अन्य नियम होने से कोई समस्या नहीं होती. प्लैटफ़ॉर्म उन्हें अपने-आप फ़िल्टर कर देता है.

अगर किसी ऐसे ऐप्लिकेशन के लिए यूआईसीसी को हटाया जाता है जो सर्टिफ़िकेट पर निर्भर करता है, तो क्या होता है?

जवाब: यूआईसीसी हटाने पर, ऐप्लिकेशन के खास अधिकार खत्म हो जाते हैं. इसकी वजह यह है कि यूआईसीसी से जुड़े नियम मिट जाते हैं.

क्या यूआईसीसी में सर्टिफ़िकेट की संख्या की कोई सीमा है?

जवाब: प्लैटफ़ॉर्म पर सर्टिफ़िकेट की संख्या की कोई सीमा नहीं है. हालांकि, जांच करने की प्रोसेस लीनियर होती है. इसलिए, बहुत ज़्यादा नियमों की वजह से जांच में देरी हो सकती है.

क्या इस तरीके से, एपीआई की संख्या पर कोई पाबंदी है?

जवाब: नहीं, लेकिन हम इसे सिर्फ़ कैरियर से जुड़े एपीआई तक सीमित रखते हैं.

क्या कुछ एपीआई के लिए, इस तरीके का इस्तेमाल करने पर पाबंदी है? अगर हां, तो इन्हें कैसे लागू किया जा सकता है? (यानी, क्या आपके पास इस तरीके से काम करने वाले एपीआई की पुष्टि करने के लिए टेस्ट हैं?)

जवाब: Android के साथ काम करने की परिभाषा वाले दस्तावेज़ (सीडीडी) का एपीआई, व्यवहार के साथ काम करने की क्षमता सेक्शन देखें. हमारे पास कुछ सीटीएस टेस्ट हैं, ताकि यह पक्का किया जा सके कि एपीआई के अनुमति मॉडल में कोई बदलाव नहीं हुआ है.

यह एक से ज़्यादा सिम की सुविधा के साथ कैसे काम करता है?

जवाब: उपयोगकर्ता ने जिस सिम को डिफ़ॉल्ट तौर पर सेट किया है उसका इस्तेमाल किया जा रहा है.

क्या यह किसी भी तरह से, SE ऐक्सेस करने वाली अन्य टेक्नोलॉजी, जैसे कि SEEK के साथ इंटरैक्ट या ओवरलैप करती है?

जवाब: उदाहरण के लिए, एसईके वही आईडी इस्तेमाल करता है जो यूज़र इंटरफ़ेस (यूआईसीसी) में है. इसलिए, ये नियम एक साथ काम करते हैं और इन्हें SEEK या UiccCarrierPrivileges में से किसी एक के हिसाब से फ़िल्टर किया जाता है.

मोबाइल और इंटरनेट सेवा देने वाली कंपनी के खास अधिकारों की जांच करने का सही समय क्या है?

जवाब: सिम की स्थिति लोड होने के बाद.

क्या OEM, मोबाइल और इंटरनेट सेवा देने वाली कंपनी के एपीआई की सुविधा को बंद कर सकते हैं?

जवाब: नहीं. हमारा मानना है कि मौजूदा एपीआई, कम से कम सेट हैं. साथ ही, हम आने वाले समय में ज़्यादा बेहतर तरीके से कंट्रोल करने के लिए, बिट मास्क का इस्तेमाल करने की योजना बना रहे हैं.

क्या setOperatorBrandOverride, ऑपरेटर के नाम वाली सभी दूसरी स्ट्रिंग को बदल देता है? उदाहरण के लिए, SE13, UICC SPN या नेटवर्क पर आधारित NITZ?

हां, ऑपरेटर ब्रैंड के बदलाव को सबसे ज़्यादा प्राथमिकता दी जाती है. यह सेट होने पर, ऑपरेटर के नाम की सभी स्ट्रिंग को बदल दिया जाता है.

injectSmsPdu तरीके से किया गया कॉल क्या करता है?

जवाब: इस तरीके से, क्लाउड में एसएमएस का बैक अप लेने/उसे वापस पाने में मदद मिलती है. injectSmsPdu कॉल, डेटा वापस पाने की सुविधा चालू करता है.

क्या onFilterSms कॉल, एसएमएस यूडीएच पोर्ट फ़िल्टर करने के हिसाब से होता है? इसके अलावा, क्या मोबाइल और इंटरनेट सेवा देने वाली कंपनी के ऐप्लिकेशन के पास, आने वाले सभी एसएमएस का ऐक्सेस है?

जवाब: मोबाइल और इंटरनेट सेवा देने वाली कंपनियों के पास एसएमएस के सभी डेटा का ऐक्सेस होता है.

ऐसा लगता है कि DeviceAppID-REF-DO के एक्सटेंशन को 32 बाइट के साथ काम करने के लिए, इसे मौजूदा GP स्पेसिफ़िकेशन के साथ काम नहीं कराया जा सकता. मौजूदा स्पेसिफ़िकेशन में सिर्फ़ 0 या 20 बाइट की अनुमति है. इसलिए, यह बदलाव क्यों किया जा रहा है? क्या SHA-1 टकरावों से बचने के लिए काफ़ी नहीं है? क्या आपने जीपी को पहले ही इस बदलाव का सुझाव दिया है, क्योंकि यह मौजूदा ARA-M/ARF के साथ काम नहीं कर सकता?

जवाब: आने वाले समय में सुरक्षा देने के लिए, इस एक्सटेंशन में SHA-1 के साथ-साथ DeviceAppID-REF-DO के लिए SHA-256 का इस्तेमाल किया गया है. फ़िलहाल, GP SEAC स्टैंडर्ड में सिर्फ़ यह विकल्प उपलब्ध है. हमारा सुझाव है कि आप SHA-256 का इस्तेमाल करें.

अगर DeviceAppID की वैल्यू 0 (खाली) है, तो क्या नियम को डिवाइस के उन सभी ऐप्लिकेशन पर लागू किया जाएगा जो किसी खास नियम के दायरे में नहीं आते?

जवाब: कैरियर एपीआई के लिए, DeviceAppID-REF-DO की वैल्यू डालना ज़रूरी है. खाली रहने का मकसद सिर्फ़ जांच करना है. ऑपरेशनल डिप्लॉयमेंट के लिए, इसके इस्तेमाल का सुझाव नहीं दिया जाता.

आपके स्पेसिफ़िकेशन के मुताबिक, PKG-REF-DO का इस्तेमाल सिर्फ़ DeviceAppID-REF-DO के बिना नहीं किया जाना चाहिए. हालांकि, इसे अब भी स्पेसिफ़िकेशन की टेबल 6-4 में, REF-DO की परिभाषा को बढ़ाने के तौर पर बताया गया है. क्या ऐसा जान-बूझकर किया गया है? जब REF-DO में सिर्फ़ PKG-REF-DO का इस्तेमाल किया जाता है, तो कोड कैसे काम करता है?

जवाब: REF-DO में PKG-REF-DO को एक वैल्यू आइटम के तौर पर इस्तेमाल करने का विकल्प, सबसे नए वर्शन में हटा दिया गया है. PKG-REF-DO को सिर्फ़ DeviceAppID-REF-DO के साथ इस्तेमाल करना चाहिए.

हम मानते हैं कि हम मोबाइल और इंटरनेट सेवा देने वाली कंपनी की सभी अनुमतियों का ऐक्सेस दे सकते हैं या उनका ज़्यादा कंट्रोल होता है. अगर ऐसा है, तो बिटमास्क और असल अनुमतियों के बीच मैपिंग को क्या तय करता है? क्या हर क्लास के लिए एक अनुमति चाहिए? क्या हर तरीके के लिए एक अनुमति चाहिए? क्या लंबे समय तक 64 अलग-अलग अनुमतियां काफ़ी हैं?

जवाब: यह सुविधा आने वाले समय में उपलब्ध होगी. हम सुझावों का स्वागत करते हैं.

क्या Android के लिए, खास तौर पर DeviceAppID के बारे में बताया जा सकता है? यह दिए गए ऐप्लिकेशन पर हस्ताक्षर करने के लिए इस्तेमाल किए गए पब्लिशर सर्टिफ़िकेट की SHA-1 (20 बाइट) हैश वैल्यू है. इसलिए, क्या नाम से इस मकसद का पता नहीं चलना चाहिए? (ऐसा हो सकता है कि यह नाम कई लोगों को समझ न आए, क्योंकि यह नियम उन सभी ऐप्लिकेशन पर लागू होता है जिन पर उसी पब्लिशर सर्टिफ़िकेट से हस्ताक्षर किए जाते हैं.)

जवाब: सर्टिफ़िकेट सेव करने की सुविधा, DeviceAppID के मौजूदा स्पेसिफ़िकेशन के साथ काम करती है. हमने स्पेसिफ़िकेशन में कम से कम बदलाव करने की कोशिश की है, ताकि इसे अपनाने में आने वाली समस्याओं को कम किया जा सके. ज़्यादा जानकारी के लिए, यूआईसीसी से जुड़े नियम देखें.