สิทธิพิเศษของผู้ให้บริการ UICC

Android 5.1 แนะนำกลไกในการให้สิทธิ์พิเศษสำหรับ API ที่เกี่ยวข้องกับเจ้าของแอปการ์ดวงจรรวมสากล (UICC) แพลตฟอร์ม Android โหลดใบรับรองที่จัดเก็บไว้ใน UICC และให้สิทธิ์แก่แอปที่ลงนามโดยใบรับรองเหล่านี้เพื่อเรียก API พิเศษจำนวนหนึ่ง

Android 7.0 ขยายคุณสมบัตินี้เพื่อรองรับแหล่งจัดเก็บข้อมูลอื่นๆ สำหรับกฎสิทธิ์ของผู้ให้บริการ UICC ซึ่งเพิ่มจำนวนผู้ให้บริการที่สามารถใช้ API ได้อย่างมาก สำหรับการอ้างอิง API โปรดดูที่ CarrierConfigManager สำหรับคำแนะนำ โปรดดูที่ การกำหนดค่าผู้ให้บริการ

ผู้ให้บริการสามารถควบคุม UICC ได้อย่างเต็มที่ ดังนั้นกลไกนี้จึงเป็นวิธีที่ปลอดภัยและยืดหยุ่นในการจัดการแอพจากผู้ให้บริการเครือข่ายมือถือ (MNO) ที่โฮสต์บนช่องทางการเผยแพร่แอพทั่วไป (เช่น Google Play) ในขณะที่ยังคงรักษาสิทธิพิเศษบนอุปกรณ์และไม่มีความจำเป็น เพื่อลงชื่อแอพด้วยใบรับรองแพลตฟอร์มต่ออุปกรณ์หรือติดตั้งล่วงหน้าเป็นแอพระบบ

หลักเกณฑ์เกี่ยวกับ UICC

ที่เก็บข้อมูลบน UICC เข้ากันได้กับ ข้อกำหนด GlobalPlatform Secure Element Access Control ตัวระบุแอปพลิเคชัน (AID) บนการ์ดคือ A00000015141434C00 และคำสั่ง GET DATA มาตรฐานใช้เพื่อดึงกฎที่จัดเก็บไว้ในการ์ด คุณสามารถอัปเดตกฎเหล่านี้ได้ผ่านการอัปเดตการ์ดแบบ over-the-air (OTA)

ลำดับชั้นข้อมูล

กฎ UICC ใช้ลำดับชั้นข้อมูลต่อไปนี้ (การรวมตัวอักษร 2 ตัวและตัวเลขในวงเล็บคือแท็กอ็อบเจกต์) แต่ละกฎคือ 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 ) คือสตริงชื่อแพ็กเกจแบบเต็มที่กำหนดในไฟล์ Manifest เข้ารหัส 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 ก่อน หากไม่พบ AID ใน UICC ก็จะกลับไปที่ ARF โดยเลือก PKCS15 AID A000000063504B43532D3135 จากนั้น Android จะอ่านไฟล์กฎการควบคุมการเข้าถึง (ACRF) ที่ 0x4300 และค้นหารายการด้วย AID FFFFFFFFFFFF รายการที่มี AID ต่างกันจะถูกละเว้น ดังนั้นกฎสำหรับกรณีการใช้งานอื่นๆ จึงอยู่ร่วมกันได้

ตัวอย่างเนื้อหา ACRF ในสตริงฐานสิบหก:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

ตัวอย่างเนื้อหาไฟล์เงื่อนไขการควบคุมการเข้าถึง (ACCF):

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 . แอปที่ลงนามโดยใบรับรองนี้จะได้รับสิทธิ์ของผู้ให้บริการ

API ที่เปิดใช้งาน

Android รองรับ API ต่อไปนี้

ผู้จัดการโทรศัพท์

โทรศัพท์โทรกลับ

TelephonyCallback มีอินเทอร์เฟซพร้อมวิธีการโทรกลับเพื่อแจ้งแอพการโทรเมื่อสถานะการลงทะเบียนเปลี่ยนไป:

  • ตัวบ่งชี้การรอข้อความเปลี่ยนไป: onMessageWaitingIndicatorChanged
  • ตัวบ่งชี้การโอนสายเปลี่ยนไป: onCallForwardingIndicatorChanged
  • สาเหตุการตัดการเชื่อมต่อการโทรของระบบมัลติมีเดีย IP (IMS) เปลี่ยนไป: onImsCallDisconnectCauseChanged
  • สถานะการเชื่อมต่อข้อมูลที่แม่นยำเปลี่ยนไป: onPreciseDataConnectionStateChanged
  • รายการหมายเลขฉุกเฉินปัจจุบันเปลี่ยนไป: onEmergencyNumberListChanged
  • ID การสมัครข้อมูลที่ใช้งานอยู่มีการเปลี่ยนแปลง: onActiveDataSubscriptionIdChanged
  • เครือข่ายผู้ให้บริการมีการเปลี่ยนแปลง: onCarrierNetworkChange
  • การลงทะเบียนเครือข่ายหรือการอัปเดตพื้นที่ตำแหน่ง/การกำหนดเส้นทาง/การติดตามล้มเหลว: onRegistrationFailed
  • การเปลี่ยนแปลงข้อมูลการจำกัด: onBarringInfoChanged
  • การกำหนดค่าฟิสิคัลแชนเนลปัจจุบันเปลี่ยนไป: onPhysicalChannelConfigChanged

ผู้จัดการการสมัครสมาชิก

SmsManager

  • วิธีการให้ผู้โทรสร้างข้อความ SMS ขาเข้าใหม่: injectSmsPdu
  • วิธีการส่งข้อความ SMS แบบข้อความโดยไม่ต้องเขียนถึงผู้ให้บริการ SMS: sendTextMessageWithoutPersisting

CarrierConfigManager

  • วิธีการแจ้งการเปลี่ยนแปลงการกำหนดค่า: notifyConfigChangedForSubId
  • วิธีรับการกำหนดค่าผู้ให้บริการสำหรับการสมัครสมาชิกเริ่มต้น: getConfig
  • วิธีรับการกำหนดค่าผู้ให้บริการสำหรับการสมัครสมาชิกที่ระบุ: getConfigForSubId

สำหรับคำแนะนำ โปรดดู การกำหนดค่าผู้ให้บริการ

BugreportManager

วิธีการเริ่มรายงานข้อผิดพลาดในการเชื่อมต่อ ซึ่งเป็นเวอร์ชันเฉพาะของรายงานข้อบกพร่องที่มีเฉพาะข้อมูลสำหรับการดีบักปัญหาที่เกี่ยวข้องกับการเชื่อมต่อ: startConnectivityBugreport

NetworkStatsManager

  • วิธีการค้นหาสรุปการใช้งานเครือข่าย: querySummary
  • วิธีการสืบค้นประวัติการใช้งานเครือข่าย: queryDetails
  • วิธีการลงทะเบียนหรือยกเลิกการลงทะเบียนการโทรกลับการใช้งานเครือข่าย:

ImsMmTelผู้จัดการ

ImsRcsผู้จัดการ

ผู้จัดการการจัดเตรียม

EuiccManager

วิธีเปลี่ยนเป็น (เปิดใช้งาน) การสมัครสมาชิกที่กำหนด: switchToSubscription

CarrierMessagingService

บริการรับสายจากระบบเมื่อมีการส่งหรือรับ SMS และ MMS ใหม่ หากต้องการขยายคลาสนี้ ให้ประกาศบริการในไฟล์รายการของคุณด้วยสิทธิ์ android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE และรวมตัวกรองเจตนาด้วยการดำเนินการ #SERVICE_INTERFACE วิธีการรวมถึง:

  • วิธีการกรองข้อความ SMS ขาเข้า: onFilterSms
  • วิธีสกัดกั้นข้อความ SMS ที่ส่งจากอุปกรณ์: onSendTextSms
  • วิธีการสกัดกั้นข้อความ SMS ไบนารีที่ส่งจากอุปกรณ์: onSendDataSms
  • วิธีสกัดกั้นข้อความ SMS ขนาดยาวที่ส่งจากอุปกรณ์: onSendMultipartTextSms
  • วิธีสกัดกั้นข้อความ MMS ที่ส่งจากอุปกรณ์: onSendMms
  • วิธีดาวน์โหลดข้อความ MMS ที่ได้รับ: onDownloadMms

CarrierService

บริการที่แสดงฟังก์ชันเฉพาะของผู้ให้บริการแก่ระบบ หากต้องการขยายคลาสนี้ ให้ประกาศบริการในไฟล์ Manifest ของแอปด้วยสิทธิ์ android.Manifest.permission#BIND_CARRIER_SERVICES และรวมตัวกรองเจตนากับการดำเนินการ CARRIER_SERVICE_INTERFACE หากบริการมีการผูกระยะยาว ให้ตั้งค่า android.service.carrier.LONG_LIVED_BINDING เป็น true ในข้อมูลเมตาของบริการ

แพลตฟอร์มดังกล่าวผูก CarrierService ด้วยแฟล็กพิเศษเพื่อให้กระบวนการบริการของผู้ให้บริการทำงานใน บัคเก็ตสแตนด์บายแอป พิเศษ การทำเช่นนี้เป็นการยกเว้นแอปบริการของผู้ให้บริการจาก การจำกัดการไม่ได้ใช้งานแอป และทำให้แอปมีโอกาสคงอยู่มากขึ้นเมื่อหน่วยความจำอุปกรณ์เหลือน้อย อย่างไรก็ตาม หากแอปบริการของผู้ให้บริการขัดข้องไม่ว่าด้วยเหตุผลใดก็ตาม แอปจะสูญเสียสิทธิ์ข้างต้นทั้งหมดจนกว่าแอปจะรีสตาร์ทและการเชื่อมโยงจะถูกสร้างขึ้นใหม่ ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องทำให้แอปบริการของผู้ให้บริการมีความเสถียร

วิธีการใน CarrierService รวมถึง:

  • หากต้องการแทนที่และตั้งค่าการกำหนดค่าเฉพาะของผู้ให้บริการ: onLoadConfig
  • หากต้องการแจ้งระบบเกี่ยวกับการเปลี่ยนแปลงเครือข่ายผู้ให้บริการที่จะเกิดขึ้นโดยเจตนาโดยแอปพลิเคชันผู้ให้บริการ: notifyCarrierNetworkChange

ผู้ให้บริการโทรศัพท์

API ผู้ให้บริการเนื้อหาเพื่ออนุญาตให้แก้ไข (แทรก ลบ อัปเดต สืบค้น) กับฐานข้อมูลระบบโทรศัพท์ ฟิลด์ค่าถูกกำหนดไว้ที่ Telephony.Carriers ; สำหรับรายละเอียดเพิ่มเติม โปรดดูการอ้างอิงคลาส Telephony

คำแนะนำเครือข่าย Wifi

เมื่อสร้างอ็อบเจ็กต์ WifiNetworkSuggestion ให้ใช้วิธีการต่อไปนี้เพื่อตั้งค่า ID การสมัครสมาชิกหรือกลุ่มการสมัครสมาชิก:

  • วิธีตั้งค่า ID การสมัครสมาชิก: setSubscriptionId
  • วิธีตั้งค่ากลุ่มการสมัครสมาชิก: setSubscriptionGroup

แพลตฟอร์มแอนดรอยด์

บน UICC ที่ตรวจพบ แพลตฟอร์มจะสร้างอ็อบเจ็กต์ UICC ภายในที่มีกฎสิทธิ์ของผู้ให้บริการเป็นส่วนหนึ่งของ UICC UiccCarrierPrivilegeRules.java โหลดกฎ แยกวิเคราะห์จากการ์ด UICC และแคชไว้ในหน่วยความจำ เมื่อจำเป็นต้องตรวจสอบสิทธิ์ UiccCarrierPrivilegeRules จะเปรียบเทียบใบรับรองผู้โทรกับกฎของตนเองทีละรายการ ถ้าเอา UICC ออก กฎจะถูกทำลายพร้อมกับอ็อบเจ็กต์ UICC

การตรวจสอบ

ในการตรวจสอบการใช้งานผ่าน Compatibility Test Suite (CTS) โดยใช้ CtsCarrierApiTestCases.apk คุณต้องมี UICC สำหรับนักพัฒนาที่มีกฎ UICC ที่ถูกต้องหรือรองรับ ARF ขอให้ผู้จำหน่ายซิมการ์ดที่คุณเลือกเตรียม UICC สำหรับนักพัฒนาด้วย ARF ที่ถูกต้องตามที่อธิบายไว้ในส่วนนี้ และใช้ UICC นั้นเพื่อเรียกใช้การทดสอบ UICC ไม่ต้องการบริการเซลลูลาร์ที่ใช้งานอยู่เพื่อให้ผ่านการทดสอบ CTS

จัดทำยูไอซีซี

สำหรับ 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

หากต้องการเรียกใช้การทดสอบ API ของผู้ให้บริการ CTS ใน Android 12 อุปกรณ์จะต้องใช้ซิมที่มีสิทธิ์ของผู้ให้บริการ CTS ที่ตรงตามข้อกำหนดที่ระบุไว้ในข้อกำหนด โปรไฟล์การทดสอบ GSMA TS.48 ของบุคคลที่สาม เวอร์ชันล่าสุด

ซิมเดียวกันนี้ยังใช้กับเวอร์ชันก่อน Android 12 ได้อีกด้วย

การแก้ไขโปรไฟล์ CTS SIM

  1. เพิ่ม: สิทธิ์ผู้ให้บริการ CTS ในแอ็พพลิเคชันหลักการเข้าถึงกฎ (ARA-M) หรือ ARF ลายเซ็นทั้งสองต้องเข้ารหัสในกฎสิทธิ์ของผู้ให้บริการ:
    1. 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 (EF) ไม่มีอยู่ใน 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
      • เนื้อหา: 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 ใน EF ตามลำดับที่มีการกำหนดนี้:
    1. EF_SPN (USIM/6F46)
      • เนื้อหา: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • เนื้อหา: Rec1 430B83413759FE4E934143EA14FF..FF

จับคู่โครงสร้างโปรไฟล์การทดสอบ

ดาวน์โหลดและจับคู่โครงสร้างโปรไฟล์การทดสอบทั่วไปต่อไปนี้ เวอร์ชันล่าสุด โปรไฟล์เหล่านี้จะไม่มีกฎสิทธิ์ของ CTS Carrier Privilege ในแบบของคุณหรือการปรับเปลี่ยนอื่นๆ ตามรายการด้านบน

การทดสอบการทำงาน

เพื่อความสะดวก CTS รองรับโทเค็นอุปกรณ์ที่จำกัดการทดสอบให้ทำงานบนอุปกรณ์ที่กำหนดค่าด้วยโทเค็นเดียวกันเท่านั้น การทดสอบผู้ให้บริการ API CTS รองรับโทเค็นอุปกรณ์ sim-card-with-certs ตัวอย่างเช่น โทเค็นอุปกรณ์ต่อไปนี้จำกัดการทดสอบ API ของผู้ให้บริการให้ทำงานบนอุปกรณ์ abcd1234 เท่านั้น :

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

เมื่อเรียกใช้การทดสอบโดยไม่ใช้โทเค็นอุปกรณ์ การทดสอบจะทำงานบนอุปกรณ์ทั้งหมด

คำถามที่พบบ่อย

จะอัปเดตใบรับรองใน UICC ได้อย่างไร

ตอบ: ใช้กลไกการอัปเดต OTA ของการ์ดที่มีอยู่

UICC อยู่ร่วมกับหลักเกณฑ์อื่นได้หรือไม่?

ตอบ: เป็นเรื่องปกติที่จะมีกฎความปลอดภัยอื่นๆ ใน UICC ภายใต้ AID เดียวกัน แพลตฟอร์มจะกรองพวกเขาออกโดยอัตโนมัติ

จะเกิดอะไรขึ้นเมื่อ UICC ถูกลบออกสำหรับแอปที่ใช้ใบรับรอง

ตอบ: แอปสูญเสียสิทธิ์เนื่องจากกฎที่เกี่ยวข้องกับ UICC ถูกทำลายเมื่อนำ UICC ออก

มีการจำกัดจำนวนใบรับรองใน UICC หรือไม่

ตอบ: แพลตฟอร์มไม่จำกัดจำนวนใบรับรอง แต่เนื่องจากการตรวจสอบเป็นแบบเชิงเส้น กฎที่มากเกินไปอาจใช้เวลาแฝงสำหรับการตรวจสอบ

มีการจำกัดจำนวน API ที่เราสามารถรองรับด้วยวิธีนี้หรือไม่?

ตอบ: ไม่ แต่เราจำกัดขอบเขตเฉพาะ API ที่เกี่ยวข้องกับผู้ให้บริการ

มี API บางตัวที่ห้ามใช้วิธีนี้หรือไม่? ถ้าเป็นเช่นนั้น คุณจะบังคับใช้อย่างไร (นั่นคือ คุณมีการทดสอบเพื่อตรวจสอบว่า API ใดรองรับวิธีนี้หรือไม่)

ตอบ: ดูส่วน ความเข้ากันได้ของพฤติกรรม API ของเอกสารนิยามความเข้ากันได้ของ Android (CDD) เรามีการทดสอบ CTS เพื่อให้แน่ใจว่ารูปแบบสิทธิ์ของ API จะไม่เปลี่ยนแปลง

สิ่งนี้ทำงานร่วมกับคุณสมบัติหลายซิมได้อย่างไร

ตอบ: ใช้ซิมเริ่มต้นที่ผู้ใช้ระบุ

สิ่งนี้โต้ตอบหรือทับซ้อนกับเทคโนโลยีการเข้าถึง SE อื่น ๆ เช่น SEEK ในทางใดทางหนึ่งหรือไม่

ตอบ: ตัวอย่างเช่น SEEK ใช้ AID แบบเดียวกับใน UICC ดังนั้นกฎจึงอยู่ร่วมกันและถูกกรองโดย SEEK หรือ UiccCarrierPrivileges

เมื่อใดควรตรวจสอบสิทธิพิเศษของผู้ให้บริการ

ตอบ: หลังจากสถานะซิมโหลดออกอากาศ

OEM สามารถปิดการใช้งานบางส่วนของ API ของผู้ให้บริการได้หรือไม่

ตอบ: ไม่ เราเชื่อว่า API ปัจจุบันเป็นชุดขั้นต่ำ และเราวางแผนที่จะใช้บิตมาสก์เพื่อการควบคุมความละเอียดที่ละเอียดยิ่งขึ้นในอนาคต

setOperatorBrandOverride แทนที่สตริงชื่อโอเปอเรเตอร์รูปแบบอื่นทั้งหมดหรือไม่ ตัวอย่างเช่น SE13, UICC SPN หรือ NITZ บนเครือข่าย

ใช่ การแทนที่แบรนด์ของผู้ให้บริการมีความสำคัญสูงสุด เมื่อตั้งค่าแล้ว จะแทนที่สตริงชื่อตัวดำเนินการรูปแบบอื่นๆ ทั้งหมด

การเรียกใช้เมธอด injectSmsPdu ทำอะไร

ตอบ: วิธีนี้ช่วยอำนวยความสะดวกในการสำรอง/กู้คืน SMS ในระบบคลาวด์ การเรียก injectSmsPdu เปิดใช้งานฟังก์ชันการคืนค่า

สำหรับการกรอง SMS การโทร onFilterSms ขึ้นอยู่กับการกรองพอร์ต SMS UDH หรือไม่ หรือแอปของผู้ให้บริการสามารถเข้าถึง SMS ขาเข้าทั้งหมดได้หรือไม่

ตอบ: ผู้ให้บริการสามารถเข้าถึงข้อมูล SMS ทั้งหมดได้

ส่วนขยายของ DeviceAppID-REF-DO เพื่อรองรับ 32 ไบต์ดูเหมือนจะเข้ากันไม่ได้กับข้อมูลจำเพาะ GP ปัจจุบัน (ซึ่งอนุญาต 0 หรือ 20 ไบต์เท่านั้น) เหตุใดคุณจึงแนะนำการเปลี่ยนแปลงนี้ SHA-1 ไม่เพียงพอต่อการหลีกเลี่ยงการชนใช่หรือไม่ คุณได้เสนอการเปลี่ยนแปลงนี้กับ GP แล้ว เนื่องจากการเปลี่ยนแปลงนี้อาจใช้ร่วมกันไม่ได้กับ ARA-M/ARF ที่มีอยู่

ตอบ: เพื่อการรักษาความปลอดภัยที่รองรับอนาคต ส่วนขยายนี้แนะนำ SHA-256 สำหรับ DeviceAppID-REF-DO นอกเหนือจาก SHA-1 ซึ่งปัจจุบันเป็นตัวเลือกเดียวในมาตรฐาน GP SEAC ขอแนะนำให้ใช้ SHA-256

หาก DeviceAppID เป็น 0 (ว่าง) คุณจะใช้กฎกับแอปในอุปกรณ์ทั้งหมดที่ไม่อยู่ในกฎเฉพาะหรือไม่

ตอบ: Carrier API จำเป็นต้องมีการเติมข้อมูล DeviceAppID-REF-DO การว่างเปล่ามีจุดประสงค์เพื่อการทดสอบและไม่แนะนำสำหรับการปรับใช้ในการดำเนินงาน

ตามข้อมูลจำเพาะของคุณ PKG-REF-DO ที่ใช้โดยลำพัง ไม่ควรยอมรับโดยไม่มี DeviceAppID-REF-DO แต่ยังคงอธิบายไว้ในตาราง 6-4 ของข้อมูลจำเพาะว่าเป็นการขยายคำจำกัดความของ REF-DO นี่เป็นความตั้งใจหรือไม่? รหัสทำงานอย่างไรเมื่อใช้เฉพาะ PKG-REF-DO ใน REF-DO

ตอบ: ตัวเลือกในการมี PKG-REF-DO เป็นรายการค่าเดียวใน REF-DO ถูกลบออกในเวอร์ชันล่าสุด PKG-REF-DO ควรเกิดขึ้นร่วมกับ DeviceAppID-REF-DO เท่านั้น

เราถือว่าเราสามารถให้สิทธิ์การเข้าถึงตามสิทธิ์ของผู้ให้บริการทั้งหมดหรือมีการควบคุมที่ละเอียดยิ่งขึ้น ถ้าเป็นเช่นนั้น อะไรกำหนดการแมประหว่างบิตมาสก์และการอนุญาตจริง หนึ่งสิทธิ์ต่อชั้นเรียน? หนึ่งสิทธิ์ต่อวิธี? 64 สิทธิ์แยกกันเพียงพอในระยะยาวหรือไม่

ตอบ: สิ่งนี้สงวนไว้สำหรับอนาคต และเรายินดีรับฟังข้อเสนอแนะ

คุณสามารถกำหนด DeviceAppID สำหรับ Android โดยเฉพาะเพิ่มเติมได้หรือไม่ นี่คือค่าแฮช SHA-1 (20 ไบต์) ของใบรับรอง Publisher ที่ใช้ในการลงนามแอปที่กำหนด ดังนั้นชื่อไม่ควรสะท้อนถึงวัตถุประสงค์นั้นใช่หรือไม่ (ชื่อนี้อาจทำให้ผู้อ่านหลายคนสับสน เนื่องจากกฎนี้มีผลกับแอปทั้งหมดที่ลงนามด้วยใบรับรองผู้เผยแพร่เดียวกันนั้น)

ตอบ: ใบรับรองการจัดเก็บ DeviceAppID ได้รับการสนับสนุนโดยข้อมูลจำเพาะที่มีอยู่ เราพยายามลดการเปลี่ยนแปลงข้อมูลจำเพาะเพื่อลดอุปสรรคในการนำไปใช้ สำหรับรายละเอียด โปรดดู กฎบน UICC