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

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

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

ผู้ให้บริการสามารถควบคุม 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 ต่อไปนี้

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

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

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

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

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

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

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

เครื่องมือจัดการการกำหนดค่าของผู้ให้บริการ

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

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

เครื่องมือจัดการรายงานข้อบกพร่อง

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

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

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

ImsMmTelManager

ImsRcsManager

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

ผู้จัดการ Euicc

วิธีการเปลี่ยนเป็น (เปิดใช้) การสมัครใช้บริการที่ระบุ 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

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

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

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

แพลตฟอร์ม Android

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

การตรวจสอบความถูกต้อง

เพื่อตรวจสอบการติดตั้งใช้งานผ่าน ความเข้ากันได้ Test Suite (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_ข้อมูล (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 ของ 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 ในปัจจุบันเป็นชุดตัวขั้นต่ำ และเรา วางแผนที่จะใช้บิตมาสก์เพื่อการควบคุมแบบละเอียดในอนาคต

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