1page.title=Device Administration 2page.tags=devicepolicymanager,policy,security 3@jd:body 4 5<div id="qv-wrapper"> 6<div id="qv"> 7 <h2>In this document</h2> 8 <ol> 9<li><a href="#overview">Device Administration API Overview</a> 10 <ol> 11 <li><a href="#how">How does it work?</a></li> 12 <li><a href="#policies">Policies</a></li> 13 </ol> 14 </li> 15 <li><a href="#sample">Sample Application</a></li> 16 <li><a href="#developing">Developing a Device Administration Application</a> 17 <ol> 18 <li><a href="#manifest">Creating the manifest</a></li> 19 <li><a href="#code">Implementing the code</a></li> 20 </ol> 21 </li> 22 23 </ol> 24 25 <h2>Key classes</h2> 26 <ol> 27 <li>{@link android.app.admin.DeviceAdminReceiver}</li> 28 <li>{@link android.app.admin.DevicePolicyManager}</li> 29 <li>{@link android.app.admin.DeviceAdminInfo}</li> 30 </ol> 31</div> 32</div> 33 34<p>Android 2.2 introduces support for enterprise applications by offering the 35Android Device Administration API. The Device Administration API provides device 36administration features at the system level. These APIs allow you to create 37security-aware applications that are useful in enterprise settings, in which IT 38professionals require rich control over employee devices. For example, the 39built-in Android Email application has leveraged the new APIs to improve 40Exchange support. Through the Email application, Exchange administrators can 41enforce password policies — including alphanumeric passwords or numeric 42PINs — across devices. Administrators can also remotely wipe (that is, 43restore factory defaults on) lost or stolen handsets. Exchange users can sync 44their email and calendar data.</p> 45 46<p>This document is intended for developers who want to develop enterprise 47solutions for Android-powered devices. It discusses the various features 48provided by the Device Administration API to provide stronger security for 49employee devices that are powered by Android.</p> 50 51<p class="note"><strong>Note</strong> For information on building a Work Policy 52Controller for Android for Work deployments, see <a 53href="{@docRoot}training/enterprise/work-policy-ctrl.html">Building a Work 54Policy Controller</a>.</p> 55 56 57<h2 id="overview">Device Administration API Overview</h2> 58 59<p>Here are examples of the types of applications that might use the Device Administration API:</p> 60<ul> 61 <li>Email clients.</li> 62 <li>Security applications that do remote wipe.</li> 63 <li>Device management services and applications.</li> 64</ul> 65 66<h3 id="how">How does it work?</h3> 67<p>You use the Device Administration API to write device admin applications that users 68install on their devices. The device admin application enforces the desired 69policies. Here's how it works:</p> <ul> 70 <li>A system administrator writes a device admin application that enforces 71remote/local device security policies. These policies could be hard-coded into 72the app, or the application could dynamically fetch policies from a third-party 73server. </li> 74<li>The application is installed on users' devices. Android does 75not currently have an automated provisioning solution. Some of the ways a sysadmin might 76distribute the application to users are as follows: 77<ul> 78<li>Google Play.</li> 79<li>Enabling installation from another store.</li> 80<li>Distributing the application through other means, such as email or websites.</li> 81 82</ul> 83 84 85</li> 86 <li>The system prompts the user to enable the device admin application. How 87and when this happens depends on how the application is implemented.</li> 88<li>Once users enable the device admin application, they are subject to 89its policies. Complying with those policies typically confers benefits, such as 90access to sensitive systems and data.</li> 91</ul> 92<p>If users do not enable the device admin app, it remains on the device, but in an inactive state. Users will not be subject to its policies, and they will conversely not get any of the application's benefits—for example, they may not be able to sync data.</p> 93<p>If a user fails to comply with the policies (for example, if a user sets a 94password that violates the guidelines), it is up to the application to decide 95how to handle this. However, typically this will result in the user not being 96able to sync data.</p> 97<p>If a device attempts to connect to a server that requires policies not 98supported in the Device Administration API, the connection will not 99be allowed. The Device Administration API does not currently allow partial 100provisioning. In other words, if a device (for example, a legacy device) does 101not support all of the stated policies, there is no way to allow the 102device to connect.</p> 103<p>If a device contains multiple enabled admin applications, the strictest policy is 104enforced. There is no way to target a particular admin 105application.</p> 106<p>To uninstall an existing device admin application, users need to 107first unregister the application as an administrator. </p> 108 109 110<h3 id="policies">Policies</h3> 111 112<p>In an enterprise setting, it's often the case that employee devices must 113adhere to a strict set of policies that govern the use of the device. The 114Device Administration API supports the policies listed in Table 1. 115Note that the Device Administration API currently only supports passwords for screen 116lock:</p> 117<p class="table-caption"><strong>Table 1.</strong> Policies supported by the Device Administration API.</p> 118<table border="1"> 119 <tr> 120 <th>Policy</th> 121 <th>Description</th> 122 </tr> 123 <tr> 124 <td>Password enabled</td> 125 <td>Requires that devices ask for PIN or passwords.</td> 126 </tr> 127 <tr> 128 <td>Minimum password length</td> 129 <td>Set the required number of characters for the password. For example, you 130can require PIN or passwords to have at least six characters. </td> </tr> 131 <tr> 132 <td>Alphanumeric password required</td> 133 <td>Requires that passwords have a 134combination of letters and numbers. They may include symbolic characters. 135 </td> 136 </tr> 137 138 <tr> 139 <td>Complex password required</td> 140 <td>Requires that passwords must contain at least a letter, a numerical digit, and a special symbol. Introduced in Android 3.0. 141 </td> 142 </tr> 143 144<tr> 145 <td>Minimum letters required in password</td> <td>The minimum number of 146letters required in the password for all admins or a particular one. Introduced in Android 3.0.</td> 147</tr> 148 149 150 <tr> 151 <td>Minimum lowercase letters required in password</td> 152 <td>The minimum number of lowercase 153letters required in the password for all admins or a particular one. Introduced in Android 3.0.</td> 154</tr> 155 156 <tr> 157 <td>Minimum non-letter characters required in password</td> 158 <td>The minimum number of 159non-letter characters required in the password for all admins or a particular one. Introduced in Android 3.0.</td> 160</tr> 161 162<tr> 163 <td>Minimum numerical digits required in password</td> 164 <td>The minimum number of numerical digits required in the password for all admins or a particular one. Introduced in Android 3.0.</td> 165</tr> 166 167<tr> 168 <td>Minimum symbols required in password</td> 169 <td>The minimum number of symbols required in the password for all admins or a particular one. Introduced in Android 3.0.</td> 170</tr> 171 172<tr> 173 <td>Minimum uppercase letters required in password</td> 174 <td>The minimum number of uppercase letters required in the password for all admins or a particular one. Introduced in Android 3.0.</td> 175</tr> 176 177<tr> 178 <td>Password expiration timeout</td> 179 <td>When the password will expire, expressed as a delta in milliseconds from when a device admin sets the expiration timeout. Introduced in Android 3.0.</td> 180</tr> 181 182<tr> 183 <td>Password history restriction</td> 184 <td>This policy prevents users from reusing the last <em>n</em> unique passwords. 185 This policy is typically used in conjunction with 186{@link android.app.admin.DevicePolicyManager#setPasswordExpirationTimeout(android.content.ComponentName,long) setPasswordExpirationTimeout()}, which forces 187users to update their passwords after a specified amount of time has elapsed. 188Introduced in Android 3.0.</td> 189</tr> 190 191 <tr> 192 <td>Maximum failed password attempts </td> 193 <td>Specifies how many times a user can enter the wrong password before the 194device wipes its data. The Device Administration API also allows administrators to 195remotely reset the device to factory defaults. This secures data in case the 196device is lost or stolen.</td> 197 </tr> 198 <tr> 199 <td>Maximum inactivity time lock</td> 200 <td>Sets the length of time since the user last touched the screen or 201pressed a button before the device locks the screen. When this happens, users 202need to enter their PIN or passwords again before they can use their devices and 203access data. The value can be between 1 and 60 minutes.</td> </tr> 204 205<tr> 206<td>Require storage encryption</td> 207<td>Specifies that the storage area should be encrypted, if the device supports it. 208Introduced in Android 3.0.</td> </tr> 209 210<tr> 211 <td>Disable camera</td> 212 213 <td>Specifies that the camera should be disabled. Note that this doesn't have 214to be a permanent disabling. The camera can be enabled/disabled dynamically 215based on context, time, and so on. Introduced in Android 4.0.</td> 216 217</tr> 218 219 220</table> 221 222<h4>Other features</h4> 223 224<p>In addition to supporting the policies listed in the above table, the Device 225Administration API lets you do the following:</p> <ul> 226 <li>Prompt user to set a new password.</li> 227 <li>Lock device immediately.</li> 228 <li>Wipe the device's data (that is, restore the device to its factory defaults).</li> 229</ul> 230 231 232<h2 id="sample">Sample Application</h2> 233 234<p>The examples used in this document are based on the Device Administration API 235sample, which is included in the SDK samples (available through the 236Android SDK Manager) and located on your system as 237<code><sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java</code>.</p> 238 239<p>The sample application offers a demo of device admin features. It presents users 240with a user interface that lets them enable the device admin application. Once 241they've enabled the application, they can use the buttons in the user interface 242to do the following:</p> 243<ul> 244 <li>Set password quality.</li> 245 <li>Specify requirements for the user's password, such as minimum length, the minimum number of 246 numeric characters it must contain, and so on.</li> 247 <li>Set the password. If the password does not conform to the specified 248policies, the system returns an error.</li> 249 <li>Set how many failed password attempts can occur before the device is wiped 250(that is, restored to factory settings).</li> 251<li>Set how long from now the password will expire.</li> 252<li>Set the password history length (<em>length</em> refers to number of old passwords stored in the history). 253This prevents users from reusing 254one of the last <em>n</em> passwords they previously used.</li> 255<li>Specify that the storage area should be encrypted, if the device supports it.</li> 256 <li>Set the maximum amount of inactive time that can elapse before the device 257locks.</li> 258 <li>Make the device lock immediately.</li> 259 <li>Wipe the device's data (that is, restore factory settings).</li> 260 <li>Disable the camera.</li> 261 262</ul> 263 264 265 266<img src="{@docRoot}images/admin/device-admin-app.png"/> 267 268<p class="img-caption"><strong>Figure 1.</strong> Screenshot of the Sample Application</p> 269 270 271 272<h2 id="developing">Developing a Device Administration Application</h2> 273 274<p>System administrators can use the Device Administration API to write an application 275that enforces remote/local device security policy enforcement. This section 276summarizes the steps involved in creating a device administration 277application.</p> 278 279<h3 id="manifest">Creating the manifest</h3> 280 281<p>To use the Device Administration API, the application's 282manifest must include the following:</p> 283<ul> 284 <li>A subclass of {@link android.app.admin.DeviceAdminReceiver} that includes the following: 285 <ul> 286 <li>The {@link android.Manifest.permission#BIND_DEVICE_ADMIN} permission.</li> 287 <li>The ability to respond to the {@link android.app.admin.DeviceAdminReceiver#ACTION_DEVICE_ADMIN_ENABLED} 288intent, expressed in the manifest as an intent filter.</li> 289 </ul> 290 </li> 291 <li>A declaration of security policies used in metadata.</li> 292</ul> 293<p>Here is an excerpt from the Device Administration sample manifest:</p> 294<pre><activity android:name=".app.DeviceAdminSample" 295 android:label="@string/activity_sample_device_admin"> 296 <intent-filter> 297 <action android:name="android.intent.action.MAIN" /> 298 <category android:name="android.intent.category.SAMPLE_CODE" /> 299 </intent-filter> 300</activity> 301<receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver" 302 android:label="@string/sample_device_admin" 303 android:description="@string/sample_device_admin_description" 304 android:permission="android.permission.BIND_DEVICE_ADMIN"> 305 <meta-data android:name="android.app.device_admin" 306 android:resource="@xml/device_admin_sample" /> 307 <intent-filter> 308 <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> 309 </intent-filter> 310</receiver></pre> 311 312 <p>Note that:</p> 313<ul> 314<li>The following attributes refer to string resources that for the sample application reside in 315<code>ApiDemos/res/values/strings.xml</code>. For more information about resources, see 316<a 317href="{@docRoot}guide/topics/resources/index.html">Application Resources</a>. 318<ul> 319<li><code>android:label="@string/activity_sample_device_admin"</code> refers to the 320user-readable label for the activity.</li> 321 322<li><code>android:label="@string/sample_device_admin"</code> refers to the 323user-readable label for the permission.</li> 324 325<li><code>android:description="@string/sample_device_admin_description"</code> refers to 326the user-readable description of the permission. A descripton is typically longer and more 327informative than 328a label.</li> 329</ul> 330 331 332<li><code>android:permission="android.permission.BIND_DEVICE_ADMIN" 333</code> is a permission that a {@link android.app.admin.DeviceAdminReceiver} subclass must 334have, to ensure that only the system can interact with the receiver (no application can be granted this permission). This 335prevents other applications from abusing your device admin app.</li> 336<li><code>android.app.action.DEVICE_ADMIN_ENABLED</code> is the primary 337action that a {@link android.app.admin.DeviceAdminReceiver} subclass must handle to be 338allowed to manage a device. This is set to the receiver when the user enables 339the device admin app. Your code typically handles this in 340{@link android.app.admin.DeviceAdminReceiver#onEnabled onEnabled()}. To be supported, the receiver must also 341require the {@link android.Manifest.permission#BIND_DEVICE_ADMIN} permission so that other applications 342cannot abuse it. </li> 343<li>When a user enables the device admin application, that gives the receiver 344permission to perform actions in response to the broadcast of particular system 345events. When suitable event arises, the application can impose a policy. For 346example, if the user attempts to set a new password that doesn't meet the policy 347requirements, the application can prompt the user to pick a different password 348that does meet the requirements.</li> 349 350 <li><code>android:resource="@xml/device_admin_sample"</code> 351declares the security policies used in metadata. The metadata provides additional 352information specific to the device administrator, as parsed by the {@link 353android.app.admin.DeviceAdminInfo} class. Here are the contents of 354<code>device_admin_sample.xml</code>:</li> 355</ul> 356<pre><device-admin xmlns:android="http://schemas.android.com/apk/res/android"> 357 <uses-policies> 358 <limit-password /> 359 <watch-login /> 360 <reset-password /> 361 <force-lock /> 362 <wipe-data /> 363 <expire-password /> 364 <encrypted-storage /> 365 <disable-camera /> 366 </uses-policies> 367</device-admin> 368</pre> 369<p> In designing your device administration application, you don't need to 370include all of the policies, just the ones that are relevant for your app. 371</p> 372For more discussion of the manifest file, see the <a 373href="{@docRoot}guide/topics/manifest/manifest-intro.html">Android Developers Guide</a>. 374 375 376 377<h3 id="code">Implementing the code</h3> 378 379<p>The Device Administration API includes the following classes:</p> 380<dl> 381 <dt>{@link android.app.admin.DeviceAdminReceiver}</dt> 382 <dd>Base class for implementing a device administration component. This class provides 383a convenience for interpreting the raw intent actions that are sent by the 384system. Your Device Administration application must include a 385{@link android.app.admin.DeviceAdminReceiver} subclass.</dd> 386 <dt>{@link android.app.admin.DevicePolicyManager}</dt> 387<dd>A class for managing policies enforced on a device. Most clients of 388this class must have published a {@link android.app.admin.DeviceAdminReceiver} that the user 389has currently enabled. The {@link android.app.admin.DevicePolicyManager} manages policies for 390one or more {@link android.app.admin.DeviceAdminReceiver} instances</dd> 391 <dt>{@link android.app.admin.DeviceAdminInfo}</dt> 392<dd>This class is used to specify metadata 393for a device administrator component.</dd> 394</dl> 395<p>These classes provide the foundation for a fully functional device administration application. 396The rest of this section describes how you use the {@link 397android.app.admin.DeviceAdminReceiver} and 398{@link android.app.admin.DevicePolicyManager} APIs to write a device admin application.</p> 399 400<h4 id="receiver">Subclassing DeviceAdminReceiver</h4> 401<p>To create a device admin application, you must subclass 402{@link android.app.admin.DeviceAdminReceiver}. The {@link android.app.admin.DeviceAdminReceiver} class 403consists of a series of callbacks that are triggered when particular events 404occur.</p> 405<p>In its {@link android.app.admin.DeviceAdminReceiver} subclass, the sample application 406simply displays a {@link android.widget.Toast} notification in response to particular 407events. For example:</p> 408<pre>public class DeviceAdminSample extends DeviceAdminReceiver { 409 410 void showToast(Context context, String msg) { 411 String status = context.getString(R.string.admin_receiver_status, msg); 412 Toast.makeText(context, status, Toast.LENGTH_SHORT).show(); 413 } 414 415 @Override 416 public void onEnabled(Context context, Intent intent) { 417 showToast(context, context.getString(R.string.admin_receiver_status_enabled)); 418 } 419 420 @Override 421 public CharSequence onDisableRequested(Context context, Intent intent) { 422 return context.getString(R.string.admin_receiver_status_disable_warning); 423 } 424 425 @Override 426 public void onDisabled(Context context, Intent intent) { 427 showToast(context, context.getString(R.string.admin_receiver_status_disabled)); 428 } 429 430 @Override 431 public void onPasswordChanged(Context context, Intent intent) { 432 showToast(context, context.getString(R.string.admin_receiver_status_pw_changed)); 433 } 434... 435}</pre> 436 437 438<h4 id="enabling">Enabling the application</h4> 439<p>One of the major events a device admin application has to handle is the user 440enabling the application. The user must explicitly enable the application for 441the policies to be enforced. If the user chooses not to enable the application 442it will still be present on the device, but its policies will not be enforced, and the user will not 443get any of the application's benefits.</p> 444<p>The process of enabling the application begins when the user performs an 445action that triggers the {@link android.app.admin.DevicePolicyManager#ACTION_ADD_DEVICE_ADMIN} 446intent. In the 447sample application, this happens when the user clicks the <strong>Enable 448Admin</strong> checkbox. </p> 449<p>When the user clicks the <strong>Enable Admin</strong> checkbox, the display 450changes to prompt the user to activate the device admin application, as shown in figure 4512.</p> 452 453<img src="{@docRoot}images/admin/device-admin-activate-prompt.png"/> 454<p class="img-caption"><strong>Figure 2.</strong> Sample Application: Activating the Application</p> 455 456<p>Below is the code that gets executed when the user clicks the <strong>Enable Admin</strong> checkbox. This has the effect of triggering the 457{@link android.preference.Preference.OnPreferenceChangeListener#onPreferenceChange(android.preference.Preference, java.lang.Object) onPreferenceChange()} 458callback. This callback is invoked when the value of this {@link android.preference.Preference} has been changed by the user and is about to be set and/or persisted. If the user is enabling the application, the display 459changes to prompt the user to activate the device admin application, as shown in figure 4602. Otherwise, the device admin application is disabled. </p> 461 462<pre>@Override 463 public boolean onPreferenceChange(Preference preference, Object newValue) { 464 if (super.onPreferenceChange(preference, newValue)) { 465 return true; 466 } 467 boolean value = (Boolean) newValue; 468 if (preference == mEnableCheckbox) { 469 if (value != mAdminActive) { 470 if (value) { 471 // Launch the activity to have the user enable our admin. 472 Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN); 473 intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample); 474 intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION, 475 mActivity.getString(R.string.add_admin_extra_app_text)); 476 startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN); 477 // return false - don't update checkbox until we're really active 478 return false; 479 } else { 480 mDPM.removeActiveAdmin(mDeviceAdminSample); 481 enableDeviceCapabilitiesArea(false); 482 mAdminActive = false; 483 } 484 } 485 } else if (preference == mDisableCameraCheckbox) { 486 mDPM.setCameraDisabled(mDeviceAdminSample, value); 487 ... 488 } 489 return true; 490 }</pre> 491 492 493<p>The line 494<code>intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, 495mDeviceAdminSample)</code> states that <code>mDeviceAdminSample</code> (which is 496a {@link android.app.admin.DeviceAdminReceiver} component) is the target policy. 497This line invokes the user interface shown in figure 2, which guides users through 498adding the device administrator to the system (or allows them to reject it).</p> 499 500<p>When the application needs to perform an operation that is contingent on the 501device admin application being enabled, it confirms that the application is 502active. To do this it uses the {@link android.app.admin.DevicePolicyManager} method 503{@link android.app.admin.DevicePolicyManager#isAdminActive(android.content.ComponentName) isAdminActive()}. Notice that the {@link android.app.admin.DevicePolicyManager} 504method {@link android.app.admin.DevicePolicyManager#isAdminActive(android.content.ComponentName) isAdminActive()} takes a {@link android.app.admin.DeviceAdminReceiver} 505component as its argument:</p> 506 507<pre> 508DevicePolicyManager mDPM; 509... 510private boolean isActiveAdmin() { 511 return mDPM.isAdminActive(mDeviceAdminSample); 512} 513</pre> 514 515 516 517<h3 id="admin_ops">Managing policies</h3> 518<p>{@link android.app.admin.DevicePolicyManager} is a public class for managing policies 519enforced on a device. {@link android.app.admin.DevicePolicyManager} manages policies for one 520or more {@link android.app.admin.DeviceAdminReceiver} instances. </p> 521<p>You get a handle to the {@link android.app.admin.DevicePolicyManager} as follows: </p> 522<pre> 523DevicePolicyManager mDPM = 524 (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE); 525</pre> 526<p>This section describes how to use {@link android.app.admin.DevicePolicyManager} to perform 527 administrative tasks:</p> 528<ul> 529 <li><a href="#pwd">Set password policies</a></li> 530 <li><a href="#lock">Set device lock</a></li> 531 <li><a href="#wipe">Perform data wipe</a></li> 532</ul> 533 534<h4 id="pwd">Set password policies</h4> 535<p>{@link android.app.admin.DevicePolicyManager} includes APIs for setting and enforcing the 536device password policy. In the Device Administration API, the password only applies to 537screen lock. This section describes common password-related tasks.</p> 538 539<h5>Set a password for the device</h5> 540<p>This code displays a user interface prompting the user to set a password:</p> 541<pre>Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); 542startActivity(intent); 543</pre> 544 545<h5>Set the password quality</h5> 546<p>The password quality can be one of the following {@link android.app.admin.DevicePolicyManager} constants: </p> 547<dl> 548 <dt>{@link android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_ALPHABETIC}</dt><dd>The user must enter a 549password containing at least alphabetic (or other symbol) characters.</dd> 550 <dt>{@link android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_ALPHANUMERIC}</dt><dd>The user must enter a 551password containing at least <em>both</em> numeric <em>and</em> alphabetic (or 552other symbol) characters.</dd> 553 <dt>{@link android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_NUMERIC}</dt><dd>The user must enter a password 554containing at least numeric characters.</dd> 555<dt>{@link 556android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_COMPLEX}</dt><dd>The user 557must have entered a password containing at least a letter, a numerical digit and 558a special symbol.</dd> 559<dt>{@link 560android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_SOMETHING}</dt><dd>The 561policy requires some kind 562of password, but doesn't care what it is.</dd> 563 <dt>{@link android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_UNSPECIFIED}</dt><dd> 564 The policy has no requirements for the password. </dd> 565</dl> 566<p>For example, this is how you would set the password policy to require an alphanumeric password:</p> 567<pre> 568DevicePolicyManager mDPM; 569ComponentName mDeviceAdminSample; 570... 571mDPM.setPasswordQuality(mDeviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC); 572</pre> 573 574<h5>Set password content requirements</h5> 575 576<p>Beginning with Android 3.0, the {@link android.app.admin.DevicePolicyManager} class 577includes methods that let you fine-tune the contents of the password. For 578example, you could set a policy that states that passwords must contain at least 579<em>n</em> uppercase letters. Here are the methods for fine-tuning a password's 580contents:</p> 581<ul> 582 583<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumLetters(android.content.ComponentName,int) setPasswordMinimumLetters()}</li> 584 585<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumLowerCase(android.content.ComponentName,int) setPasswordMinimumLowerCase()}</li> 586 587<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumUpperCase(android.content.ComponentName,int) setPasswordMinimumUpperCase()}</li> 588 589<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumNonLetter(android.content.ComponentName,int) setPasswordMinimumNonLetter()}</li> 590 591<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumNumeric(android.content.ComponentName,int) setPasswordMinimumNumeric()}</li> 592 593<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumSymbols(android.content.ComponentName,int) setPasswordMinimumSymbols()}</li> 594</ul> 595<p>For example, this snippet states that the password must have at least 2 uppercase letters:</p> 596<pre> 597DevicePolicyManager mDPM; 598ComponentName mDeviceAdminSample; 599int pwMinUppercase = 2; 600... 601mDPM.setPasswordMinimumUpperCase(mDeviceAdminSample, pwMinUppercase);</pre> 602 603 604<h5>Set the minimum password length</h5> 605<p>You can specify that a password must be at least the specified minimum 606length. For example:</p> 607<pre>DevicePolicyManager mDPM; 608ComponentName mDeviceAdminSample; 609int pwLength; 610... 611mDPM.setPasswordMinimumLength(mDeviceAdminSample, pwLength); 612</pre> 613 614<h5>Set maximum failed password attempts</h5> 615<p>You can set the maximum number of allowed failed password attempts before the 616device is wiped (that is, reset to factory settings). For example:</p> 617<pre>DevicePolicyManager mDPM; 618ComponentName mDeviceAdminSample; 619int maxFailedPw; 620 ... 621mDPM.setMaximumFailedPasswordsForWipe(mDeviceAdminSample, maxFailedPw);</pre> 622 623<h5 id="expiration">Set password expiration timeout</h5> 624<p>Beginning with Android 3.0, you can use the 625{@link android.app.admin.DevicePolicyManager#setPasswordExpirationTimeout(android.content.ComponentName,long) setPasswordExpirationTimeout()} 626method to set when a password will expire, expressed as a delta in milliseconds from when a device admin sets the expiration timeout. For example:</p> 627 628<pre>DevicePolicyManager mDPM; 629ComponentName mDeviceAdminSample; 630long pwExpiration; 631... 632mDPM.setPasswordExpirationTimeout(mDeviceAdminSample, pwExpiration); 633</pre> 634 635<h5 id="history">Restrict password based on history</h5> 636 637<p>Beginning with Android 3.0, you can use the 638{@link android.app.admin.DevicePolicyManager#setPasswordHistoryLength(android.content.ComponentName,int) setPasswordHistoryLength()} 639method to limit users' 640ability to reuse old passwords. This method takes a <em>length</em> 641parameter, which specifies how many old 642passwords are stored. When this policy is active, users cannot enter a new 643password that matches the last <em>n</em> passwords. This prevents 644users from using the same password over and over. This policy is typically used 645in conjunction with 646{@link android.app.admin.DevicePolicyManager#setPasswordExpirationTimeout(android.content.ComponentName,long) setPasswordExpirationTimeout()}, 647which forces users 648to update their passwords after a specified amount of time has elapsed. </p> 649 650<p>For example, this snippet prohibits users from reusing any of their last 5 passwords:</p> 651 652<pre>DevicePolicyManager mDPM; 653ComponentName mDeviceAdminSample; 654int pwHistoryLength = 5; 655... 656mDPM.setPasswordHistoryLength(mDeviceAdminSample, pwHistoryLength); 657</pre> 658 659<h4 id="lock">Set device lock</h4> 660<p>You can set the maximum period of user inactivity that can occur before the 661device locks. For example:</p> 662<pre> 663DevicePolicyManager mDPM; 664ComponentName mDeviceAdminSample; 665... 666long timeMs = 1000L*Long.parseLong(mTimeout.getText().toString()); 667mDPM.setMaximumTimeToLock(mDeviceAdminSample, timeMs); 668</pre> 669<p>You can also programmatically tell the device to lock immediately:</p> 670<pre> 671DevicePolicyManager mDPM; 672mDPM.lockNow(); 673</pre> 674 675 676 677<h4 id="wipe">Perform data wipe</h4> 678 679<p>You can use the {@link android.app.admin.DevicePolicyManager} method 680{@link android.app.admin.DevicePolicyManager#wipeData wipeData()} to reset the device to factory settings. This is useful 681if the device is lost or stolen. Often the decision to wipe the device is the 682result of certain conditions being met. For example, you can use 683{@link android.app.admin.DevicePolicyManager#setMaximumFailedPasswordsForWipe setMaximumFailedPasswordsForWipe()} to state that a device should be 684wiped after a specific number of failed password attempts.</p> 685<p>You wipe data as follows:</p> 686<pre> 687DevicePolicyManager mDPM; 688mDPM.wipeData(0);</pre> 689<p>The {@link android.app.admin.DevicePolicyManager#wipeData wipeData()} method takes as its 690 parameter a bit mask of additional options. Currently the value must be 0. </p> 691 692<h4>Disable camera</h4> 693<p>Beginning with Android 4.0, you can disable the camera. Note that this doesn't have to be a permanent disabling. The camera can be enabled/disabled dynamically based on context, time, and so on. </p> 694<p>You control whether the camera is disabled by using the 695{@link android.app.admin.DevicePolicyManager#setCameraDisabled(android.content.ComponentName, boolean) setCameraDisabled()} method. For example, this snippet sets the camera to be enabled or disabled based on a checkbox setting:</p> 696 697<pre>private CheckBoxPreference mDisableCameraCheckbox; 698DevicePolicyManager mDPM; 699ComponentName mDeviceAdminSample; 700... 701mDPM.setCameraDisabled(mDeviceAdminSample, mDisableCameraCheckbox.isChecked());<br /> 702</pre> 703 704 705<h4 id="storage">Storage encryption</h4> 706<p>Beginning with Android 3.0, you can use the 707{@link android.app.admin.DevicePolicyManager#setStorageEncryption(android.content.ComponentName,boolean) setStorageEncryption()} 708method to set a policy requiring encryption of the storage area, where supported.</p> 709 710<p>For example:</p> 711 712<pre> 713DevicePolicyManager mDPM; 714ComponentName mDeviceAdminSample; 715... 716mDPM.setStorageEncryption(mDeviceAdminSample, true); 717</pre> 718<p> 719See the Device Administration API sample for a complete example of how to enable storage encryption. 720</p> 721