Android自定义开机引导最强篇

本文基于Android 10

Andoid开机引导应的本质是一个具有android.intent.category.HOME属性的Launcher，在Pixel手机上，作为开机向导的应用是Google的com.google.android.setupwizard应用，这是谷歌的应用，代码不在AOSP中，在AOSP中有一个包名为com.android.provision的应用供厂商定制开机向导，该应用在源码中的位置是packages\apps\Provision，所以我们注意Provision应用做了些什么就好了，这个应用只做了两件事，第一：设置相关属性让自己早于Launcher起来；第二：设置开机引导已经走完的标记位。
具体代码实现，让自己的应用比Launcher先起来的方式，Provision在Manifest中做的：

除了Manifest中的内容，系统还做了一步才让Provision比Launcher先启动，就是将Provision内置到/system/product/priv-app/目录下，这是因为不在这个目录下的应用设置android:priority属性会被重置为0，至于启动优先级的细节可以再详细阅读Android系统启动Launcher的源码，切入点在com.android.server.am.ActivityManagerService#systemReady()方法中,参考文章：HomeLauncher启动、Launcher的启动过程等，这里不做展开叙述，画重点：

当自己写Demo代替Provision在Android Studio上跑起来而不是以系统应用集成在Rom的时候，自己Demo的Activity设置如上属性后并不会比Launcher先启动，这是因为不在/system/product/priv-app/目录下的应用设置了android:priority后依然会被置为0，优先级也不会高于Launcher，解决方法：
1. 直接将Demo打进系统/system/product/priv-app/目录下（正式编译Rom时用）
2. 如果Launcher的代码在自己手上就把Launcher的android:priority设置为-1。（仅在Android Studio上编译做验证时用）
添加 android:sharedUserId=“android.uid.system” 不生效
手动安装方式不生效（这个要注意，即使已经打进Rom了，这个时候再添加一个不同android:priority等级的Activity重新安装，这个新添加的Activity也不会有相应的android:priority等级）

再来看启动之后Provision的DefaultActivity中做了什么，代码非常简单：

public class DefaultActivity extends Activity {

    @Override
    protected void onCreate(Bundle icicle) {
        super.onCreate(icicle);

        // 添加持久设置以允许其他应用程序知道设备已配置。
        Settings.Global.putInt(getContentResolver(), Settings.Global.DEVICE_PROVISIONED, 1);
        //这个标记位标识当前用户已经走完引导流程，如果不设置这个值，Home键、锁屏等将不可用
        Settings.Secure.putInt(getContentResolver(), Settings.Secure.USER_SETUP_COMPLETE, 1);

        // 从PackageManager中禁用该Activity。
        PackageManager pm = getPackageManager();
        ComponentName name = new ComponentName(this, DefaultActivity.class);
        pm.setComponentEnabledSetting(name, PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
                PackageManager.DONT_KILL_APP);

        finish();
    }
}

可以看到DefaultActivity中具体做了如下操作：

设置相关标记位
将该Activity禁用
finish自己

设置相关标记位可以让其他服务知道设备可用，如锁屏服务可用，启用Home键功能等，将该Activity禁用可以让下次开机时我们的应用不会再起来而直接启动桌面，finish就不用做解释，开机引导走完了就该销毁自己了。
自己写Demo测试时这一步需要注意的点，设置Settings.Global.DEVICE_PROVISIONED和Settings.Secure.USER_SETUP_COMPLETE两个属性需要添加如下两个权限：

如果引用不到Settings.Global.DEVICE_PROVISIONED和Settings.Secure.USER_SETUP_COMPLETE就直接写字符串device_provisioned和user_setup_complete。

如上需要实现我们自己业务的Android开机向导就只需要将Provision的代码移到自己的项目，走完我们自己的引导流程后设置相关属性，然后把Provision从编译的Rom移除就行了，或者直接在Provision应用里写自己的业务，另外调试的时候因为开机向导只会走一次，所以调试起来会比较麻烦，我们可以通过adb命令重置属性方便调试：

1.通过如下命令使能进入开机向导
adb shell
settings put global device_provisioned 0
settings put secure user_setup_complete 0
//开启Provision应用的DefaultActivity
pm enable com.android.provision/com.android.provision.DefaultActivity
//或者
//开启Demo的MainActivity
pm enable com.xzzbz.setupdemo/com.xzzbz.setupdemo.MainActivity
sync
//重启
reboot

2.查询settings的值
settings get global device_provisioned
settings get secure user_setup_complete

3.通过代码实现
Settings.Global.putInt(mContext.getContentResolver(), Settings.Global.DEVICE_PROVISIONED, 0);
Settings.Secure.putInt(mContext.getContentResolver(), Settings.Secure.USER_SETUP_COMPLETE, 0);
ComponentName name = new ComponentName("com.android.provision", "com.android.provision.DefaultActivity");
mContext.getPackageManager().setComponentEnabledSetting(name,PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP);

这里通过adb命令设置属性的时候有一点需要注意，每一步adb命令执行后需要等几秒，比如执行pm enable com.xzzbz.setupdemo/com.xzzbz.setupdemo.MainActivity后没有等几秒直接执行sync和reboot的话开机向导还是会起来，应该是需要时间同步状态。

在有的应用中可能需要对用户是否走完开机引导流程做判断，例如语音助手中判断用户走完了开机引导流程才响应语音唤醒，我们可以取开机引导中设置的标记位做判断，这是个系统标记位，可以在不同应用中取到值，示例如下：

if (Settings.Secure.getInt(mContext.getContentResolver(), Settings.Global.DEVICE_PROVISIONED, 0) == 1) {
  //开机引导走完了,走正常业务逻辑
} else {
  Log.e(TAG, "收到了唤醒，但是开机引导没走完，不做通知");
}

援引：
Google开机向导解析
android开机向导的实现
Android 自定义开机向导踩坑
Android10定制Google开机向导
Android 9.1 定制开机向导
Android 8.1自定义开机向导
Android7.1 应用组件添加intent-filter priority(优先级)不生效
另：
android系统开机向导无法启动数据进行上网

Android自定义开机引导最强篇

你可能感兴趣的:(Android自定义开机引导最强篇)