Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

‫Android 5.1 ואילך

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

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

הוספת פרופיל עבודה מההגדרות
הורדה של אפליקציית Device Policy ל-Android
קישור לטוקן הרשמה
כתובת 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 Management. — **איור 1.** יוצרים טוקן שרושם את המכשירים ומחיל עליהם את policy1. אחרי 1,800 שניות (30 דקות), תוקף האסימון פג.

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

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

ציון מדיניות

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

ציון שימוש אישי

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

אכיפת אימות ב-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 Device Policy ואסימון רישום.

{
    "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 זמינה במאמר יצירת קוד QR.

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

שיטות הקצאת הרשאות

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

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

‫Android 5.1 ואילך

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

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

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

הורדה של Device Policy ל-Android

‫Android 5.1 ואילך

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

שיטה באמצעות קוד QR

‫Android 7.0 ואילך

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

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

שיטת NFC

‫Android 6.0 ואילך

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

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

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

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

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

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

הרשמה דרך הארגון

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

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

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

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

אם אתם מעדיפים שהלקוחות שלכם יגדירו ויקצו הגדרות ישירות ממסוף ה-EMM שלכם, אתם צריכים לבצע שילוב עם zero-touch customer 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 כדי לסמן את ההשלמה ולאפשר לאפליקציית Device Policy למכשירי Android להשלים את הקצאת ההרשאות למכשיר או לפרופיל העבודה. כדי להפעיל אפליקציה במהלך ההגדרה:

מוודאים ש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 לבין השקה שלה על ידי משתמש, הפעילות שמופעלת ראשונה כחלק מהאפליקציה מכילה את התוסף הבוליאני של הכוונה com.google.android.apps.work.clouddpc.EXTRA_LAUNCHED_AS_SETUP_ACTION (מוגדר כ-true). התוסף הזה מאפשר לכם להתאים אישית את האפליקציה בהתאם לאופן ההשקה שלה – מ-setupActions או על ידי משתמש.

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

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

האפליקציה הושקה כ-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

הרשמה דרך הארגון

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

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

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

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

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

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