1page.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 28href="multi-user.html">user</a> with additional special properties around 29management and visual aesthetic.</p> 30 31<p>The primary goal of a managed profile is to create a segregated and secure 32space for managed data (such as corporate date) to reside. The administrator of 33the profile has full control over scope, ingress, and egress of data as well as 34its lifetime. These policies offer great powers and therefore fall upon the 35managed 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 59exists in the primary user and managed profile. Generally, applications act 60independently of one another and cannot communicate directly with one another 61across 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. 66There is no way to access credentials across the profile-user boundary. Only 67apps 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 72profile or not. Applications from the managed profile are default scoped to 73stay 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 78exceptions for lockscreen and encryption settings that are still scoped 79to the device and shared between the primary user and managed profile. 80Otherwise, a profile owner does not have any device administrator privileges 81outside 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 93separated by userId. You may consider instead using 94<code>Binder.getCallingUserHandle</code> rather than <code>getCallingUid</code> 95to avoid confusion between uid and userId.</p> 96 97<p>The AccountManagerService maintains a separate list of accounts for each 98user. The main differences between a managed profile and a regular secondary 99user 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 117administrators 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 126available only to profile or device owners. Traditional device administrators 127remain but are applicable to the simpler consumer-only case (e.g., find my 128device).</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. 133The DPC app is typically provided by an enterprise mobility management (EMM) 134partner, 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 138distinguished by the appearance of badged instances of 139apps, as well as personal instances. That badge, or Android device 140administration icon, identifies which apps are work apps.</p> 141 142<p>The EMM has control only over the managed profile (not personal space) with 143some 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 170dozens of new APIs to support both corporate-owned and bring your own device 171(BYOD) administration use cases. Examples include app restrictions, silent 172installation of certificates, and cross-profile sharing intent access control. 173Use the sample Device Policy Client (DPC) app 174<a href="https://developer.android.com/samples/BasicManagedProfile/index.html">BasicManagedProfile.apk</a> 175as a starting point. For details, refer to 176<a href="https://developer.android.com/training/enterprise/work-policy-ctrl.html">Building 177a Work Policy Controller</a>.</p> 178