directboot_是DirectBoot，您在寻找什么？-CSDN博客

directboot

Android brings various features for users and developers, one such feature was added in Android 7, called DirectBoot, but what exactly is DirectBoot? Let’s try to find that in the next few minutes, and also when, why, and how to use it.

Android为用户和开发人员带来了各种功能，Android 7中增加了一项这样的功能，称为DirectBoot，但是DirectBoot到底是什么呢？让我们尝试在接下来的几分钟内找到它，以及何时，为什么以及如何使用它。

什么是DirectBoot？ (What is DirectBoot?)

Starting with Android N, a device that has been powered on can boot into a new mode called Direct Boot before the user has a chance to unlock it for the first time. In this mode, the operating system is fully operational, but access to private app data is limited and only apps that have been updated to be Direct Boot Aware can run, which basically means that you can perform actions even before the user unlocks the device.

从Android N开始，已打开电源的设备可以在用户首次解锁之前启动到称为“直接启动”的新模式。在这种模式下，操作系统可以完全运行，但是对私有应用程序数据的访问受到限制，并且只有已更新为Direct Boot Aware的应用程序才能运行，这基本上意味着您甚至可以在用户解锁设备之前执行操作。

您的应用程序甚至需要DirectBoot吗？ (Does your app even need the DirectBoot?)

Let’s consider a real-world scenario, of an Alarm Clock App. Suppose a user sets an Alarm for 6'o clock in the morning and if the device gets rebooted during the sleep cycle, the user won’t be able to receive the alarm and might miss out on important things for which they scheduled the alarm. So to prevent such scenarios from happening Google included Direct Boot Aware in Android 7.

让我们考虑一个闹钟应用程序的实际场景。假设用户在早上6点钟设置了一个闹钟，并且如果设备在睡眠周期中重新启动，则该用户将无法接收该闹钟，并且可能错过了为其安排闹钟的重要事项。因此，为防止发生此类情况，Google在Android 7中包含了Direct Boot Aware。

Any application that schedules alarms like the alarm clock we discussed, provides important and timely notifications like a messaging app or provides services to other apps or the system like a keyboard or a launcher, all these apps need to update to Direct Boot Aware for better user experience and special scenarios.

任何安排警报(例如我们讨论过的闹钟)，提供重要而及时的通知(例如消息传递应用程序)或向其他应用程序或系统(例如键盘或启动器)提供服务的应用程序 ，所有这些应用程序都需要更新为Direct Boot Aware，以更好地吸引用户经验和特殊情况。

如果设备重新启动，直接启动有何帮助？ (How does Direct Boot help if the device is rebooted?)

To support DirectBoot, the system provides two storage locations for data:

为了支持DirectBoot，系统提供了两个数据存储位置：

Credential encrypted storage, which is the default storage location and only available after the user has unlocked the device. The data could be found in /user folder in rooted devices.

凭据加密存储 ，这是默认的存储位置，仅在用户解锁设备后可用。可以在已root 用户的设备的/ user文件夹中找到数据。

Device encrypted storage, which is a storage location available both during Direct Boot mode and after the user has unlocked the device. For this mode, all the data is present in the /user_de folder.

设备加密存储 ，这是在直接启动模式下以及用户解锁设备后可用的存储位置。对于此模式，所有数据都位于/ user_de文件夹中。

So even if the device is rebooted the application can perform actions and use the user data that is present in the Device Encrypted Storage

因此，即使重新启动设备，应用程序也可以执行操作并使用设备加密存储中存在的用户数据

如何使用Direct Boot Aware？ (How to use Direct Boot Aware?)

1. Analyze the components of your app, which you would like to make boot-ware. A service launched on boot, for instance, which is responsible for initiating the alarms. Declare those components as boot-aware in manifest

1.分析您想要制作引导软件的应用程序组件。例如，在启动时启动的服务，该服务负责启动警报。在清单中将这些组件声明为可引导的组件

<activity|provider|receiver|service …
android:directBootAware=”true”>

If you implement a custom Application class and register any sub-component as boot-aware, the Application class automatically inherits the boot-aware property.

如果实现自定义Application类并将任何子组件注册为可识别启动，则Application类将自动继承boot-aware属性。

2. Components that rely on broadcast ACTION_BOOT_COMPLETED as a trigger to start, must switch to the broadcast ACTION_LOCKED_BOOT_COMPLETED. This broadcast is received by all boot-aware components, as soon as the device is booted. At this moment only Device protected storage is accessible.

2.依靠广播ACTION_BOOT_COMPLETED作为启动触发器的组件，必须切换到广播ACTION_LOCKED_BOOT_COMPLETED 。设备启动后，所有启动支持组件都会收到此广播。目前，只能访问受设备保护的存储。

P.S: ACTION_BOOT_COMPLETED will also be received by boot-aware components but only once the device has been unlocked by the user. At this moment, both Credential protected storage and Device protected storage are accessible.

PS：动作识别组件也将收到ACTION_BOOT_COMPLETED，但只有在用户将设备解锁后，该组件才能接收到。目前，可访问受凭据保护的存储和受设备保护的存储。

如何访问两个不同的存储路径？ (How do I access the two different storage paths?)

Android APIs have made this extremely easy, as the only variable that differentiates between the two storage paths is Context. The default context points to Credential protected storage. A new context can be requested anytime by createDeviceProtectedStorageContext() whose storage APIs point to the Device protected storage.

Android API使其非常容易，因为区分两个存储路径的唯一变量是Context。默认上下文指向受凭据保护的存储。 createContextProtectedStorageContext()可以随时请求一个新的上下文，其存储API指向受设备保护的存储。

Context credentialProtectedContext =getApplicationContext();
Context deviceProtectedContext = credentialProtectedStorage.createDeviceProtectedStorageContext();

担心凭证存储中已经存在的数据？ (Worried about the Data already present in Credential Storage?)

If the app hasn’t been rolled out to the public yet, you wouldn’t face this issue, because you would, by default, place boot-aware data at device protected storage. But, updating an app that is already available to users, you might consider moving the data which is required by boot-aware components from Credential protected storage to Device protected storage to maintain the integrity of the app after the update. This can be done by moveSharedPreferencesFrom() or moveDatabaseFrom() respectively.

如果该应用尚未向公众推出，那么您将不会遇到此问题，因为默认情况下，您会将引导启动数据放在设备保护的存储中。但是，在更新用户可用的应用程序时，您可能会考虑将启动感知组件所需的数据从受凭据保护的存储区移至受设备保护的存储区，以在更新后保持应用程序的完整性。这可以通过moveSharedPreferencesFrom()完成 要么 moveDatabaseFrom() 分别。

// For Shared Preferences
deviceProtectedContext.moveSharedPreferencesFrom(credentialProtectedContext,SHARED_PREFERENCE_NAME);//For Databases
deviceProtectedContext.moveDatabaseFrom(credentialProtectedContext,DATABASE_NAME);

To move any other files residing at internal app storage, which may be required by boot-aware components, you can manually copy the file :

要移动驻留在内部应用程序存储中的任何其他文件(启动感知组件可能需要)，您可以手动复制该文件：

File fileAtCredentialStorage= credentialProtectedContext.getFilesDir()+File.seperator+FILE_NAME;
File fileAtDeviceStorage= deviceProtectedContext.getFilesDir()+File.seperator+FILE_NAME; FileUtils.copyFile(fileAtCredentialStorage, fileAtDeviceStorage);

使用第三方图书馆，我们可以帮助您！!!! (Using 3rd party libraries, we got you covered!!!!)

3rd party libraries like Firebase, Crashylitics, AdMob, etc. require to be initialized at app startup. They internally use SharedPreferences and databases, and most of them don’t support device protected storage. So, it’s a good idea to take care of them only after the device has been unlocked else they will throw an exception.

需要在应用启动时初始化Firebase，Crashylitics，AdMob等第三方库。它们在内部使用SharedPreferences和数据库，并且大多数不支持设备保护的存储。因此，最好仅在设备解锁后对其进行保养，否则它们将引发异常。

To check at runtime, whether credential protected storage is available or not, this function may help UserManagerCompat.isUserUnlocked()

要在运行时检查是否有受凭证保护的存储，此函数可以帮助UserManagerCompat.isUserUnlocked()

要注意的事项： (Things to be taken care of :)

A common mistake may arise while moving databases. If a connection to a database is opened, a singleton for the database is persisted by the system. Upon moving the database to another location, the singleton may not be aware of the move and subsequent call to the database may throw an exception:

移动数据库时可能会出现常见错误。如果打开了与数据库的连接，则系统将保留数据库的单例。将数据库移动到另一个位置时，单例可能不知道该移动，并且随后对数据库的调用可能会引发异常：

It is not guaranteed that this exception is thrown for all devices, as it is system dependent, but it is always better to be on a safe side. Make sure that the migration always takes place before opening the database.

由于与系统有关，因此不能保证会为所有设备引发此异常，但是最好还是安全起见。在打开数据库之前，请确保始终进行迁移。

使用Direct Boot Aware安全吗？ (Is it safe to use Direct Boot Aware?)

You should not migrate 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. Use this feature wisely and only take advantage of it, when there is a real reason for doing that!

您不应将私有用户信息(例如密码或授权令牌)迁移到设备加密的存储中。在某些情况下，您可能需要在两个加密存储中管理单独的数据集。明智地使用此功能，只有在确实有这样做的理由时才利用它！

This article is co-authored by RISHABH KHEMKA and Saurabh Tomar.

本文由RISHABH KHEMKA和Saurabh Tomar共同撰写。