安卓开机重启需要哪个系统权限？

Question

在Android系统开发中，实现设备开机或重启功能需要特定的系统权限。常见的问题是：应用调用重启接口时抛出`SecurityException`异常，提示“Permission denial”。这是由于开发者未正确获取`REBOOT`系统权限所致。`android.permission.REBOOT`是用于执行重启操作的系统级权限，普通第三方应用无法申请，仅限于系统应用或具有root权限的应用使用。此外，在部分定制ROM中还可能涉及`android.permission.RESTART_PACKAGES`或`android.permission.SHUTDOWN`等权限。因此，实现重启功能不仅需要在AndroidManifest.xml中声明相应权限，还需将应用预置在system分区或获取root权限。这使得在非系统应用中安全、合法地实现重启功能成为常见技术难题。

Answer 1

一、Android系统中重启功能的权限机制与挑战

在Android系统开发中，实现设备开机或重启功能是一项涉及系统底层操作的任务。这类操作通常由系统服务（如PowerManagerService）控制，并通过Binder IPC机制对外提供接口。

当应用尝试调用android.os.PowerManager.reboot(String reason)方法时，系统会检查调用者是否具备android.permission.REBOOT权限。若权限缺失，则抛出SecurityException异常，提示“Permission denial”。

1.1 权限分类层级解析

• Normal Permissions：普通权限，安装即授予。
• Dangerous Permissions：危险权限，需运行时请求。
• Signature Permissions：签名级权限，要求应用与系统使用相同证书签名。
• SignatureOrSystem Permissions：仅系统分区或签名匹配的应用可获得。

其中，android.permission.REBOOT属于signatureOrSystem级别权限，意味着第三方应用即使在AndroidManifest.xml中声明也无法获取。

1.2 常见错误场景分析

错误现象	根本原因	日志关键词
SecurityException: Permission denial	未拥有REBOOT权限	java.lang.SecurityException
Method returns without effect	空reason参数或非法调用上下文	W/PowerManager: reboot called with null reason
No response after reboot()	应用未预置于/system/app或/system/priv-app	E/ContextImpl: Failed to get package info
Shutdown instead of reboot	调用了SHUTDOWN权限接口且设备不支持热重启	I/BootReceiver: android.intent.action.SHUTDOWN

二、深入系统源码视角看权限校验流程

以AOSP源码为例，PowerManager.reboot()最终调用的是IPowerManager.aidl中的远程接口，其实现在PowerManagerService.java中：

@Override
public void reboot(boolean confirm, String reason, boolean wait) {
    // 权限校验起点
    mContext.enforceCallingOrSelfPermission(android.Manifest.permission.REBOOT, null);

    final long token = Binder.clearCallingIdentity();
    try {
        if (PowerManager.REBOOT_RECOVERY.equals(reason)) {
            Log.i(TAG, "Rebooting into recovery mode");
        }
        shutdownOrRebootInternal(HALT_MODE_REBOOT, confirm, reason, wait);
    } finally {
        Binder.restoreCallingIdentity(token);
    }
}
    

上述代码中enforceCallingOrSelfPermission是关键校验点。只有满足以下任一条件才能通过：

1. 调用进程具有REBOOT权限且已授权；
2. 应用位于/system/priv-app目录下；
3. 应用使用平台密钥（platform.pk8 + platform.x509.pem）签名；
4. 设备已root，且通过su执行命令绕过SELinux限制。

三、可行的技术路径与适配策略

针对不同使用场景，开发者可选择如下方案：

3.1 系统应用预置方案（推荐用于定制ROM）

将应用打包为系统应用并放置于/system/priv-app/<PackageName>目录，同时使用与系统镜像一致的密钥进行签名。示例构建脚本片段：

# 使用signapk.jar对APK进行平台签名
java -jar signapk.jar platform.x509.pem platform.pk8 app-unsigned.apk app-signed.apk

# 推送至系统分区
adb remount
adb push app-signed.apk /system/priv-app/MyRebootApp/
    

3.2 Root权限调用Shell命令（适用于调试或特定工业设备）

利用su执行底层reboot命令：

public static void rebootDevice() {
    try {
        Process process = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(process.getOutputStream());
        os.writeBytes("reboot\n");
        os.flush();
        os.close();
        process.waitFor();
    } catch (Exception e) {
        Log.e("Reboot", "Failed to execute reboot", e);
    }
}
    

四、权限扩展与厂商差异性处理

部分国产ROM（如MIUI、EMUI）引入了额外权限机制：

• android.permission.RESTART_PACKAGES：允许终止并重启指定包名进程（非整机重启）；
• android.permission.SHUTDOWN：关机权限，部分设备支持带参数重启；
• 厂商私有API：如华为提供的HwShutdownManager类。

应对策略包括：

1. 动态检测ROM类型（通过Build.MANUFACTURER）；
2. 反射调用厂商特定API；
3. 结合JNI层调用libc库函数__reboot()；
4. 使用AccessibilityService模拟电源键长按（受限但无需权限）。

五、安全边界与合规性考量

从安全模型角度看，Android通过多层机制防止恶意应用滥用重启能力：

graph TD A[App调用reboot()] --> B{是否持有REBOOT权限?} B -- 否 --> C[抛出SecurityException] B -- 是 --> D{是否在system分区?} D -- 否 --> C D -- 是 --> E{签名是否匹配?} E -- 否 --> C E -- 是 --> F[执行shutdown_or_reboot()] F --> G[内核触发reboot系统调用]

此外，SELinux策略进一步限制域间访问。例如，在untrusted_app域中无法执行reboot系统调用，必须切换至init或system_app域。