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

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

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

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

תרחישי פריסה

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

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

מצבי פעולה

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

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

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

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

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

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

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

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

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

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

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

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

תרחיש פריסה	מצב פעולה	שיטת ההקצאה	5.0, 5.1	6.0, מאוחר יותר	7.0 ואילך
בבעלות החברה	בעלי המכשיר	קוד QR			✓
		חשבונות Google Play מנוהלים		✓	✓
		חשבון Google		✓	✓
		NFC	✓	✓	✓
BYOD	בעלי הפרופיל	חשבונות Google Play מנוהלים	✓	✓	✓
		חשבון Google	5.1^1	✓	✓
		התקנה ידנית של בקר DPC	✓	✓	✓

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

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

תאימות לשירותי Google Play

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

נקודות עיקריות לגבי תאימות של בקר DPC עם Google Play Services:

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

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

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

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

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

הערה: אפשר להתקשר למכשירים.update מיד אחרי הרשמת המכשיר. לא צריך להמתין עד ש-Devices.get יחזיר את פרטי המכשיר.

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

יש כמה דברים שכדאי לקחת בחשבון כשכותבים את ה-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, והמשתמשים יקבלו עדכוני אפליקציות ברגע שיהיו זמינים.

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

כדי לאפשר למשתמשים לראות את אפליקציות המערכת ברגע שהם מתחילים להשתמש במכשירים שלהם, צריך להפעיל את אפליקציות המערכת כחלק מתהליך הקצאת המכשירים. בקר ה-DPC מאפשר להפעיל אפליקציות מערכת לפי שם חבילה או לפי Intent באמצעות 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 לא ירצו לדחוף אפליקציות מרובות, אבל הם לא יכולים למנוע זאת כשיש מספר רכיבי handler של Intent.

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

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

יתרונות:

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

חסרונות:

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

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

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

• הדמיית תכונות ב-Android
• הגדרה ואכיפה של כללי מדיניות
• הגדרת הגבלות על אפליקציות ו-Intent
• הגדרה של פרופילי עבודה
• הגדרה של מכשירי 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.

כדי לראות איך המספרים השלמים מיוצגים, עיינו בקטע Color. לדוגמה, תוכלו לקרוא את המאמר 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® Object Notation (JSON) בקידוד UTF-8. אפשר לכלול את המאפיינים הבאים בקוד 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, שהם בדרך כלל פרטי כניסה לאימייל עסקי.

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

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

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

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

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

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

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(). אם אתם מקצים מצב 'בעלי מכשיר', עליכם לציין חשבון מכשיר (לפריסות מכשירים ייעודיות) או חשבון משתמש (לפריסות בבעלות החברה).

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

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

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

7. ה-Google Play EMM API מחזיר את אסימון האימות למסוף ה-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 למכשיר באופן אוטומטי ומופעלת באמצעות ה-handler של ACTION_GET_PROVISIONING_MODE, כדי לוודא שהבקר DPC תומך בניהול ההקצאות של פרופיל העבודה.
   • EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE — פרטים נוספים לפרופיל העבודה, כמו כתובת אימייל. ה-DPC יקבל גם את is_setup_אשף כאן כחלק מהחבילה הזו. החבילה הזו תיכלל ב-ACTION_GET_PROVISIONING_MODE וב-ACTION_ADMIN_POLICY_COMPLIANCE handlers.
   • EXTRA_PROVISIONING_ACCOUNT_TO_MIGRATE — השם של החשבון המאומת שרוצים להעביר לפרופיל העבודה החדש.
4. הפלטפורמה מבצעת הקצאת הרשאות של פרופיל עבודה.
5. אחרי ההקצאה של פרופיל העבודה, בקר ה-DPC מקבל את השידור ACTION_PROFILE_PROVISIONING_COMPLETE. ה-handler של ACTION_ADMIN_POLICY_COMPLIANCE של ה-DPC הופעל בפרופיל העבודה. אחרי שיוצרים את פרופיל העבודה, ה-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_אשף כאן כחלק מהחבילה הזו. החבילה הזו תיכלל ב-handlers של ACTION_GET_PROVISIONING_MODE ו-ACTION_ADMIN_POLICY_COMPLIANCE.
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 — מציין שהחשבון נוסף מאשף ההגדרה או דרך Settings > Add account (הגדרות > הוספת חשבון), וכדי לנהל את המכשיר או הפרופיל יש להפעיל את בקר ה-DPC.
  • is_setup_wizard מסוג בוליאני — אם הערך הוא True, ה-DPC הופעל באשף ההגדרה לפני השלמת אשף ההגדרה, אחרת דרך Settings > Add account (הגדרות > הוספת חשבון) או בתהליך אחר.

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

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

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

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

  בגלל האופי של תהליך ההגדרה שעשוי להיות אסינכרוני, בקר ה-DPC לא יכול להסתמך על קוד התוצאה RESULT_OK כדי לציין שההקצאה הצליחה. הדרך המובטחת היחידה היא להסתמך על קריאה חוזרת (callback) מ-DeviceAdminReceiver להקצאת בהצלחה. 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. הבלף מעביר את ההגדרות למכשיר כדי להתחבר לאינטרנט ומוריד את ההגדרות וכללי המדיניות המתאימים. לאחר מכן המכשיר מנוהל על ידי בקר ה-DPC.

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

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

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

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

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

1. מכניסים את המכשיר עם המתכנת או את תג ה-NFC במכשיר חדש או במכשיר שעבר איפוס להגדרות המקוריות.
2. מוודאים שהמכשיר נשאר במסך הברוכים הבאים הראשוני שמוצג עם ההפעלה. הטקסט מצוין ב-Ready to send:{...} באפליקציית Programmer.
3. ממתינים בזמן בקר ה-DPC:
   1. מצפין את המכשיר.
   2. אם מדובר במכשיר Code-Division Multiple Access (CDMA): הפעלת הטלפון בזמן שמוצג ממשק משתמש טלפוני (לא נדרשת אינטראקציה).
   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 יכול ליצור פרופיל עבודה שמבוסס על פרטי הכניסה של המשתמש לניהול הניידות בארגון, במקום לבקש תחילה את חשבון Google המנוהל.

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

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

1. המשתמש מוריד את בקר ה-DPC מ-Google Play ומתקין אותו.
2. בקר ה-DPC מוסיף את חשבון Google המנוהל לפני יצירת פרופיל העבודה באמצעות AccountManager.addAccount().
3. בקר ה-DPC מתחיל לפעול בפרופיל האישי ומתחיל בתהליך ליצירת פרופיל עבודה באמצעות:
   • ACTION_PROVISION_MANAGED_PROFILE — מקצה את פרופיל העבודה.
   • EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE — מידע נוסף לפרופיל העבודה, כמו לוקאל, Wi-Fi וכתובת אימייל.
   • 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 וכתובת אימייל.
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 בפרופיל האישי משבית את עצמו או שהמשתמש מסיר אותו.

---

1. השיטה של חשבון Google ב-Android 5.1 תומכת רק במצב הפעולה של בעלי הפרופיל, והמשתמש יכול להגדיר אותה רק דרך הגדרות > הוספת חשבון.↩