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

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

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

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

यूआईसीसी से जुड़े नियम

यूआईसीसी पर मौजूद स्टोरेज, GlobalPlatform Secure Element Access Control specification के साथ काम करता है. कार्ड पर मौजूद ऐप्लिकेशन आइडेंटिफ़ायर (एआईडी) 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 मौजूद नहीं है, तो सर्टिफ़िकेट से साइन किए गए किसी भी ऐप्लिकेशन को ऐक्सेस दिया जाता है. अगर 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 प्लैटफ़ॉर्म, सबसे पहले ऐक्सेस रूल ऐप्लिकेशन (एआरए) एआईडी A00000015141434C00 को चुनने की कोशिश करता है. अगर UICC पर एआईडी नहीं मिलता है, तो यह PKCS15 एआईडी A000000063504B43532D3135 को चुनकर, एआरएफ़ पर वापस आ जाता है. इसके बाद, Android 0x4300 पर मौजूद ऐक्सेस कंट्रोल रूल फ़ाइल (एसीआरएफ़) को पढ़ता है और FFFFFFFFFFFF एआईडी वाली एंट्री खोजता है. अलग-अलग एआईडी वाली एंट्री को अनदेखा किया जाता है, ताकि इस्तेमाल के अन्य उदाहरणों के लिए नियम एक साथ मौजूद रह सकें.

हेक्स स्ट्रिंग में 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
  • कॉल की स्थिति बदल गई है: onCallStateChanged
  • आईपी मल्टीमीडिया सिस्टम (आईएमएस) कॉल डिसकनेक्ट होने की वजह बदली गई: 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

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

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

WifiNetworkSuggestion

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

  • सदस्यता आईडी सेट करने का तरीका: setSubscriptionId
  • सदस्यता ग्रुप सेट करने का तरीका: setSubscriptionGroup

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

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

Validation

CtsCarrierApiTestCases.apk का इस्तेमाल करके, Compatibility Test Suite (CTS) के ज़रिए लागू करने की पुष्टि करने के लिए, आपके पास सही UICC नियमों या ARF की सुविधा वाला डेवलपर 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 carrier API टेस्ट चलाने के लिए, डिवाइस में ऐसा सिम कार्ड इस्तेमाल करना होगा जिसमें CTS carrier के विशेषाधिकार हों. साथ ही, यह सिम कार्ड, तीसरे पक्ष के नए वर्शन के GSMA TS.48 Test Profile स्पेसिफ़िकेशन में बताई गई ज़रूरी शर्तों को पूरा करता हो. इसमें ADM1, key = 55555555 / 0x3535353535353535 तय किया गया हो.

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

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

  1. जोड़ें: ऐक्सेस के नियम तय करने वाले ऐप्लिकेशन के मास्टर (एआरए-एम) या एआरएफ़ में, सीटीएस कैरियर के खास अधिकार. दोनों सिग्नेचर को, कैरियर के फ़ायदों से जुड़े नियमों में कोड में बदला जाना चाहिए:
    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 की ऐसी एलिमेंट्री फ़ाइलें (ईएफ़) जो TS.48 में मौजूद नहीं हैं और CTS के लिए ज़रूरी हैं:
    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
      • Content: 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. 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

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

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

टेस्ट चलाना

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

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

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

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

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

A: मौजूदा कार्ड के OTA अपडेट करने के तरीके का इस्तेमाल करें.

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

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

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

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

क्या UICC पर मौजूद सर्टिफ़िकेट की संख्या की कोई सीमा है?

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

क्या इस तरीके से इस्तेमाल किए जा सकने वाले एपीआई की संख्या को लेकर कोई सीमा तय की गई है?

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

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

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

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

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

क्या यह किसी भी तरह से, एसई के ऐक्सेस से जुड़ी अन्य टेक्नोलॉजी के साथ इंटरैक्ट करता है या ओवरलैप होता है? उदाहरण के लिए, SEEK?

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

मोबाइल और इंटरनेट सेवा देने वाली कंपनी के फ़ायदे देखने का सही समय क्या है?

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

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

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

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

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

injectSmsPdu तरीके को कॉल करने से क्या होता है?

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

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

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

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

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

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

A: Carrier API के लिए, 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 में सर्टिफ़िकेट सेव करने की सुविधा, मौजूदा स्पेसिफ़िकेशन के साथ काम करती है. हमने स्पेसिफ़िकेशन में कम से कम बदलाव करने की कोशिश की है, ताकि इसे आसानी से अपनाया जा सके. ज़्यादा जानकारी के लिए, UICC से जुड़े नियम देखें.