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

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

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

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

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

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

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

กฎ UICC ใช้ลำดับชั้นข้อมูลต่อไปนี้ (ตัวอักษรสองตัวและตัวเลขรวมกันในวงเล็บคือแท็กอ็อบเจ็กต์) แต่ละกฎคือ 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 คือที่อยู่สำหรับ ACCF ซึ่งประกอบด้วยแฮชใบรับรอง 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . แอปที่ลงนามโดยใบรับรองนี้จะได้รับสิทธิ์ของผู้ให้บริการ

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

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

TelephonyManager

โทรกลับ

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

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

SubscriptionManager

  • วิธีการรับข้อมูลการสมัครสมาชิกต่างๆ:
  • วิธีรับจำนวนการสมัครสมาชิกที่ใช้งานอยู่: getActiveSubscriptionInfoCount
  • วิธีการจัดการกลุ่มการสมัครสมาชิก:
  • วิธีการรับหรือตั้งค่าคำอธิบายของแผนความสัมพันธ์การเรียกเก็บเงินระหว่างผู้ให้บริการขนส่งและผู้สมัครสมาชิกรายใดรายหนึ่ง:
  • วิธีการแทนที่แผนความสัมพันธ์การเรียกเก็บเงินชั่วคราวระหว่างผู้ให้บริการและผู้สมัครสมาชิกรายใดรายหนึ่งที่จะพิจารณาว่าไม่มีการตรวจวัด: setSubscriptionOverrideUnmetered
  • วิธีการแทนที่แผนความสัมพันธ์การเรียกเก็บเงินชั่วคราวระหว่างผู้ให้บริการและผู้สมัครสมาชิกรายใดรายหนึ่งที่จะพิจารณาว่าแออัด: setSubscriptionOverrideCongested
  • วิธีการตรวจสอบว่าแอปพลิเคชันที่มีบริบทที่กำหนดได้รับอนุญาตให้จัดการการสมัครสมาชิกที่กำหนดตามข้อมูลเมตาหรือไม่: canManageSubscription

ผู้จัดการฝ่าย SMS

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

CarrierConfigManager

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

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

BugreportManager

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

NetworkStatsManager

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

ImsMmTelManager

ImsRcsผู้จัดการ

ProvisioningManager

Euicผู้จัดการ

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

บริการส่งข้อความของผู้ให้บริการ

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

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

ผู้ให้บริการบริการ

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

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

วิธีการใน CarrierService ประกอบด้วย:

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

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

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

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

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

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

แพลตฟอร์ม Android

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

การตรวจสอบ

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

เตรียม 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

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

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

การปรับเปลี่ยนโปรไฟล์ CTS SIM

  1. เพิ่ม: สิทธิ์ของผู้ให้บริการ CTS ในแอปพลิเคชันหลักกฎการเข้าถึง (ARA-M) หรือ 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. 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 รองรับโทเค็นอุปกรณ์ที่จำกัดการทดสอบให้ทำงานบนอุปกรณ์ที่กำหนดค่าด้วยโทเค็นเดียวกันเท่านั้น การทดสอบ Carrier 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 ไบต์) ของใบรับรองผู้เผยแพร่ที่ใช้ในการลงนามแอปที่กำหนด ดังนั้นชื่อไม่ควรสะท้อนถึงวัตถุประสงค์ดังกล่าวใช่หรือไม่ (ชื่อนี้อาจทำให้ผู้อ่านหลายคนสับสนได้ เนื่องจากกฎดังกล่าวจะมีผลกับแอปทั้งหมดที่ลงนามด้วยใบรับรองผู้เผยแพร่เดียวกัน)

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