אחזור משוב מאפליקציות

אפליקציות מסוימות יכולות לשלוח משוב לספקי EMM בצורת מצבים של אפליקציות עם קידוד. מצב האפליקציה של המפתח מורכב ממזהה ייחודי (מפתח), הודעה תואמת (אופציונלי), נתונים קריאים למחשבים (אופציונלי), סטטוס החומרה וחותמת זמן. כדי לשלוח אותם, האפליקציה צריכה להשתלב עם ספריית Jetpack לארגונים.

כמפעילי EMM, אתם יכולים להשתמש בנתונים ממצבים של אפליקציות מרכזיות כדי לעדכן את האדמינים ב-IT באפליקציות שמותקנות במכשירים ובפרופילים מנוהלים. דוגמה לאופן הפעולה הזה מתוארת במאמר הצגת משוב לארגונים.

הפעלת דוחות על מכשירים

אפליקציות שולחות את מצבי האפליקציה העיקריים לפי מכשיר. לפני שמקבלים מצבים של אפליקציות מקושרות כלשהו מהאפליקציות במכשיר, צריך להפעיל את דוחות המכשיר עבור המכשיר. עד שהמדיניות תעודכן במכשיר, המערכת תתעלם מכל המצבים של האפליקציות שמקישים עליהן ויאבדו לתמיד. הפעילו דוחות על מכשירים לפני שמשלימים את שיוך המכשיר, בהקדם האפשרי בתהליך הרישום. כך אפשר לוודא שהמשוב על האפליקציה שנוצר במהלך רישום המכשיר הוא ושמצבים של האפליקציות שהקשת עליהן לא יאבדו.

• מתקשרים אל devices.update() ומגדירים את policy.deviceReportPolicy ל-"deviceReportEnabled".

אחזור דוחות על מכשירים

יש כמה דרכים לאחזר דוח מכשירים:

• כדי לאחזר דוחות על מכשירים יחד עם התראות אחרות, צריך להתקשר למספר enterprises.pullNotificationSet(). בתגובה, כל deviceReportUpdateEvent מציין דוח מכשיר.
• כדי לאחזר דוח על מכשירים המעודכן עם המצבים האחרונים של האפליקציות שמקושרות למכשיר מסוים, מתקשרים אל devices.get().
• כדי לאלץ מכשיר להעלות את מצבי האפליקציה העדכניים ביותר, מתקשרים אל devices.forceReportUpload(). השיטה הזו מעלה דוח שמכיל את השינויים במצבי האפליקציה במכשיר מאז יצירת הדוח האחרון.

הערה: ניתן להתקשר devices.forceReportUpload() עד שלוש פעמים בכל 24 שעות במכשיר נתון. בדרך כלל, המכשיר מעלה משוב על אפליקציות לפחות פעם ביום. התקשרות אל 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 יכול לשלוח שאילתות לגביו במסוף, כמו "Tell me if the battery_warning data < 10" (אני רוצה לקבל התראה אם נתוני הסוללה < 10).
stateTimestampMillis	חותמת הזמן (באלפיות שנייה) שמציינת מתי מצב האפליקציה עודכן לאחרונה במכשיר.
lastUpdatedTimestampMillis	חותמת הזמן (באלפיות שנייה) שמציינת מתי המכשיר העלה לאחרונה את מצב האפליקציה שמפתחת.

הצגת משוב על האפליקציה לארגונים

אפליקציות יכולות לשלוח משוב ממגוון סיבות. עם זאת, התרחיש לדוגמה הנפוץ ביותר לשליחת מצבים של אפליקציות מרכזיות הוא משוב על ההגדרות המנוהלות. למשל:

1. מנהל IT משתמש במסוף ה-EMM כדי להגדיר הגדרות מנוהלות לאפליקציה.
2. בקצה העורפי, צריך לשלוח את ההגדרות האישיות לאפליקציה.
3. האפליקציה מנסה להחיל את ההגדרות האישיות. לכל הגדרה, האפליקציה שולחת מצב אפליקציה עם מפתח שמציין את הסטטוס שלה (למשל, הודעת אישור או התראת שגיאה).
4. כדי להציג את המצבים העיקריים של האפליקציות, מאחזרים דוח מכשירים.
5. הסטטוס של ההגדרות המנוהלות מוצג במסוף ה-EMM באופן ידידותי למשתמש, על סמך מידע ממצבי האפליקציה העיקריים.

דיווח לאדמינים ב-IT על שגיאות

מצב של מפתח אפליקציה עם חומרה ERROR מציין שהארגון צריך לנקוט פעולה כדי לתקן בעיה. ספקי EMM צריכים תמיד להתריע לארגונים על שגיאות, באמצעות מסוף ה-EMM שלהם או באמצעים אחרים. לדוגמה, במסוף EMM עשוי להופיע לוח בקרה של שגיאות עם קישור למשוב על מכשיר נתון עם שגיאות.

אחרי שמתקנים את מצב השגיאה, האפליקציה שולחת מצב המשך עם אותו מפתח כמו מצב השגיאה המקורי ורמת חומרה מעודכנת של INFO. ספקי EMM תמיד צריכים להודיע לארגונים מיד לאחר תיקון שגיאה. לדוגמה, מסירים את השגיאה ממרכז הבקרה של השגיאות במסוף או מסמנים אותה כשגיאה שנפתרה.

טיפ: כדאי להוסיף תמיכה לאדמינים ב-IT כדי להשתיק שגיאה ספציפית במקרה שהאפליקציה לא מצליחה לעדכן מצב שגיאה בצורה נכונה אחרי תיקון השגיאה.