אנדרואיד 5.1 הציגה מנגנון להענקת הרשאות מיוחדות לממשקי API רלוונטיים לבעלי אפליקציות כרטיס מעגל משולב אוניברסלי (UICC). פלטפורמת אנדרואיד טוענת אישורים המאוחסנים ב-UICC ומעניקה הרשאה לאפליקציות החתומות על ידי אישורים אלו לבצע שיחות לקומץ ממשקי API מיוחדים.
אנדרואיד 7.0 הרחיבה תכונה זו כדי לתמוך במקורות אחסון אחרים עבור כללי הרשאות ספק UICC, והגדילה באופן דרמטי את מספר הספקים שיכולים להשתמש בממשקי ה-API. לעיון ב-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 במחרוזת hex היא:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
הכלל על UICC במחרוזת hex הוא:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
תמיכה בקבצי כלל גישה
אנדרואיד 7.0 מוסיפה תמיכה בקריאת כללי הרשאות ספק מקובץ כללי הגישה (ARF).
פלטפורמת אנדרואיד מנסה תחילה לבחור את אפליקציית כלל הגישה (ARA) AID A00000015141434C00
. אם הוא לא מוצא את ה-AID ב-UICC, הוא נופל בחזרה ל-ARF על ידי בחירת PKCS15 AID A000000063504B43532D3135
. לאחר מכן אנדרואיד קורא את קובץ כללי בקרת הגישה (ACRF) ב 0x4300
ומחפש ערכים עם AID FFFFFFFFFFFF
. מתעלמים מערכים עם מכשירי AID שונים, כך שכללים למקרי שימוש אחרים יכולים להתקיים במקביל.
תוכן ACRF לדוגמה במחרוזת hex:
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, המכילה את ה-hash של האישור 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
. לאפליקציות החתומות על ידי אישור זה מוענקות הרשאות ספק.
ממשקי API מופעלים
אנדרואיד תומך בממשקי ה-API הבאים.
מנהל טלפוניה
- שיטה לאפשר לאפליקציית הספק לבקש מ-UICC אתגר/תשובה:
getIccAuthentication
. - שיטה לבדוק אם האפליקציה המתקשרת קיבלה הרשאות ספק:
hasCarrierPrivileges
. - שיטות לעקוף מותג ומספר:
- שיטות לתקשורת UICC ישירה:
- שיטה להגדיר את מצב המכשיר לגלובל:
setPreferredNetworkTypeToGlobal
. - שיטות לקבל את זהויות המכשיר או הרשת:
- זהות ציוד נייד בינלאומי (IMEI):
getImei
- מזהה ציוד נייד (MEID):
getMeid
- מזהה גישה לרשת (NAI):
getNai
- מספר סידורי SIM:
getSimSerialNumber
- זהות ציוד נייד בינלאומי (IMEI):
- שיטה לקבל את תצורת הספק:
getCarrierConfig
- שיטה לקבל את סוג הרשת להעברת נתונים:
getDataNetworkType
- שיטה לקבל את סוג הרשת עבור שירות קולי:
getVoiceNetworkType
- שיטות לקבלת מידע על אפליקציית UICC SIM (USIM):
- מספר סידורי SIM:
getSimSerialNumber
- מידע על הכרטיס:
getUiccCardsInfo
- GID1 (קבוצה מזהה level1):
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 מבוססת טקסט מבלי לכתוב לספק ה-SMS:
sendTextMessageWithoutPersisting
CarrierConfigManager
- שיטה להודיע על שינוי תצורה:
notifyConfigChangedForSubId
. - שיטה לקבל תצורת ספק עבור מנוי ברירת המחדל:
getConfig
- שיטה לקבל תצורת ספק עבור המנוי שצוין:
getConfigForSubId
להוראות, ראה תצורת ספק .
BugreportManager
שיטה להפעלת דוח באג בקישוריות, שהוא גרסה מיוחדת של דוח הבאג הכוללת רק מידע לאיתור בעיות הקשורות לקישוריות: startConnectivityBugreport
NetworkStatsManager
- שיטה לשאילתה של סיכום השימוש ברשת:
querySummary
- שיטה לשאילתה על היסטוריית השימוש ברשת:
queryDetails
- שיטות לרישום או ביטול רישום השימוש ברשת:
ImsMmTelManager
- שיטות לרישום או ביטול רישום של IMS MmTel התקשרות חוזרת לרישום:
ImsRcsManager
- שיטות לרישום או ביטול רישום של IMS RCS התקשרות חוזרת:
- שיטות לקבלת מצב רישום IMS או סוג תחבורה:
מנהל אספקה
- שיטות לרישום וביטול רישום של עדכוני אספקת תכונות IMS התקשרות חוזרת:
- שיטות הקשורות לסטטוס ההקצאה עבור יכולת IMS MmTel או RCS:
EuiccManager
שיטה למעבר (לאפשר) את המנוי הנתון: switchToSubscription
CarrierMessagingService
שירות המקבל שיחות מהמערכת כאשר נשלחים או מתקבלים SMS ו-MMS חדשים. כדי להרחיב מחלקה זו, הכריז על השירות בקובץ המניפסט שלך עם ההרשאה android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
וכלול מסנן כוונות עם הפעולה #SERVICE_INTERFACE
. השיטות כוללות:
- שיטה לסינון הודעות SMS נכנסות:
onFilterSms
- שיטה ליירט הודעות SMS שנשלחו מהמכשיר:
onSendTextSms
- שיטה ליירט הודעות SMS בינאריות שנשלחו מהמכשיר:
onSendDataSms
- שיטה ליירט הודעות SMS ארוכות שנשלחות מהמכשיר:
onSendMultipartTextSms
- שיטה ליירט הודעות MMS שנשלחו מהמכשיר:
onSendMms
- שיטה להורדת הודעות MMS שהתקבלו:
onDownloadMms
CarrierService
שירות החושף למערכת פונקציות ספציפיות לספק. כדי להרחיב את המחלקה הזו, הכריז על השירות בקובץ המניפסט של האפליקציה עם ההרשאה android.Manifest.permission#BIND_CARRIER_SERVICES
וכלול מסנן כוונות עם הפעולה CARRIER_SERVICE_INTERFACE
. אם לשירות יש כריכה ארוכת חיים, הגדר את android.service.carrier.LONG_LIVED_BINDING
ל- true
במטא נתונים של השירות.
הפלטפורמה קושרת את CarrierService
עם דגלים מיוחדים כדי לאפשר לתהליך שירות הספק לפעול בדלי המתנה מיוחד של אפליקציות . זה פוטר את אפליקציית שירות הספק מהגבלה על סרק האפליקציה ומגדיל את הסיכוי שהיא תישאר בחיים כאשר זיכרון המכשיר נמוך. עם זאת, אם אפליקציית שירות הספק קורסת מסיבה כלשהי, היא מאבדת את כל ההרשאות לעיל עד שהאפליקציה מופעלת מחדש והקישור יוקם מחדש. אז זה קריטי לשמור על יציבות אפליקציית שירות הספק.
השיטות ב- CarrierService
כוללות:
- כדי לעקוף ולהגדיר את התצורות הספציפיות לספק:
onLoadConfig
- כדי ליידע את המערכת על שינוי מכוון של רשת הספק על ידי אפליקציית הספק:
notifyCarrierNetworkChange
ספק טלפוניה
ממשקי API של ספקי תוכן לאפשר שינויים (הוספה, מחיקה, עדכון, שאילתה) במסד הנתונים של הטלפוניה. שדות ערכים מוגדרים ב- Telephony.Carriers
; לפרטים נוספים, עיין בהפניה למחלקת Telephony
הצעה WifiNetwork
בעת בניית אובייקט WifiNetworkSuggestion
, השתמש בשיטות הבאות כדי להגדיר מזהה מנוי או קבוצת מנוי:
- שיטה להגדרת מזהה מנוי:
setSubscriptionId
- שיטה להגדרת קבוצת מנויים:
setSubscriptionGroup
פלטפורמת אנדרואיד
ב-UICC שזוהה, הפלטפורמה בונה אובייקטי UICC פנימיים הכוללים כללי הרשאות ספק כחלק מה-UICC. UiccCarrierPrivilegeRules.java
טוען כללים, מנתח אותם מכרטיס UICC ושומר אותם בזיכרון. כאשר יש צורך בבדיקת הרשאות, UiccCarrierPrivilegeRules
משווה את אישור המתקשר עם הכללים שלו בזה אחר זה. אם ה-UICC מוסר, הכללים מושמדים יחד עם אובייקט ה-UICC.
מַתַן תוֹקֵף
כדי לאמת את ההטמעה באמצעות Compatibility Test Suite (CTS) באמצעות CtsCarrierApiTestCases.apk
, עליך להיות בעל UICC למפתחים עם כללי UICC נכונים או תמיכה ב-ARF. בקש מהספק כרטיס ה-SIM לבחירתך להכין UICC למפתחים עם ה-ARF הנכון כמתואר בסעיף זה ולהשתמש ב-UICC זה כדי להפעיל את הבדיקות. ה-UICC אינו דורש שירות סלולרי פעיל כדי לעבור מבחני CTS.
הכן את UICC
עבור אנדרואיד 11 ומטה, CtsCarrierApiTestCases.apk
חתום על ידי aosp-testkey
, עם ערך hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
.
החל באנדרואיד 12, CtsCarrierApiTestCases.apk
חתום על ידי cts-uicc-2021-testkey
, ערך hash 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 באנדרואיד 12, המכשיר צריך להשתמש ב-SIM עם הרשאות ספק CTS העומד בדרישות המפורטות בגרסה העדכנית ביותר של מפרט GSMA TS.48 Test Profile של צד שלישי.
ניתן להשתמש באותו SIM גם עבור גרסאות שקדמו לאנדרואיד 12.
שינוי פרופיל ה-SIM של CTS
- הוסף: הרשאות ספק CTS באסטרטגיית יישום כללי גישה (ARA-M) או ARF. שתי החתימות חייבות להיות מקודדות בכללי הרשאות הספק:
- Hash1(SHA1):
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
- 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
- Hash1(SHA1):
- צור: קבצי 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: אפשר שירותים n°47, n°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 תומך באסימון מכשיר המגביל את הבדיקות לפעול רק במכשירים המוגדרים עם אותו אסימון. בדיקות ה-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 במסמך הגדרת תאימות אנדרואיד (CDD). יש לנו כמה בדיקות CTS כדי לוודא שמודל ההרשאה של ממשקי ה-API לא משתנה.
איך זה עובד עם תכונת ריבוי ה-SIM?
ת: נעשה שימוש ב-SIM ברירת המחדל שצוין על ידי המשתמש.
האם זה מקיים אינטראקציה כלשהי או חופף עם טכנולוגיות גישה אחרות ל-SE, למשל, SEEK?
ת: כדוגמה, SEEK משתמש באותו AID כמו ב-UICC. אז הכללים מתקיימים במקביל ומסוננים על ידי SEEK או UiccCarrierPrivileges
.
מתי זה זמן טוב לבדוק את הרשאות הספק?
ת: לאחר שידור מצב ה-SIM נטען.
האם יצרני 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
.
אנו מניחים שאנו יכולים להעניק גישה לכל ההרשאות מבוססות הספק או שיש לנו שליטה עדינה יותר. אם כן, מה מגדיר את המיפוי בין מסיכת הסיביות להרשאות בפועל? רשות אחת לכיתה? הרשאה אחת לכל שיטה? האם 64 הרשאות נפרדות מספיקות בטווח הארוך?
ת: זה שמור לעתיד, ונשמח לקבל הצעות.
האם תוכל להגדיר יותר את DeviceAppID
עבור אנדרואיד באופן ספציפי? זהו ערך הגיבוב SHA-1 (20 בתים) של אישור המפרסם המשמש לחתימה על האפליקציה הנתונה, אז האם השם לא אמור לשקף את המטרה הזו? (השם עלול לבלבל קוראים רבים מכיוון שהכלל חל אז על כל האפליקציות החתומות עם אותו אישור מפרסם).
ת: האישורים המאחסנים DeviceAppID
נתמכים על ידי המפרט הקיים. ניסינו למזער שינויים במפרט כדי להוריד את המחסום לאימוץ. לפרטים, ראה כללים על UICC .