मोबाइल और इंटरनेट सेवा देने वाली कंपनी के लिए UICC के खास अधिकार

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 में, ऐक्सेस नियम फ़ाइल (ARF) से कैरियर की विशेषता के नियम पढ़ने की सुविधा जोड़ी गई है.

Android प्लैटफ़ॉर्म सबसे पहले ऐक्सेस नियम ऐप्लिकेशन (ARA) AID A00000015141434C00 चुनने की कोशिश करता है. अगर उसे यूआईसीसी पर एआईडी नहीं मिलता है, तो वह PKCS15 एआईडी A000000063504B43532D3135 को चुनकर, एआरएफ़ पर वापस आ जाता है. इसके बाद, 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, इन एपीआई के साथ काम करता है.

TelephonyManager

TelephonyCallback

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

  • मैसेज भेजने के लिए इंतज़ार करने का इंडिकेटर बदल गया है: onMessageWaitingIndicatorChanged
  • कॉल फ़ॉरवर्ड करने की सुविधा का इंडिकेटर बदल गया है: onCallForwardingIndicatorChanged
  • आईपी मल्टीमीडिया सिस्टम (आईएमएस) कॉल डिसकनेक्ट होने की वजह बदल गई है: 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
  • सदस्यता ग्रुप सेट करने का तरीका: setSubscriptionGroup

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

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

पुष्टि करें

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

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

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

  1. जोड़ें: ऐक्सेस नियम ऐप्लिकेशन के मुख्य वर्शन (ARA-M) या एआरएफ़ में, मोबाइल और इंटरनेट सेवा देने वाली कंपनी के लिए सीटीएस की विशेषताएं. दोनों हस्ताक्षरों को, कैरियर के विशेषाधिकारों के नियमों में कोड में बदला जाना चाहिए:
    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 का इस्तेमाल करें उन ईएफ़ में जिनमें यह पद शामिल है:
    1. EF_SPN (USIM/6F46)
      • कॉन्टेंट: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • कॉन्टेंट: Rec1 430B83413759FE4E934143EA14FF..FF

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

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

टेस्ट चलाना

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

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

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

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

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

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

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

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

किसी ऐसे ऐप्लिकेशन के लिए यूआईसीसी हटाने पर क्या होता है जो उसमें मौजूद सर्टिफ़िकेट पर निर्भर करता है?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

injectSmsPdu का तरीका क्या करता है?

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

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

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

ऐसा लगता है कि DeviceAppID-REF-DO को 32 बाइट के साथ काम करने के लिए एक्सटेंशन देने की सुविधा, जीपी के मौजूदा स्पेसिफ़िकेशन के साथ काम नहीं करती. जीपी के मौजूदा स्पेसिफ़िकेशन के मुताबिक, सिर्फ़ 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 के मौजूदा स्पेसिफ़िकेशन के साथ काम करती है. हमने स्पेसिफ़िकेशन में कम से कम बदलाव करने की कोशिश की है, ताकि इसे अपनाने में आने वाली समस्याओं को कम किया जा सके. ज़्यादा जानकारी के लिए, यूआईसीसी से जुड़े नियम देखें.