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

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

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

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

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

यूआईसीसी पर स्टोरेज ग्लोबलप्लेटफ़ॉर्म सिक्योर एलिमेंट एक्सेस कंट्रोल विनिर्देश के साथ संगत है। कार्ड पर एप्लिकेशन पहचानकर्ता (एआईडी) 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 ) प्रमाणपत्र के एसएचए-1 (20 बाइट्स) या एसएचए-256 (32 बाइट्स) हस्ताक्षर संग्रहीत करता है।
    • PKG-REF-DO ( CA ) मेनिफेस्ट में परिभाषित पूर्ण पैकेज नाम स्ट्रिंग है, एएससीआईआई एन्कोडेड, अधिकतम लंबाई 127 बाइट्स।
  • AR-DO ( E3 ) को PERM-AR-DO ( DB ) को शामिल करने के लिए विस्तारित किया गया है, जो 64 अलग-अलग अनुमतियों का प्रतिनिधित्व करने वाला 8-बाइट बिट मास्क है।

यदि 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 एक्सेस नियम फ़ाइल (एआरएफ) से वाहक विशेषाधिकार नियमों को पढ़ने के लिए समर्थन जोड़ता है।

एंड्रॉइड प्लेटफ़ॉर्म सबसे पहले एक्सेस रूल एप्लिकेशन (एआरए) एआईडी A00000015141434C00 का चयन करने का प्रयास करता है। यदि इसे UICC पर AID नहीं मिलता है, तो यह PKCS15 AID A000000063504B43532D3135 का चयन करके ARF पर वापस आ जाता है। एंड्रॉइड फिर 0x4300 पर एक्सेस कंट्रोल नियम फ़ाइल (ACRF) पढ़ता है और AID 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 शामिल है 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
  • नेटवर्क उपयोग कॉलबैक को पंजीकृत या अपंजीकृत करने की विधियाँ:

ImsMmTelManager

ImsRcs प्रबंधक

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

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

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

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

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

  • इनबाउंड एसएमएस संदेशों को फ़िल्टर करने की विधि: onFilterSms
  • डिवाइस से भेजे गए टेक्स्ट एसएमएस संदेशों को इंटरसेप्ट करने की विधि: onSendTextSms
  • डिवाइस से भेजे गए बाइनरी एसएमएस संदेशों को इंटरसेप्ट करने की विधि: onSendDataSms
  • डिवाइस से भेजे गए लंबे एसएमएस संदेशों को रोकने की विधि: onSendMultipartTextSms
  • डिवाइस से भेजे गए एमएमएस संदेशों को रोकने की विधि: 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
  • सदस्यता समूह सेट करने का तरीका: setSubscriptionGroup

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

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

मान्यकरण

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

यूआईसीसी तैयार करें

एंड्रॉइड 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

एंड्रॉइड 12 में सीटीएस वाहक एपीआई परीक्षण चलाने के लिए, डिवाइस को सीटीएस वाहक विशेषाधिकारों के साथ एक सिम का उपयोग करने की आवश्यकता होती है जो तृतीय-पक्ष जीएसएमए टीएस.48 टेस्ट प्रोफ़ाइल विनिर्देश के नवीनतम संस्करण में निर्दिष्ट आवश्यकताओं को पूरा करता है।

उसी सिम का उपयोग एंड्रॉइड 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. 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: एफएफ...एफएफ
    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. डीएफ-5जीएस - ईएफ एसयूसीआई_कैल्क_इन्फो (यूएसआईएम/5एफसी0/4एफ07)
      • सामग्री: A0020000FF…FF
    4. डीएफ-एसएआईपी - ईएफ एसयूसीआई_कैल्क_इन्फो_यूएसआईएम (यूएसआईएम/5एफडी0/4एफ01)
      • सामग्री: A0020000FF…FF
  5. संशोधित करें: इस पदनाम वाले संबंधित ईएफ में वाहक नाम स्ट्रिंग एंड्रॉइड सीटीएस का उपयोग करें:
    1. ईएफ_एसपीएन (यूएसआईएम/6एफ46)
      • सामग्री: 01416E64726F696420435453FF..FF
    2. ईएफ_पीएनएन (यूएसआईएम/6एफसी5)
      • सामग्री: Rec1 430B83413759FE4E934143EA14FF..FF

परीक्षण प्रोफ़ाइल संरचना का मिलान

निम्नलिखित सामान्य परीक्षण प्रोफ़ाइल संरचनाओं के नवीनतम संस्करण को डाउनलोड करें और मिलान करें। इन प्रोफाइलों में सीटीएस कैरियर प्रिविलेज नियम वैयक्तिकृत या ऊपर सूचीबद्ध अन्य संशोधन नहीं होंगे।

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

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

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

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

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

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

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

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

उ: समान एआईडी के तहत यूआईसीसी पर अन्य सुरक्षा नियम रखना ठीक है; प्लेटफ़ॉर्म उन्हें स्वचालित रूप से फ़िल्टर कर देता है।

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

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

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

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

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

उत्तर: नहीं, लेकिन हम इसका दायरा वाहक-संबंधित एपीआई तक सीमित रखते हैं।

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

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

यह मल्टी-सिम सुविधा के साथ कैसे काम करता है?

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

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

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

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

उत्तर: सिम स्थिति लोड होने के बाद प्रसारण।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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