قدم 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
هو عنوان 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
SmsManager
- طريقة للسماح للمتصل بإنشاء رسائل SMS واردة جديدة:
injectSmsPdu
. - طريقة لإرسال رسالة SMS تستند إلى نص دون الكتابة في مزود خدمة الرسائل القصيرة:
sendTextMessageWithoutPersisting
CarrierConfigManager
- طريقة الإعلام بتغيير التكوين:
notifyConfigChangedForSubId
. - طريقة الحصول على تكوين الناقل للاشتراك الافتراضي:
getConfig
- طريقة الحصول على تكوين الناقل للاشتراك المحدد:
getConfigForSubId
للحصول على التعليمات ، راجع تكوين الناقل .
BugreportManager
طريقة لبدء تقرير خطأ الاتصال ، وهو إصدار متخصص من تقرير الخطأ الذي يتضمن فقط معلومات لتصحيح الأخطاء المتعلقة بالاتصال: startConnectivityBugreport
NetworkStatsManager
- طريقة الاستعلام عن ملخص استخدام الشبكة:
querySummary
- طريقة الاستعلام عن سجل استخدام الشبكة:
queryDetails
- طرق تسجيل أو إلغاء تسجيل معاودة اتصال استخدام الشبكة:
ImsMmTelManager
- طرق تسجيل أو إلغاء تسجيل رد تسجيل IMS MmTel:
ImsRcsManager
- طرق تسجيل أو إلغاء تسجيل رد اتصال تسجيل IMS RCS:
- طرق الحصول على حالة تسجيل IMS أو نوع النقل:
ProvisioningManager
- طرق تسجيل وإلغاء تسجيل رد تحديثات توفير ميزات IMS:
- الطرق المتعلقة بحالة التوفير لقدرة IMS MmTel أو RCS:
EuiccManager
طريقة التبديل إلى (تمكين) الاشتراك المحدد: switchToSubscription
CarrierMessagingService
خدمة تستقبل المكالمات من النظام عند إرسال أو استقبال رسائل SMS و MMS جديدة. لتوسيع هذه الفئة ، قم بالإعلان عن الخدمة في ملف البيان الخاص بك باستخدام إذن android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
وتضمين عامل تصفية النية مع إجراء #SERVICE_INTERFACE
. تشمل الطرق:
- طريقة تصفية رسائل SMS الواردة:
onFilterSms
- طريقة اعتراض الرسائل النصية القصيرة المرسلة من الجهاز:
onSendTextSms
- طريقة اعتراض رسائل SMS الثنائية المرسلة من الجهاز:
onSendDataSms
- طريقة اعتراض رسائل SMS الطويلة المرسلة من الجهاز:
onSendMultipartTextSms
- طريقة اعتراض رسائل الوسائط المتعددة المرسلة من الجهاز:
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
WifiNetwork اقتراح
عند إنشاء كائن WifiNetworkSuggestion
، استخدم الطرق التالية لتعيين معرف اشتراك أو مجموعة اشتراك:
- طريقة تعيين معرف الاشتراك:
setSubscriptionId
- Metohd لتعيين اشتراك مجموعة:
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. يجب ترميز كلا التوقيعين في قواعد امتياز الناقل:
-
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
-
- إنشاء: ملفات ADF USIM الأولية (EFs) غير موجودة في TS.48 ومطلوبة لـ CTS:
- EF_MBDN (6FC7) ، حجم السجل: 28 ، رقم السجل: 4
- محتوى
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF… FF
- Rec2-n: FF… FF
- محتوى
- EF_EXT6 (6FC8) ، حجم السجل: 13 ، رقم السجل: 1
- المحتوى: 00FF… FF
- EF_MBI (6FC9) ، حجم السجل: 4 ، رقم السجل: 1
- المحتوى: Rec1: 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 أو تعديلات أخرى مذكورة أعلاه.
إجراء الاختبارات
للراحة ، يدعم CTS رمز الجهاز الذي يقيد الاختبارات للتشغيل فقط على الأجهزة التي تم تكوينها بنفس الرمز المميز. تدعم اختبارات Carrier API CTS الرمز المميز للجهاز sim-card-with-certs
. على سبيل المثال ، يقوم الرمز المميز التالي للجهاز بتقييد اختبارات واجهة برمجة تطبيقات الناقل للتشغيل فقط على الجهاز abcd1234
:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
عند إجراء اختبار بدون استخدام رمز مميز للجهاز ، يتم تشغيل الاختبار على جميع الأجهزة.
التعليمات
كيف يمكن تحديث الشهادات على UICC؟
ج: استخدم آلية تحديث البطاقة الحالية عبر الهواء.
هل يمكن أن يتعايش UICC مع القواعد الأخرى؟
ج: من الجيد أن يكون لديك قواعد أمنية أخرى على UICC تحت نفس المساعدة ؛ تقوم المنصة بترشيحها تلقائيًا.
ماذا يحدث عند إزالة UICC لتطبيق يعتمد على الشهادات الموجودة عليه؟
ج: يفقد التطبيق امتيازاته لأن القواعد المرتبطة بـ UICC يتم إتلافها عند إزالة UICC.
هل يوجد حد لعدد الشهادات في UICC؟
ج: النظام الأساسي لا يحد من عدد الشهادات ؛ ولكن نظرًا لأن الشيك خطي ، فقد تتطلب العديد من القواعد وقت استجابة للتحقق.
هل هناك حد لعدد واجهات برمجة التطبيقات التي يمكننا دعمها بهذه الطريقة؟
ج: لا ، لكننا نقصر النطاق على واجهات برمجة التطبيقات المتعلقة بالناقل.
هل هناك بعض واجهات برمجة التطبيقات المحظورة من استخدام هذه الطريقة؟ إذا كان الأمر كذلك ، فكيف تطبقها؟ (أي هل لديك اختبارات للتحقق من واجهات برمجة التطبيقات المدعومة بهذه الطريقة؟)
ج: راجع قسم التوافق السلوكي لواجهة برمجة التطبيقات في مستند تعريف توافق Android (CDD). لدينا بعض اختبارات CTS للتأكد من عدم تغيير نموذج إذن واجهات برمجة التطبيقات.
كيف يعمل هذا مع ميزة الشرائح المتعددة؟
ج: يتم استخدام بطاقة 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 .