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

ตัวอย่างเนื้อหา ACRF ในสตริงเลขฐาน 16

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

TelephonyCallback มีอินเทอร์เฟซที่มีเมธอดการเรียกกลับเพื่อ แจ้งให้แอปที่เรียกใช้ทราบเมื่อสถานะที่ลงทะเบียนมีการเปลี่ยนแปลง

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

SubscriptionManager

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

SmsManager

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

CarrierConfigManager

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

โปรดดูวิธีการที่การกำหนดค่าผู้ให้บริการ

BugreportManager

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

NetworkStatsManager

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

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

วิธีเปลี่ยนไปใช้ (เปิดใช้) การสมัครใช้บริการที่ระบุ switchToSubscription

CarrierMessagingService

บริการที่รับสายจากระบบเมื่อมีการส่งหรือรับ 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

CarrierService

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

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

วิธีการใน CarrierService มีดังนี้

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

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

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

WifiNetworkSuggestion

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

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

แพลตฟอร์ม Android

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

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

นอกจากนี้ คุณยังใช้ซิมเดียวกันกับ Android เวอร์ชันก่อนหน้า 12 ได้ด้วย

แก้ไขโปรไฟล์ซิม CTS

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

ทำการทดสอบ

CTS รองรับโทเค็นอุปกรณ์ที่จำกัด การทดสอบให้ทำงานเฉพาะในอุปกรณ์ที่กำหนดค่าด้วยโทเค็นเดียวกันเพื่อความสะดวก CTS ของ Carrier API รองรับโทเค็นอุปกรณ์ 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 ปัจจุบันเป็นชุด API ขั้นต่ำ และเรา วางแผนที่จะใช้บิตมาสก์เพื่อควบคุมระดับการเข้าถึงที่ละเอียดยิ่งขึ้นในอนาคต

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

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

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

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

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

ตอบ: 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 เท่านั้น

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

ตอบ: ฟีเจอร์นี้จะพร้อมใช้งานในอนาคต และเรายินดีรับฟังคำแนะนำ

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

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