‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

רישום וניהול של מכשיר

הקצאת הרשאות היא תהליך של הגדרת מכשיר לניהול באמצעות policies על ידי enterprise. במהלך התהליך, המכשיר מתקין את Android Device Policy, שמשמשת לקבלה ולאכיפה של policies. אם ההקצאה מצליחה, ה-API יוצר אובייקט devices, שמקשר את המכשיר לארגון.

‫Android Management API משתמש באסימוני רישום כדי להפעיל את תהליך הקצאת ההרשאות. אסימון ההרשמה ושיטת ההקצאה שבהם אתם משתמשים קובעים את הבעלות על המכשיר (בבעלות אישית או בבעלות החברה) ואת מצב הניהול (פרופיל עבודה או מכשיר בניהול מלא).

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

מכשירים בבעלות אישית

Android מגרסה 5.1 ואילך

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

כדי להגדיר פרופיל עבודה במכשיר בבעלות אישית, יוצרים אסימון רישום (מוודאים שהערך של allowPersonalUsage מוגדר ל-PERSONAL_USAGE_ALLOWED) ומשתמשים באחת מהשיטות הבאות להקצאת הרשאות:

הוספת פרופיל עבודה דרך "הגדרות"
הורדת Android Device Policy
קישור לטוקן רישום
כתובת ה-URL לכניסה

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

Android מגרסה 8 ואילך

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

רוב policies של האפליקציות, הנתונים וניהול אחר חלים רק על פרופיל העבודה.
הפרופיל האישי של העובד נשאר פרטי. עם זאת, ארגונים יכולים לאכוף כללי מדיניות מסוימים ברמת המכשיר וכללי מדיניות לגבי שימוש אישי.
ארגונים יכולים להשתמש ב-blockScope כדי לאכוף פעולות תאימות במכשיר כולו או רק בפרופיל העבודה שלו.
devices.delete ופקודות למכשירים חלים על כל המכשיר.

כדי להגדיר מכשיר בבעלות החברה עם פרופיל עבודה, יוצרים אסימון רישום (מוודאים שהערך של allowPersonalUsage הוא PERSONAL_USAGE_ALLOWED) ומשתמשים באחת מהשיטות הבאות להקצאת הרשאות:

שיוך אוטומטי לארגון
קוד QR
כתובת ה-URL לכניסה
מזהה DPC

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

Android מגרסה 5.1 ואילך

ניהול מלא של המכשיר מתאים למכשירים בבעלות החברה שמיועדים רק למטרות עבודה. ארגונים יכולים לנהל את כל האפליקציות במכשיר ולאכוף את כל המדיניות והפקודות של Android Management API.

אפשר גם לנעול מכשיר (באמצעות מדיניות) לאפליקציה אחת או לקבוצה קטנה של אפליקציות, כדי לשרת מטרה או תרחיש שימוש ייעודיים. קבוצת המשנה הזו של מכשירים בניהול מלא נקראת מכשירים ייעודיים. בטוקנים של רישום למכשירים האלה, צריך להגדיר את allowPersonalUsage בתור PERSONAL_USAGE_DISALLOWED_USERLESS.

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

שיוך אוטומטי לארגון
קוד QR
כתובת URL לכניסה (לא מתאימה למכשירים ייעודיים)
NFC
מזהה DPC

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

‫PasswordPolicyScope: ההגדרה הזו קובעת את הדרישות לגבי סיסמאות.
PermittedInputMethods: ההגדרה הזו קובעת את שיטות הקלט של החבילה.
PermittedAccessibilityServices: ההגדרה הזו קובעת אילו שירותי נגישות מותרים במכשירים בניהול מלא ובפרופיל העבודה.
SetupActions: ההגדרה הזו קובעת אילו פעולות יבוצעו במהלך ההגדרה.
‫ApplicationsPolicy: ההגדרה הזו קובעת את המדיניות של אפליקציה ספציפית.

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

יצירת טוקן רישום

סקירה כללית על ניהול Android. — **איור 1.** יוצרים טוקן שרושם את המכשירים ומחיל עליהם את "policy1". אחרי 1,800 שניות (30 דקות), תוקף האסימון יפוג.

צריך טוקן רישום לכל מכשיר שרוצים לרשום (אפשר להשתמש באותו טוקן לכמה מכשירים). כדי לבקש טוקן הרשמה, צריך להפעיל את enterprises.enrollmentTokens.create. כברירת מחדל, התוקף של אסימוני רישום פג אחרי שעה אחת, אבל אפשר לציין זמן תפוגה בהתאמה אישית (duration) עד כ-10,000 שנים.

אם הבקשה תצליח, יוחזר אובייקט enrollmentToken שמכיל enrollmentTokenId ו-qrcode, שבהם אדמינים ממחלקת IT ומשתמשי קצה יכולים להשתמש כדי להקצות מכשירים.

ציון מדיניות

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

הגדרת שימוש אישי

ההגדרה allowPersonalUsage קובעת אם אפשר להוסיף פרופיל עבודה למכשיר במהלך ההקצאה. צריך להגדיר את הערך PERSONAL_USAGE_ALLOWED כדי לאפשר למשתמש ליצור פרופיל עבודה (חובה במכשירים בבעלות אישית, אופציונלי במכשירים בבעלות החברה).

פטור לטוקנים קיימים של רישום

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

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

אכיפת אימות של Google בזמן ההרשמה

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

אפשרויות להגדרות אישיות

אתם יכולים לשלוט בהתנהגות האימות באמצעות האובייקט googleAuthenticationOptions בתוך EnrollmentToken או SigninDetail.

שדה	תיאור	ערכים
`authenticationRequirement`	ההגדרה קובעת אם המשתמש חייב לבצע אימות באמצעות Google במהלך ההרשמה.	‫AUTHENTICATION_REQUIREMENT_UNSPECIFIED: חזרה להגדרות ברירת המחדל של הארגון. ‫ אופציונלי: המשתמש רואה את מסך הכניסה של Google אבל יכול לבחור לדלג עליו. חובה: המשתמש לא יכול לדלג על הכניסה. הכפתור "דילוג" מוסתר.
`requiredAccountEmail`	כתובת האימייל הספציפית של חשבון Google המנוהל שבו המשתמש צריך להשתמש. הערה: אם משתמשים בשדה הזה, חובה להגדיר את `authenticationRequirement` כ-REQUIRED.	מחרוזת (למשל, "user@enterprise.com")

דוגמאות למטען ייעודי (payload) של JSON

השבתת כפתור הדילוג

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

{
  ...
  "googleAuthenticationOptions": {
    "authenticationRequirement": "REQUIRED"
  }
}

דרישה לכתובת אימייל ספציפית של החשבון

כדי לאלץ את המשתמש להיכנס באמצעות חשבון ייעודי, מגדירים את המחרוזת requiredAccountEmail. הבקשה ליצירת טוקן תיכשל עם השגיאה INVALID_ARGUMENT אם שדה הדרישה לא מוגדר כ-REQUIRED לצד השדה.

{
...
  "googleAuthenticationOptions": {
    "authenticationRequirement": "REQUIRED",
    "requiredAccountEmail": "user@enterprise.com"
  }
}

מידע על קודי QR

קודי QR הם שיטה יעילה להקצאת מכשירים בארגונים שבהם יש הרבה כללי מדיניות שונים. קוד ה-QR שמוחזר מ-enterprises.enrollmentTokens.create מורכב ממטען ייעודי (payload) של צמדי מפתח/ערך שמכילים אסימון רישום ואת כל המידע שנדרש ל-Android Device Policy כדי להקצות מכשיר.

חבילת קודי QR לדוגמה

החבילה כוללת את מיקום ההורדה של מדיניות מכשיר Android ואסימון רישום.

{
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup",
    "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
        "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "{enrollment-token}"
    }
}

אפשר להשתמש בקוד ה-QR שמתקבל מ-enterprises.enrollmentTokens.create ישירות או להתאים אותו אישית. כאן מפורטת רשימה מלאה של המאפיינים שאפשר לכלול בחבילת קוד QR.

כדי להמיר את המחרוזת qrcode לקוד QR שניתן לסריקה, משתמשים במחולל קודי QR כמו ZXing.

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

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

הוספת פרופיל עבודה דרך "הגדרות"

Android מגרסה 5.1 ואילך

כדי להגדיר פרופיל עבודה במכשיר, המשתמש יכול:

עוברים אל הגדרות > Google > הגדרה ושחזור.
לוחצים על הגדרת פרופיל העבודה.

השלבים האלה מפעילים אשף הגדרה שמוריד את Android Device Policy למכשיר. בשלב הבא, המשתמש יתבקש לסרוק קוד QR או להזין ידנית טוקן רישום כדי להשלים את ההגדרה של פרופיל העבודה.

הורדת Device Policy למכשירי Android

Android מגרסה 5.1 ואילך

כדי להגדיר פרופיל עבודה במכשיר Android, המשתמשים יכולים להוריד את Android Device Policy מחנות Google Play. אחרי שהאפליקציה תותקן, המשתמש יתבקש לסרוק קוד QR או להזין ידנית טוקן רישום כדי להשלים את הגדרת פרופיל העבודה.

קישור לטוקן הרישום

Android מגרסה 5.1 ואילך

משתמשים בטוקן ההרשמה שהוחזר מ-enrollmentTokens.create או ב-signinEnrollmentToken של הארגון, ויוצרים כתובת URL בפורמט הבא:

https://enterprise.google.com/android/enroll?et=<enrollmentToken>

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

כתובת ה-URL לכניסה

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

מציינים את כתובת ה-URL לכניסה ב-enterprises.signInDetails[]. מגדירים את allowPersonalUsage לערך PERSONAL_USAGE_ALLOWED אם רוצים לאפשר למשתמש ליצור פרופיל עבודה (חובה במכשירים בבעלות אישית, אופציונלי במכשירים בבעלות החברה).

מוסיפים את ה-signinEnrollmentToken שנוצר כתוספת להקצאת ההרשאות לקוד QR, למטען ייעודי (payload) של NFC או להגדרה ללא מגע ידני. אפשר גם לתת למשתמשים את הערך של signinEnrollmentToken ישירות.

הערה: בדומה ליצירת טוקן רישום, אם כתובת URL לכניסה יצרה טוקן רישום לפני שהארגון הפעיל את האפשרות "אימות באמצעות Google" בפעם הראשונה, המשתמש לא יתבקש להיכנס. עם זאת, כל הטוקנים שנוצרו אחרי שההגדרה הזו הופעלה יפעלו לפי ההתנהגות המעודכנת וישתמשו בהגדרות האימות שנקבעו על ידי האדמין ממחלקת ה-IT.
בוחרים אפשרות:
1. מכשירים בבעלות החברה: אחרי שמפעילים מכשיר חדש או מכשיר שאופס להגדרות המקוריות, מעבירים את signinEnrollmentToken למכשיר (באמצעות קוד QR, הצמדת NFC וכו') או מבקשים מהמשתמשים להזין את האסימון באופן ידני. המכשיר יפתח את כתובת ה-URL לכניסה שצוינה בשלב 1.
2. מכשירים בבעלות אישית: מבקשים מהמשתמשים להוסיף פרופיל עבודה דרך "הגדרות". כשמוצגת בקשה, המשתמש סורק קוד QR שמכיל את signinEnrollmentToken או מזין את האסימון באופן ידני. המכשיר יפתח את כתובת ה-URL לכניסה שצוינה בשלב 1.
3. מכשירים בבעלות אישית: מספקים למשתמשים קישור לטוקן הרשמה, שבו טוקן ההרשמה הוא signinEnrollmentToken. המכשיר יפתח את כתובת ה-URL לכניסה שצוינה בשלב 1.
בודקים אם Google כבר אימתה את המשתמש. מקבלים את פרטי ניהול הקצאות המכשירים (במהלך רישום המכשיר) באמצעות הפרמטר GET‏ provisioningInfo ובודקים אם יש ערך בשדה authenticatedUserEmail. אם יש ערך בשדה הזה, המשתמש כבר אומת בהצלחה על ידי Google ואתם יכולים להשתמש בזהות הזו בלי אימות נוסף.

הערה: האובייקט provisioningInfo זמין למשך עד 24 שעות אחרי הקצאת המכשיר.
אם Google עדיין לא אימתה את המשתמש, כתובת ה-URL לכניסה צריכה לבקש מהמשתמשים להזין את פרטי הכניסה שלהם. על סמך הזהות שלהם, אתם יכולים לקבוע את המדיניות המתאימה ולקבל את פרטי הקצאת ההרשאות למכשיר (במהלך רישום המכשיר) באמצעות הפרמטר GET provisioningInfo.

שיטה מומלצת: השתמשו בספק ה-SSO של הארגון כדי לאמת את פרטי הכניסה שהמשתמשים מזינים בכתובת ה-URL לכניסה (או בכל הפניה אוטומטית לאחר מכן). כתובות ה-URL לכניסה נפתחות בכרטיסייה מותאמת אישית ב-Chrome, והכניסה היחידה (SSO) של המשתמשים נשמרת לכניסה עתידית לאפליקציה באמצעות App Auth.
מפעילים את enrollmentTokens.create ומציינים את הערך המתאים של policyId על סמך פרטי הכניסה של המשתמש.

הערה: המערכת מתעלמת מהשדה allowPersonalUsage כי הערך כבר צוין ב-enterprises.signInDetails[]. אי אפשר לשנות את ערך השימוש האישי במהלך ההרשמה.
מחזירים את אסימון ההרשמה שנוצר בשלב 5 באמצעות הפניה אוטומטית לכתובת URL, בפורמט https://enterprise.google.com/android/enroll?et=<token>.

הערה: אם למשתמש אין הרשאה להשלים את תהליך ההקצאה, אפשר להציג מסכי שגיאה בהתאמה אישית ולהפנות לכתובת https://enterprise.google.com/android/enroll/invalid כדי לעזור למשתמש לאפס את המכשיר.

אכיפת אימות של Google עם תהליך כתובת URL לכניסה

כשמשתמשים ב-SigninDetail לתהליכי כניסה של צד שלישי (באמצעות enterprises.create או enterprises.patch), אפשר להעביר את googleAuthenticationOptions. כך הכללים נאכפים לפני שהמשתמש מופנה לכתובת ה-URL לכניסה של הצד השלישי.

כשיוצרים EnrollmentToken בסוף תהליך של כתובת URL לכניסה, דרישות האימות שלו משפיעות על ה-SigninDetail הראשוני:

אם המשתמש דילג על הכניסה ל-Google כי היא לא נדרשה על ידי SigninDetail, אבל ב-EnrollmentToken שנוצר הדרישה מוגדרת כ-REQUIRED, המשתמש יראה שגיאה ויצטרך להיכנס לחשבון.
אם requiredAccountEmail מוגדר באסימון והמשתמש נכנס עם כתובת אחרת ששייכת לארגון, הוא יקבל את השגיאה "חשבון שגוי" ויצטרך להיכנס שוב עם כתובת האימייל הנכונה.

שיטת קוד QR

Android מגרסה 7.0 ואילך

כדי להקצות מכשיר בבעלות החברה, אתם יכולים ליצור קוד QR ולהציג אותו במסוף ה-EMM:

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

שיטת NFC

‫Android מגרסה 6.0 ואילך

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

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

https://play.google.com/managed/downloadManagingApp?identifier=setup

שיטת המזהה של DPC

אם אי אפשר להוסיף את מדיניות מכשיר Android באמצעות קוד QR או NFC, משתמש או אדמין ממחלקת IT יכולים לבצע את השלבים הבאים כדי להקצות מכשיר בבעלות החברה:

פועלים לפי ההוראות של אשף ההגדרה במכשיר חדש או במכשיר שאופס להגדרות המקוריות.
מזינים את פרטי ההתחברות ל-Wi-Fi כדי לחבר את המכשיר לאינטרנט.
כשמוצגת בקשה להיכנס לחשבון, מזינים afw#setup כדי להוריד את מדיניות מכשיר Android.
סורקים קוד QR או מזינים ידנית אסימון רישום כדי להקצות את המכשיר.

שיוך אוטומטי לארגון

‫Android 8.0 ואילך (Pixel 7.1 ואילך)

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

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

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

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

{
   "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
   "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":"I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
   "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
      "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"{Sign In URL token}"
   }
}

הפעלת אפליקציה במהלך ההגדרה

setupaction — **איור 2.** אפשר להשתמש ב-`setupActions` כדי להפעיל אפליקציה במהלך ההגדרה.

ב-policies, אפשר לציין אפליקציה אחת ש-Android Device Policy תפעיל במהלך הגדרת המכשיר או פרופיל העבודה. לדוגמה, אפשר להפעיל אפליקציית VPN כדי שהמשתמשים יוכלו לקבוע את הגדרות ה-VPN כחלק מתהליך ההגדרה. האפליקציה צריכה להחזיר את הערך RESULT_OK כדי לאותת על סיום הפעולה ולאפשר ל-Android Device Policy להשלים את הקצאת המכשיר או פרופיל העבודה. כדי להפעיל אפליקציה במהלך ההגדרה:

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

{
   "applications":[
      {
         "packageName":"com.my.vpnapp.",
         "installType":"REQUIRED_FOR_SETUP"
      }
   ]
}

מוסיפים את שם החבילה של האפליקציה אל setupActions. משתמשים ב-title וב-description כדי לציין הוראות שגלויות למשתמשים.

{
   "setupActions":[
      {
         "title":{
            "defaultMessage":"Configure VPN"
         },
         "description":{
            "defaultMessage":"Enable your VPN client to access corporate resources."
         },
         "launchApp":{
            "packageName":"com.my.vpnapp."
         }
      }
   ]
}

כדי להבחין שאפליקציה הופעלה מ-launchApp, הפעילות שמופעלת ראשונה כחלק מהאפליקציה מכילה את ה-intent extra הבוליאני com.google.android.apps.work.clouddpc.EXTRA_LAUNCHED_AS_SETUP_ACTION (מוגדר כ-true). ה-intent extra הזה מאפשר להתאים אישית את האפליקציה על סמך השאלה אם היא הופעלה מ-setupActions או על ידי משתמש.

אחרי שהאפליקציה מחזירה את הערך RESULT_OK, אפליקציית Android Device Policy משלימה את כל השלבים שנותרו כדי להקצות את המכשיר או את פרופיל העבודה.

ביטול ההרשמה במהלך ההגדרה

האפליקציה שהופעלה בתור SetupAction יכולה לבטל את הרישום ולהחזיר את הערך RESULT_FIRST_USER.

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

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

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

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

(מומלץ) כשיוצרים אסימון רישום, אפשר לציין את שם המדיניות (policyName) שתקושר למכשיר בהתחלה. כשרושמים מכשיר עם הטוקן, המדיניות מוחלת עליו באופן אוטומטי.
הגדרת מדיניות כמדיניות ברירת המחדל של הארגון. אם לא צוין שם מדיניות באסימון הרישום ויש מדיניות בשם enterprises/<enterprise_id>/policies/default, כל מכשיר חדש מקושר אוטומטית למדיניות ברירת המחדל בזמן הרישום.
להירשם לנושא ב-Cloud Pub/Sub כדי לקבל התראות על מכשירים חדשים שנרשמו. בתגובה להתראה ENROLLMENT, קוראים ל-enterprises.devices.patch כדי לקשר את המכשיר למדיניות.

רישום מכשיר בלי מדיניות

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

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

דוגמה לתהליך עבודה של בדיקת רישיון

מכשיר רשום בלי מדיניות ברירת מחדל או מדיניות ספציפית.
בודקים כמה רישיונות נשארו לארגון.
אם יש רישיונות זמינים, משתמשים ב-devices.patch כדי לצרף מדיניות למכשיר, ואז מפחיתים את מספר הרישיונות. אם אין רישיונות זמינים, צריך להשתמש ב-devices.patch כדי להשבית את המכשיר. לחלופין, ה-API מאפס להגדרות המקוריות כל מכשיר שלא מצורף למדיניות תוך חמש דקות מההרשמה.

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

מכשירים בבעלות אישית

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

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

יצירת טוקן רישום

ציון מדיניות

הגדרת שימוש אישי

פטור לטוקנים קיימים של רישום

אכיפת אימות של Google בזמן ההרשמה

אפשרויות להגדרות אישיות

דוגמאות למטען ייעודי (payload) של JSON

מידע על קודי QR

חבילת קודי QR לדוגמה

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

הוספת פרופיל עבודה דרך "הגדרות"

הורדת Device Policy למכשירי Android

קישור לטוקן הרישום

כתובת ה-URL לכניסה

אכיפת אימות של Google עם תהליך כתובת URL לכניסה

שיטת קוד QR

שיטת NFC

שיטת המזהה של DPC

שיוך אוטומטי לארגון

הפעלת אפליקציה במהלך ההגדרה

ביטול ההרשמה במהלך ההגדרה

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

רישום מכשיר בלי מדיניות

דוגמה לתהליך עבודה של בדיקת רישיון

רישום וניהול של מכשיר