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

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

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 पर एआईडी नहीं मिलता है, तो यह पीकेसीएस15 एआईडी 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
  • आईपी मल्टीमीडिया सिस्टम (आईएमएस) कॉल डिसकनेक्ट होने की वजह बदली गई: onImsCallDisconnectCauseChanged
  • डेटा कनेक्शन की सटीक स्थिति में बदलाव हुआ: onPreciseDataConnectionStateChanged
  • आपातकालीन नंबर की मौजूदा सूची में बदलाव किया गया है: onEmergencyNumberListChanged
  • चालू डेटा सदस्यता का आईडी बदल गया है: onActiveDataSubscriptionIdChanged
  • मोबाइल और इंटरनेट सेवा देने वाली कंपनी का नेटवर्क बदल गया है: onCarrierNetworkChange
  • नेटवर्क रजिस्ट्रेशन या जगह की जानकारी/रास्ते/ट्रैकिंग की जानकारी से जुड़ा अपडेट नहीं हो सका: onRegistrationFailed
  • बिलिंग से जुड़ी जानकारी में बदलाव: onBarringInfoChanged
  • मौजूदा फ़िज़िकल चैनल कॉन्फ़िगरेशन बदल गया है: onPhysicalChannelConfigChanged

SubscriptionManager

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 ऑब्जेक्ट के साथ-साथ नियम भी मिट जाते हैं.

Validation

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

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

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

  1. जोड़ें: CTS carrier privileges in access rule app master (ARA-M) or 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 की एलिमेंट्री फ़ाइलें (ईएफ़) 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
      • 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: मौजूदा कार्ड के ओटीए अपडेट करने के तरीके का इस्तेमाल करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आपके स्पेसिफ़िकेशन के मुताबिक, PKG-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 बाइट) हैश वैल्यू है. इसलिए, क्या नाम से यह पता नहीं चलना चाहिए कि इसका इस्तेमाल किस मकसद से किया गया है? (नाम कई लोगों को भ्रमित कर सकता है, क्योंकि यह नियम उस पब्लिशर सर्टिफ़िकेट से साइन किए गए सभी ऐप्लिकेशन पर लागू होता है.)

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