何时使用DONT_KILL_APP标识禁用Android组件是安全的？

默认调用PackageManager.setComponentEnabledSetting()修改组件状态时，系统会主动杀死应用所在进程，目的是清除所有已加载的组件状态缓存，确保全系统的组件状态统一。传入DONT_KILL_APP的作用就是跳过杀进程的步骤，让应用继续运行。

官方提到的「行为不可预测」的具体风险如下：

设置此标识时需谨慎，因为修改组件状态可能会导致所属应用的行为不可预测

这句话对应的实际问题只有三类：

• 组件状态临时不一致：系统存储的组件持久化状态已经更新，但当前进程内的组件状态缓存还没同步，短时间内可能出现查询组件状态返回旧值、或者已经禁用的组件还能收到广播/被启动的情况，这个状态同步的延迟一般在几秒以内，进程重启后状态就会完全统一。
• 多进程状态不同步：如果你的应用使用了多进程，只有调用这个方法的进程不会被杀，其他进程的组件状态缓存不会主动同步，会出现不同进程读到的组件状态不一致的问题。
• 正在运行的组件逻辑异常：如果你修改的是当前正在运行的Activity、Service等组件的状态，且这些组件后续的逻辑依赖系统返回的组件状态判断，可能会出现逻辑异常。

安全的适用场景 #

只要符合以下任意一种情况，使用DONT_KILL_APP都是完全安全的，可直接在生产环境使用：

• 你修改状态的组件，不会在当前应用进程的剩余生命周期内被访问或触发：比如你现在要禁用的静态注册BOOT_COMPLETED广播接收器，这个广播只有设备开机时才会触发，本次进程运行期间根本不会收到这个广播，就算存在临时状态不一致也完全不影响，下次开机进程重启后状态已经是最新的，完全符合使用要求。
• 你不需要依赖系统返回的组件状态做业务逻辑：你自己的业务代码里会维护组件的启用/禁用标记，不会调用getComponentEnabledSetting()查询系统状态，也不会主动尝试启动已经被你修改过状态的组件，临时的状态不一致不会影响你的业务。
• 你的应用是单进程架构，且修改的是未在运行的非活跃组件：比如你测试的在onReceive()或者Activity中调用禁用广播接收器的场景，都是完全安全的，这类用法已经在大量生产级应用中验证过没有问题。

内容的提问来源于stack exchange，提问作者pedh7