java.lang.SecurityException: Unknown calling package name, com.google.android.gms.common.internal.zz

来源:互联网 发布:阿里云短信授权书 编辑:程序博客网 时间:2024/05/22 06:59

java.lang.SecurityException: Unknown calling package name, com.google.android.gms.common.internal.zzs

印尼项目碰到一些崩溃,每天大概有几十例,比较奇怪的是看不出来是App导致的,从崩溃信息上看是来自GCM.
比较棘手,但是这个问题并不紧急,就临时跟进这个问题.了解到一些信息:
- 该崩溃是最近一个月出现的,每天大概几十例(比较稳定);
- 公司最新没有发布什么活动,因此不会发送任何的推送信息;

也有同事怀疑是应用被篡改了,但是我觉得可能性不大.根源应该是在GCM那边(因为一般人都不会怀疑谷歌的专业能力).

0x01. 崩溃信息

java.lang.SecurityException: Unknown calling package name'com.mypackagename'.-android.os.Parcel.readException(1465) android.os.Parcel.readException(1419)com.google.android.gms.common.internal.zzs$zza$zza.zza(-1)com.google.android.gms.common.internal.zzs$zza$zza.zza(-1)com.google.android.gms.common.internal.zzj.zza(-1)com.google.android.gms.common.internal.zzj$zzf.zza(-1)com.google.android.gms.common.internal.zzj$zzh.zzqL(-1)com.google.android.gms.common.internal.zzj$zza.zzc(-1)com.google.android.gms.common.internal.zzj$zza.zzw(-1)com.google.android.gms.common.internal.zzj$zzc.zzqN(-1)com.google.android.gms.common.internal.zzj$zzb.handleMessage(-1)android.os.Handler.dispatchMessage(110)android.os.Looper.loop(193)android.app.ActivityThread.main(5292)java.lang.reflect.Method.invokeNative(-2)java.lang.reflect.Method.invoke(515)com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(828)com.android.internal.os.ZygoteInit.main(644)dalvik.system.NativeStart.main(-2)

0x02. 分析和跟进

先看看网上有没有类似问题,结果确实发现有同样的问题,但是没有任何解法.

  • 0x01.根据崩溃详情,在网上有一个相关的帖子,但是没有google官方的人员进行解释.
    https://code.google.com/p/android/issues/detail?id=230497

  • 0x02.同类型的问题,网上很少几乎没有参考意义.

因为基本上断定是GCM的问题,怀疑是Google自己推送一些广告或者其它内容导致我们的App崩溃了,因此直接让研发同事,使用开发账号联系google plyer的技术支持.
- 0x03.经过联系Google Player的相关技术人员,并且提供了详细的崩溃信息, 然后我们今天监控到的崩溃数据已经没有了.

实际上联系了之后,对方要我们提供最新的崩溃数据等,反正是比较繁琐的一些流程,最后我们也无法提供,因为崩溃数据是通过google的sdk抓的. 但是惊喜是当我们反馈了之后,第二天这个崩溃就没有了!
到现在为止这个问题过去了10个多月,就再也没有出现过.

0x03. GCM的架构

这里写图片描述

从架构图上我们可以看出.

总共有两种场景:

  • 0x01. 第一种场景:

我们的正式release app版本发生了崩溃:
我们自己的后台发送我们的推送信息到我们自己的App,全程由Google服务托管.这种情况下同时崩溃位置在google GCM的代码中,那么可以断定的是:崩溃和我们的App无关.

PS:但是经过健哥确认,这个时间段内,我们后台没有配置任何的推送内容和动作,那么我们官方App如果收到了推送内容,也是和我们自己的App无关的.

  • 0x02. 第二种场景:
    我们的我们的App被反编译重新打包了. 这种情况也是不会发生崩溃的. 按照健哥之前的测试:

我们自己打的debug签名包,也是可以正常接收推送消息的.那么说明GCM本身没有对应用做签名的校验.

那么如果别人修改了我们的App,重新进行了签名,那么这种场景和我们原生的官方App相比较(相对于Google GCM来说,仅仅是签名不同),因此是不会在接收推送消息的时候发生崩溃的.

0x04. 结论

  1. Google自己处理其它App的广播信息时候导致我们的App崩溃了;
  2. Google自己给我们的App发送了广告或者其它数据导致我们的App崩溃了;

最后,通过今天的崩溃数据来看,应该是符合这个推测结论的.

https://developers.google.com/android/reference/com/google/android/gms/gcm/GcmReceiver

public class GcmReceiver extends WakefulBroadcastReceiverWakefulBroadcastReceiver that receives GCM messages and delivers them to an application-specific GcmListenerService subclass. 
阅读全文
0 0
原创粉丝点击