สิทธิ์ของผู้ให้บริการ 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 ต่อไปนี้

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

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

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

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

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

WifiNetworkSuggestion

เมื่อสร้างออบเจ็กต์ 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 เวอร์ชันก่อนหน้า Android 12 ได้ด้วย

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

  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 Carrier Privilege ที่ปรับเปลี่ยนในแบบของคุณหรือการแก้ไขอื่นๆ ที่ระบุไว้ข้างต้น

เรียกใช้การทดสอบ

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

ตอบ: 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