यूआईसीसी कैरियर विशेषाधिकार

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

एंड्रॉइड 5.1 ने यूनिवर्सल इंटीग्रेटेड सर्किट कार्ड (यूआईसीसी) ऐप्स के मालिकों के लिए प्रासंगिक एपीआई के लिए विशेष विशेषाधिकार प्रदान करने के लिए एक तंत्र पेश किया। एंड्रॉइड प्लेटफॉर्म यूआईसीसी पर संग्रहीत प्रमाणपत्रों को लोड करता है और इन प्रमाणपत्रों द्वारा हस्ताक्षरित ऐप्स को मुट्ठी भर विशेष एपीआई को कॉल करने की अनुमति देता है।

एंड्रॉइड 7.0 ने यूआईसीसी वाहक विशेषाधिकार नियमों के लिए अन्य भंडारण स्रोतों का समर्थन करने के लिए इस सुविधा का विस्तार किया, नाटकीय रूप से उन वाहकों की संख्या में वृद्धि की जो एपीआई का उपयोग कर सकते हैं। API संदर्भ के लिए, कैरियरकॉन्फ़िगमैनेजर देखें; निर्देशों के लिए, कैरियर कॉन्फ़िगरेशन देखें।

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

यूआईसीसी पर नियम

UICC पर संग्रहण GlobalPlatform Secure Element Access Control विनिर्देश के साथ संगत है। कार्ड पर एप्लिकेशन आइडेंटिफायर (AID) A00000015141434C00 है, और मानक GET DATA कमांड का उपयोग कार्ड पर संग्रहीत नियमों को लाने के लिए किया जाता है। आप इन नियमों को कार्ड ओवर-द-एयर (OTA) अपडेट के जरिए अपडेट कर सकते हैं।

डेटा पदानुक्रम

यूआईसीसी नियम निम्नलिखित डेटा पदानुक्रम का उपयोग करते हैं (कोष्ठक में दो-वर्ण अक्षर और संख्या संयोजन ऑब्जेक्ट टैग है)। प्रत्येक नियम 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

एक्सेस नियम फ़ाइल समर्थन

एंड्रॉइड 7.0 एक्सेस रूल फाइल (एआरएफ) से कैरियर विशेषाधिकार नियमों को पढ़ने के लिए समर्थन जोड़ता है।

Android प्लेटफ़ॉर्म पहले एक्सेस रूल एप्लिकेशन (ARA) AID A00000015141434C00 का चयन करने का प्रयास करता है। यदि इसे UICC पर AID नहीं मिलता है, तो यह PKCS15 AID A000000063504B43532D3135 का चयन करके ARF पर वापस आ जाता है। Android फिर 0x4300 पर एक्सेस कंट्रोल रूल्स फ़ाइल (ACRF) को 0x4300 है और 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 का पता है, जिसमें प्रमाणपत्र हैश 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 । इस प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स को वाहक विशेषाधिकार दिए गए हैं।

सक्षम एपीआई

एंड्रॉइड निम्नलिखित एपीआई का समर्थन करता है।

टेलीफोनी प्रबंधक

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

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

सदस्यता प्रबंधक

एसएमएस प्रबंधक

  • कॉल करने वाले को नए आने वाले एसएमएस संदेश बनाने की विधि: injectSmsPdu ।
  • एसएमएस प्रदाता में लिखे बिना पाठ आधारित एसएमएस संदेश भेजने की विधि: sendTextMessageWithoutPersisting

कैरियरकॉन्फ़िगरेशन प्रबंधक

  • कॉन्फ़िगरेशन को सूचित करने का तरीका बदल गया: notifyConfigChangedForSubId ।
  • डिफ़ॉल्ट सदस्यता के लिए वाहक कॉन्फ़िगरेशन प्राप्त करने की विधि: getConfig
  • निर्दिष्ट सदस्यता के लिए वाहक कॉन्फ़िगरेशन प्राप्त करने की विधि: getConfigForSubId

निर्देशों के लिए, कैरियर कॉन्फ़िगरेशन देखें।

बुग्रेपोर्ट प्रबंधक

कनेक्टिविटी बग रिपोर्ट शुरू करने की विधि, जो बग रिपोर्ट का एक विशेष संस्करण है जिसमें केवल डिबगिंग कनेक्टिविटी संबंधी मुद्दों के लिए जानकारी शामिल है: startConnectivityBugreport

नेटवर्कस्टैट्समैनेजर

  • नेटवर्क उपयोग सारांश को क्वेरी करने की विधि: querySummary
  • नेटवर्क उपयोग इतिहास को क्वेरी करने की विधि: queryDetails
  • नेटवर्क उपयोग कॉलबैक को पंजीकृत या अपंजीकृत करने के तरीके:

आईएमएसएमएमटेलमैनेजर

आईएमएसआरसीएसप्रबंधक

प्रावधान प्रबंधक

ईयूआईसीसी प्रबंधक

दी गई सदस्यता पर स्विच करने (सक्षम) करने की विधि: switchToSubscription

कैरियर मैसेजिंग सेवा

सेवा जो नए एसएमएस और एमएमएस भेजे या प्राप्त होने पर सिस्टम से कॉल प्राप्त करती है। इस वर्ग का विस्तार करने के लिए, android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE अनुमति के साथ अपनी मेनिफेस्ट फ़ाइल में सेवा घोषित करें और #SERVICE_INTERFACE क्रिया के साथ एक इंटेंट फ़िल्टर शामिल करें। विधियों में शामिल हैं:

  • इनबाउंड एसएमएस संदेशों को फ़िल्टर करने की विधि: onFilterSms
  • डिवाइस से भेजे गए टेक्स्ट एसएमएस संदेशों को इंटरसेप्ट करने की विधि: onSendTextSms
  • डिवाइस से भेजे गए बाइनरी एसएमएस संदेशों को इंटरसेप्ट करने की विधि: onSendDataSms
  • डिवाइस से भेजे गए लंबे एसएमएस संदेशों को रोकने की विधि: onSendMultipartTextSms
  • डिवाइस से भेजे गए MMS संदेशों को इंटरसेप्ट करने की विधि: onSendMms
  • प्राप्त एमएमएस संदेशों को डाउनलोड करने की विधि: onDownloadMms

कैरियर सेवा

सेवा जो सिस्टम के लिए वाहक-विशिष्ट कार्यक्षमताओं को उजागर करती है। इस वर्ग का विस्तार करने के लिए, android.Manifest.permission#BIND_CARRIER_SERVICES अनुमति के साथ ऐप मेनिफेस्ट फ़ाइल में सेवा घोषित करें और CARRIER_SERVICE_INTERFACE कार्रवाई के साथ एक इंटेंट फ़िल्टर शामिल करें। यदि सेवा में लंबे समय तक बाध्यकारी है, तो सेवा के मेटाडेटा में android.service.carrier.LONG_LIVED_BINDING को true पर सेट करें।

प्लेटफ़ॉर्म कैरियर सर्विस को विशेष CarrierService के साथ बांधता है ताकि कैरियर सेवा प्रक्रिया को एक विशेष ऐप स्टैंडबाय बकेट में चलने दिया जा सके। यह कैरियर सेवा ऐप को ऐप निष्क्रिय प्रतिबंध से छूट देता है और डिवाइस मेमोरी कम होने पर इसके जीवित रहने की अधिक संभावना बनाता है। हालाँकि, यदि वाहक सेवा ऐप किसी भी कारण से क्रैश हो जाता है, तो यह उपरोक्त सभी विशेषाधिकारों को तब तक खो देता है जब तक कि ऐप पुनरारंभ नहीं हो जाता और बाइंडिंग फिर से स्थापित नहीं हो जाती। इसलिए कैरियर सेवा ऐप को स्थिर रखना महत्वपूर्ण है।

CarrierService सेवा में विधियों में शामिल हैं:

  • कैरियर विशिष्ट कॉन्फ़िगरेशन को ओवरराइड और सेट करने के लिए: onLoadConfig
  • वाहक एप्लिकेशन द्वारा एक जानबूझकर आगामी वाहक नेटवर्क परिवर्तन की प्रणाली को सूचित करने के लिए: सूचित करें notifyCarrierNetworkChange

टेलीफोनी प्रदाता

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

वाईफ़ाई नेटवर्क सुझाव

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

  • सदस्यता आईडी सेट करने की विधि: setSubscriptionId
  • सदस्यता समूह सेट करने के लिए Metohd: setSubscriptionGroup

एंड्रॉइड प्लेटफॉर्म

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

मान्यकरण

CtsCarrierApiTestCases.apk का उपयोग करके संगतता परीक्षण सूट (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 के साथ 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 परीक्षण चलाने के लिए, डिवाइस को तृतीय-पक्ष GSMA TS.48 परीक्षण प्रोफ़ाइल विनिर्देश के नवीनतम संस्करण में निर्दिष्ट आवश्यकताओं को पूरा करने वाले CTS वाहक विशेषाधिकारों के साथ एक सिम का उपयोग करने की आवश्यकता है।

उसी सिम का उपयोग Android 12 से पहले के संस्करणों के लिए भी किया जा सकता है।

सीटीएस सिम प्रोफाइल को संशोधित करना

  1. जोड़ें: एक्सेस रूल एप्लिकेशन मास्टर (ARA-M) या ARF में CTS कैरियर विशेषाधिकार। दोनों हस्ताक्षर वाहक विशेषाधिकार नियमों में एन्कोड किए जाने चाहिए:
    1. हैश1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. हैश2(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 प्राथमिक फ़ाइलें (EFs) 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
      • सामग्री: Rec1: 01010101
        1. EF_MWIS (6FCA), रिकॉर्ड आकार: 5, रिकॉर्ड संख्या: 1
      • सामग्री: 000000000000
  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 कैरियर विशेषाधिकार नियम वैयक्तिकृत या ऊपर सूचीबद्ध अन्य संशोधन नहीं होंगे।

चल रहे परीक्षण

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

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

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

सामान्य प्रश्न

UICC पर प्रमाणपत्रों को कैसे अद्यतन किया जा सकता है?

ए: मौजूदा कार्ड ओटीए अपडेट तंत्र का प्रयोग करें।

क्या UICC अन्य नियमों के साथ सह-अस्तित्व में आ सकता है?

उ: UICC पर समान AID के अंतर्गत अन्य सुरक्षा नियमों का होना ठीक है; प्लेटफ़ॉर्म उन्हें स्वचालित रूप से फ़िल्टर कर देता है।

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

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

क्या UICC पर प्रमाणपत्रों की संख्या की कोई सीमा है?

ए: प्लेटफ़ॉर्म प्रमाणपत्रों की संख्या को सीमित नहीं करता है; लेकिन क्योंकि चेक रैखिक है, बहुत से नियमों में चेक के लिए विलंब हो सकता है।

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

उ: नहीं, लेकिन हम इसका दायरा वाहक-संबंधित API तक सीमित करते हैं।

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

उ: Android संगतता परिभाषा दस्तावेज़ (CDD) का API व्यवहार संगतता अनुभाग देखें। हमारे पास यह सुनिश्चित करने के लिए कुछ सीटीएस परीक्षण हैं कि एपीआई का अनुमति मॉडल नहीं बदला गया है।

यह मल्टी-सिम फीचर के साथ कैसे काम करता है?

ए: उपयोगकर्ता द्वारा निर्दिष्ट डिफ़ॉल्ट सिम का उपयोग किया जाता है।

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

उ: उदाहरण के तौर पर, SEEK उसी AID का उपयोग करता है जो UICC पर होता है। तो नियम सह-अस्तित्व में हैं और SEEK या UiccCarrierPrivileges द्वारा फ़िल्टर किए जाते हैं।

वाहक विशेषाधिकारों की जांच करने का यह एक अच्छा समय कब है?

ए: सिम राज्य लोड होने के बाद प्रसारण।

क्या ओईएम कैरियर एपीआई के हिस्से को अक्षम कर सकते हैं?

उ: नहीं। हम मानते हैं कि वर्तमान एपीआई न्यूनतम सेट हैं, और हम भविष्य में बारीक ग्रैन्युलैरिटी नियंत्रण के लिए बिट मास्क का उपयोग करने की योजना बना रहे हैं।

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

हां, ऑपरेटर ब्रांड ओवरराइड की सर्वोच्च प्राथमिकता होती है। जब यह सेट हो जाता है, तो यह ऑपरेटर नाम स्ट्रिंग के अन्य सभी रूपों को ओवरराइड करता है।

injectSmsPdu विधि कॉल क्या करता है?

ए: यह विधि क्लाउड में एसएमएस बैकअप/पुनर्स्थापना की सुविधा प्रदान करती है। injectSmsPdu कॉल पुनर्स्थापना फ़ंक्शन को सक्षम करता है।

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

ए: वाहक के पास सभी एसएमएस डेटा तक पहुंच है।

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

उ: भविष्य-सबूत सुरक्षा प्रदान करने के लिए, यह एक्सटेंशन SHA-1 के अलावा DeviceAppID-REF-DO के लिए SHA-256 पेश करता है, जो वर्तमान में GP SEAC मानक में एकमात्र विकल्प है। हम SHA-256 का उपयोग करने की अत्यधिक अनुशंसा करते हैं।

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

उ: कैरियर API के लिए DeviceAppID-REF-DO को पॉप्युलेट करना आवश्यक है। खाली होने का उद्देश्य परीक्षण उद्देश्यों के लिए है और परिचालन परिनियोजन के लिए अनुशंसित नहीं है।

आपकी युक्ति के अनुसार, PKG-REF-DO केवल स्वयं के द्वारा उपयोग किया जाता है, बिना DeviceAppID-REF-DO के, स्वीकार नहीं किया जाना चाहिए। लेकिन यह अभी भी REF-DO की परिभाषा को विस्तारित करने के रूप में विनिर्देश की तालिका 6-4 में वर्णित है। क्या यह उद्देश्य पर है? जब REF-DO में केवल PKG-REF-DO REF-DO उपयोग किया जाता है तो कोड कैसे व्यवहार करता है?

उ: नवीनतम संस्करण में PKG-REF-DO को एकल मान आइटम के रूप में रखने का विकल्प REF-DO में हटा दिया गया था। PKG-REF-DO केवल DeviceAppID-REF-DO के संयोजन में होना चाहिए।

हम मानते हैं कि हम सभी वाहक-आधारित अनुमतियों तक पहुंच प्रदान कर सकते हैं या बेहतर नियंत्रण रख सकते हैं। यदि हां, तो बिट मास्क और वास्तविक अनुमतियों के बीच मानचित्रण को क्या परिभाषित करता है? प्रति वर्ग एक अनुमति? प्रति विधि एक अनुमति? क्या लंबे समय में 64 अलग-अलग अनुमतियां पर्याप्त हैं?

ए: यह भविष्य के लिए आरक्षित है, और हम सुझावों का स्वागत करते हैं।

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

उ: DeviceAppID सर्टिफिकेट मौजूदा स्पेक द्वारा समर्थित है। हमने गोद लेने की बाधा को कम करने के लिए विशिष्ट परिवर्तनों को कम करने का प्रयास किया। विवरण के लिए, UICC पर नियम देखें।