GMS应用引起待机电流偏高问题
来源:互联网 发布:信息处理技术员软件 编辑:程序博客网 时间:2024/04/28 18:09
GMS应用引起待机电流偏高问题
[DESCRIPTION]
GMS应用引起底电流偏高问题
[SOLUTION]
一般来说,在打开数据连接的情况下,GMS中会有一些alarm唤醒,唤醒后,通常会去做一些downloadManager或者其他的一些动作,占用比较久的
wakelock,导致系统唤醒后一段时间内无法睡下去,最后导致平均电流变高的情况。
例如在待机期间,搜索wakelock占用的时间情况,会搜到例如如下这种log:
05-26 15:50:53.010 695 777 D PowerManagerService: acquireWakeLockInternal: lock=938627931, flags=0x1, tag="GCM_CONN_ALARM",
ws=null, uid=10040, pid=4575
05-26 15:50:58.046 695 1387 D PowerManagerService: releaseWakeLockInternal: lock=938627931 [GCM_CONN_ALARM], flags=0x0,
total_time=5036ms
05-26 15:59:20.029 695 2676 D PowerManagerService: acquireWakeLockInternal: lock=38175938, flags=0x1, tag="GCM_CONN_ALARM",
ws=null, uid=10040, pid=4575
05-26 15:59:25.065 695 1423 D PowerManagerService: releaseWakeLockInternal: lock=38175938 [GCM_CONN_ALARM], flags=0x0, total_time=
5035ms
05-26 16:07:34.147 695 2676 D PowerManagerService: acquireWakeLockInternal: lock=38175938, flags=0x1, tag="GCM_CONN_ALARM",
ws=null, uid=10040, pid=4575
05-26 16:07:37.935 695 2676 D PowerManagerService: releaseWakeLockInternal: lock=38175938 [GCM_CONN_ALARM], flags=0x0, total_time=
3788ms
...
05-26 16:26:13.187 695 1040 D PowerManagerService: acquireWakeLockInternal: lock=333788137, flags=0x1, tag="DownloadManager",
ws=WorkSource{10062}, uid=10038, pid=3356
05-26 16:26:17.665 695 4538 D PowerManagerService: releaseWakeLockInternal: lock=333788137 [DownloadManager], flags=0x0,
total_time=4477ms
05-26 16:26:17.976 695 710 D PowerManagerService: acquireWakeLockInternal: lock=669960491, flags=0x1, tag="DownloadManager",
ws=WorkSource{10062}, uid=10038, pid=3356
05-26 16:27:34.408 695 1387 D PowerManagerService: releaseWakeLockInternal: lock=669960491 [DownloadManager], flags=0x0,
total_time=76432ms
对这些wakelock进行summary,就会发现基本上都是4575进程申请的wakelock,而4575进程刚好是GMS中的com.google.process.gapps进程:
05-26 15:20:02.766 695 1040 I am_proc_start: [0,4575,10040,com.google.process.gapps,content
provider,com.google.Android.gsf/.gservices.GservicesProvider]
最后两个wakelock虽然是3356进程申请的,3356是downloadProvider,但是downloadProvider也是由GMS进程启动的:
05-26 16:26:17.648 695 1445 D ActivityManager: getContentProviderImpl: from caller=android.app.ApplicationThreadProxy@98a8b0f
(pid=5664, userId=0) to get content provider downloads cpr=ContentProviderRecord{1c90f7b0 u0
com.android.providers.downloads/.DownloadProvider}
05-26 16:26:17.853 3356 3356 D ActivityThread: SVC-Creating service: CreateServiceData{token=android.os.BinderProxy@1ccc5f61
className=com.android.providers.downloads.DownloadService packageName=com.android.providers.downloads intent=null}
05-26 16:26:17.976 695 710 D PowerManagerService: acquireWakeLockInternal: lock=669960491, flags=0x1, tag="DownloadManager",
ws=WorkSource{10062}, uid=10038, pid=3356
05-26 16:27:34.408 695 1387 D PowerManagerService: releaseWakeLockInternal: lock=669960491 [DownloadManager], flags=0x0,
total_time=76432ms
而pid 5564正是GMS中的com.google.android.configupdater app。
05-26 15:35:47.803 695 765 I am_proc_start:
[0,5664,10062,com.google.android.configupdater,broadcast,com.google.android.configupdater/.CertPin.CertPinUpdateRequestReceiver]
可以对比在关闭数据连接的情况下的log,可以发现每次相关的wakelock很快就会释放,没有这样的问题。
因此,一般遇到这类问题,都是GMS这边在手机待机后,GMS中的进程中做的一些操作,占用了过久的wakelock,造成电流偏高。
但是因为GMS是google研发的,我方没有souce code,暂时还无法获知GMS中做这么久动作的原因。所以也没有比较好的办法能够优化。
GMS应用引起底电流偏高问题
[SOLUTION]
一般来说,在打开数据连接的情况下,GMS中会有一些alarm唤醒,唤醒后,通常会去做一些downloadManager或者其他的一些动作,占用比较久的
wakelock,导致系统唤醒后一段时间内无法睡下去,最后导致平均电流变高的情况。
例如在待机期间,搜索wakelock占用的时间情况,会搜到例如如下这种log:
05-26 15:50:53.010 695 777 D PowerManagerService: acquireWakeLockInternal: lock=938627931, flags=0x1, tag="GCM_CONN_ALARM",
ws=null, uid=10040, pid=4575
05-26 15:50:58.046 695 1387 D PowerManagerService: releaseWakeLockInternal: lock=938627931 [GCM_CONN_ALARM], flags=0x0,
total_time=5036ms
05-26 15:59:20.029 695 2676 D PowerManagerService: acquireWakeLockInternal: lock=38175938, flags=0x1, tag="GCM_CONN_ALARM",
ws=null, uid=10040, pid=4575
05-26 15:59:25.065 695 1423 D PowerManagerService: releaseWakeLockInternal: lock=38175938 [GCM_CONN_ALARM], flags=0x0, total_time=
5035ms
05-26 16:07:34.147 695 2676 D PowerManagerService: acquireWakeLockInternal: lock=38175938, flags=0x1, tag="GCM_CONN_ALARM",
ws=null, uid=10040, pid=4575
05-26 16:07:37.935 695 2676 D PowerManagerService: releaseWakeLockInternal: lock=38175938 [GCM_CONN_ALARM], flags=0x0, total_time=
3788ms
...
05-26 16:26:13.187 695 1040 D PowerManagerService: acquireWakeLockInternal: lock=333788137, flags=0x1, tag="DownloadManager",
ws=WorkSource{10062}, uid=10038, pid=3356
05-26 16:26:17.665 695 4538 D PowerManagerService: releaseWakeLockInternal: lock=333788137 [DownloadManager], flags=0x0,
total_time=4477ms
05-26 16:26:17.976 695 710 D PowerManagerService: acquireWakeLockInternal: lock=669960491, flags=0x1, tag="DownloadManager",
ws=WorkSource{10062}, uid=10038, pid=3356
05-26 16:27:34.408 695 1387 D PowerManagerService: releaseWakeLockInternal: lock=669960491 [DownloadManager], flags=0x0,
total_time=76432ms
对这些wakelock进行summary,就会发现基本上都是4575进程申请的wakelock,而4575进程刚好是GMS中的com.google.process.gapps进程:
05-26 15:20:02.766 695 1040 I am_proc_start: [0,4575,10040,com.google.process.gapps,content
provider,com.google.Android.gsf/.gservices.GservicesProvider]
最后两个wakelock虽然是3356进程申请的,3356是downloadProvider,但是downloadProvider也是由GMS进程启动的:
05-26 16:26:17.648 695 1445 D ActivityManager: getContentProviderImpl: from caller=android.app.ApplicationThreadProxy@98a8b0f
(pid=5664, userId=0) to get content provider downloads cpr=ContentProviderRecord{1c90f7b0 u0
com.android.providers.downloads/.DownloadProvider}
05-26 16:26:17.853 3356 3356 D ActivityThread: SVC-Creating service: CreateServiceData{token=android.os.BinderProxy@1ccc5f61
className=com.android.providers.downloads.DownloadService packageName=com.android.providers.downloads intent=null}
05-26 16:26:17.976 695 710 D PowerManagerService: acquireWakeLockInternal: lock=669960491, flags=0x1, tag="DownloadManager",
ws=WorkSource{10062}, uid=10038, pid=3356
05-26 16:27:34.408 695 1387 D PowerManagerService: releaseWakeLockInternal: lock=669960491 [DownloadManager], flags=0x0,
total_time=76432ms
而pid 5564正是GMS中的com.google.android.configupdater app。
05-26 15:35:47.803 695 765 I am_proc_start:
[0,5664,10062,com.google.android.configupdater,broadcast,com.google.android.configupdater/.CertPin.CertPinUpdateRequestReceiver]
可以对比在关闭数据连接的情况下的log,可以发现每次相关的wakelock很快就会释放,没有这样的问题。
因此,一般遇到这类问题,都是GMS这边在手机待机后,GMS中的进程中做的一些操作,占用了过久的wakelock,造成电流偏高。
但是因为GMS是google研发的,我方没有souce code,暂时还无法获知GMS中做这么久动作的原因。所以也没有比较好的办法能够优化。
0 0
- GMS应用引起待机电流偏高问题
- GMS应用引起待机电流偏高分析
- [FAQ09542] [Power]待机电流问题,如何查找wakelock
- [Power]待机电流问题,如何查找wakelock
- [Power]待机电流问题,如何查找wakelock
- [FAQ09542] [Power]待机电流问题,如何查找wakelock
- 待机电流问题,如何查找EINT唤醒源
- [Power]待机电流问题,如何查找wakelock
- [Power]待机电流问题,如何查找wakelock
- [FAQ09541] [Power]待机电流问题,如何查找EINT唤醒源
- [FAQ09541] [Power]待机电流问题,如何查找EINT唤醒源
- 基底电流和待机电流是什么含义?
- 待机电流过高bug解决
- 关于RTC引起的待机功耗的问题
- 在 RK3026 平台调试 PWM 的问题和待机电流大的问题
- MTK feature phone 待机电流过大调试
- 待机电流过大的一些调试方法
- 飞行模式待机电流异常分析
- Android Studio常用插件整理
- git学习笔记
- window xampp 配置
- SIP电话(一)之程控交换机-FreeSWITCH的使用总结
- 对代码不满足,是任何真正有天才的程序员的根本特征
- GMS应用引起待机电流偏高问题
- log4j配置
- Android-仿小米巨无霸字体调整控件
- swift protocol 协议代理的使用以及解决循环引用问题
- AFNetWorking 详解
- css中常见的选择器
- Android监测手指上下左右滑动屏幕
- android动画的用法
- sp_help (Transact-SQL)