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中做這麼久動作的原因。所以也沒有比較好的辦法能夠優化。