背景介绍：客户给了定制的launcher，要求在设备上启动他们的launcher，实现过程中出现的问题是 开机引导还没走完，launcher就会自己弹出来打断开机引导，按道理来说launcher是在开机引导结束后，由开机引导通过intent启动才对。看了log之后发现是客户launcher监听了BOOT_COMPLETED广播实现了开机自启动导致了问题。
像这种情况，开机引导还没走完，客户给的应用就开机自启动了，肯定是不行的，我们怎么在framework层禁止呢？下面给出一种实际可行的修改方式。
注：Android 每个大版本断层严重，本文章只针对Android 11 ，其它版本不一定适用，读者需自己斟酌一下。类似的文章还有 Android系统层面限制应用开机自启动详解
一、分析过程
做framework层的修改，最好的思路是 找到相关log——>找到相关代码——>理解相关代码——>修改相关逻辑实现需求。很多人会走错路，一遇到问题就直接去搜某个模块的代码流程梳理博客来看，结果就是看半天看懵逼了，花了很多时间，结果还是不知道从何下手，浪费时间，原因是Android的代码调用了太多层，像这种代码启动流程平时看看就可以了，但绝对不是一个合理的系统层开发手段。这些都是血淋淋的教训，切记。 相关日志如下：
BroadcastQueue: Permission Denial: receiving Intent { act=android.intent.action.BOOT_COMPLETED flg=0x89000010 (has extras) } to com.xinjing.hotel/com.mydlna.application.DmpBroadcastReceiver requires ...
找到这段打印的位置：
frameworks\base\services\core\java\com\android\server\am\BroadcastQueue.java
final void processNextBroadcastLocked(boolean fromMsg, boolean skipOomAdj) {
. . . . . .
. . . . . .
. . . . . .
perm = PackageManager.PERMISSION_DENIED;
}
if (perm != PackageManager.PERMISSION_GRANTED) {
Slog.w(TAG, "Permission Denial: receiving "
+ r.intent + " to "
+ component.flattenToShortString()
+ " requires " + requiredPermission
+ " due to sender " + r.callerPackage
+ " (uid " + r.callingUid + ")");
. . . . . .
. . . . . .
. . . . . .
看了一下附近的逻辑，BroadcastQueue是负责发送广播的类，不管是系统还是上层应用发送广播都会调用到它，这里的意思是com.xinjing.hotel 监听了BOOT_COMPLETED广播，给com.xinjing.hotel 发送，那么思路就来了，可不可以在这里做截断呢？下面看看具体实现。
二、修改
在代码如下位置加入注释//xuhao之间的代码即可。
frameworks\base\services\core\java\com\android\server\am\BroadcastQueue.java
final void processNextBroadcastLocked(boolean fromMsg, boolean skipOomAdj) {
. . . . . .
. . . . . .
. . . . . .
ResolveInfo info = (ResolveInfo)nextReceiver;
ComponentName component = new ComponentName(
info.activityInfo.applicationInfo.packageName,
info.activityInfo.name);
//xuhao
if(component.flattenToShortString().contains("com.xinjing.hotel")) {
Slog.w(TAG,"component.flattenToShortString "+component.flattenToShortString());
Slog.w(TAG,"r.intent.toString "+r.intent.toString());
}
if(component.flattenToShortString().contains("com.xinjing.hotel")) {
if(r.intent.toString().contains("android.intent.action.BOOT_COMPLETED") || r.intent.toString().contains("android.intent.action.MEDIA_MOUNTED") ){
Slog.w(TAG,"tongzhouzhixing return");
return;
}
}
//xuhao
上述代码修改解释：客户给的launcher com.xinjing.hotel，开机自启动监听了两个广播android.intent.action.BOOT_COMPLETED、android.intent.action.MEDIA_MOUNTED，屏蔽掉即可禁止该应用开机自启动。
三、思维发散
上述的方案不完美但是可用，完美的方案是开机引导结束后设置一个系统属性为1，该属性初始值为0，伪代码如下：
if(component.flattenToShortString().contains("com.xinjing.hotel")&& persisit.me.xuhao == 0) {
if(r.intent.toString().contains("android.intent.action.BOOT_COMPLETED") || r.intent.toString().contains("android.intent.action.MEDIA_MOUNTED") ){
Slog.w(TAG,"tongzhouzhixing return");
return;
}
}
这样能保证只在开机引导没完成前对应用有限制，完成后不对应用限制，逻辑得到完善。开发时间急就用上面现成的，不急就完善下。
这个地方还可以做成读取配置文件的方式，xml里配置一堆需要禁止开机自启动的应用，这里读取xml文件解析，在开机引导没有完成前对所有xml中的APP做出限制，客户需求大的话，这样做最好。
