สิทธิ์ของผู้ให้บริการ UICC

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

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

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

กฎบน UICC

พื้นที่เก็บข้อมูลใน UICC ใช้ได้กับ ข้อกำหนดการควบคุมการเข้าถึงองค์ประกอบที่ปลอดภัยของ GlobalPlatform ตัวระบุแอป (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 จะพยายามเลือกแอปพลิเคชันกฎการเข้าถึง (ARA) AID A00000015141434C00 เป็นครั้งแรก หากไม่พบ AID ใน UICC ระบบจะกลับไปใช้ ARF โดยเลือก AID PKCS15 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 ต่อไปนี้

เครื่องมือจัดการโทรศัพท์

การติดต่อกลับทางโทรศัพท์

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

  • ไฟแสดงข้อความรอรับมีการเปลี่ยนแปลงดังนี้ onMessageWaitingIndicatorChanged
  • สัญญาณบอกสถานะการโอนสายมีการเปลี่ยนแปลง: onCallForwardingIndicatorChanged
  • สาเหตุที่ทำให้สายจากระบบมัลติมีเดียอินเทอร์เน็ต (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
  • วิธีลงทะเบียนหรือยกเลิกการลงทะเบียน Callback ของการใช้งานเครือข่าย

ImsMmTelManager

ImsRcsManager

ProvisioningManager

ผู้จัดการ Euicc

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

เมธอดใน CarrierService มีดังนี้

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

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

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

คำแนะนำเครือข่าย Wi-Fi

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

  • วิธีตั้งค่ารหัสการสมัครใช้บริการ 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 อุปกรณ์ต้องใช้ SIM ที่มีสิทธิ์ของผู้ให้บริการ 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 ออก

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

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

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

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

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

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

ฟีเจอร์นี้ทำงานร่วมกับฟีเจอร์หลายซิมอย่างไร

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

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

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

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

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

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

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

setOperatorBrandOverride ลบล้างรูปแบบอื่นๆ ทั้งหมดของสตริงชื่อโอเปอเรเตอร์ไหม เช่น SE13, SPN ของ UICC หรือ 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 (ว่าง) คุณจะนํากฎไปใช้กับแอปทั้งหมดในอุปกรณ์ที่ไม่ได้อยู่ภายใต้กฎที่เฉพาะเจาะจงไหม

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

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

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

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

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