חלק מהאפליקציות יכולות לשלוח משוב לספקי EMM בצורה של אפליקציה מקושרת . מצב האפליקציה עם קוד מפתח מורכב ממזהה ייחודי (מפתח), הודעה תואמת (אופציונלי), נתונים קריאים למחשבים (אופציונלי), חומרה ובחותמת הזמן. כדי לשלוח אותן, האפליקציה צריכה להשתלב עם ספריית Jetpack ב-Enterprise.
בתור EMM, יש לך אפשרות להשתמש בנתונים ממצבי מפתח של אפליקציות כדי להשאיר את האדמינים ב-IT שהם מעודכנים באפליקציות המותקנות במכשירים ובפרופילים מנוהלים. דוגמה מוסבר איך זה יכול לעבוד, בקטע הצגת משוב לארגונים.
הפעלת דוחות מכשירים
אפליקציות שולחות מצבי מפתח של אפליקציות לפי מכשיר. לפני שמזינים מצבי מפתח באפליקציה מתקבלים מכל האפליקציות במכשיר, עליך להפעיל את המכשיר דוחות למכשיר מסוים. עד שהמדיניות תתעדכן במכשיר, כל אפליקציה עם קוד אימות המערכת מתעלמת מהמצבים האלה ומאבדת אותם לתמיד. הפעלת דוחות במכשיר לפני להשלים את שיוך המכשיר, בהקדם האפשרי במהלך ההרשמה תהליך האימות. כך אפשר לקבל משוב על האפליקציה שנוצר במהלך המכשיר ושמצבי המפתח של האפליקציה לא יאבדו.
- קוראים לפונקציה
devices.update()
, מגדיר אתpolicy.deviceReportPolicy
כ-"deviceReportEnabled"
.
אחזור דוחות על מכשירים
יש כמה דרכים לאחזור דוח מכשירים:
- כדי לאחזר דוחות על מכשירים יחד עם התראות אחרות, צריך להתקשר
enterprises.pullNotificationSet()
בתגובה, כלdeviceReportUpdateEvent
מציין דוח על מכשיר. - כדי לאחזר דוח מכשירים המעודכן עם מצבי המפתח האחרונים של אפליקציה,
למכשיר שצוין, קוראים לפונקציה
devices.get()
. - כדי לאלץ מכשיר להעלות את המצבים האחרונים של האפליקציה, צריך להתקשר
devices.forceReportUpload()
השיטה הזו טוענת דוח שמכיל את השינויים במצבי האפליקציה מאז יצירת הדוח האחרון.
הצגת מצבי המפתח של האפליקציה
דוחות על מכשירים הם חלק ממשאבי המכשירים. הדוחות כוללים appState
לכל אפליקציה (חבילה) שמותקנת במכשיר או בפרופיל העבודה שלו.
מצבי האפליקציה המטורגטים (keyedAppState
) של חבילה נתונה מפורטים ב-
appState
, כמו בדוגמה הבאה:
{
"result":{
"kind":"androidenterprise#device",
"report":{
"appState":[
{
"keyedAppState":[
{
"severity":"severityError",
"data":"user",
"message":"Username or password are incorrect",
"key":"account",
"stateTimestampMillis":"1556206406926"
}
],
"packageName":"com.google.android.feedbacktestapp"
}
],
"lastUpdatedTimestampMillis":"1556206407685"
},
"androidId":"32714368a0ad8ad5",
"managementType":"managedProfile",
"policy":{
"deviceReportPolicy":"deviceReportEnabled"
}
}
}
כל מצבי המפתח של האפליקציה כוללים את הפרטים הבאים:
שדה | תיאור |
---|---|
key |
המפתח הייחודי שמזהה את המדינה. |
severity |
חומרת המדינה: INFO מציינת הודעה אינפורמטיבית. לדוגמה, אם הגדרה מנוהלת נקבעה בהצלחה. ERROR מציין שהארגון צריך לנקוט פעולה כדי לתקן בעיה. לדוגמה, אם ההגדרה של הגדרה מנוהלת נכשלה. |
message |
מחרוזת אופציונלית עם פרטים על מצב האפליקציה. אנחנו ממליצים למפתחי אפליקציות להתייחס לשדה הזה כהודעה למשתמשים. |
data |
מחרוזת אופציונלית עם פרטים שקריאים למחשב לספקי ה-EMM על מצב האפליקציה. לדוגמה, ערך שאדמין ב-IT יכול לשלוח לגביו שאילתה במסוף, כמו 'Notify me if the battery_warning data < 10 אינץ'. |
stateTimestampMillis |
חותמת הזמן (באלפיות שנייה) שמציינת מתי בוצע העדכון האחרון של מצב האפליקציה במכשיר. |
lastUpdatedTimestampMillis |
חותמת הזמן (באלפיות שנייה) שמציינת את מועד ההעלאה האחרונה של האפליקציה המקושרת במכשיר. |
הצגת משוב על אפליקציות לארגונים
אפליקציות יכולות לשלוח משוב מסיבות שונות. אבל השימוש הנפוץ ביותר לשליחת מצבי מפתח של אפליקציה היא לשלוח משוב על נתונים מנוהלים הגדרות אישיות. לדוגמה:
- אדמין ב-IT משתמש במסוף ה-EMM כדי להגדיר הגדרות מנוהלות של אפליקציה.
- בקצה העורפי, שולחים את ההגדרות האישיות לאפליקציה.
- האפליקציה מנסה להחיל את ההגדרות האישיות. לכל הגדרה, האפליקציה שולח מצב אפליקציה עם קידוד המציין את הסטטוס שלו (לדוגמה, אישור או הודעת שגיאה).
- כדי להציג את מצבי המפתח האלה, מאחזרים דוח מכשירים.
- באמצעות מידע ממצבי האפליקציה המקושרים, מסוף ה-EMM מציג בסטטוס של ההגדרות האישיות המנוהלות בצורה ידידותית למשתמש.
התראה לאדמינים ב-IT על שגיאות
מצב אפליקציה מטורגט עם רמת חומרה ERROR
מציין שהארגון צריך לבצע את הפעולות הבאות
פעולה כלשהי כדי לתקן בעיה. ספקי EMM צריכים תמיד להודיע לארגונים
לשגיאות, דרך מסוף ה-EMM או אמצעים אחרים. לדוגמה,
מסוף ה-EMM עשוי להציג מרכז בקרה לשגיאות עם קישור למשוב
במכשיר עם שגיאות.
אם מצב שגיאה יתוקן, האפליקציה תשלח מצב המשך עם אותו מפתח
במצב השגיאה המקורי ובחומרה מעודכנת של INFO
. כדאי ש-EMM
תמיד מיידעים ארגונים מיד עם תיקון השגיאה. לדוגמה,
מסירים את השגיאה ממרכז הבקרה של השגיאות במסוף או מסמנים אותה כ'טופלה'.