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