Android 5.0之后隐式声明Intent 启动Service引发的问题

一.概述

       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早就想这么干了.

[java]  view plain  copy

1. private void validateServiceIntent(Intent service) {  
2.     if (service.getComponent() == null && service.getPackage() == null) {  
3.         if (true || getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.KITKAT) {  
4.             Log.w(TAG, "Implicit intents with startService are not safe: " + service  
5.                     + " " + Debug.getCallers(2, 3));  
6.             //IllegalArgumentException ex = new IllegalArgumentException(  
7.             //        "Service Intent must be explicit: " + service);  
8.             //Log.e(TAG, "This will become an error", ex);  
9.             //throw ex;  
10.         }  
11.     }  
12. }  

       果然在Android 5.0的源码中上面注释的代码已经不注释了,当targetSdkVersion版本大于LOLLIPOP直接异常抛出来,要求Service intent必须显式声明.所以如果开发的应用指定targetSdkVersion版本是小于LOLLIPOP的话还是按以前的方式给报个警报,这也就造成了如果没有做了完善的Android 5.0兼容就贸然把targetSdkVersion升到LOLLIPOP的话很有可能就会碰到这个问题.并且这个问题是很严重的,想象一下,你的app自升级的Service是隐式启动的,碰到这个问题后app就不能自升级了,这批用户有可能就一直停留在当前版本.会产生很致命的问题.

[java]  view plain  copy

1. private void validateServiceIntent(Intent service) {  
2.     if (service.getComponent() == null && service.getPackage() == null) {  
3.         if (getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.LOLLIPOP) {  
4.             IllegalArgumentException ex = new IllegalArgumentException(  
5.                     "Service Intent must be explicit: " + service);  
6.             throw ex;  
7.         } else {  
8.             Log.w(TAG, "Implicit intents with startService are not safe: " + service  
9.                     + " " + Debug.getCallers(2, 3));  
10.         }  
11.     }  
12. }  

       从源码中的逻辑来看的话,判断一个intent是不是显式声明的点就是component和package,只要这两个有一个生效就不算是隐式声明的,接下来继续分析一下Intent的源码,可以看到下面三种构造方式,设置action来声明Intent是没有构建component的,所以显式声明需要用到第一和第二种构造(还有带packagename或component的拷贝构造),或者后面设置package属性.

[java]  view plain  copy

1. public Intent(Context packageContext, Class<?> cls) {  
2.     mComponent = new ComponentName(packageContext, cls);  
3. }  
4. public Intent(String action) {  
5.     setAction(action);  
6. }  
7. public Intent(String action, Uri uri,  
8.               Context packageContext, Class<?> cls) {  
9.     setAction(action);  
10.     mData = uri;  
11.     mComponent = new ComponentName(packageContext, cls);  
12. }  
13. public Intent setPackage(String packageName) {  
14.     if (packageName != null && mSelector != null) {  
15.         throw new IllegalArgumentException(  
16.                 "Can't set package name when selector is already set");  
17.     }  
18.     mPackage = packageName;  
19.     return this;  
20. }  

三.案例分析

       经过这么分析之后单看这个问题是很好做兼容的,但是结合实际的一些复杂情况就不一定了.之前就碰到过一个比较复杂的兼容.

       场景复现:

       将项目里的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.

[java]  view plain  copy

1. private boolean a(Activity paramActivity)  
2. {  
3.     Context localContext = paramActivity.getApplicationContext();  
4.     Intent mIntent = new Intent("com.sina.weibo.remotessoservice");  
5.     mIntent.setPackage("com.sina.weibo");  
6.     return localContext.bindService(mIntent, this.serviceConnection, Context.BIND_AUTO_CREATE);  
7. }  

       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