יש כמה דרכים להקצות מכשירים. של הלקוחות עסק הדרישות קובעות באילו שיטות להקצאת הרשאות כדאי להשתמש.
עקרונות בסיסיים של הקצאת מכשירים
תרחישי הפריסה של הקצאת מכשירים שהם רוצים שהלקוחות שלכם תמיכה (למשל, 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
תרחיש פריסה | אופן הפעולה | שיטת ההקצאה | 5.0, 5.1 | 6.0, מאוחר יותר | 7.0, מאוחר יותר |
---|---|---|---|---|---|
בבעלות החברה | בעלי המכשיר | קוד QR | ✓ | ||
חשבונות Google Play מנוהלים | ✓ | ✓ | |||
חשבון Google | ✓ | ✓ | |||
NFC | ✓ | ✓ | ✓ | ||
BYOD | בעלי הפרופיל | חשבונות Google Play מנוהלים | ✓ | ✓ | ✓ |
חשבון Google | 5.11 | ✓ | ✓ | ||
התקנה ידנית של בקר DPC | ✓ | ✓ | ✓ |
שיקולים כלליים לגבי הטמעה
הנה כמה דברים שכדאי להביא בחשבון לכתוב את ה-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 האישי
- בקר ה-DPC האישי מקשיב
ACTION_MANAGED_PROFILE_PROVISIONED
(במכשירי Android 5.1, ה-DPC האישי צריך במקום זאת להאזין לACTION_MANAGED_PROFILE_ADDED
). - בקר ה-DPC האישי שולח בקשה להסרה
ACTION_UNINSTALL_PACKAGE
תוצג למשתמש בקשה להסיר את בקר ה-DPC האישי. למשתמש הטוב ביותר תהליך ההסרה אמור להתרחש במהלך הקצאת ההרשאות הידנית.
בקר DPC אישי משבית את עצמו
- בקר ה-DPC האישי מקשיב
ACTION_MANAGED_PROFILE_PROVISIONED
(במכשירי Android 5.1, ה-DPC האישי צריך במקום זאת להאזין לACTION_MANAGED_PROFILE_ADDED
). - אם רלוונטי, בקר ה-DPC האישי צריך לשחרר הרשאות אדמין במכשיר לפני שהוא משבית את עצמו.
- בקר ה-DPC האישי יוזם
setApplicationEnabledSetting
להשבית את הבקשה עםCOMPONENT_ENABLED_STATE_DISABLED
הפרמטר. - המשתמש יכול להפעיל מחדש את בקר ה-DPC האישי מ-Google Play.
שיקולים להטמעה במצב 'בעלי המכשיר'
יש כמה דברים שחשוב להביא בחשבון כשכותבים את ה-DPC כדי להטמיע את מצב הפעולה של בעלי המכשיר.
המכשיר צריך להיות חדש או לאפס להגדרות המקוריות
צריך להקצות את מצב הפעולה של בעלי המכשיר במהלך ההגדרה הראשונית ממכשיר חדש או אחרי איפוס להגדרות המקוריות. מצב 'בעלי המכשיר' לא יכול להיות יוקצה במכשיר בכל זמן אחר.
מצב 'בעלי המכשיר' נותן ל-DPC שליטה מלאה במכשיר. אם מתבצעת הקצאה מצב 'בעלי המכשיר' אחרי התרת ההגדרה הראשונית:
- תוכנה זדונית עלולה ליצור בעלי מכשיר והשתלטות על המכשיר.
- יכול להיות שיש בעיות בפרטיות אם כבר מותקנות נתוני משתמשים או אפליקציות מסוימות במכשיר.
הגדרת מצב 'בעלי מכשירים' רק במכשירים שהם בבעלות החברה
יש להקצות את מצב 'בעלי המכשיר' רק במכשירים שמזוהים בתור להיות בבעלות החברה של הלקוח שלך. אפשר לאמת זאת על ידי זיהוי מזהה מכשיר ייחודי (כגון מספר סידורי), או באמצעות קבוצת חשבונות שמורשים לרשום את המכשיר דרך ה-EMM המדיניות בנושא
אם אין לך אפשרות לאמת את הבעלות של החברה על מכשיר, עליך ליצור אמצעי הגנה מפני כשל כדי שמצב בעלי המכשיר לא יוקצה בטעות. לדוגמה, אפשר לבקש ממשתמש המכשיר לאשר או לבצע פעולת אישור לפני ניהול ההקצאות של מצב 'בעלי המכשיר'.
הפעלת אפליקציות מערכת
כשבקר DPC מקצה פרופיל עבודה, אפליקציות מערכת ללא סמלי מרכז אפליקציות נחשבות לקריטיות למכשיר והם מורשים לפעול באופן אוטומטי בפרופיל העבודה. אפליקציות מערכת עם סמלי מרכז אפליקציות נחשבות לאפליקציות אופציונלי, ולהחליט אם להפעיל אותם.
הפעלת אפליקציות מערכת דרך Google Play
הפעלת אפליקציות מערכת באמצעות Google Play פשוטה, והמשתמשים מקבלים עדכונים לאפליקציה ברגע שהם זמינים.
הפעלת אפליקציות מערכת באמצעות ממשקי API של Android framework
כדי שהמשתמשים יוכלו לראות את אפליקציות המערכת ברגע שהם יתחילו להשתמש במכשירים שלהם,
להפעיל אפליקציות מערכת כחלק מתהליך הקצאת המכשיר. בקר ה-DPC מאפשר
אפליקציות מערכת לפי שם חבילה או לפי כוונה באמצעות
DevicePolicyManager.enableSystemApp()
יש כמה דרכים לזהות את אפליקציות המערכת שאתם רוצים להפעיל ולהציג במסוף ה-EMM למנהלי IT.
יצירת קטלוגים של אפליקציות מערכת
בשיטה הזו, כל מכשיר קובע אילו אפליקציות מותקנות במכשיר ושולח את הנתונים האלה חזרה למסוף ה-EMM. זה מוצג באופן דינמי במסוף ה-EMM נתונים במהלך יצירת מדיניות מכשיר, שמאפשרת לאדמין ב-IT לנהל לאפליקציות לכל אפליקציה בנפרד.
אם פרופיל העבודה עדיין לא הוקצה במכשיר, אפשר לעיין ברשימה את כל האפליקציות עם סמלי מרכז האפליקציות במכשיר באמצעות
queryIntentActivities()
:private List<ResolveInfo> getAppsWithLauncher() { Intent i = new Intent(Intent.ACTION_MAIN); i.addCategory(Intent.CATEGORY_LAUNCHER); return getPackageManager().queryIntentActivities(i, 0); }
אם פרופיל העבודה כבר הוקצה במכשיר, מוצאים רשימה של כל האפליקציות בפרופיל העבודה שמשתמשות ב-
PackageManager.GET_DISABLED_COMPONENTS
וגםPackageManager.GET_UNINSTALLED_PACKAGES
כדי למצוא את אפליקציות המערכת ברשימת האפליקציות, מסמנים את התיבה
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 תקין:
תמיד נדרש
חובה אם עדיין לא מותקן בקר DPC במכשיר
EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION
EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM
מומלץ אם המכשיר עוד לא מחובר ל-Wi-Fi
אופציונלי
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
- אשף ההגדרה מבקש מהמשתמש להקיש על מסך הפתיחה 6 פעמים. עליך לבצע את ההקשות באותו מקום במסך.
- אשף ההגדרה מבקש מהמשתמש להתחבר לאינטרנט כדי שההתקנה יכול להוריד קורא קודי QR.
- אפליקציית Google Play Services מורידה מודול שמכיל זיהוי קוד QR של מנוע החיפוש.
- המשתמש סורק את קוד ה-QR שסופק על ידי האדמין ב-IT.
- אשף ההגדרה מוריד את אפליקציית ה-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 כמכשיר אישי.
- המשתמש מוריד את בקר ה-DPC באופן ידני מ-Google Play ומפעיל אותו.
- ה-DPC מקצה את פרופיל העבודה באמצעות
ACTION_PROVISION_MANAGED_PROFILE
- מבצעים את שלבי ההגדרה הסופיים.
הגדרת מצב 'בעלי המכשיר'
עליך להקצות את מצב הפעולה של בעלי המכשיר במהלך ההגדרה הראשונית של במכשיר חדש או לאחר איפוס להגדרות המקוריות. לא ניתן להקצות את מצב 'בעלי המכשיר' ב- מכשיר בכל זמן אחר.
במהלך הגדרת המכשיר, המשתמש מזין אסימון מיוחד שספציפי ל-DPC,
כשמבקשים להוסיף חשבון. הפורמט של אסימון הוא afw#DPC_IDENTIFIER
. עבור
ספק EMM בשם ACME, afw#acme
יתקין את בקר ה-DPC המוגדר כברירת מחדל של ACME EMM.
כל EMM חייב לבקש מזהה DPC ספציפי מ-Google כדי להשתמש בו
אותו בתהליך ההקצאה.
- המשתמש מפעיל מכשיר חדש או מכשיר שאופס להגדרות המקוריות ואת אשף ההגדרה השקות.
- כאשר המשתמש מתבקש להוסיף חשבון, הוא מזין אסימון מיוחד
פורמט
afw#DPC_IDENTIFIER
שמזהה את בקר ה-DPC של ה-EMM. - באמצעות מזהה ה-DPC באסימון, אשף ההגדרה מוסיף מזהה זמני חשבון Google למכשיר. החשבון הזמני הזה משמש רק להורדה בקר ה-DPC עבור ה-EMM מ-Google Play, והוא מוסר בעוד שלבי ההגדרה הסופיים.
- ה-DPC מקצה את המכשיר באמצעות
ACTION_PROVISION_MANAGED_DEVICE
- מבצעים את שלבי ההגדרה הסופיים.
שלבי ההגדרה הסופיים של כל מצבי הפעילות
צריך לבצע את השלבים האלה רק אחרי השלבים הראשוניים להגדרה הושלמו את מצב 'בעלי הפרופיל' או את מצב 'בעלי המכשיר'.
בקר ה-DPC מוודא שהמכשיר יכול לתמוך בחשבונות Google Play מנוהלים על ידי אתחול ספריית התמיכה של בקר DPC:
AndroidForWorkAccountSupport androidForWorkAccountSupport = new AndroidForWorkAccountSupport(context, admin); androidForWorkAccountSupport.ensureWorkingEnvironment(callback);
אם מגדירים את מצב 'בעלי המכשיר' במכשיר, השלב הזה מסיר את חשבון Google הזמני שנוסף כדי להוריד את ה-DPC.
המשתמש נכנס ל-DPC באמצעות פרטי הכניסה שלו ל-EMM. הנושאים האלה בדרך כלל פרטי הכניסה לאימיילים של הארגון.
ה-DPC מבקש את פרטי הכניסה של חשבון Google Play לארגונים עבור משתמש ארגוני מאומת ממסוף ה-EMM.
אם למסוף ה-EMM אין
userId
של Google Play למשתמש, יוצר משתמש חדש באמצעות קריאהUsers.insert()
. אם אתם מקצים הרשאות גישה למצב 'בעלי המכשיר', ציינו את חשבון המכשיר (ל פריסות של מכשירים ייעודיים) או חשבון משתמש (לפריסות בבעלות החברה).כדי להגדיר את מדיניות המכשיר, צריך לשלוח קריאה
Devices.update
עליך להגדיר את המדיניות לפני שמוסיפים את חשבון Google Play המנוהל אל במכשיר, אחרת המדיניות לא תחול במשך פרק זמן קצר לאחר הוספת החשבון למכשיר.מסוף ה-EMM מבקש את פרטי הכניסה של החשבון עבור
userId
על ידי שיחותUsers.generateAuthenticationToken()
. אסימון האימות הזה הוא לטווח קצר ולא ניתן להשתמש בו שוב. בקר ה-DPC להשתמש באסימון כדי להוסיף את החשבון באופן פרוגרמטי (אין לו שימוש בסוף משתמש).ממשק ה-API של Google Play ל-EMM מחזיר את אסימון האימות למסוף ה-EMM.
מסוף ה-EMM מעביר את אסימון האימות אל ה-DPC.
בקר ה-DPC מוסיף את חשבון Google Play המנוהל למכשיר באמצעות
androidForWorkAccountSupport.addAndroidForWorkAccount(token, accountAddedCallback);
השיטה של חשבון Google
מחשב DPC יכול להשתמש בשיטה להקצאת הרשאות ידנית בחשבון Google כדי להגדיר את בעל המכשיר או מצב הבעלים של הפרופיל. באמצעות שיטת ההקצאה של חשבון Google, בקר DPC מנחה את המשתמש לאורך שלבי הקצאת ההרשאות לאחר שהמשתמש מוסיף את חשבון Google במהלך ההגדרה הראשונית של המכשיר.
כשמשתמשים מזינים את פרטי הכניסה לחשבון Google:
- שרת האימות של Google מאמת את חשבון המשתמש.
- לאחר מכן שרת האימות מתקשר עם השרת הארגוני כדי לראות אם הדומיין של החשבון רשום כדומיין ב-Google Workspace או כדומיין דומיין שמנוהל על ידי EMM.
- במקרה כזה, המערכת תוריד באופן אוטומטי את ה-DPC המשויך לדומיין מ-Google Play ומתקין אותו.
הגדרת מצב הבעלים של הפרופיל
ניתן להקצות את מצב הפעולה של הבעלים של הפרופיל במהלך ההגדרה הראשונית של או כאשר המשתמש מוסיף חשבון באמצעות הגדרות > מוסיפים חשבון.
- אימות החשבון מתחיל על ידי משתמש מאשף ההגדרה או מהגדרות > מוסיפים חשבון.
- GMSCore מתחיל הקצאת הרשאות ידנית של פרופיל עבודה באמצעות
ACTION_PROVISION_MANAGED_DEVICE_FROM_TRUSTED_SOURCE
. - מתבצעת הורדה אוטומטית של בקר ה-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
– השם של החשבון המאומת שרוצים להעביר לפרופיל העבודה החדש.
- הפלטפורמה מבצעת הקצאה של פרופיל עבודה.
- כשפרופיל העבודה מוקצה, ה-DPC מקבל את השידור
ACTION_PROFILE_PROVISIONING_COMPLETE
בקר DPCACTION_ADMIN_POLICY_COMPLIANCE
ה-handler מופעל בפרופיל העבודה. אחרי שיוצרים את פרופיל העבודה, ה-DPC פועל גם בתוך פרופיל העבודה. בקר ה-DPC מגדיר כללי מדיניות עבור חשבון Google המנוהל מוודא שהמכשיר לא נמצא בסיכון ומאמת שכללי המדיניות נאכפים (למשל, הסיסמה). - בקר ה-DPC בפרופיל האישי מושבת בעצמו או שהמשתמש מסיר אותו.
![](https://developers-dot-devsite-v2-prod.appspot.com/static/android/work/images/post-suw.png?authuser=1&hl=he)
הגדרת מצב בעלי המכשיר או COPE
עליך להקצות את מצב הפעולה של בעלי המכשיר במהלך ההגדרה הראשונית של במכשיר חדש או לאחר איפוס להגדרות המקוריות. לא ניתן להוסיף את מצב 'בעלי המכשיר' אל בכל שלב.
- אימות החשבון מתחיל על ידי משתמש מאשף ההגדרה.
- GMSCore מתחיל את ניהול ההקצאות של בעלי המכשיר באמצעות
ACTION_PROVISION_MANAGED_DEVICE_FROM_TRUSTED_SOURCE
. 3.ה-DPC יורד באופן אוטומטי למכשיר והוא מופעל באמצעות ה-handlerGET_PROVISIONING_MODE
כדי לבחור את מצב ההקצאה הרצוי.EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
— מידע נוסף לגבי פרופיל העבודה, כמו המיקום, ה-Wi-Fi וכתובת האימייל. כחלק מחבילה זו, גם ה-DPC יקבל כאן את is_setup_אשף. החבילה הזו תיכלל ב-ACTION_GET_PROVISIONING_MODE
ו-ACTION_ADMIN_POLICY_COMPLIANCE
handlers.
- הפלטפורמה מקצה את המכשיר למצב הקצאת ההרשאות הרצוי.
- לאחר הקצאת המכשיר, ה-DPC מקבל את השידורים האלה ומופעל ה-handler
ACTION_ADMIN_POLICY_COMPLIANCE
של ה-DPC: - בקר ה-DPC משתמש בערך של
Global.DEVICE_PROVISIONED
כדי לאמת שהמכשיר חדש או שהוא אופס להגדרות המקוריות (לא הוקצה):- 0 – לא הוקצה.
- 1 – מוקצה.
- ה-DPC משלים את תהליך ההקצאה על ידי דחיפת מדיניות עבור שהמכשיר מנוהל, מוודאים שהמכשיר לא נמצא במצב 'פרוץ', אימות שכללי המדיניות נאכפים (למשל, דרישת סיסמה).
![](https://developers-dot-devsite-v2-prod.appspot.com/static/android/work/images/in-suw.png?authuser=1&hl=he)
שיקולים להטמעה של שיטת הבידינג בחשבון 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:
- מורידים את האפליקציה לדוגמה של מתכנת NFC. אפשר להשתמש בדוגמה כפי שהיא ללא תוספות, או לשנות אותה ערכי ברירת המחדל שלכם.
- מתקינים את אפליקציית המתכנת במכשיר הנבחר.
- מפעילים את אפליקציית מתכנת NFC ובוחרים באפשרות Load Defaults (טעינת ברירות המחדל)
עבור
com.example.android.apis
. (הטקסט הזה עשוי להשתנות בהתאם לברירת המחדל הפרמטרים שאתם מגדירים).
הקצאת מכשיר של לקוח
- להצמיד את המכשיר המתכנת או את תג ה-NFC במכשיר חדש או במכשיר חדש איפוס להגדרות המקוריות.
- מוודאים שהמכשיר נשאר במסך תחילת העבודה הראשוני ש
יוצג בתחילת ההפעלה. הטקסט צוין ב
Ready to send:{...}
באפליקציית המתכנתים. - ממתינים בזמן ה-DPC:
- הצפנת המכשיר.
- אם מדובר במכשיר עם גישה מרובה (CDMA) של Code-Division: מפעילה את הטלפון בזמן שמוצג ממשק משתמש של טלפון (אין צורך באינטראקציה).
- מגדיר את חיבור ה-Wi-Fi.
- הורדת קובץ ה-APK עבור com.example.android.apis.
- מתקין את com.example.android.apis.
- מגדיר את דגימת האדמין של המכשיר בכתובת com.example.android.apis בתור הבעלים של המכשיר.
- מציג 'טוסט' שהצליח כשבעלי המכשיר מופעלים.
- לאחר חזרה לדף הבית (דילוג אוטומטי על אשף ההגדרה),
צריך לבדוק ש-com.example.android.apis מוגדר כבעלים של המכשיר:
- בהגדרות > אבטחה > מנהלי מכשירים, צריך לוודא שמכשיר לדוגמה לא ניתן להסיר את האדמין.
- בהגדרות > משתמשים > משתמשים ו פרופילים > אתם (בעלים), צריך לוודא הבעלים הוא החשבון היחיד הזמין (מכשיר יכול להיות רק פעיל אחד של הבעלים של המכשיר).
מקורות מידע נוספים
NFC מתקדם מתאר נושאים כגון עבודה עם טכנולוגיות תגים שונות, כתיבה ל-NFC תגים ושליחת נתונים בחזית.
שיטת התקנה ידנית של בקר DPC
כדי להגדיר את מצב הבעלים של הפרופיל באמצעות השיטה הידנית להקצאה ידנית של הרשאות התקנה מ-DPC: המשתמש מוריד את בקר ה-DPC מ-Google Play ומתקין אותו. ואז בקר DPC מנחה את המשתמש בתהליך ההגדרה של בעלי הפרופיל חשבון Google המנוהל.
בקר ה-DPC יכול להוסיף את חשבון Google המנוהל לפני או אחרי היצירה פרופיל העבודה. לדוגמה, בקר ה-DPC יכול ליצור פרופיל עבודה המבוסס על פרטי הכניסה ל-EMM של המשתמש במקום לבקש גישה לחשבון Google המנוהל קודם.
הגדרת מצב הבעלים של הפרופיל
קודם צריך להוסיף את חשבון Google המנוהל
- המשתמש מוריד את בקר ה-DPC מ-Google Play ומתקין אותו.
- בקר ה-DPC מוסיף את חשבון Google המנוהל לפני יצירת פרופיל העבודה
באמצעות
AccountManager.addAccount()
. - ה-DPC מתחיל לפעול בפרופיל האישי ומבצע את התהליך כדי
יצירת פרופיל עבודה באמצעות:
ACTION_PROVISION_MANAGED_PROFILE
— הקצאת פרופיל העבודה.EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
— מידע נוסף על פרופיל העבודה, כמו מקום, Wi-Fi, אימייל address.EXTRA_PROVISIONING_ACCOUNT_TO_MIGRATE
— שם החשבון המאומת שיועבר ליצירה החדשה פרופיל.
- תהליך ההקצאה משלים את ה-DPC בפרופיל העבודה. אחרי שהעבודה ה-DPC פועל גם בתוך פרופיל העבודה. בקר DPC ב פרופיל העבודה משלים את תהליך ההקצאה על ידי דחיפת מדיניות עבור שחשבון Google מנוהל, כדי לוודא שהמכשיר לא נמצא בסיכון ואימות שכללי המדיניות נאכפים (למשל דרישה הסיסמה).
- כשפרופיל העבודה מוקצה, ה-DPC מקבל את השידור
ACTION_PROFILE_PROVISIONING_COMPLETE
- בקר ה-DPC בפרופיל האישי משבית את עצמו או שהמשתמש מסיר אותו.
![](https://developers-dot-devsite-v2-prod.appspot.com/static/android/work/images/google_acct_first.png?authuser=1&hl=he)
קודם צריך ליצור את פרופיל העבודה
- המשתמש מוריד את בקר ה-DPC מ-Google Play ומתקין אותו.
- ה-DPC מתחיל לפעול בפרופיל האישי ומבצע את התהליך כדי
יצירת פרופיל עבודה באמצעות:
ACTION_PROVISION_MANAGED_PROFILE
— הקצאת פרופיל העבודה.EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
— מידע נוסף על פרופיל העבודה, כמו מקום, Wi-Fi, אימייל address.
- בקר ה-DPC מוסיף את חשבון Google המנוהל באמצעות
AccountManager.addAccount()
- ה-DPC מקבל את השידור
ACTION_PROFILE_PROVISIONING_COMPLETE
וקוראEXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
- תהליך ההקצאה משלים את ה-DPC בפרופיל העבודה. לאחר יצירת פרופיל העבודה, ה-DPC פועל גם בתוך סביבת העבודה פרופיל. ה-DPC בפרופיל העבודה משלים את תהליך ההקצאה על ידי להגדיר כללי מדיניות לחשבון Google המנוהל הזה, כדי לוודא שהמכשיר לא במצב 'פרוץ', ולאמת שכללי המדיניות נאכפים. (למשל, דרישת סיסמה).
- ה-DPC מפעיל את פרופיל העבודה באמצעות
DevicePolicyManager.setProfileEnabled()
- בקר ה-DPC בפרופיל האישי משבית את עצמו או שהמשתמש מסיר אותו.
![](https://developers-dot-devsite-v2-prod.appspot.com/static/android/work/images/work_profile_first.png?authuser=1&hl=he)
-
השיטה של חשבון Google ב-Android 5.1 תומכת רק במצב הפעולה של בעל הפרופיל, והמשתמש יכול להגדיר אותה רק דרך הגדרות > מוסיפים חשבון.↩