Android短信拦截机制适配的坑(上)--4.4以下系统

最近项目遇到短信拦截的问题,新短信到达以后,项目app希望可以提示用户未读短信的数据,并且可以将短信置为已读。

这个可能在不同系统中都遇到了问题,并且和其他短信访问的app,例如微信电话本发生冲突,下面内容主要针对Android4.4以下系统,和部分被修改的操作系统,例如小米


首先就说和微信电话本冲突的情况,由于微信电话本也要实现上述功能,可是它有一个坑就是,它收到短信以后,就将短信置为已读(完全搞不明白为什么要这样做啊喂!)

由于它在系统中的优先级比较高,所以当我的App读取短信的时候,就没有未读短信了!


下面就这个内容,来说一下短信接收优先级的问题。


众所周知,监听短信有两种方式

1,是注册一个BroastReceiver,监听系统的短信到底的广播

public class SmsReceiver extends BroadcastReceiver{
	
	public SmsReceiver() {
		Log.i("cky", "new SmsReceiver");
	}
	@Override
	public void onReceive(Context context, Intent intent) {  
		// TODO Auto-generated method stub
		Log.i("cky", "接收到广播");		  		
	}		
}


2,是使用ContentObserver来监听系统短信数据库的变化

public class SmsObserver extends ContentObserver{    
    public SmsObserver(Context context, Handler handler) {
        super(handler);
        mContext = context;                 
    }

    @Override
    public void onChange(boolean selfChange) {
        super.onChange(selfChange);
        Log.i("cky","短信数据库变化了");
    }   
}

那么问题来了,如果我两个方法都使用了,到底谁会先接收到短信到达的通知呢?


经过测试,虽然没有真正去看源码,发现应该是这样的:

1,当短信到底,首先BroastReceiver会接收到通知,此时该新短信,会被系统记录进系统的短信数据库

如果我们在BroastReceiver里面查询短信数据库,有可能查询不到新短信,因为数据库写入需要一定时间

经过测试,如果onReceive()方法里面,我暂停1秒以后再去查短信数据库,才能查到新短信的信息

2,当系统数据库被写入后,马上会通知ContentObserver,调用其onChange()方法


由于我的app是使用ContentObserver去探测短信的,所以当然要比微信电话本慢,测试结果是,

在4.4系统以下,和4.4的小米系统,当我的onChange()方法去查询数据库的时候,果然查询到新短信记录,但是很快就被微信电话本清除了。。

在google原生6.0系统,onChange()方法查询数据库时,没有查询到新短信,说明在这之前,记录就被微信电话本清除了。。。


那么解决办法是什么呢?

我们要想办法抢在微信电话本前面收到短信,然后把短信广播给拦截了(短信广播是有序广播,在4.4以下系统,是可以阻止其传播的)

但是问题是我的app不是短信应用啊,我这样做的话,用户就收不到短信了,体验太差。

而且问题来了,就是我怎么样才能抢在微信电话本前面呢,我们能做的事情,微信电话本都能做。

所以结局悲剧了(>﹏<),这个bug没有办法修改!


不过我还有要说一下短信拦截的机制,让我们的app第一个接收到短信到底的消息

首先我们要注册BroastReceiver,根据源码,广播接收优先级有以下规律:



静态广播接收器 由PackageManagerService负责,当手机启动时(或者新安装了应用),PackageManagerService负责扫描手机中所有已安装的APP应用(题外话,确定不再使用的APP需要卸载了),将AndroidManifest.xml中 有关注册广播的信息 解析出来,存储至一个全局静态变量当中mReceivers。
  需要注意的是:
 1 PackageManagerService扫描目录的顺序如下:
  system/framework
  system/app
  vendor/app
  data/app
  drm/app-private
  2 当处于同一目录下时:按照file.list()的返回顺序。(题外话:因为在data/app下的应用都是用户安装的,并且都是以com.xxx.xxx-1.apk 的形式出现,所以如果打算做手机管家之类的应用,需要好好的研究下包名,争取在file.list()的独木桥下抢的头筹---优先接收开机启动完成的广播。)
   3 在此处并未对 接收顺序做完整的排序。(注意修饰词完整的,毕竟先扫描的当然会有一定优先级)
 
    动态广播接收器 由ActivityManagerService负责,当APP的服务或者进程起来之后,执行了注册广播接收的代码逻辑,即进行加载,最后会存储在一个全局静态变量
mReceiverResolver中。
    需要注意的是:
    1 这个并非是一成不变的,当程序被杀死之后,  已注册的动态广播接收器也会被移出mReceiverResolver,直到下次程序启动,再进行动态广播的注册,当然这里面的顺序也已经变更了一次。
    2  这里也并没完整的进行广播的排序,只记录的注册的先后顺序,并未有结合优先级的处理。
 
当有广播发出时,接收顺序如下:


在ActivityManagerService处理广播,当广播为有序广播时,将动态广播接收器和动态广播接收器合并起来,形成最终的有序广播接收顺序。
   上述的规则1排序为:
                                1 优先级高的先接收
                                2 同优先级的动静态广播接收器,动态优先于静态
                                3 同优先级的动态广播接收器  或者同优先级的静态广播接收器,按照图1 的流程注册顺序。
                                   即静态:先扫描的大于后扫描的,动态:先注册的大于后注册的。

  
   当广播为普通广播时,规则2排序为:
                                1 无视优先级,动态广播接收器优先于静态广播接收器
                                2 同规则1排序的第3点

 
接下来请看代码以片段:

private final int broadcastIntentLocked(ProcessRecord callerApp,   
        String callerPackage, Intent intent, String resolvedType,   
        IIntentReceiver resultTo, int resultCode, String resultData,   
        Bundle map, String requiredPermission,   
        boolean ordered, boolean sticky, int callingPid, int callingUid) {   

    …………
    …………
    
    // 静态广播接收器list
    List receivers = null; 
    
    // 动态广播接收器List
    List<BroadcastFilter> registeredReceivers = null;   

    // 获取静态广播接收器mReceivers
    try {   
        if (intent.getComponent() != null) {   
            // Broadcast is going to one specific receiver class...   
            ActivityInfo ai = AppGlobals.getPackageManager().   
                getReceiverInfo(intent.getComponent(), STOCK_PM_FLAGS);   
            if (ai != null) {   
                receivers = new ArrayList();   
                ResolveInfo ri = new ResolveInfo();   
                ri.activityInfo = ai;
                receivers.add(ri);   
            }   
        } else {   
            // Need to resolve the intent to interested receivers...   
            if ((intent.getFlags()&Intent.FLAG_RECEIVER_REGISTERED_ONLY)   
                     == 0) {   
                receivers =   
                    AppGlobals.getPackageManager().queryIntentReceivers(   
                            intent, resolvedType, STOCK_PM_FLAGS);   
            } 
            // 获取动态广播接收器mReceiverResolver
            registeredReceivers = mReceiverResolver.queryIntent(intent, resolvedType, false);   
        }   
    } catch (RemoteException ex) {   
        // pm is in same process, this will never happen.   
    }   
  
    final boolean replacePending =   
            (intent.getFlags()&Intent.FLAG_RECEIVER_REPLACE_PENDING) != 0;   
      
    int NR = registeredReceivers != null ? registeredReceivers.size() : 0;  
    ……
    // 如果接收到的广播 是普通广播。
    if (!ordered && NR > 0) {   
        // If we are not serializing this broadcast, then send the   
        // registered receivers separately so they don't wait for the   
        // components to be launched.   
        BroadcastRecord r = new BroadcastRecord(intent, callerApp,   
                callerPackage, callingPid, callingUid, requiredPermission,   
                registeredReceivers, resultTo, resultCode, resultData, map,   
                ordered, sticky, false);   

    // 很明显接收到普通广播之后,在这只处理了动态广播 registeredReceivers,对于普通广播而言,动态广播接收器要优先于静态广播接收器 无关设置的优先级
        boolean replaced = false;   
        if (replacePending) {   
            for (int i=mParallelBroadcasts.size()-1; i>=0; i--) {   
                if (intent.filterEquals(mParallelBroadcasts.get(i).intent)) {   
                    if (DEBUG_BROADCAST) Slog.v(TAG,   
                            "***** DROPPING PARALLEL: " + intent);   
                    mParallelBroadcasts.set(i, r);   
                    replaced = true;   
                    break;   
                }   
            }   
        }   
        if (!replaced) {   
            mParallelBroadcasts.add(r);   
            scheduleBroadcastsLocked();   
        }   
        //将registeredReceivers置为null,后面只处理静态广播接收器,所以不会有冲突。
        registeredReceivers = null;   
        NR = 0;   
    }   
    
    //如果是有序广播,将静态广播接收器和动态广播接收器组合成一个最终的顺序
    int ir = 0;   
    if (receivers != null) {   
        ...   
        //合并的过程,注意顺序   
        int NT = receivers != null ? receivers.size() : 0;   
        int it = 0;   
        ResolveInfo curt = null;   
        BroadcastFilter curr = null;   
        while (it < NT && ir < NR) {   
            if (curt == null) {   
                curt = (ResolveInfo)receivers.get(it);   
            }   
            if (curr == null) {   
                curr = registeredReceivers.get(ir);   
            }   
            //如果动态广播接收器优先级高于或者等于静态广播接收器,那么就插到前面      
            //很明显动态的要在静态的前面 
            if (curr.getPriority() >= curt.priority) {   
                // Insert this broadcast record into the final list.   
                receivers.add(it, curr);   
                ir++;   
                curr = null;   
                it++;   
                NT++;   
            } else {   
                // Skip to the next ResolveInfo in the final list.   
                it++;   
                curt = null;   
            }   
        }   
    }


OK,了解规律以后,我们来考虑具体怎么实现:

首先我们要动态注册广播,那么我们怎么样才能在开机之后,马上就动态注册呢?

显然开机广播只能使用静态注册的方式来监听,所以我注册一个广播用于监听开机广播,然后在该onReceive()方法中,创建一个service,再在这个service重新动态注册一个Receiver,优先级为2147483647

这里注意两个问题,1是保证我们的应用首先接收到开机广播,根据上述原则,只能让我们的应用最先安装(这个当然没有办法保证),并且文件包排在最前面(这个要修改包名,所以我们做这类应用的时候,也要注意包名)

2是保证我们的service长期存活,因为一旦service死掉,会造成动态注册的广播也死掉


源码下载地址:

接收广播的最高优先级


根据上面的方法,原则上我们就能保证我们的app是第一个接收到短信广播的,当然这是在4.4系统以下,如果是4.4系统,请看下一篇文章!

Android短信拦截机制适配的坑(下)--4.4以上系统,主要是6.0


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值