在Android 14 AOSP中为SystemProperties.get添加系统启动完成检查

深入探讨如何在Android核心框架中安全地判断系统引导状态

您希望在 Android 14 AOSP 的 `frameworks/base/core/java/android/os/SystemProperties.java` 文件中的 `get` 方法内，添加一个逻辑来判断 Android 系统是否已经完成了启动过程。这是一个常见的需求，尤其是在开发系统级功能或需要确保在稳定状态下访问系统属性时。直接修改 AOSP 核心组件需要谨慎，但通过检查特定的系统属性是可行的。

核心要点速览

关键属性: Android 系统使用名为 sys.boot_completed 的系统属性来标识引导过程是否完成。当其值为 "1" 时，表示系统已完全启动。
实现方式: 在 SystemProperties.get 方法内部，应使用内部的 native_get 方法来查询 sys.boot_completed 的状态，以避免无限递归调用。
处理逻辑: 如果系统尚未完成启动（属性值不为 "1"），应决定如何处理该情况，例如记录警告日志并返回默认值，以防止后续操作出错。

为何要在 SystemProperties 中检查启动状态？

在 Android 系统启动的早期阶段，并非所有服务和功能都已准备就绪。如果在系统完全启动之前访问某些依赖特定服务的系统属性，可能会遇到以下问题：

数据不一致： 获取到的属性值可能不准确或尚未初始化。
应用或服务崩溃： 依赖该属性值的代码可能会因为无效数据而失败。
安全风险： 在某些安全敏感的操作中，确保系统处于完全运行状态至关重要，例如在 Direct Boot 模式下，某些存储是加密的，直到用户解锁后才可用。
Android 14 特性： Android 14 进一步加强了启动过程的验证（如 Verified Boot）和系统属性的管理。在 `SystemProperties.get` 中添加检查可以增强代码的健壮性，尤其是在处理与设备状态紧密相关的属性时。

因此，在访问可能受启动状态影响的系统属性之前，增加一个检查步骤可以显著提高系统的稳定性和可靠性。

Android 启动流程示意图

上图简要展示了 Android 启动涉及的关键阶段，理解这个过程有助于明白为何需要在特定时机检查启动完成状态。

识别 Android 启动完成状态

关键系统属性：`sys.boot_completed`

Android 系统通过设置一个名为 sys.boot_completed 的系统属性来标准化地指示启动过程是否已经完成。这个属性通常由系统的 init 进程在启动流程的后期阶段，当所有关键系统服务（如 Activity Manager Service, Package Manager Service 等）都已成功启动并运行时设置。

设置时机： 当系统认为自身已达到一个稳定、功能完整的状态，足以响应用户交互和运行应用程序时，init 会将 sys.boot_completed 的值设置为 "1"。
初始状态： 在此之前，该属性可能不存在，或者值为 "0" 或空字符串。
可靠性： sys.boot_completed 是检查系统是否完全启动的最常用且可靠的指标之一，被广泛应用于系统服务和应用中，以触发 `BOOT_COMPLETED` 广播等事件。

Android 启动流程与 `sys.boot_completed` 的关系

为了更好地理解 `sys.boot_completed` 的作用，下面的思维导图概述了 Android 启动的关键步骤及其与该属性设置的关系。

mindmap root["Android Boot Process"] id1["1. Bootloader"] id1a["Hardware Init"] id1b["Loads Kernel"] id2["2. Kernel"] id2a["Initializes Core Systems (Memory, CPU)"] id2b["Mounts Root Filesystem"] id2c["Starts Init Process"] id3["3. Init Process"] id3a["Parses init.rc scripts"] id3b["Starts Zygote"] id3c["Starts System Services (via SystemServer)"] id3d["Mounts Filesystems"] id3e["Sets System Properties"] id3e1["..."] id3e2["Sets sys.boot_completed = 1 (Late Stage)"] id4["4. Zygote Process"] id4a["Preloads Classes & Resources"] id4b["Forks App Processes"] id5["5. System Server"] id5a["Starts Core Android Services (AMS, PMS, etc.)"] id5b["Broadcasts ACTION_BOOT_COMPLETED (after sys.boot_completed=1)"] id6["6. System Ready"] id6a["Home Screen Appears"] id6b["Device is Interactive"]

这个思维导图清晰地展示了 sys.boot_completed 是在 init 进程执行后期，通常在核心系统服务启动之后设置的，标志着系统基本准备就绪。

在 `SystemProperties.get` 中实现启动完成检查

建议的代码修改

您可以按如下方式修改 `SystemProperties.java` 文件中的 `get` 方法。关键在于调用 `native_get` 来检查 `sys.boot_completed`，而不是递归调用 `get` 方法本身。


import android.annotation.NonNull;
import android.annotation.Nullable;
import android.annotation.SystemApi;
import android.util.Log; // 确保导入 Log 类

// ... 其他导入和类定义 ...

public class SystemProperties {
    private static final String TAG = "SystemProperties"; // 定义日志标签
    private static final boolean TRACK_KEY_ACCESS = false; // 假设 TRACK_KEY_ACCESS 的定义

    // ... 其他方法和变量 ...

    /**
     * Gets the String value for the given key.
     *
     * @param key the key to lookup.
     * @param def the default value in case the property is not set or empty.
     * @return the String value of the property.
     */
    @SystemApi
    public static String get(@NonNull String key, @Nullable String def) {
        // 如果启用了键访问跟踪，则记录
        if (TRACK_KEY_ACCESS) onKeyAccess(key);

        // --- 添加启动完成判断 ---
        // 检查请求的键是否是 sys.boot_completed 本身，如果是，则直接返回其值
        // 避免在检查自身状态时陷入逻辑循环
        if ("sys.boot_completed".equals(key)) {
            return native_get(key, def != null ? def : ""); // 直接获取并返回 sys.boot_completed 的值
        }

        // 获取 sys.boot_completed 属性的值，默认值为 "0" 表示未完成
        String bootCompleted = native_get("sys.boot_completed", "0");

        // 检查系统是否已完成启动
        if (!"1".equals(bootCompleted)) {
            // 系统尚未完全启动
            // 记录警告信息，包含被请求的 key
            Log.w(TAG, "System boot not completed yet. Accessing key '" + key + "' might return default or unstable value.");

            // 在系统未启动完成时，返回默认值 'def'
            // 这是相对安全的做法，避免因访问未就绪的属性而导致崩溃
            // 注意：根据具体需求，也可以选择返回 null 或抛出特定异常，但这可能影响系统稳定性
            return def;
        }
        // --- 启动完成判断结束 ---

        // 如果系统已启动完成，则正常获取并返回请求的属性值
        return native_get(key, def);
    }

    // 模拟 native_get 方法签名 (实际实现在 JNI 层)
    private static String native_get(String key, String def) {
        // 这是本地方法的实际调用处，这里只是占位符
        // return /* actual native call */;
        // 在实际 AOSP 代码中，这里会调用到 C++ 实现
        // 为演示目的，假设它能正常工作
        if (System.getProperty(key) != null) {
             return System.getProperty(key);
        }
        return def;
    }

    // 模拟 onKeyAccess 方法 (如果 TRACK_KEY_ACCESS 为 true 时使用)
    private static void onKeyAccess(String key) {
        // Log.d(TAG, "Accessed key: " + key);
    }

    // ... 其他 SystemProperties 方法 ...
}

代码逻辑解释

日志标签： 定义了 `TAG` 用于 Logcat 输出。
避免递归检查： 首先检查请求的 `key` 是否就是 `sys.boot_completed` 本身。如果是，直接调用 `native_get` 返回其当前值，避免无限循环。
获取启动状态： 使用 `native_get("sys.boot_completed", "0")` 获取启动状态属性。提供默认值 "0" 确保即使属性尚未设置，代码也能正常工作。
判断状态： 检查 `bootCompleted` 的值是否为 "1"。
未启动处理： 如果值不为 "1"，表示系统尚未完成启动。此时，代码会：
- 打印一条警告日志到 Logcat，提示开发者此时访问属性可能存在风险。
- 返回传递给 `get` 方法的默认值 `def`。这通常是比较安全的选择，因为它允许调用者处理默认情况，而不是让系统因异常而崩溃。
已启动处理： 如果值为 "1"，表示系统已启动完成，代码继续执行 `native_get(key, def)`，正常获取并返回用户请求的属性值。
`native_get` 说明： 请注意，代码示例中的 `native_get` 是一个占位符。在实际的 AOSP 源代码中，这是一个 JNI (Java Native Interface) 调用，它会执行底层的 C/C++ 代码来读取系统属性。

修改核心 AOSP 组件的考量因素

直接修改像 `SystemProperties.java` 这样的 Android 核心框架组件需要仔细评估多方面因素。下面的图表从几个关键维度比较了进行此类修改时需要考虑的潜在影响和挑战。

此雷达图比较了两种策略：“直接修改 SystemProperties.get” 与 “在需要的地方（调用处）添加检查”。直接修改核心方法可能引入更大的稳定性、安全性和兼容性风险，且测试和维护更复杂。而在调用方进行检查虽然可能导致代码重复，但通常对系统的整体影响较小，更易于测试和维护，也更符合分层架构的思想。

重要注意事项与 Android 14 上下文

性能影响

每次调用 `SystemProperties.get` 时，都会增加一次额外的 `native_get("sys.boot_completed", ...)` 调用。虽然读取系统属性通常很快，但在高频率调用的场景下（例如，在系统服务的循环或频繁事件处理中），这种微小的开销累积起来可能会产生影响。需要进行性能分析以确定实际影响。

安全性和权限

SELinux

系统属性的访问受到 SELinux (Security-Enhanced Linux) 策略的严格控制。虽然 `sys.boot_completed` 通常是允许被广泛读取的属性，但如果您修改了 AOSP，需要确保相关的 SELinux 策略（通常在 `system/sepolicy` 目录下）允许执行此操作的上下文（例如 `system_server` 或特定应用）读取该属性。不正确的 SELinux 配置可能导致权限拒绝 (avc: denied) 错误。

Direct Boot 模式

Android 7.0 引入了 Direct Boot 模式，允许设备在用户输入锁屏密码/图案之前启动到一个受限的环境中运行某些应用（如闹钟）。在 Direct Boot 模式下，用户数据分区仍然是加密的。`sys.boot_completed` 通常在用户解锁设备后（即退出 Direct Boot 模式）才被设置为 "1"。如果您需要在 Direct Boot 模式下运行的代码中检查启动状态，需要注意 `sys.boot_completed` 可能长时间保持非 "1" 状态。对于这种情况，可能需要关注 `ACTION_LOCKED_BOOT_COMPLETED` 广播。

Android 14 Verified Boot

Android 14 继续使用并可能增强了 Verified Boot 机制。Verified Boot 会在启动过程的每个阶段验证下一个阶段软件的加密签名，确保系统的完整性未被破坏。如果 Verified Boot 检测到问题（例如，系统分区被修改），设备可能无法正常启动或进入安全模式。在这种情况下，`sys.boot_completed` 可能永远不会被设置为 "1"。您添加的检查逻辑需要能优雅地处理这种情况（例如，通过返回默认值）。

测试

对 AOSP 核心组件的任何修改都必须进行彻底测试：

单元测试： 如果可能，为修改后的 `SystemProperties` 类编写单元测试。
集成测试： 在完整的 AOSP 构建中测试此修改，覆盖各种启动场景（正常启动、重启、工厂重置、安全模式启动等）。
压力测试： 测试高频率访问 `SystemProperties.get` 的场景，监控性能和稳定性。
CTS/VTS 测试： 运行 Android 兼容性测试套件 (CTS) 和供应商测试套件 (VTS) 以确保修改没有破坏 Android 的兼容性要求。

替代方案

如果认为直接修改 `SystemProperties.get` 的风险过高或不符合架构原则，可以考虑：

包装类/辅助方法： 创建一个辅助类或方法，封装 `SystemProperties.get` 的调用，并在该辅助方法中添加启动检查逻辑。
在调用方检查： 在真正需要确保系统已启动的服务或应用代码中，显式检查 `SystemProperties.get("sys.boot_completed", "0")` 的值，然后再进行后续操作。这使得检查逻辑更局部化，易于管理。
使用 `BroadcastReceiver`： 对于需要在启动完成后执行一次性任务的场景，注册一个接收 `android.intent.action.BOOT_COMPLETED` 广播的 `BroadcastReceiver` 是更标准的做法。

指示器	类型	设置/触发者	含义	主要用途	注意事项
`sys.boot_completed`	系统属性	`init` 进程	系统核心服务已启动，设备基本功能完整（通常在用户空间完全启动后）。	系统内部检查点，判断系统是否准备就绪。	值设为 "1" 表示完成。
`dev.bootcomplete`	系统属性	`init` 或相关服务	通常与 `sys.boot_completed` 类似或用于特定设备/阶段的指示。不如 `sys` 标准化。	某些旧版本或特定实现可能使用。	优先使用 `sys.boot_completed`。
`android.intent.action.BOOT_COMPLETED`	广播 Intent	`SystemServer` (ActivityManagerService)	系统完全启动并准备好接收用户交互后发送一次。	应用在启动后执行初始化任务（需要 `RECEIVE_BOOT_COMPLETED` 权限）。	在 `sys.boot_completed` 设置为 "1" 之后发送。需要注册 `BroadcastReceiver`。在 Android 8.0+ 对后台执行有限制。
`android.intent.action.LOCKED_BOOT_COMPLETED`	广播 Intent	`SystemServer` (ActivityManagerService)	设备在 Direct Boot 模式下启动完成时发送一次（用户尚未解锁）。	应用在 Direct Boot 模式下执行任务（需要 `RECEIVE_LOCKED_BOOT_COMPLETED` 权限，应用需标记为 `directBootAware`）。	早于 `BOOT_COMPLETED` 发送。用于需要在解锁前运行的服务（如闹钟）。

常见问题解答 (FAQ)

问题 1：`sys.boot_completed` 和 `dev.bootcomplete` 有什么区别？应该用哪个？

sys.boot_completed 是 Android AOSP 中更为标准和推荐使用的属性，用于指示系统级别的启动完成。它通常由核心的 `init` 进程在系统服务准备就绪后设置。

dev.bootcomplete（有时也写作其他变体）可能在某些特定的设备实现或较旧的 Android 版本中被用作类似的指示器，但它不是 AOSP 标准强制要求的。其行为可能因设备制造商而异。

结论： 除非有特定于设备或旧版本的理由，否则应优先使用 sys.boot_completed 来检查通用的系统启动完成状态。

问题 2：如果 `sys.boot_completed` 由于启动失败等原因从未被设置为 "1"，我的代码会怎样？

根据我们建议的修改方案：


String bootCompleted = native_get("sys.boot_completed", "0");
if (!"1".equals(bootCompleted)) {
    Log.w(TAG, "System boot not completed yet...");
    return def; // 返回默认值
}

如果 sys.boot_completed 从未被设置或其值不是 "1"，native_get 会返回默认值 "0"。因此，!"1".equals(bootCompleted) 条件将为 true。代码会记录一条警告日志，并返回传递给 get 方法的默认值 def。这意味着依赖此属性的代码不会获取到实际值，而是得到一个预设的默认值。这通常比抛出异常或返回 null（如果调用者未处理 null）更安全，可以防止因启动未完成而导致的崩溃，但调用者需要能正确处理这个默认值。

问题 3：这个修改会对接收 `BOOT_COMPLETED` 广播的应用产生影响吗？

这个修改本身不会直接影响系统发送 `BOOT_COMPLETED` 广播的行为。`BOOT_COMPLETED` 广播是由 `ActivityManagerService` 在检测到系统启动完成后发送的，这个检测逻辑通常也依赖于 `sys.boot_completed` 属性（或其他内部状态）。

但是，如果在接收 `BOOT_COMPLETED` 广播的 `BroadcastReceiver` 内部，应用代码调用了 `SystemProperties.get` 来获取其他属性，那么这个修改就会生效：

如果此时 `sys.boot_completed` 已经是 "1"（通常应该是这样，因为广播是在此之后发送的），那么 `get` 方法会正常返回请求的属性值。
如果在极少数异常情况下，广播被发送时 `sys.boot_completed` 还不是 "1"（理论上不应发生，但这可能指示系统状态异常），那么应用通过 `get` 获取属性时会收到默认值 `def`，并可能在 Logcat 中看到警告信息。

总的来说，此修改主要是增强了 `SystemProperties.get` 方法本身的健壮性，对于依赖标准 `BOOT_COMPLETED` 广播机制的应用影响不大，除非系统启动过程本身存在异常。

问题 4：直接修改 AOSP 核心代码的最佳实践是什么？

修改 AOSP 核心代码（如 `frameworks/base`）通常需要遵循一些最佳实践：

最小化修改： 尽可能减少对原始代码的改动范围。
清晰注释： 为您的修改添加详细的注释，解释修改的原因和逻辑。
考虑替代方案： 优先考虑是否可以通过配置、插件、覆盖或在更高层实现相同功能，而不是直接修改核心框架。
彻底测试： 进行全面的单元测试、集成测试和兼容性测试（CTS/VTS）。
代码审查： 让团队成员或其他有经验的 AOSP 开发者审查您的代码。
版本控制： 使用 Git 等版本控制系统管理您的修改，并与 AOSP 的更新保持同步。
性能分析： 评估修改对系统性能（CPU、内存、启动时间）的影响。
遵循架构： 尽量使您的修改符合 Android 的现有设计模式和分层架构。如此处讨论的，将检查逻辑放在调用方可能比修改通用 `get` 方法更符合分层原则。

非必要不修改核心框架是基本原则。如果必须修改，务必谨慎评估并严格测试。