做Android系统定制的人，几乎都会遇到一个需求：设备开机后必须直接进入指定的桌面。无论是医院自助终端、车载中控、酒店大屏，还是政企定制的平板盒子，Android 13上“设置默认Launcher”这件事绕不开，但坑也确实多。我在某方案商的定制项目中处理过类似问题，一开始以为跟Android 9一样直接改个priority、或者设一下默认Activity就行，结果在Android 13上踩了一路坑。这篇文章把我实际用过的几种方案、以及每个方案的原理和排查经验梳理一下，给准备做Android 13设备定制、拉ROM包改预设桌面的朋友做一个参考。

1. 为什么Android 13设置默认Launcher没有想象中简单

1.1 需求场景：不只是“换个桌面”

先看几个真实场景。某项目要做一台医院自助挂号机，设备开机后必须自动进入医院定制的自助服务平台，用户不能回到系统自带桌面；某车载方案商的Android 13中控盒子，要求开机直接进入定制车载桌面，而不是AOSP原生的Launcher；还有政企项目里的平板，要锁死到一个安全桌面，防止用户乱装应用、乱改设置。

这些需求听起来就是“把默认桌面换成我的App”，但真正动手时会发现，Android 13跟旧版本的机制差异很大。比如早期Android版本里，给Launcher的Manifest声明里加上：

<intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.HOME" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter>

然后加一个android:priority，系统就会优先选择它作为默认桌面。但Android 8.0之后这个行为变了，priority不再被系统作为HOME Intent解析的决策依据。到了Android 10引入角色（Role）管理机制后，设置默认Launcher的底层逻辑已经变成“系统把HOME这个角色分配给某个包”。

所以Android 13上讨论设置默认Launcher，首先得适应Role这个概念，而不是继续抱着老一套Priority的思路不放。

1.2 Android 13的默认应用机制：从Priority到Role

Android 13继续沿用并强化了Android 10引入的RoleManager机制。系统把一类默认行为抽象成“角色”，比如浏览器角色、拨号角色、短信角色，以及我们关心的HOME角色。系统在开机或者安装应用时，会综合分析各应用声明的Intent Filter、系统预设值、用户历史选择等，最终把角色分配给具体的包名。这个分配结果会持久化存储，后续所有需要解析HOME Intent的操作，都会优先交给该角色持有者。

听起来有点绕，打个比方：系统里的“默认桌面”就像公司里一个“前台接待”的岗位，Intent过来时说“我要找前台”，系统直接把这个接待任务分配给已经入职的那个App。原来那个老办法priority只是在简历上写“我优先级高”，但在Android 13这套招聘体系里，HR（RoleManager）根本不看这一行了。

因此，设置默认Launcher的方案可以分成几条路：编译期直接写死System Default值、运行时通过RoleManager分配角色、把Launcher做成persistent常驻并且排他性地成为唯一候选、以及通过DeviceOwner的持久化偏好绑定。下面我逐个拆。

2. 方案一：编译期静态配置（改config_defaultHome）

2.1 修改方法，两步到位

第一种思路，也是最直白的一种：既然系统需要知道“默认桌面是谁”，那就在系统资源里把默认值写死。Android 13的frameworks/base/core/res/res/values/config.xml中有一个关键字符串：

<string name="config_defaultHome">com.example.launcher/com.example.launcher.MainActivity</string>

格式是“包名/完整类名”的ComponentName扁平化写法，注意类名一定要写完整的，不要只写一个MainActivity。改完之后，系统在进行首次HOME角色分配时，会优先参考这个预设值，把该组件作为默认Home的候选。

实际操作时有两步。第一步，在源码的overlay资源目录（或者直接改config.xml）中加入这个配置；第二步，确保Launcher包本身已经被预置进系统分区，或者至少是PRODUCT_PACKAGES里的必装应用。如果Launcher根本没装进去，改了这个字符串也不会生效，HOME Intent还是会解析到别的桌面去。

2.2 为什么有人改了还是弹选择器

这大概是反馈最多的问题：明明改好了config_defaultHome，开机后按Home键，系统还是弹出选择器，让用户选“用哪个桌面”。原因很实在——config_defaultHome只是一个“建议值”，不是“强制绑定值”。如果系统里同时还存在另外的Launcher（比如AOSP自带桌面、或者厂商预置的另一个桌面），并且它们都声明了HOME相关的Intent Filter，那系统在第一次解析时仍然可能把这个岗位当作“待分配”，弹窗让用户选择。用户一旦选了另一个，系统就把角色给了别人，你的预设值就被覆盖了。

这个行为逻辑上是合理的：系统需要考虑用户可能在多个桌面间切换的需求。但在设备定制场景里，这种“合理”恰恰是我们不想要的。所以操作上要同时做两件事：一是确保目标Launcher之外没有其他声明了android.intent.action.MAIN加android.intent.category.HOME的应用；二是在系统首次开机时，通过Provision或者其他系统服务把Home角色固定到这个Launcher上。如果只是单改配置而不处理其他候选，那弹选择器就一点都不意外。

2.3 overlay方式的工程建议

直接改frameworks/base/core/res/res/values/config.xml很容易，但在项目交付和OTA升级时非常痛苦——每次同步新版本源码都要重新patch，还容易冲突。更推荐的做法是用Android 13的资源覆盖（RRO）机制，单独建一个overlay包，像这样：

<resources> <string name="config_defaultHome">com.example.launcher/com.example.launcher.MainActivity</string> </resources>

把覆盖文件放到vendor/overlay/XXXOverlay/res/values/config.xml，然后在产品配置里加进PRODUCT_PACKAGES_OVERLAYS。这样源码主干不需要动，升级时只要overlay包还在，配置就一直生效。这个习惯我后面所有定制项都沿用了，省了很多维护上的麻烦。

3. 方案二：运行时用RoleManager设置

3.1 原理：角色（Role）的一锤定音

如果你做的不是ROM，而是基于已经出厂的Android 13设备做应用层定制，那就没法改源码配置了。这时候要走的API是RoleManager。Android 13上，系统设置“默认桌面”最终落地的操作，就是把android.app.role.HOME这个角色分配给你指定的包。普通应用想设置默认桌面，可以弹系统授权框让用户确认，代码大致长这样：

RoleManager roleManager = getSystemService(RoleManager.class); Intent intent = roleManager.createRequestRoleIntent(RoleManager.ROLE_HOME); startActivityForResult(intent, REQUEST_CODE_SET_HOME);

用户弹窗点“允许”后，你的Launcher就被设为系统默认桌面。这个流程最适合做“首次启动引导”：设备第一次开机后，我们的引导App调用这个接口，用户点一下确认，系统角色就交出去了。之后按Home键、开机自启，系统都会直接拉起该Launcher。好处是不依赖系统源码，普通签名的应用也能用；缺点是必须有人去点那一下确认。

3.2 ADB调试验证方法

开发阶段调试、验证当前HOME角色被谁持有，最方便的还是ADB命令。Android 13上常用的两条：

# 直接分配HOME角色 adb shell cmd role add-role-holder android.app.role.HOME com.example.launcher # 查看当前角色持有者 adb shell cmd role get-role-holders android.app.role.HOME

这两条命令在调试时非常有用。add-role-holder本质上就是在系统没弹窗、不经过用户交互的情况下，直接把角色塞给指定包。实际项目中我通常先手工用这条命令验证Launcher本身没问题，再回到代码里走正规流程。

验证解析结果，还可以用：

adb shell cmd package resolve-activity --brief -a android.intent.action.MAIN -c android.intent.category.HOME

输出如果只有一个包名/Activity名，说明默认桌面已经稳定绑定；输出如果带多个候选，说明系统大概率还会弹选择器。这个命令在Android 13上仍然可用，排查“为什么没有生效”时建议第一时间跑一下。

3.3 系统应用代码动态设置

如果你的项目本身就是系统应用、对稳定性要求高，可以直接绕过用户弹窗，在开机阶段调用addRoleHolderAsUser来设置。Android 13上大致写法：

RoleManager roleManager = getSystemService(RoleManager.class); ComponentName homeComponent = new ComponentName(context, LauncherActivity.class); roleManager.addRoleHolderAsUser( RoleManager.ROLE_HOME, homeComponent, 0, UserHandle.CURRENT, new RoleManager.ManagedPreSetRoleUserCallback() { @Override public void onSuccess(@NonNull Bundle resultData) { // 分配成功 } @Override public void onFailure(@NonNull Bundle resultData) { // 分配失败 } });

这里注意几个细节。addRoleHolderAsUser在Android 13上操作的是指定用户下的角色，默认UserHandle.CURRENT就是当前用户；如果设备开了多用户、工作资料，或者有多Profile场景，还需要分别在对应的UserHandle下再设置一次。另外，普通应用直接调用这个API大概率会抛SecurityException，需要系统签名权限（对应MANAGE_ROLE_HOLDERS），这也是为什么它只适合系统签名的预置应用使用。

4. 方案三：Persistent模式与锁桌面

4.1 persistent属性到底是什么，以及限制

Android 13的Launcher要让设备真正做到“不可被替换”，甚至用户去设置里都换不掉，光设置默认角色往往还不够。很多商用终端要求桌面进程必须常驻、崩溃后自动拉起、不允许用户强行停止。于是有人想到了Manifest里那个经典属性android:persistent="true"。

<application android:persistent="true" android:label="KioskLauncher"> ... </application>

persistent属性的意思是：拥有此属性的应用会由系统进程主动启动，并处于常驻状态；它的进程被杀后会由系统立即重启；并且在系统内存紧张时，非persistent应用可以被杀掉腾出资源，而persistent应用不在这个范围内。

这里要先打破一个常见误解：给Launcher加persistent并不会自动把它设为默认桌面。它是“常驻应用”，不是“默认Home角色”。如果你只改这一项，开机后桌面进程确实活着，但按下Home键时系统仍可能把HOME Intent交给另外一个Launcher。要真正锁死桌面，必须把“常驻”和“默认”两件事都做了。

4.2 真正锁死桌面的组合拳

我参与过的某自助终端项目里，当时的组合是这样的：

第一，在Launcher的Manifest里声明persistent属性，并且保证应用是系统预置应用、带平台签名。普通应用就算声明了persistent也会被忽略，这是Android系统的硬性校验。

第二，把竞争对手全部禁掉。系统里如果有其他Launcher或者带Home category的应用，通过PackageManager.setApplicationEnabledSetting把它们禁用：

PackageManager pm = getPackageManager(); pm.setApplicationEnabledSetting( "com.android.launcher3", PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP);

禁用掉其他候选之后，就算系统不做角色分配，按Home键时能响应的也只有一个桌面，系统别无选择只能拉起它。这个方式的效果非常接近“锁死”。

第三，还是推荐配合RoleManager把HOME角色固定给自己，避免系统在特定场景下重新扫描候选应用时又弹一次选择器。

这套组合拳下来，设备开机后桌面必然启动，进程被强杀也会自动拉起，用户几乎没有任何路径可以切走。但副作用也很明显，见下节。

4.3 这种方案的风险与适用边界

persistent不是免死金牌，反而是一把双刃剑。Launcher一旦加了persistent，进程就必须非常稳定。如果桌面App在启动过程中崩溃，系统会不断尝试拉起它，拉起又崩、崩了又拉起，轻则死循环，重则影响开机流程，甚至可能卡在启动界面反复无常。所以代码质量、初始化逻辑、第三方SDK的稳定性都要额外把关，最好在方案阶段就确定“这个桌面能不能承受persistent级别的要求”。

另外，persistent应用由于不会被系统主动杀，它的内存占用也会一直留存。多任务场景下用户会觉得系统卡、费电，因为其他应用能用的内存更少了。协议里说的“不被杀”是保护机制，不是免费特权。

所以我一般只在自助终端、单一功能设备这类不需要频繁切换任务的场景里推荐persistent方案。普通的手机、平板、追求日常体验的设备，设完默认角色就够了，没必要上persistent。

5. 方案四：DeviceOwner + addPersistentPreferredActivity

5.1 DeviceOwner的持久化绑定流程

还有一类场景：设备是企业MDM管理的、或者走的是DeviceOwner模式。Android 13上，如果一个应用被设置为设备所有者（DeviceOwner），可以对系统做更底层的策略控制，其中包括把一个IntentFilter持久化绑定到指定Activity。相关API是DevicePolicyManager.addPersistentPreferredActivity(ComponentName admin, IntentFilter filter, ComponentName activity)。

这种方式的特点在于“持久化偏好”：它比普通默认应用优先级更高，而且不会轻易被用户设置或安装新应用冲掉。即使系统里同时存在多个Launcher，系统解析HOME Intent时也会直接命中绑定的那个Activity。Android 13官方虽然弱化了一些旧API，但addPersistentPreferredActivity在设备所有者场景下仍然可以工作。

要把应用设为DeviceOwner，常见有两种方式：一是设备出厂前在Provision阶段通过dpm set-device-owner命令指定；二是通过企业级MDM服务器下发策略。开发调试时最快的方式是：

adb shell dpm set-device-owner com.example.admin/.AdminReceiver

注意执行这条命令前，设备上不能有其他已登录的账户，而且有些应用（包括部分Launcher）也会干扰DeviceOwner设置。报错的话清理一下账户、恢复出厂再试。

5.2 代码与验证

在DeviceOwner管理应用里，绑定HOME Intent的代码大致是这样：

DevicePolicyManager dpm = (DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE); ComponentName admin = new ComponentName(context, AdminReceiver.class); ComponentName launcher = new ComponentName(context, LauncherActivity.class); IntentFilter homeFilter = new IntentFilter(Intent.ACTION_MAIN); homeFilter.addCategory(Intent.CATEGORY_HOME); homeFilter.addCategory(Intent.CATEGORY_DEFAULT); dpm.addPersistentPreferredActivity(admin, homeFilter, launcher);

绑完之后，验证方式跟前面类似：

adb shell cmd package resolve-activity --brief -a android.intent.action.MAIN -c android.intent.category.HOME

如果输出一直是你的Launcher组件，说明绑定生效。要注意的是，addPersistentPreferredActivity设置的绑定并不是永久固化的，恢复出厂设置会被清掉，OTA升级也可能因为策略变更而产生偏移。所以DeviceOwner方案通常要和MDM策略联动，比如设备上线后由服务器重新下发一次绑定策略，而不是完全依赖本地一次性设置。

6. 常见问题排查速查表

实际项目里遇到过的典型问题，我整理成了一个速查表，Android 13定制设备设置Launcher时可以直接对照排查。

6.1 多用户场景的坑

Android 13对多用户的隔离做得更彻底。如果你只在主用户下设置默认Launcher，切换到访客用户、工作资料用户时，系统会按照那个用户自己的角色分配去解析HOME Intent。换句话说，每个用户下都要单独设置，不能默认主用户配好了全局生效。做定制时如果设备需要多用户切换，一定记得在用户切换、创建的逻辑里也做一次角色分配。

6.2 排查命令的优先级

很多问题的排查路径其实是有固定顺序的。我演示一下个人习惯：先跑get-role-holders确认角色是谁，再跑resolve-activity确认Intent解析到谁，最后跑dumpsys package看预置和禁用状态。按这个顺序基本能把问题缩小到“角色没分配”“组件没预置”“Intent解析到别人”三个方向。不要一开始就去翻源码，浪费时间。

7. 实操经验与个人总结

最后分享一套我在实际项目里沉淀下来的选择逻辑，希望能给你一个比较清晰的决策路径。

如果项目是普通手机/平板，只是希望开机默认进定制桌面，用户仍然可以手动改回系统桌面，推荐方案二，用RoleManager在首次开机引导阶段弹窗或直接分配角色。这种方式对系统侵入最小，日常升级影响也小。

如果项目是自助终端、车机、单一功能设备，且桌面不允许被切换、进程不允许被杀，推荐方案三的“persistent + 禁用其他候选 + RoleManager分配”组合。但这个组合只适合真正需要封闭环境的设备，开发测试时务必做好崩溃恢复验证，不然桌面的一个小崩溃可能把开机流程拖进死循环。

如果是企业MDM管理的设备，推荐方案四，走DeviceOwner + addPersistentPreferredActivity。这种方式管理面更统一，策略下发、状态上报都跟企业后端打通，比本地硬编码更可持续。

我个人在实际工程中更常用“方案一打底、方案二补刀”的组合：config_defaultHome保证第一轮开机时系统有一个稳定的建议值，再由开机初始化逻辑调用RoleManager把角色真正固定到目标Launcher。这样既控制了首启体验，又不会因为加persistent而产生不必要的系统稳定风险。等后续产品要求升级成纯封闭终端时，再叠加方案三也不迟。

如果你也在做Android 13的设备定制，希望这篇记录能帮你少踩几个坑。Launcher设置只是定制工作的第一关，后面还有开机向导、默认输入法、默认浏览器等一系列同性质问题，理解了Role机制的处理套路，这些问题都可以举一反三。