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中做这么久动作的原因。所以也没有比较好的办法能够优化。

签到专用组  

申明：网友回复良莠不齐，仅供参考。如需专业帮助，请学习易迪拓培训专家讲授的ADS视频培训课程。