您的位置:首页 > 移动开发 > Android开发

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

2017-10-13 18:26 567 查看

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. 结论

Google自己处理其它App的广播信息时候导致我们的App崩溃了;

Google自己给我们的App发送了广告或者其它数据导致我们的App崩溃了;

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

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

public class GcmReceiver extends WakefulBroadcastReceiver

WakefulBroadcastReceiver that receives GCM messages and delivers them to an application-specific GcmListenerService subclass.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐