הקצאת מכשירים

יש כמה דרכים להקצות מכשירים. של הלקוחות עסק הדרישות קובעות באילו שיטות להקצאת הרשאות כדאי להשתמש.

עקרונות בסיסיים של הקצאת מכשירים

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

תרחישי פריסה

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

חברות שתומכות בתרחיש פריסת BYOD מאפשרות להביא לעבודה מכשירים בבעלות אישית ולהשתמש במכשירים האלה כדי לגשת לאפליקציות ולמידע מוגבל של החברה.

מצבי פעולה

פריסות בבעלות החברה נתמכות במצב בעלי המכשיר בפעולה. ב-Android, אפליקציית הניהול נקראת 'מדיניות המכשיר' בקר (DPC). בקר ה-DPC אוכף כללי מדיניות במכשיר מבוסס Android וגם כשהוא פועל כבעלים של המכשיר, הוא מנהל את כל המכשיר. כבעלים של המכשיר, ה-DPC יכול לבצע פעולות בכל המכשיר, כמו הגדרה ברמת המכשיר קישוריות, לקבוע הגדרות גלובליות ולבצע איפוס להגדרות המקוריות.

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

שיטות להקצאה של בעלי מכשיר

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

בהתאם לתרחיש לדוגמה, יש 2 סוגים עיקריים של שיטות ניהול הרשאות: ניהול תצורה של מצב 'בעלי המכשיר'.

• בתהליך מבוסס-מכשיר, מנהלי IT יכולים להשתמש ב-NFC כדי להקצות מספר המכשירים. אפשר להשתמש בתהליך הזה בחשבון Google Play לארגונים או ב-Google Workspace מנוהלים במקרים מסוימים.
• בתהליך מבוסס-משתמשים, האפשרויות תלויות בשאלה אם הארגון משתמש ב-Google Workspace.
  • בתרחיש של Google Workspace, המשתמש מוסיף את חשבון Google שלו במהלך ההגדרה הראשונית של המכשיר, וה-DPC צריך להנחות את המשתמש השלבים להגדרה של בעל המכשיר. תהליכים שמבוססים על משתמשים יכולים לעזור למשתמשי הקצה להגדיר מכשירים חדשים, ואפשר להשתמש בו גם כחלופה למכשירים שאין בהם תמיכה ב-NFC.
  • אם ארגון לא משתמש ב-Google Workspace, יש להשתמש חשבונות Google Play מנוהלים.

הערה: אם אתם מגבילים את ההפצה של האפליקציה למדינות ספציפיות במדינות ספציפיות Google Play, המערכת מתעלמת מההגבלות האלה במהלך ההקצאה של בעלי המכשיר. תתבצע הורדה של ה-DPC גם אם המכשיר לא נמצא במדינת היעד.

שיטות להקצאת הרשאות ידנית של בעלי הפרופיל

השיטה המומלצת להקצאת מצב הפעולה של בעלי הפרופיל תלויה אם הארגון משתמש ב-Google Workspace.

• במקרה של Google Workspace, השיטה המומלצת היא תהליך מבוסס-משתמש שבו המשתמשים מוסיפים את חשבון Google שלהם, ובקר ה-DPC מנחה את המשתמש בשלבים להגדרת הבעלים של הפרופיל.
• אם בארגון לא משתמשים ב-Google Workspace, השיטה המומלצת היא השיטה חשבונות Google Play מנוהלים.

השיטה המסורתית שבה המשתמש מורה יש תמיכה גם בהתקנה ידנית של בקר DPC. הדפדפן מסתמך על המשתמש שיוריד את בקר ה-DPC מ-Google Play ויתקין אותו, ה-DPC מנחה את המשתמש בהמשך התהליך כדי להגדיר בעלים של פרופיל.

הבדלים בהקצאת הרשאות ידנית בין גרסאות Android

שיקולים כלליים לגבי הטמעה

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

תאימות של Google Play Services

מדריך לחבילת ה-APK של Google Play Services מורה למפתחים לבצע בדיקת גרסאות של Google Play Services לפני ביצוע עסקאות API. כי מתבצע ניסיון לעדכן את Google Play Services תגרום לשיבושים חמורים בתהליך הגדרת המכשיר, בקר ה-DPC לא לנסות לעדכן את Google Play Services לפני שהקצאת המכשיר תושלם.

כמה נקודות עיקריות לגבי תאימות של בקר DPC לשירותי Google Play הן:

• בקר ה-DPC צריך לפעול באמצעות שירותי Google Play שנשלחים עם למכשיר מסוים.
• בקר ה-DPC לא צריך להסתמך על תכונות חדשות בגרסאות עתידיות של Google Play שהיו זמינים במועד הקצאת המכשיר.

כשהקצאת המכשיר תושלם, ה-DPC יכול לבקש מהמשתמש לעדכן Google Play Services, כדי שבקר ה-DPC יוכל להשתמש בתכונות העדכניות ביותר. אבל אם התכונה לא זמינה מסיבה כלשהי, ה-DPC חייב לחזור באלגנטיות הגרסה שנשלחה עם המכשיר.

אחזור פרטי מכשיר

בגלל עיכובים בהפצה, יכול להיות שיעברו עד 2 דקות לפני שהשיחה אל device.get יחזיר את הפרטים של המכשיר שנרשם לאחרונה.

אם בתהליך העבודה שלכם נדרשים הפרטים כדי שמשתמש הקצה יוכל להשתמש במכשיר או מומלץ להשתמש במסך התקדמות בבקר ה-DPC ולהמתין הקריאה מצליחה.

שיקולים להטמעה במצב 'בעלים של פרופיל'

הנה כמה דברים שכדאי להביא בחשבון לכתוב את ה-DPC כדי להטמיע את הבעלים של הפרופיל מצב פעולה.

הסרה או השבתה של ה-DPC האישי

כשמקצים את מצב הפעולה של בעלי הפרופיל, ה-DPC מתחיל לפעול בפרופיל האישי כדי להתחיל את תהליך היצירה של פרופיל עבודה. לאחר יצירת פרופיל העבודה, ה-DPC פועל גם בתוך סביבת העבודה פרופיל. תהליך ההקצאה משלים את ה-DPC בפרופיל העבודה. בשעה כלומר, ה-DPC בפרופיל האישי אמור להשבית את עצמו או את המכשיר המשתמש צריך להסיר אותו.

המשתמש מסיר את בקר ה-DPC האישי

1. בקר ה-DPC האישי מקשיב ACTION_MANAGED_PROFILE_PROVISIONED (במכשירי Android 5.1, ה-DPC האישי צריך במקום זאת להאזין ל ACTION_MANAGED_PROFILE_ADDED).
2. בקר ה-DPC האישי שולח בקשה להסרה ACTION_UNINSTALL_PACKAGE תוצג למשתמש בקשה להסיר את בקר ה-DPC האישי. למשתמש הטוב ביותר תהליך ההסרה אמור להתרחש במהלך הקצאת ההרשאות הידנית.

בקר DPC אישי משבית את עצמו

1. בקר ה-DPC האישי מקשיב ACTION_MANAGED_PROFILE_PROVISIONED (במכשירי Android 5.1, ה-DPC האישי צריך במקום זאת להאזין ל ACTION_MANAGED_PROFILE_ADDED).
2. אם רלוונטי, בקר ה-DPC האישי צריך לשחרר הרשאות אדמין במכשיר לפני שהוא משבית את עצמו.
3. בקר ה-DPC האישי יוזם setApplicationEnabledSetting להשבית את הבקשה עם COMPONENT_ENABLED_STATE_DISABLED הפרמטר.
4. המשתמש יכול להפעיל מחדש את בקר ה-DPC האישי מ-Google Play.

שיקולים להטמעה במצב 'בעלי המכשיר'

יש כמה דברים שחשוב להביא בחשבון כשכותבים את ה-DPC כדי להטמיע את מצב הפעולה של בעלי המכשיר.

המכשיר צריך להיות חדש או לאפס להגדרות המקוריות

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

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

• תוכנה זדונית עלולה ליצור בעלי מכשיר והשתלטות על המכשיר.
• יכול להיות שיש בעיות בפרטיות אם כבר מותקנות נתוני משתמשים או אפליקציות מסוימות במכשיר.

הגדרת מצב 'בעלי מכשירים' רק במכשירים שהם בבעלות החברה

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

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

הפעלת אפליקציות מערכת

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

הפעלת אפליקציות מערכת דרך Google Play

הפעלת אפליקציות מערכת באמצעות Google Play פשוטה, והמשתמשים מקבלים עדכונים לאפליקציה ברגע שהם זמינים.

הפעלת אפליקציות מערכת באמצעות ממשקי API של Android framework

כדי שהמשתמשים יוכלו לראות את אפליקציות המערכת ברגע שהם יתחילו להשתמש במכשירים שלהם, להפעיל אפליקציות מערכת כחלק מתהליך הקצאת המכשיר. בקר ה-DPC מאפשר אפליקציות מערכת לפי שם חבילה או לפי כוונה באמצעות DevicePolicyManager.enableSystemApp()

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

יצירת קטלוגים של אפליקציות מערכת

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

1. אם פרופיל העבודה עדיין לא הוקצה במכשיר, אפשר לעיין ברשימה את כל האפליקציות עם סמלי מרכז האפליקציות במכשיר באמצעות queryIntentActivities():

   private List<ResolveInfo> getAppsWithLauncher() {
     Intent i = new Intent(Intent.ACTION_MAIN);
     i.addCategory(Intent.CATEGORY_LAUNCHER);
     return getPackageManager().queryIntentActivities(i, 0);
   }
   

2. אם פרופיל העבודה כבר הוקצה במכשיר, מוצאים רשימה של כל האפליקציות בפרופיל העבודה שמשתמשות ב- PackageManager.GET_DISABLED_COMPONENTS וגם PackageManager.GET_UNINSTALLED_PACKAGES

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

יתרונות:

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

חסרונות:

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

סיווג אפליקציות מערכת לפי פונקציונליות

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

יתרונות:

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

חסרונות:

• הגבלת אפליקציות המערכת לאפליקציות שנתמכות בכל סוגי המכשירים.
• ייתכן שאדמינים ב-IT ירצו לשלוח גרסה אחת של ה-OEM (יצרן הציוד המקורי) של האפליקציה (כמו דפדפן Samsung® ), אך לא בדפדפן אחר (כגון דפדפן LG® ).
• יכול להיות שמנהלי IT לא רוצים לדחוף אפליקציות מרובות, אבל הם לא יכולים למנוע כשיש כמה גורמים המטפלים ב-Intent.

תמיכה רק באפליקציות מערכת שאושרו

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

יתרונות:

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

חסרונות:

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

תרחישי בדיקה של בקר DPC

Test DPC הוא קוד פתוח אפליקציה שסופקה על ידי Google כדי לבדוק יכולות ארגוניות באפליקציית בקר ה-DPC. בקר DPC לבדיקה זמין מ- github או Google Play. אפשר להשתמש לבקר בבקר DPC כדי לבצע את הפעולות הבאות:

• סימולציה של תכונות ב-Android
• הגדרה ואכיפה של כללי מדיניות
• הגדרה של הגבלות על אפליקציות וכוונת רכישה
• הגדרת פרופילים של עבודה
• הגדרת מכשירי Android מנוהלים

בקר DPC לבדיקה משמש בעיקר ככלי רכב לבדיקת הארגון לפתרון של Android, תוכלו להשתמש בו גם כמקור לדוגמה של קוד ל-Android לבינה מלאכותית גנרטיבית.

התאמה אישית של ניהול הקצאות

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

בקר ה-DPC אוכף את בחירות הצבעים והלוגו באמצעות DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR וגם DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI תוספות.

כדי להגדיר צבע בהתאמה אישית, משתמשים בפונקציה EXTRA_PROVISIONING_MAIN_COLOR כדי להגדיר מספר שלם שמציין את הצבע העיקרי שיוצג במהלך המכשיר הקצאה. מזינים את התוספת (הקבועה) ב-Intent עם ACTION_PROVISION_MANAGED_PROFILE או ACTION_PROVISION_MANAGED_DEVICE

כדי לראות איך המספרים השלמים מיוצגים: צבע. לדוגמה, אפשר להיכנס אל MAIN_COLOR באפליקציה TestDPC.

כדי להגדיר לוגו מותאם אישית, משתמשים EXTRA_PROVISIONING_LOGO_URI כדי להגדיר תמונה שתוצג בחלק העליון של המסך במהלך המכשיר הקצאה. מזינים את התוספת (הקבועה) ב-Intent עם ACTION_PROVISION_MANAGED_PROFILE או ACTION_PROVISION_MANAGED_DEVICE צריך לוודא שהתמונה בצפיפות פיקסלים סבירה עבור המכשיר.

לדוגמה, אפשר להיכנס אל LOGO_URI באפליקציה TestDPC.

שיטת קוד QR

השיטה להקצאת קוד QR מגדירה ומגדירה את מצב בעל המכשיר לפי לסרוק קוד QR מאשף ההגדרה. קוד ה-QR מכיל מטען ייעודי (payload) של צמדי מפתח/ערך עם כל המידע שדרוש ל-DPC מכשיר.

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

תרחישים לדוגמה להקצאת קוד QR

מכשירים מסוימים, כמו טאבלטים, לא תומכים ב-NFC. הקצאת קוד QR היא דרך פשוטה להקצות צי מבוזר של מכשירים שאינם תומכים NFC. אדמין ב-IT יכול לשלוח קודי QR למשתמשים שלו כדי להפעיל אפליקציות מבוססות-משתמש הקצאה.

כדי להקצות קוד QR, לא נדרשת זהות ב-Google, כמו דומיין של Google או לחשבון Google. ארגונים שמשתמשים ב-Android אבל לא משתמשים ב-Google ל-Workspace, אתם לא יכולים לזהות זהות ב-Google.

בדומה ל-NFC, הקצאת קוד QR מאפשרת פריסות "קיוסק" ופריסות לשימוש חד-פעמי, שבהן זהות Google (או זהות כלשהי) אינה נחוצה או רצויה. לדוגמה, מכשיר קיוסק בחנות לא שייך לאף אחד ולא צריך להיות לו משתמש קצה זהות.

יצירת קוד QR

קוד QR חוקי להקצאת קוד QR הוא אובייקט JavaScript® בקידוד UTF-8 מחרוזת סימון (JSON). אפשר לכלול את המאפיינים הבאים בקוד QR תקין:

תמיד נדרש

• EXTRA_PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME

חובה אם עדיין לא מותקן בקר DPC במכשיר

• EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION
• EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM

מומלץ אם המכשיר עוד לא מחובר ל-Wi-Fi

• EXTRA_PROVISIONING_WIFI_SSID
• EXTRA_PROVISIONING_WIFI_PASSWORD

אופציונלי

• EXTRA_PROVISIONING_LOCALE
• EXTRA_PROVISIONING_TIME_ZONE
• EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
• EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_COOKIE_HEADER
• EXTRA_PROVISIONING_LOCAL_TIME
• EXTRA_PROVISIONING_WIFI_HIDDEN
• EXTRA_PROVISIONING_WIFI_SECURITY_TYPE
• EXTRA_PROVISIONING_WIFI_PROXY_HOST
• EXTRA_PROVISIONING_WIFI_PROXY_PORT
• EXTRA_PROVISIONING_WIFI_PROXY_BYPASS
• EXTRA_PROVISIONING_WIFI_PAC_URL
• EXTRA_PROVISIONING_SKIP_ENCRYPTION

הדוגמה הבאה יוצרת קוד QR תקין:

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.emm.android/com.emm.android.DeviceAdminReceiver",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":
"gJD2YwtOiWJHkSMkkIfLRlj-quNqG1fb6v100QmzM9w=",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
"https://path.to/dpc.apk",
    "android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
    "android.app.extra.PROVISIONING_WIFI_SSID": "GuestNetwork",
    "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
        "dpc_company_name": "Acme Inc.",
        "emm_server_url": "https://server.emm.biz:8787",
        "another_custom_dpc_key": "dpc_custom_value"
    }
}

תהליך הקצאת קוד QR

1. אשף ההגדרה מבקש מהמשתמש להקיש על מסך הפתיחה 6 פעמים. עליך לבצע את ההקשות באותו מקום במסך.
2. אשף ההגדרה מבקש מהמשתמש להתחבר לאינטרנט כדי שההתקנה יכול להוריד קורא קודי QR.
3. אפליקציית Google Play Services מורידה מודול שמכיל זיהוי קוד QR של מנוע החיפוש.
4. המשתמש סורק את קוד ה-QR שסופק על ידי האדמין ב-IT.
5. אשף ההגדרה מוריד את אפליקציית ה-DPC ומפעיל את בעלי המכשיר תהליך הקצאה באמצעות ACTION_PROVISION_MANAGED_DEVICE

שיטת 'חשבונות Google Play לארגונים'

בקר DPC יכול להשתמש בשיטה להקצאת חשבונות Google Play לארגונים כדי להגדיר מצב 'בעלי המכשיר' או מצב 'בעלי הפרופיל'. השיטה הזו של ניהול ההקצאות מטורגטת בארגונים שלא משתמשים ב-Google Workspace.

השיטה של הקצאת חשבונות Google Play לארגונים משתמשת ב ספריית התמיכה של DPC ספריית הלקוח הזו מבטיחה פעולה חלקה של Google Play לארגונים חשבונות. הוא גם שומר על תאימות לעדכונים עתידיים של האפליקציה המנוהלת תהליך הקצאת חשבונות Google Play.

דרישות מוקדמות להקצאת מכשירים

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

הגדרת מצב הבעלים של הפרופיל

אפשר להקצות את מצב הפעולה של בעלי הפרופיל במכשיר שנמצא בתהליך שמשמש בתרחיש BYOD כמכשיר אישי.

1. המשתמש מוריד את בקר ה-DPC באופן ידני מ-Google Play ומפעיל אותו.
2. ה-DPC מקצה את פרופיל העבודה באמצעות ACTION_PROVISION_MANAGED_PROFILE
3. מבצעים את שלבי ההגדרה הסופיים.

הגדרת מצב 'בעלי המכשיר'

עליך להקצות את מצב הפעולה של בעלי המכשיר במהלך ההגדרה הראשונית של במכשיר חדש או לאחר איפוס להגדרות המקוריות. לא ניתן להקצות את מצב 'בעלי המכשיר' ב- מכשיר בכל זמן אחר.

במהלך הגדרת המכשיר, המשתמש מזין אסימון מיוחד שספציפי ל-DPC, כשמבקשים להוסיף חשבון. הפורמט של אסימון הוא afw#DPC_IDENTIFIER. עבור ספק EMM בשם ACME, afw#acme יתקין את בקר ה-DPC המוגדר כברירת מחדל של ACME EMM. כל EMM חייב לבקש מזהה DPC ספציפי מ-Google כדי להשתמש בו אותו בתהליך ההקצאה.

1. המשתמש מפעיל מכשיר חדש או מכשיר שאופס להגדרות המקוריות ואת אשף ההגדרה השקות.
2. כאשר המשתמש מתבקש להוסיף חשבון, הוא מזין אסימון מיוחד פורמט afw#DPC_IDENTIFIER שמזהה את בקר ה-DPC של ה-EMM.
3. באמצעות מזהה ה-DPC באסימון, אשף ההגדרה מוסיף מזהה זמני חשבון Google למכשיר. החשבון הזמני הזה משמש רק להורדה בקר ה-DPC עבור ה-EMM מ-Google Play, והוא מוסר בעוד שלבי ההגדרה הסופיים.
4. ה-DPC מקצה את המכשיר באמצעות ACTION_PROVISION_MANAGED_DEVICE
5. מבצעים את שלבי ההגדרה הסופיים.

שלבי ההגדרה הסופיים של כל מצבי הפעילות

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

1. בקר ה-DPC מוודא שהמכשיר יכול לתמוך בחשבונות Google Play מנוהלים על ידי אתחול ספריית התמיכה של בקר DPC:

   AndroidForWorkAccountSupport androidForWorkAccountSupport =
     new AndroidForWorkAccountSupport(context, admin);
   androidForWorkAccountSupport.ensureWorkingEnvironment(callback);
   

   אם מגדירים את מצב 'בעלי המכשיר' במכשיר, השלב הזה מסיר את חשבון Google הזמני שנוסף כדי להוריד את ה-DPC.

2. המשתמש נכנס ל-DPC באמצעות פרטי הכניסה שלו ל-EMM. הנושאים האלה בדרך כלל פרטי הכניסה לאימיילים של הארגון.

3. ה-DPC מבקש את פרטי הכניסה של חשבון Google Play לארגונים עבור משתמש ארגוני מאומת ממסוף ה-EMM.

4. אם למסוף ה-EMM אין userId של Google Play למשתמש, יוצר משתמש חדש באמצעות קריאה Users.insert(). אם אתם מקצים הרשאות גישה למצב 'בעלי המכשיר', ציינו את חשבון המכשיר (ל פריסות של מכשירים ייעודיים) או חשבון משתמש (לפריסות בבעלות החברה).

5. כדי להגדיר את מדיניות המכשיר, צריך לשלוח קריאה Devices.update עליך להגדיר את המדיניות לפני שמוסיפים את חשבון Google Play המנוהל אל במכשיר, אחרת המדיניות לא תחול במשך פרק זמן קצר לאחר הוספת החשבון למכשיר.

6. מסוף ה-EMM מבקש את פרטי הכניסה של החשבון עבור userId על ידי שיחות Users.generateAuthenticationToken(). אסימון האימות הזה הוא לטווח קצר ולא ניתן להשתמש בו שוב. בקר ה-DPC להשתמש באסימון כדי להוסיף את החשבון באופן פרוגרמטי (אין לו שימוש בסוף משתמש).

7. ממשק ה-API של Google Play ל-EMM מחזיר את אסימון האימות למסוף ה-EMM.

8. מסוף ה-EMM מעביר את אסימון האימות אל ה-DPC.

9. בקר ה-DPC מוסיף את חשבון Google Play המנוהל למכשיר באמצעות

   androidForWorkAccountSupport.addAndroidForWorkAccount(token,
     accountAddedCallback);
   

השיטה של חשבון Google

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

כשמשתמשים מזינים את פרטי הכניסה לחשבון Google:

• שרת האימות של Google מאמת את חשבון המשתמש.
• לאחר מכן שרת האימות מתקשר עם השרת הארגוני כדי לראות אם הדומיין של החשבון רשום כדומיין ב-Google Workspace או כדומיין דומיין שמנוהל על ידי EMM.
• במקרה כזה, המערכת תוריד באופן אוטומטי את ה-DPC המשויך לדומיין מ-Google Play ומתקין אותו.

הגדרת מצב הבעלים של הפרופיל

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

1. אימות החשבון מתחיל על ידי משתמש מאשף ההגדרה או מהגדרות > מוסיפים חשבון.
2. GMSCore מתחיל הקצאת הרשאות ידנית של פרופיל עבודה באמצעות ACTION_PROVISION_MANAGED_DEVICE_FROM_TRUSTED_SOURCE.
3. מתבצעת הורדה אוטומטית של בקר ה-DPC למכשיר והוא מופעל באמצעות ACTION_GET_PROVISIONING_MODE handler כדי לאמת שה-DPC תומך בהקצאת הרשאות ידנית.
   • EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE — מידע נוסף על פרופיל העבודה, כמו כתובת אימייל. כחלק מחבילה זו, גם ה-DPC יקבל כאן את is_setup_אשף. החבילה הזו תיכלל ב-handlers של ACTION_GET_PROVISIONING_MODE ו-ACTION_ADMIN_POLICY_COMPLIANCE.
   • EXTRA_PROVISIONING_ACCOUNT_TO_MIGRATE – השם של החשבון המאומת שרוצים להעביר לפרופיל העבודה החדש.
4. הפלטפורמה מבצעת הקצאה של פרופיל עבודה.
5. כשפרופיל העבודה מוקצה, ה-DPC מקבל את השידור ACTION_PROFILE_PROVISIONING_COMPLETE בקר DPC ACTION_ADMIN_POLICY_COMPLIANCE ה-handler מופעל בפרופיל העבודה. אחרי שיוצרים את פרופיל העבודה, ה-DPC פועל גם בתוך פרופיל העבודה. בקר ה-DPC מגדיר כללי מדיניות עבור חשבון Google המנוהל מוודא שהמכשיר לא נמצא בסיכון ומאמת שכללי המדיניות נאכפים (למשל, הסיסמה).
6. בקר ה-DPC בפרופיל האישי מושבת בעצמו או שהמשתמש מסיר אותו.

הגדרת מצב בעלי המכשיר או COPE

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

1. אימות החשבון מתחיל על ידי משתמש מאשף ההגדרה.
2. GMSCore מתחיל את ניהול ההקצאות של בעלי המכשיר באמצעות ACTION_PROVISION_MANAGED_DEVICE_FROM_TRUSTED_SOURCE. 3.ה-DPC יורד באופן אוטומטי למכשיר והוא מופעל באמצעות ה-handler GET_PROVISIONING_MODE כדי לבחור את מצב ההקצאה הרצוי.
   • EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE— מידע נוסף לגבי פרופיל העבודה, כמו המיקום, ה-Wi-Fi וכתובת האימייל. כחלק מחבילה זו, גם ה-DPC יקבל כאן את is_setup_אשף. החבילה הזו תיכלל ב-ACTION_GET_PROVISIONING_MODE ו-ACTION_ADMIN_POLICY_COMPLIANCE handlers.
3. הפלטפורמה מקצה את המכשיר למצב הקצאת ההרשאות הרצוי.
4. לאחר הקצאת המכשיר, ה-DPC מקבל את השידורים האלה ומופעל ה-handler ACTION_ADMIN_POLICY_COMPLIANCE של ה-DPC:
   • ACTION_READY_FOR_USER_INITIALIZATION
   • ACTION_PROFILE_PROVISIONING_COMPLETE.
5. בקר ה-DPC משתמש בערך של Global.DEVICE_PROVISIONED כדי לאמת שהמכשיר חדש או שהוא אופס להגדרות המקוריות (לא הוקצה):
   • 0 – לא הוקצה.
   • 1 – מוקצה.
6. ה-DPC משלים את תהליך ההקצאה על ידי דחיפת מדיניות עבור שהמכשיר מנוהל, מוודאים שהמכשיר לא נמצא במצב 'פרוץ', אימות שכללי המדיניות נאכפים (למשל, דרישת סיסמה).

שיקולים להטמעה של שיטת הבידינג בחשבון Google

• ה-DPC אמור לזהות את תהליך האימות של חשבון Google על ידי חיפוש תוספות ספציפיות בכוונת ההשקה שבה נעשה שימוש (ראו LaunchIntentUtil):

  • חשבון מסוג android.accounts.Account — מציין ש- נוסף דרך אשף ההגדרה או דרך הגדרות > הוספת חשבון, כדי לנהל את המכשיר או הפרופיל, נדרש ה-DPC שהופעל.
  • is_setup_wizard מסוג בוליאני — אם True, ה-DPC הופעל ב אשף ההגדרה לפני השלמת אשף ההגדרה. אחרת, הגדרות > הוספת חשבון או תהליך אחר.

  בדיקה אם בקר ה-DPC הופעל כחלק משיטת הבידינג של חשבון Google היא:

  boolean isSynchronousAuthLaunch(Intent launchIntent) {
    return launchIntent.hasExtra("is_setup_wizard");
  }
  

• אין להפעיל את ה-DPC: finish() לפני סיום ההגדרה. הוא צריך גם להחזיר קוד תוצאה חיובי (למשל RESULT_OK), כשבקר ה-DPC מופעל באמצעות startActivityForResult() ומחכה לתוצאה.

  ה-DPC צריך להמתין לקבלת קוד תוצאה מתהליך ההקצאה לפני קוראים לפונקציה finish() אם תהליך ההגדרה של בקר DPC מגיע לנקודה של שליחת Intent מסוג ACTION_PROVISION_*. משתמשים ב startActivityForResult() ו-onActivityResult() קריאות חוזרות (callback) כשמפעילים את ה-Intents של ACTION_PROVISION_*. (ראו LaunchActivity ו-SetupSyncAuthManagement לקבלת דוגמאות).

  בשל אופיו של תהליך ההגדרה שעשוי להיות אסינכרוני, בקר ה-DPC לא יכול להסתמך על קוד תוצאה של RESULT_OK כדי לציין שהקצאה הצליחה. הדרך היחידה והמובטחת היא להסתמך DeviceAdminReceiver קריאות חוזרות (callback) להקצאת הרשאות ידנית. RESULT_CANCELED מציין שהמשתמש מגובים בחלק סינכרוני בתהליך ההגדרה, וה-DPC אמור להגיב לזה.

  בדוגמה זו, ה-DPC מפעיל הקצאת הרשאות ידנית וממתין לקוד התוצאה מפעילות:

  Intent intent = new Intent(ACTION_PROVISION_MANAGED_PROFILE);
  startActivityForResult(intent, REQUEST_MANAGED_PROFILE);
  ...
  
  @Override
  public void onActivityResult(int req, int res, Intent i) {
      if (req == REQUEST_MANAGED_PROFILE) {
          if (res == Activity.RESULT_OK) {
              setResult(Activity.RESULT_OK);
              finish();
          } else {
              Toast.makeText(this, “Provisioning failed”,
                      Toast.LENGTH_SHORT).show();
          }
      }
  }
  

• אסור שה-DPC ינסה להגדיר את מצב הפעולה של בעלי המכשיר אם שהמכשיר כבר הוקצה ProvisioningStateUtil.isDeviceProvisioned()). בדוגמה זו, בקר ה-DPC בודק אם המכשיר מוקצה:

  public static boolean isDeviceProvisioned(Context context) {
  ContentResolver cr = context.getContentResolver();
      return
  Settings.Global.getInt(cr, DEVICE_PROVISIONED, 0) != 0;
  }
  

• זה שינוי אופציונלי. בקר ה-DPC יכול להשתמש EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE נוספות בעת הפעלת הקצאה להעברת מידע על מצב DeviceAdminReceiver (שבמקרה של בעלי הפרופיל, פועל בתוך פרופיל העבודה). הפונקציה TestDPC משתמשת בתוספת הזאת. להזין קבוצה אחרת של פעילויות בתהליך של חשבון Google לאחר ההקצאה הושלמה. פרטים נוספים זמינים במאמר DeviceAdminReceiver

  public class DeviceAdminReceiver extends android.app.admin.DeviceAdminReceiver
  {
    @Override
    public void onProfileProvisioningComplete(Context context, Intent intent) {
      // Retrieve the admin extras bundle, which we can use to determine the original context for
      // Test DPC's launch.
      PersistableBundle extras = intent.getParcelableExtra(
              EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE);
      ...
  

• כדי להגדיר פרופיל עבודה, ה-DPC צריך להעביר את החשבון שנוסף פרופיל עבודה חדש. לשם כך, ה-DPC צריך להעביר את החשבון שצוין ב כוונת השקה עבור ACTION_PROVISION_MANAGED_PROFILE

• בקר ה-DPC צריך לספק למשתמש קריאה ברורה לפעולה (כמו הלחצן 'סיום') כדי לצאת מהאפליקציה בסיום ההגדרה, כדי שהמשתמש לא יחשוב הם הגיעו למבוי סתום בתהליך.

• ה-DPC צריך להשתמש בעיצוב או בספריית הפריסה של אשף ההגדרה כדי שהמשתמש היא חלקה ומשולבת היטב.

שיטת NFC

בקר DPC יכול להשתמש בשיטה של הקצאת NFC כדי להגדיר את מצב בעלי המכשיר. ב בדרך של הקצאת NFC, או תג NFC, אתם יוצרים אפליקציה של מתכנת NFC כולל את המדיניות הראשונית ואת תצורת ה-Wi-Fi, ההגדרות פרטי הקצאת ההרשאות שנדרשים על ידי הלקוח כדי להגדיר את בעלי המכשיר מצב פעולה. כאשר הלקוח שלך או שלך מתקינים את אפליקציית מתכנת NFC במכשיר מכשיר שמופעל על ידי Android, המכשיר הזה הופך למכשיר של המתכנת.

כדי להקצות מכשיר, האדמין ב-IT מוציא מכשיר חדש ומצמידים אותו למכשיר המתכנת או לתג ה-NFC. העברת Bump את ההגדרות האישיות של המכשיר כך שהוא יתחבר לאינטרנט ויוריד את את המדיניות ואת ההגדרות המתאימות. לאחר מכן המכשיר מנוהל על ידי בקר ה-DPC.

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

יצירת האפליקציה של מתכנת NFC ומכשיר המתכנת

במכשירים עם Android מגרסה 10 ומעלה, אפשר להשתמש ב-Android Beam כדי משלימים הקצאת NFC:

1. מורידים את האפליקציה לדוגמה של מתכנת NFC. אפשר להשתמש בדוגמה כפי שהיא ללא תוספות, או לשנות אותה ערכי ברירת המחדל שלכם.
2. מתקינים את אפליקציית המתכנת במכשיר הנבחר.
3. מפעילים את אפליקציית מתכנת NFC ובוחרים באפשרות Load Defaults (טעינת ברירות המחדל) עבור com.example.android.apis. (הטקסט הזה עשוי להשתנות בהתאם לברירת המחדל הפרמטרים שאתם מגדירים).

הקצאת מכשיר של לקוח

1. להצמיד את המכשיר המתכנת או את תג ה-NFC במכשיר חדש או במכשיר חדש איפוס להגדרות המקוריות.
2. מוודאים שהמכשיר נשאר במסך תחילת העבודה הראשוני ש יוצג בתחילת ההפעלה. הטקסט צוין בReady to send:{...} באפליקציית המתכנתים.
3. ממתינים בזמן ה-DPC:
   1. הצפנת המכשיר.
   2. אם מדובר במכשיר עם גישה מרובה (CDMA) של Code-Division: מפעילה את הטלפון בזמן שמוצג ממשק משתמש של טלפון (אין צורך באינטראקציה).
   3. מגדיר את חיבור ה-Wi-Fi.
   4. הורדת קובץ ה-APK עבור com.example.android.apis.
   5. מתקין את com.example.android.apis.
   6. מגדיר את דגימת האדמין של המכשיר בכתובת com.example.android.apis בתור הבעלים של המכשיר.
   7. מציג 'טוסט' שהצליח כשבעלי המכשיר מופעלים.
4. לאחר חזרה לדף הבית (דילוג אוטומטי על אשף ההגדרה), צריך לבדוק ש-com.example.android.apis מוגדר כבעלים של המכשיר:
   1. בהגדרות > אבטחה > מנהלי מכשירים, צריך לוודא שמכשיר לדוגמה לא ניתן להסיר את האדמין.
   2. בהגדרות > משתמשים > משתמשים ו פרופילים > אתם (בעלים), צריך לוודא הבעלים הוא החשבון היחיד הזמין (מכשיר יכול להיות רק פעיל אחד של הבעלים של המכשיר).

מקורות מידע נוספים

NFC מתקדם מתאר נושאים כגון עבודה עם טכנולוגיות תגים שונות, כתיבה ל-NFC תגים ושליחת נתונים בחזית.

שיטת התקנה ידנית של בקר DPC

כדי להגדיר את מצב הבעלים של הפרופיל באמצעות השיטה הידנית להקצאה ידנית של הרשאות התקנה מ-DPC: המשתמש מוריד את בקר ה-DPC מ-Google Play ומתקין אותו. ואז בקר DPC מנחה את המשתמש בתהליך ההגדרה של בעלי הפרופיל חשבון Google המנוהל.

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

הגדרת מצב הבעלים של הפרופיל

קודם צריך להוסיף את חשבון Google המנוהל

1. המשתמש מוריד את בקר ה-DPC מ-Google Play ומתקין אותו.
2. בקר ה-DPC מוסיף את חשבון Google המנוהל לפני יצירת פרופיל העבודה באמצעות AccountManager.addAccount().
3. ה-DPC מתחיל לפעול בפרופיל האישי ומבצע את התהליך כדי יצירת פרופיל עבודה באמצעות:
   • ACTION_PROVISION_MANAGED_PROFILE — הקצאת פרופיל העבודה.
   • EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE — מידע נוסף על פרופיל העבודה, כמו מקום, Wi-Fi, אימייל address.
   • EXTRA_PROVISIONING_ACCOUNT_TO_MIGRATE — שם החשבון המאומת שיועבר ליצירה החדשה פרופיל.
4. תהליך ההקצאה משלים את ה-DPC בפרופיל העבודה. אחרי שהעבודה ה-DPC פועל גם בתוך פרופיל העבודה. בקר DPC ב פרופיל העבודה משלים את תהליך ההקצאה על ידי דחיפת מדיניות עבור שחשבון Google מנוהל, כדי לוודא שהמכשיר לא נמצא בסיכון ואימות שכללי המדיניות נאכפים (למשל דרישה הסיסמה).
5. כשפרופיל העבודה מוקצה, ה-DPC מקבל את השידור ACTION_PROFILE_PROVISIONING_COMPLETE
6. בקר ה-DPC בפרופיל האישי משבית את עצמו או שהמשתמש מסיר אותו.

קודם צריך ליצור את פרופיל העבודה

1. המשתמש מוריד את בקר ה-DPC מ-Google Play ומתקין אותו.
2. ה-DPC מתחיל לפעול בפרופיל האישי ומבצע את התהליך כדי יצירת פרופיל עבודה באמצעות:
   • ACTION_PROVISION_MANAGED_PROFILE — הקצאת פרופיל העבודה.
   • EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE — מידע נוסף על פרופיל העבודה, כמו מקום, Wi-Fi, אימייל address.
3. בקר ה-DPC מוסיף את חשבון Google המנוהל באמצעות AccountManager.addAccount()
4. ה-DPC מקבל את השידור ACTION_PROFILE_PROVISIONING_COMPLETE וקורא EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
5. תהליך ההקצאה משלים את ה-DPC בפרופיל העבודה. לאחר יצירת פרופיל העבודה, ה-DPC פועל גם בתוך סביבת העבודה פרופיל. ה-DPC בפרופיל העבודה משלים את תהליך ההקצאה על ידי להגדיר כללי מדיניות לחשבון Google המנוהל הזה, כדי לוודא שהמכשיר לא במצב 'פרוץ', ולאמת שכללי המדיניות נאכפים. (למשל, דרישת סיסמה).
6. ה-DPC מפעיל את פרופיל העבודה באמצעות DevicePolicyManager.setProfileEnabled()
7. בקר ה-DPC בפרופיל האישי משבית את עצמו או שהמשתמש מסיר אותו.