قدم Android 5.1 آلية لمنح امتيازات خاصة لواجهات برمجة التطبيقات ذات الصلة بمالكي تطبيقات بطاقة الدوائر المتكاملة العالمية (UICC). يقوم نظام Android الأساسي بتحميل الشهادات المخزنة على UICC ويمنح الإذن للتطبيقات الموقعة بواسطة هذه الشهادات لإجراء مكالمات إلى عدد قليل من واجهات برمجة التطبيقات الخاصة.
قام Android 7.0 بتوسيع هذه الميزة لدعم مصادر التخزين الأخرى لقواعد امتيازات شركات الاتصالات UICC، مما أدى إلى زيادة كبيرة في عدد شركات الاتصالات التي يمكنها استخدام واجهات برمجة التطبيقات. للحصول على مرجع API، راجع CarrierConfigManager ; للحصول على التعليمات، راجع تكوين الناقل .
تتمتع شركات الاتصالات بالتحكم الكامل في UICC، لذا توفر هذه الآلية طريقة آمنة ومرنة لإدارة التطبيقات من مشغل شبكة الهاتف المحمول (MNO) المستضاف على قنوات توزيع التطبيقات العامة (مثل Google Play) مع الاحتفاظ بامتيازات خاصة على الأجهزة ودون الحاجة لتوقيع التطبيقات باستخدام شهادة النظام الأساسي لكل جهاز أو التثبيت المسبق كتطبيق نظام.
قواعد UICC
التخزين في UICC متوافق مع مواصفات GlobalPlatform Secure Element Access Control . معرف التطبيق (AID) الموجود على البطاقة هو A00000015141434C00
، ويتم استخدام أمر GET DATA
القياسي لجلب القواعد المخزنة على البطاقة. يمكنك تحديث هذه القواعد من خلال تحديثات البطاقة عبر الأثير (OTA).
التسلسل الهرمي للبيانات
تستخدم قواعد UICC التسلسل الهرمي للبيانات التالي (مجموعة الأحرف والأرقام المكونة من حرفين بين قوسين هي علامة الكائن). كل قاعدة هي 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
) هي سلسلة اسم الحزمة الكاملة المحددة في البيان، بتشفير 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 عن طريق تحديد 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
. يتم منح التطبيقات الموقعة بهذه الشهادة امتيازات مشغل شبكة الجوال.
واجهات برمجة التطبيقات الممكّنة
يدعم Android واجهات برمجة التطبيقات التالية.
مدير الهاتف
- طريقة للسماح لتطبيق الناقل بمطالبة UICC بالتحدي/الاستجابة:
getIccAuthentication
. - طريقة التحقق مما إذا كان تطبيق الاتصال قد تم منحه امتيازات مشغل شبكة الجوال:
hasCarrierPrivileges
. - طرق تجاوز العلامة التجارية والرقم:
- طرق الاتصال المباشر بـ UICC:
- طريقة ضبط وضع الجهاز على الوضع العمومي:
setPreferredNetworkTypeToGlobal
. - طرق الحصول على هويات الجهاز أو الشبكة:
- الهوية الدولية للأجهزة المحمولة (IMEI):
getImei
- معرف الجهاز المحمول (MEID):
getMeid
- معرف الوصول إلى الشبكة (NAI):
getNai
- الرقم التسلسلي لبطاقة SIM:
getSimSerialNumber
- الهوية الدولية للأجهزة المحمولة (IMEI):
- طريقة الحصول على تكوين الناقل:
getCarrierConfig
- طريقة الحصول على نوع الشبكة لنقل البيانات:
getDataNetworkType
- طريقة الحصول على نوع الشبكة للخدمة الصوتية:
getVoiceNetworkType
- طرق الحصول على معلومات حول تطبيق UICC SIM (USIM):
- الرقم التسلسلي لبطاقة SIM:
getSimSerialNumber
- معلومات البطاقة:
getUiccCardsInfo
- GID1 (مستوى معرف المجموعة 1):
getGroupIdLevel1
- سلسلة رقم الهاتف للسطر 1:
getLine1Number
- شبكة الهاتف المحمول الأرضية العامة المحظورة (PLMN):
getForbiddenPlmns
- أي ما يعادل المنزل PLMN:
getEquivalentHomePlmns
- الرقم التسلسلي لبطاقة SIM:
- طرق الحصول على رقم البريد الصوتي أو تعيينه:
- طريقة إرسال رمز الاتصال الخاص:
sendDialerSpecialCode
- طريقة إعادة ضبط مودم الراديو:
rebootModem
- طرق الحصول على أوضاع اختيار الشبكة أو ضبطها:
- طريقة طلب فحص الشبكة:
requestNetworkScan
- طرق الحصول على أو تعيين أنواع الشبكات المسموح بها/المفضلة:
- طرق التحقق من تمكين بيانات الجوال أو التجوال حسب إعدادات المستخدم:
- طرق التحقق من اتصال البيانات أو ضبطه مع السبب:
- طريقة الحصول على قائمة أرقام الطوارئ:
getEmergencyNumberList
- أساليب السيطرة على الشبكات الانتهازية:
- طرق ضبط أو مسح طلب تحديث قوة الإشارة الخلوية:
رد الاتصال الهاتفي
يحتوي TelephonyCallback
على واجهات مع طريقة رد اتصال لإعلام تطبيق الاتصال عند تغيير الحالات المسجلة:
- تغير مؤشر انتظار الرسالة:
onMessageWaitingIndicatorChanged
- تم تغيير مؤشر تحويل المكالمات:
onCallForwardingIndicatorChanged
- تم تغيير سبب قطع اتصال نظام الوسائط المتعددة IP (IMS):
onImsCallDisconnectCauseChanged
- تم تغيير حالة اتصال البيانات الدقيقة:
onPreciseDataConnectionStateChanged
- تم تغيير قائمة أرقام الطوارئ الحالية:
onEmergencyNumberListChanged
- تم تغيير معرف اشتراك البيانات النشط:
onActiveDataSubscriptionIdChanged
- تغيرت شبكة الناقل:
onCarrierNetworkChange
- فشل تسجيل الشبكة أو تحديث الموقع/التوجيه/منطقة التتبع:
onRegistrationFailed
- تغيير معلومات الحظر:
onBarringInfoChanged
- تم تغيير تكوين القناة الفعلية الحالي:
onPhysicalChannelConfigChanged
مدير الاشتراكات
- طرق الحصول على معلومات الاشتراك المختلفة:
- طريقة الحصول على عدد الاشتراكات النشطة:
getActiveSubscriptionInfoCount
- طرق إدارة مجموعات الاشتراك:
- طرق الحصول على أو تعيين وصف خطة علاقة الفوترة بين شركة الاتصالات ومشترك محدد:
- طريقة لتجاوز خطة علاقة الفوترة مؤقتًا بين شركة النقل ومشترك محدد لاعتبارها غير محدودة:
setSubscriptionOverrideUnmetered
- طريقة لتجاوز خطة علاقة الفوترة مؤقتًا بين شركة النقل ومشترك محدد لاعتبارها مزدحمة:
setSubscriptionOverrideCongested
- طريقة للتحقق مما إذا كان التطبيق ذو السياق المحدد مصرحًا له بإدارة الاشتراك المحدد وفقًا لبياناته التعريفية:
canManageSubscription
com.SmsManager
- طريقة السماح للمتصل بإنشاء رسائل SMS واردة جديدة:
injectSmsPdu
. - طريقة إرسال رسالة نصية قصيرة SMS دون الكتابة إلى موفر خدمة الرسائل القصيرة:
sendTextMessageWithoutPersisting
CarrierConfigManager
- طريقة الإعلام بتغيير التكوين:
notifyConfigChangedForSubId
. - طريقة الحصول على تكوين الناقل للاشتراك الافتراضي:
getConfig
- طريقة الحصول على تكوين الناقل للاشتراك المحدد:
getConfigForSubId
للحصول على التعليمات، راجع تكوين الناقل .
BugreportManager
طريقة لبدء تقرير أخطاء الاتصال، وهو إصدار متخصص من تقرير الأخطاء الذي يتضمن معلومات فقط لتصحيح أخطاء المشكلات المتعلقة بالاتصال: startConnectivityBugreport
مدير إحصائيات الشبكة
- طريقة الاستعلام عن ملخص استخدام الشبكة:
querySummary
- طريقة الاستعلام عن سجل استخدام الشبكة:
queryDetails
- طرق تسجيل أو إلغاء تسجيل رد اتصال استخدام الشبكة:
ImsMmTelManager
- طرق تسجيل أو إلغاء تسجيل رد اتصال تسجيل IMS MmTel:
ImsRcsManager
- طرق تسجيل أو إلغاء تسجيل رد اتصال تسجيل IMS RCS:
- طرق الحصول على حالة تسجيل IMS أو نوع النقل:
ProvisioningManager
- طرق تسجيل وإلغاء تسجيل رد اتصال تحديثات توفير ميزات IMS:
- الطرق المتعلقة بحالة التزويد بإمكانية IMS MmTel أو RCS:
EuiccManager
طريقة التبديل إلى (تمكين) الاشتراك المحدد: switchToSubscription
خدمة الرسائل الناقلة
خدمة استقبال المكالمات من النظام عند إرسال أو استقبال رسائل SMS وMMS جديدة. لتوسيع هذه الفئة، أعلن عن الخدمة في ملف البيان الخاص بك باستخدام إذن android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
وقم بتضمين مرشح الغرض مع الإجراء #SERVICE_INTERFACE
. تشمل الطرق ما يلي:
- طريقة تصفية الرسائل القصيرة الواردة:
onFilterSms
- طريقة اعتراض الرسائل النصية القصيرة المرسلة من الجهاز:
onSendTextSms
- طريقة اعتراض رسائل SMS الثنائية المرسلة من الجهاز:
onSendDataSms
- طريقة اعتراض الرسائل القصيرة الطويلة المرسلة من الجهاز:
onSendMultipartTextSms
- طريقة اعتراض رسائل MMS المرسلة من الجهاز:
onSendMms
- طريقة تنزيل رسائل الوسائط المتعددة المستلمة:
onDownloadMms
خدمة الناقل
الخدمة التي تعرض وظائف خاصة بالناقل للنظام. لتوسيع هذه الفئة، أعلن عن الخدمة في ملف بيان التطبيق باستخدام إذن android.Manifest.permission#BIND_CARRIER_SERVICES
وقم بتضمين مرشح الغرض مع إجراء CARRIER_SERVICE_INTERFACE
. إذا كانت الخدمة تحتوي على ربط طويل الأمد، فاضبط android.service.carrier.LONG_LIVED_BINDING
على true
في البيانات التعريفية للخدمة.
يربط النظام الأساسي CarrierService
بعلامات خاصة للسماح بتشغيل عملية خدمة الناقل في مجموعة الاستعداد الخاصة للتطبيق . يؤدي هذا إلى إعفاء تطبيق خدمة الناقل من تقييد التطبيق في وضع الخمول ويزيد من احتمالية بقائه على قيد الحياة عندما تكون ذاكرة الجهاز منخفضة. ومع ذلك، إذا تعطل تطبيق خدمة الناقل لأي سبب من الأسباب، فإنه يفقد جميع الامتيازات المذكورة أعلاه حتى تتم إعادة تشغيل التطبيق وإعادة إنشاء الارتباط. لذلك من الضروري الحفاظ على استقرار تطبيق خدمة الناقل.
تتضمن الطرق الموجودة في CarrierService
ما يلي:
- لتجاوز التكوينات الخاصة بالناقل وتعيينها:
onLoadConfig
- لإبلاغ النظام بالتغيير المتعمد القادم لشبكة الناقل من خلال تطبيق الناقل:
notifyCarrierNetworkChange
مزود الهاتف
واجهات برمجة تطبيقات موفر المحتوى للسماح بإجراء تعديلات (إدراج أو حذف أو تحديث أو استعلام) على قاعدة البيانات الهاتفية. يتم تعريف حقول القيم في Telephony.Carriers
؛ لمزيد من التفاصيل، راجع مرجع فئة Telephony
اقتراح شبكة واي فاي
عند إنشاء كائن WifiNetworkSuggestion
، استخدم الطرق التالية لتعيين معرف الاشتراك أو مجموعة الاشتراك:
- طريقة تعيين معرف الاشتراك:
setSubscriptionId
- طريقة تعيين مجموعة الاشتراك:
setSubscriptionGroup
منصة أندرويد
على UICC المكتشف، يقوم النظام الأساسي بإنشاء كائنات UICC داخلية تتضمن قواعد امتياز الناقل كجزء من UICC. يقوم UiccCarrierPrivilegeRules.java
بتحميل القواعد، وتحليلها من بطاقة UICC، وتخزينها مؤقتًا في الذاكرة. عند الحاجة إلى التحقق من الامتيازات، تقوم UiccCarrierPrivilegeRules
بمقارنة شهادة المتصل بقواعدها الخاصة واحدة تلو الأخرى. إذا تمت إزالة UICC، فسيتم إتلاف القواعد مع كائن UICC.
تصديق
للتحقق من صحة التنفيذ من خلال مجموعة اختبار التوافق (CTS) باستخدام CtsCarrierApiTestCases.apk
، يجب أن يكون لديك مطور UICC لديه قواعد UICC الصحيحة أو دعم ARF. اطلب من بائع بطاقة SIM الذي تختاره إعداد مطور 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 في Android 12، يحتاج الجهاز إلى استخدام بطاقة SIM مع امتيازات الناقل CTS التي تلبي المتطلبات المحددة في أحدث إصدار من مواصفات ملف تعريف اختبار GSMA TS.48 التابع لجهة خارجية.
يمكن أيضًا استخدام نفس بطاقة SIM للإصدارات السابقة لنظام Android 12.
تعديل ملف تعريف CTS SIM
- إضافة: امتيازات حامل CTS في تطبيق قاعدة الوصول الرئيسي (ARA-M) أو ARF. يجب ترميز كلا التوقيعين في قواعد امتيازات الناقل:
- التجزئة1(SHA1)
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
-
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
- التجزئة1(SHA1)
- إنشاء: ملفات ADF USIM الأولية (EFs) غير موجودة في TS.48 وهي مطلوبة لـ CTS:
- EF_MBDN (6FC7)، حجم السجل: 28، رقم السجل: 4
- محتوى
- التوصية 1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-ن: FF…FF
- محتوى
- EF_EXT6 (6FC8)، حجم السجل: 13، رقم السجل: 1
- المحتوى: 00FF…FF
- EF_MBI (6FC9)، حجم السجل: 4، رقم السجل: 1
- المحتوى: التوصية 1: 01010101
- EF_MWIS (6FCA)، حجم السجل: 5، رقم السجل: 1
- المحتوى: 0000000000
- المحتوى: 00FF…FF
- EF_MBDN (6FC7)، حجم السجل: 28، رقم السجل: 4
- تعديل: جدول خدمة USIM: تمكين الخدمات رقم 47، رقم 48
- EF_UST (6F38)
- المحتوى:
9EFFBF1DFFFE0083410310010400406E01
- المحتوى:
- EF_UST (6F38)
- تعديل: ملفات DF-5GS وDF-SAIP
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- المحتوى:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- المحتوى:
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- المحتوى:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- المحتوى:
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- المحتوى:
A0020000FF…FF
- المحتوى:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- المحتوى:
A0020000FF…FF
- المحتوى:
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- تعديل: استخدم سلسلة اسم الناقل Android CTS في EFs المعنية التي تحتوي على هذا التعيين:
- EF_SPN (USIM/6F46)
- المحتوى:
01416E64726F696420435453FF..FF
- المحتوى:
- EF_PNN (USIM/6FC5)
- المحتوى:
Rec1 430B83413759FE4E934143EA14FF..FF
- المحتوى:
- EF_SPN (USIM/6F46)
مطابقة هيكل ملف تعريف الاختبار
قم بتنزيل أحدث إصدار من بنيات ملفات تعريف الاختبار العامة التالية ومطابقتها. لن تحتوي ملفات التعريف هذه على قاعدة CTS Carrier Privilege المخصصة أو التعديلات الأخرى المذكورة أعلاه.
تشغيل الاختبارات
من أجل الراحة، تدعم CTS رمزًا مميزًا للجهاز الذي يقيد الاختبارات ليتم تشغيلها فقط على الأجهزة التي تم تكوينها بنفس الرمز المميز. تدعم اختبارات Carrier API CTS رمز الجهاز المميز sim-card-with-certs
. على سبيل المثال، يعمل الرمز المميز للجهاز التالي على تقييد اختبارات API الخاصة بشركة الجوال بحيث يتم تشغيلها فقط على الجهاز abcd1234
:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
عند إجراء اختبار دون استخدام رمز مميز للجهاز، يتم تشغيل الاختبار على جميع الأجهزة.
التعليمات
كيف يمكن تحديث الشهادات على UICC؟
ج: استخدم آلية التحديث عبر الهواء للبطاقة الحالية.
هل يمكن لـ UICC التعايش مع القواعد الأخرى؟
ج: من الجيد أن يكون لديك قواعد أمان أخرى على UICC تحت نفس معرف AID؛ تقوم المنصة بتصفية هذه العناصر تلقائيًا.
ماذا يحدث عند إزالة UICC لتطبيق يعتمد على الشهادات الموجودة عليه؟
ج: يفقد التطبيق امتيازاته لأنه يتم إتلاف القواعد المرتبطة بـ UICC عند إزالة UICC.
هل هناك حد لعدد الشهادات في UICC؟
ج: المنصة لا تحدد عدد الشهادات؛ ولكن نظرًا لأن التحقق خطي، فقد يؤدي وجود عدد كبير جدًا من القواعد إلى حدوث زمن انتقال للتحقق.
هل هناك حد لعدد واجهات برمجة التطبيقات التي يمكننا دعمها بهذه الطريقة؟
ج: لا، ولكننا نحصر النطاق في واجهات برمجة التطبيقات ذات الصلة بشركة الاتصالات.
هل هناك بعض واجهات برمجة التطبيقات المحظورة من استخدام هذه الطريقة؟ إذا كان الأمر كذلك، كيف يمكنك تنفيذها؟ (أي هل لديك اختبارات للتحقق من صحة واجهات برمجة التطبيقات المدعومة بهذه الطريقة؟)
ج: راجع قسم التوافق السلوكي لواجهة برمجة التطبيقات (API) في مستند تعريف توافق Android (CDD). لدينا بعض اختبارات CTS للتأكد من عدم تغيير نموذج الأذونات لواجهات برمجة التطبيقات.
كيف يعمل هذا مع ميزة SIM المتعددة؟
ج: يتم استخدام بطاقة SIM الافتراضية التي حددها المستخدم.
هل يتفاعل هذا أو يتداخل بأي شكل من الأشكال مع تقنيات الوصول الأخرى إلى SE، على سبيل المثال، SEEK؟
ج: على سبيل المثال، يستخدم SEEK نفس AID الموجود في UICC. لذلك تتعايش القواعد ويتم تصفيتها بواسطة SEEK أو UiccCarrierPrivileges
.
متى يكون الوقت المناسب للتحقق من امتيازات الناقل؟
ج: بعد تحميل حالة SIM للبث.
هل يمكن لمصنعي المعدات الأصلية تعطيل جزء من واجهات برمجة تطبيقات الناقل؟
ج: لا، نحن نعتقد أن واجهات برمجة التطبيقات الحالية هي الحد الأدنى من المجموعة، ونخطط لاستخدام قناع البت للتحكم الدقيق في التفاصيل في المستقبل.
هل يتجاوز setOperatorBrandOverride
جميع الأشكال الأخرى لسلاسل أسماء المشغلين؟ على سبيل المثال، SE13، أو UICC SPN، أو NITZ المستندة إلى الشبكة؟
نعم، إن تجاوز العلامة التجارية للمشغل له الأولوية القصوى. عندما يتم ضبطه، فإنه يتجاوز جميع الأشكال الأخرى لسلاسل أسماء المشغلين.
ماذا يفعل استدعاء الأسلوب injectSmsPdu
؟
ج: تسهل هذه الطريقة النسخ الاحتياطي/الاستعادة للرسائل النصية القصيرة في السحابة. يقوم استدعاء injectSmsPdu
بتمكين وظيفة الاستعادة.
بالنسبة لتصفية الرسائل النصية القصيرة، هل تعتمد مكالمة onFilterSms
على تصفية منفذ SMS UDH؟ أو هل تتمتع تطبيقات الناقل بإمكانية الوصول إلى جميع الرسائل القصيرة الواردة؟
ج: يمكن لشركات الاتصالات الوصول إلى جميع بيانات الرسائل النصية القصيرة.
يبدو أن امتداد 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 (فارغ)، فهل يتم تطبيق القاعدة على جميع تطبيقات الجهاز التي لا تغطيها قاعدة محددة؟
ج: تتطلب واجهات برمجة تطبيقات الناقل أن يتم ملء 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
.
نحن نفترض أنه يمكننا منح حق الوصول إلى جميع الأذونات المستندة إلى شركة الاتصالات أو الحصول على تحكم أكثر دقة. إذا كان الأمر كذلك، ما الذي يحدد التعيين بين قناع البت والأذونات الفعلية؟ إذن واحد لكل فئة؟ إذن واحد لكل طريقة؟ هل 64 إذنًا منفصلاً كافية على المدى الطويل؟
ج: هذا للمستقبل، ونحن نرحب بالاقتراحات.
هل يمكنك تحديد DeviceAppID
لنظام Android على وجه التحديد؟ هذه هي قيمة التجزئة SHA-1 (20 بايت) لشهادة الناشر المستخدمة لتوقيع التطبيق المحدد، لذا ألا ينبغي أن يعكس الاسم هذا الغرض؟ (قد يكون الاسم مربكًا للعديد من القراء نظرًا لأن القاعدة تنطبق بعد ذلك على جميع التطبيقات الموقعة باستخدام شهادة الناشر نفسها.)
ج: يتم دعم شهادات تخزين DeviceAppID
بواسطة المواصفات الموجودة. لقد حاولنا تقليل تغييرات المواصفات لتقليل حاجز التبني. لمزيد من التفاصيل، راجع قواعد UICC .