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

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

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

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

กฎบน UICC

พื้นที่เก็บข้อมูลใน UICC สามารถใช้งานร่วมกับ แพลตฟอร์มระดับโลก ข้อกำหนดของการควบคุมการเข้าถึงองค์ประกอบความปลอดภัย ตัวระบุแอป (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 ในสตริงเลขฐาน 16 คือ

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

เครื่องมือจัดการการสมัครใช้บริการ

เครื่องมือจัดการ SMS

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

CarrierConfigManager

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

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

BugreportManager

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

ผู้จัดการสถิติเครือข่าย

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

ImsMmTelManager

ImsRcsManager

เครื่องมือจัดการการจัดสรร

EuiccManager

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

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

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

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

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

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

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

  • วิธีตั้งรหัสการสมัครใช้บริการ setSubscriptionId
  • Metohd เพื่อตั้งค่ากลุ่มการสมัครสมาชิก: 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

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

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

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

  1. เพิ่ม: สิทธิ์ของผู้ให้บริการ CTS ใน แอปหลักกฎการเข้าถึง (ARA-M) หรือ ARF ลายเซ็นทั้ง 2 แบบต้องเป็น เข้ารหัสในกฎสิทธิ์ของผู้ให้บริการ ดังนี้
    1. แฮช1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. แฮช2(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, 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 (ว่าง) คุณจะนํากฎไปใช้กับแอปทั้งหมดในอุปกรณ์ที่ไม่ได้อยู่ภายใต้กฎที่เฉพาะเจาะจงไหม

ตอบ: ต้องป้อนข้อมูล 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