1 <html devsite> 2 <head> 3 <title>Employing Managed Profiles</title> 4 <meta name="project_path" value="/_project.yaml" /> 5 <meta name="book_path" value="/_book.yaml" /> 6 </head> 7 <body> 8 <!-- 9 Copyright 2017 The Android Open Source Project 10 11 Licensed under the Apache License, Version 2.0 (the "License"); 12 you may not use this file except in compliance with the License. 13 You may obtain a copy of the License at 14 15 http://www.apache.org/licenses/LICENSE-2.0 16 17 Unless required by applicable law or agreed to in writing, software 18 distributed under the License is distributed on an "AS IS" BASIS, 19 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 20 See the License for the specific language governing permissions and 21 limitations under the License. 22 --> 23 24 25 26 <p>A <em>managed profile</em> or <em>work profile</em> is an Android <a 27 href="multi-user.html">user</a> with additional special properties around 28 management and visual aesthetic.</p> 29 30 <p>The primary goal of a managed profile is to create a segregated and secure 31 space for managed data (such as corporate data) to reside. The administrator of 32 the profile has full control over scope, ingress, and egress of data as well as 33 its lifetime. These policies offer great powers and therefore fall upon the 34 managed profile instead of the device administrator.</p> 35 36 <ul> 37 <li><strong>Creation</strong>. Managed profiles can be created by any 38 application in the primary user. The user is notified of managed profile 39 behaviors and policy enforcement before creation.</li> 40 <li><strong>Management</strong>. Management is performed by applications that 41 programmatically invoke APIs in the 42 <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">DevicePolicyManager</a> 43 class to restrict use. Such applications are referred to as <em>profile 44 owners</em> and are defined at initial profile setup. Policies unique to 45 managed profile involve app restrictions, updatability, and intent behaviors. 46 </li> 47 <li><strong>Visual treatment</strong>. Applications, notifications, and 48 widgets from the managed profile are always badged and typically made 49 available inline with user interface (UI) elements from the primary user.</li> 50 </ul> 51 52 <h2 id=data_segregation>Data segregation</h2> 53 <p>Managed profiles use the following data segregation rules.</p> 54 55 <h3 id=applications>Applications</h3> 56 57 <p>Applications are scoped with their own segregated data when the same app 58 exists in the primary user and managed profile. Generally, applications act 59 independently of one another and cannot communicate directly with one another 60 across the profile-user boundary.</p> 61 62 <h3 id=accounts>Accounts</h3> 63 64 <p>Accounts in the managed profile are distinctly unique from the primary user. 65 There is no way to access credentials across the profile-user boundary. Only 66 apps in their respective context are able to access their respective accounts.</p> 67 68 <h3 id=intents>Intents</h3> 69 70 <p>The administrator controls whether intents are resolved in/out of managed 71 profile or not. Applications from the managed profile are default scoped to 72 stay within the managed profile exception of the Device Policy API.</p> 73 74 <h3 id=settings>Settings</h3> 75 76 <p>Enforcement of settings is generally scoped to the managed profile, with 77 exceptions for lockscreen and encryption settings that are still scoped 78 to the device and shared between the primary user and managed profile. 79 Otherwise, a profile owner does not have any device administrator privileges 80 outside the managed profile.</p> 81 82 <p>Managed profiles are implemented as a new kind of secondary user, such that:</p> 83 84 <pre class="devsite-click-to-copy"> 85 uid = 100000 * userid + appid 86 </pre> 87 88 <p>They have separate app data like regular users:</p> 89 90 <pre class="devsite-click-to-copy"> 91 /data/user/<userid> 92 </pre> 93 94 <p>The UserId is calculated for all system requests using 95 <code>Binder.getCallingUid()</code>, and all system state and responses are 96 separated by userId. You may consider instead using 97 <code>Binder.getCallingUserHandle</code> rather than <code>getCallingUid</code> 98 to avoid confusion between uid and userId.</p> 99 100 <p>The AccountManagerService maintains a separate list of accounts for each 101 user. The main differences between a managed profile and a regular secondary 102 user are as follows:</p> 103 104 <ul> 105 <li>The managed profile is associated with its parent user and started 106 alongside the primary user at boot time.</li> 107 <li>Notifications for managed profiles are enabled by ActivityManagerService 108 allowing the managed profile to share the activity stack with the primary 109 user.</li> 110 <li>Other shared system services include IME, A11Y services, Wi-Fi, and NFC. 111 </li> 112 <li>New Launcher APIs allow launchers to display badged apps and whitelisted 113 widgets from the managed profile alongside apps in the primary profile without 114 switching users.</li> 115 </ul> 116 117 <h2 id=device_administration>Device administration</h2> 118 119 <p>Android device administration includes the following types of device 120 administrators for enterprises:</p> 121 122 <ul> 123 <li><em>Profile owner</em>. Designed for bring your own device (BYOD) 124 environments</li> 125 <li><em>Device Owner</em>. Designed for corp-liable environments</li> 126 </ul> 127 128 <p>The majority of the new device administrator APIs added for Android 5.0 are 129 available only to profile or device owners. Traditional device administrators 130 remain but are applicable to the simpler consumer-only case (e.g., find my 131 device).</p> 132 133 <h3 id=profile_owners>Profile owners</h3> 134 135 <p>A Device Policy Client (DPC) app typically functions as the profile owner. 136 The DPC app is typically provided by an enterprise mobility management (EMM) 137 partner, such as Google Apps Device Policy.</p> 138 139 <p>The profile owner app creates a managed profile on the device by sending the 140 <code>ACTION_PROVISION_MANAGED_PROFILE</code> intent. This profile is 141 distinguished by the appearance of badged instances of 142 apps, as well as personal instances. That badge, or Android device 143 administration icon, identifies which apps are work apps.</p> 144 145 <p>The EMM has control only over the managed profile (not personal space) with 146 some exceptions, such as enforcing the lock screen.</p> 147 148 <h3 id=device_owners>Device owners</h3> 149 150 <p>The device owner can be set only in an unprovisioned device:</p> 151 152 <ul> 153 <li>Can be provisioned only at initial device setup</li> 154 <li>Enforced disclosure always displayed in quick-settings</li> 155 </ul> 156 157 <p>Device owners can conduct some tasks profile owners cannot, such as:</p> 158 159 <ul> 160 <li>Wipe device data</li> 161 <li>Disable Wi-Fi/Bluetooth</li> 162 <li>Control <code>setGlobalSetting</code></li> 163 <li><code>setLockTaskPackages</code> (the ability to whitelist packages that 164 can pin themselves to the foreground)</li> 165 <li>Set <code>DISALLOW_MOUNT_PHYSICAL_MEDIA</code> (<code>FALSE</code> by 166 default). When <code>TRUE</code>, physical media, both portable and adoptable, 167 cannot be mounted.</li> 168 </ul> 169 170 <h3 id=dpm_api>DevicePolicyManager APIs</h3> 171 172 <p>Android 5.0 and higher offers a greatly improved DevicePolicyManager with 173 dozens of new APIs to support both corporate-owned and bring your own device 174 (BYOD) administration use cases. Examples include app restrictions, silent 175 installation of certificates, and cross-profile sharing intent access control. 176 Use the sample Device Policy Client (DPC) app 177 <a href="https://developer.android.com/samples/BasicManagedProfile/index.html">BasicManagedProfile.apk</a> 178 as a starting point. For details, refer to 179 <a href="https://developer.android.com/training/enterprise/work-policy-ctrl.html">Building 180 a Work Policy Controller</a>.</p> 181 182 </body> 183 </html> 184
