diff --git a/docs/html/preview/features/direct-boot.jd b/docs/html/preview/features/direct-boot.jd new file mode 100644 index 0000000000000..8d4b561f9abe1 --- /dev/null +++ b/docs/html/preview/features/direct-boot.jd @@ -0,0 +1,176 @@ +page.title=Direct Boot +page.keywords=preview,sdk,direct boot +page.tags=androidn + +@jd:body + +
The system now runs in a secure, Direct Boot mode when the device has been +powered on but the user has not unlocked the device. To support this, the +system provides two storage locations for data:
+ +By default apps will not run during Direct Boot mode, because apps won't +have access to credential encrypted storage.
+ +If your app needs to take action during Direct Boot mode, you can register +app components that should be run during this mode. Some common use cases +for applications needing to run during Direct Boot mode include:
+If your app needs to access data while running in Direct Boot mode, use +device encrypted storage. Device encrypted storage contains data +encrypted with a key that is only available after a device has performed a +successful verified boot.
+ +For data that should be encrypted with a key associated with user +credentials, such as a PIN or password, use credential encrypted storage. +Credential encrypted storage is only available after the user has successfully +unlocked the device, up until when the user restarts the device again. If the +user enables the lock screen after unlocking the device, this will not lock +credential encrypted storage.
+ +Applications must register their components with the system before they
+can run during the limited Direct Boot mode, or access device encrypted
+storage. Applications register with the system by marking components as
+encryption aware. To mark your component as encryption aware, set the
+android:encryptionAware attribute to true in your manifest.
+ +
When a component is marked as encryption aware, the component receives a
+new LOCKED_BOOT_COMPLETED broadcast message from the
+system when the device has been restarted. At this point device encrypted
+storage is available, and your component can run whatever tasks need to be
+done during Direct Boot mode, such as triggering a scheduled alarm.
The following code snippet is an example of how to register a
+BroadcastReceiver as encryption aware, and add an intent filter
+for LOCKED_BOOT_COMPLETED, in the application manifest:
+<receiever + android:encryptionAware="true" > + ... + <intent-filter> + <action android:name="android.intent.action.LOCKED_BOOT_COMPLETED" /> + </intent-filter> +</receiver> ++ +
Once the user has unlocked the device, components can access both the +device encrypted storage as well as credential encrypted storage.
+ +To access device encrypted storage, create a second Context
+instance by calling Context.createDeviceEncryptedStorageContext().
+All storage API calls made using this context access the device encrypted
+storage. The following example accesses the device encrypted storage and opens
+an existing app data file:
+Context directBootContext = Context.createDeviceEncryptedStorageContext(); +// Access appDataFilename that lives in device encrypted storage +FileInputStream inStream = directBootContext.openFileInput(appDataFilename); +// Use inStream to read content... ++ +
Note: Use device encrypted storage only for +information that must be accessible during the Direct Boot mode. +Don't use device encrypted storage as a general-purpose encrypted store. +For private user information, or encrypted data that isn't needed during +Direct Boot mode, use credential encrypted storage.
+ +Once the user unlocks the device after restart, your app can switch to +accessing credential encrypted storage and use regular system services that +depend on user credentials, like Google Play Services.
+ +To get notified when the user unlocks the device after a reboot,
+register a BroadcastReceiver from a running component to listen
+for the ACTION_USER_UNLOCKED message. Or, you can receive the
+existing BOOT_COMPLETED message, which now indicates the
+device has booted and the user has unlocked the device.
You can directly query if the user has unlocked the device by calling
+UserManager.isUserUnlocked().
If a user updates their device to use Direct Boot mode, you might have
+existing data that needs to get migrated to device encrypted storage. Use
+Context.migrateSharedPreferencesFrom() and
+Context.migrateDatabaseFrom() to migrate preference and database
+data between credential encrypted storage and device encrypted storage.
Use your best judgment when deciding what data to migrate from credential +encrypted storage to device encrypted storage. You should not be migrating +private user information, such as passwords or authorization tokens, to +device encrypted storage. In some scenarios, you might need to manage +separate sets of data in the two encrypted stores.
+ +Test your encryption aware application using the new Direct Boot mode. +On supported devices with Android N Developer Preview installed, enable Direct +Boot by doing one of the following:
+ ++$ adb reboot-bootloader +$ fastboot --wipe-and-use-fbe ++
An emulated Direct Boot mode is also available, in case you need to switch +modes on your test devices. Emulated mode should only be used during +development and may cause data loss. To enable emulated Direct Boot mode, +set a lock pattern on the device, choose "No thanks" if prompted for a +secure start-up screen when setting a lock pattern, and then use the +following adb shell command:
+ ++$ adb shell sm set-emulate-fbe true ++ +
To turn off emulated Direct Boot mode, use the following command:
+ ++$ adb shell sm set-emulate-fbe false ++ +
Note that using these commands will automatically cause the device to +reboot.