一.概述
Android系统升级到5.0之后做了不少的变化(5.0变化),开发人员一定要注意这些变化,要不然就有的折腾了.这次最大的变化应该是把Dalvik虚拟机改成了ART(Android Runtime),后续会专门讲解这一块.其他的都是一些零碎的问题,例如前段时间发了一篇Android
5.0之后修改了HashMap的实现(传送门).这篇主要讲一下遇到跟Service相关的问题.
二.详情
Service身为Android四大组件之一,它的使用频率还是比较高的,并且现在主要都是运用在比较关键的部位,例如升级推送等.在Android 5.0之后google出于安全的角度禁止了隐式声明Intent来启动Service.也禁止使用Intent filter.否则就会抛个异常出来.
官方的解释如下.
那么google到底是怎么限制的呢?限制的判定条件是什么呢？这些都可以从Android 4.4和Android 5.0的源码中找到区别.
在Android 4.4的ContextImpl源码中,能看到如果启动service的intent的component和package都为空并且版本大于KITKAT的时候只是报出一个警报,告诉开发者隐式声明intent去启动Service是不安全的.再往下看,丫的异常都写好了只是注释掉了,看来google早就想这么干了.
private void validateServiceIntent(Intent service) {
if (service.getComponent() == null && service.getPackage() == null) {
if (true || getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.KITKAT) {
Log.w(TAG, "Implicit intents with startService are not safe: " + service
+ " " + Debug.getCallers(2, 3));
//IllegalArgumentException ex = new IllegalArgumentException(
// "Service Intent must be explicit: " + service);
//Log.e(TAG, "This will become an error", ex);
//throw ex;
}
}
}
果然在Android 5.0的源码中上面注释的代码已经不注释了,当targetSdkVersion版本大于LOLLIPOP直接异常抛出来,要求Service intent必须显式声明.所以如果开发的应用指定targetSdkVersion版本是小于LOLLIPOP的话还是按以前的方式给报个警报,这也就造成了如果没有做了完善的Android
5.0兼容就贸然把targetSdkVersion升到LOLLIPOP的话很有可能就会碰到这个问题.并且这个问题是很严重的,想象一下,你的app自升级的Service是隐式启动的,碰到这个问题后app就不能自升级了,这批用户有可能就一直停留在当前版本.会产生很致命的问题.
private void validateServiceIntent(Intent service) {
if (service.getComponent() == null && service.getPackage() == null) {
if (getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.LOLLIPOP) {
IllegalArgumentException ex = new IllegalArgumentException(
"Service Intent must be explicit: " + service);
throw ex;
} else {
Log.w(TAG, "Implicit intents with startService are not safe: " + service
+ " " + Debug.getCallers(2, 3));
}
}
}
从源码中的逻辑来看的话,判断一个intent是不是显式声明的点就是component和package,只要这两个有一个生效就不算是隐式声明的,接下来继续分析一下Intent的源码,可以看到下面三种构造方式,设置action来声明Intent是没有构建component的,所以显式声明需要用到第一和第二种构造(还有带packagename或component的拷贝构造),或者后面设置package属性.
public Intent(Context packageContext, Class<?> cls) {
mComponent = new ComponentName(packageContext, cls);
}
public Intent(String action) {
setAction(action);
}
public Intent(String action, Uri uri,
Context packageContext, Class<?> cls) {
setAction(action);
mData = uri;
mComponent = new ComponentName(packageContext, cls);
}
public Intent setPackage(String packageName) {
if (packageName != null && mSelector != null) {
throw new IllegalArgumentException(
"Can't set package name when selector is already set");
}
mPackage = packageName;
return this;
}
三.案例分析
经过这么分析之后单看这个问题是很好做兼容的,但是结合实际的一些复杂情况就不一定了.之前就碰到过一个比较复杂的兼容.
场景复现:
将项目里的targetSdkVersion升级到22之后,针对这篇Service的问题做了兼容,so easy啊,但是万万没想到项目里用的某盟的第三方登陆分享的SDK版本太老了(一年前),开发没有去升级SDK跟check兼容性.并且经过四轮测试愣是没有测到这个点,结果在线上发现了这个Bug,泥煤啊Android 5.0设备用微博登陆就闪退,泥煤啊.幸好这个项目做了线上bug热修复,这个时候就体现出这个功能的好处了,之前又博客简单讲解了一下实现原理(传送门).
接下来思路就是升级最新的某盟SDK然后打个补丁包给线上升级过去.然而升级完最新的SDK之后发现并没有什么卵用,看过热修复那篇博客的童鞋应该可以想到,那种打dex补丁的形式是不能添加新资源的,而最新的SDK新增了不少资源进来,所以这个思路是行不通的.
既然升级最新的SDK不行,那能不能修改老的SDK自己给它做Android 5.0兼容呢?理论上来说是可行的.说干就干,先记录一下SDK崩溃的记录.
再把SDK jar反编译一下,里面很多被混淆过,幸好崩溃的位置这个类的逻辑还有可读性都还比较完整.直接定位到崩溃的方法.果然是隐式绑定的Service,上面分析源码的时候从Intent构造源码可以看到这种声明方式既没有构造有效的component,也没有提供出packageName,崩了也无话可说.
既然定位到了位置,那么就单独把这个类抽离出来,新开一个Android工程,建立一个library的module,里面只有接下来要修改的这一个文件,由于这个类里面会引用SDK jar包里面的资源,所以也要把jar包引入到module里面.
包名一定要和之前一模一样.因为我们修改过之后要替换掉SDK中原有的.class文件.
build一下每问题,OK.因为这里启动的Service是新浪微博客户端里面的一个Service,连接上之后会通过AIDL进行跨进程通讯.所以我们没办法在构造Intent的时候就显式声明.既然没有办法构建有效的component,那么给它设置一个包名也可以生效的.既然是新浪微博那么包名应该是com.sina.weibo.
private boolean a(Activity paramActivity)
{
Context localContext = paramActivity.getApplicationContext();
Intent mIntent = new Intent("com.sina.weibo.remotessoservice");
mIntent.setPackage("com.sina.weibo");
return localContext.bindService(mIntent, this.serviceConnection, Context.BIND_AUTO_CREATE);
}
reBuild一下,然后去主项目build文件夹里面的中间资源里面找到module打成的jar包,直接把编译好的.class解压出来.
解压某盟的SDK,进入到正确的路径下直接替换刚才编译出来的.class文件.
回到SDK的跟目录下,运行 jar cvf sdk.jar * 命令进行重打包,将重新打好的SDK替换到项目里面.验证bug.BinGo!搞定!这样就可以打个dex补丁包给线上的版本更新过去修复5.0兼容的bug了.
四.总结
这里结合这个案例简单分析了一下Android 5.0之后对启动绑定Service做的变化.碰到这种问题也是因为做兼容的时候没有覆盖所有的地方,这些坑都是跑不掉的.
转载请注明出处:http://blog.csdn.net/l2show/article/details/47421961