[過去ﾛｸﾞ] 【通知来ない】Doze総合【GCM？】©2ch.net (507ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
183(1): 2016/12/30(金)18:22 ID:Xq2a/kM3(1/2) AAS
Dozeの無効化
adb shell dumpsys deviceidle disable
これだと再起動時に毎回実行しないとダメで、これをScript化したのがありDisabledoze はこれをアプリ化したものと自分は思っている。
Script化のURLしたもの
外部ﾘﾝｸ[html]:www18.atwiki.jp
ちなみに
このスレの中でアクア作者の紹介URLにScript化したものとDisabledoze は紹介されている
184: 2016/12/30(金)18:41 ID:Xq2a/kM3(2/2) AAS
↑
ごめん違う
Disabledoze はDozeに入った直後に止めている。
185(1): 2016/12/31(土)16:11 ID:a+zP8RTj(1/3) AAS
>>180
うろ覚えだがGmailはsession保持がたしか20分くらいだったような
無通信（keep aliveなし）でも相手が同じIPでListeningしていると見なす時間が長ければ長いほどクライアントには都合がいいが、鯖にとってはいい迷惑なのでGmailがフリーでは最大級なんだろうな（憶測）
Gmailでもダメな人は自前で鯖を立てる
Exchangeはデフォ30分最大一日とかできたはず…アホくさコスト的にありえん
186(1): 2016/12/31(土)16:12 ID:a+zP8RTj(2/3) AAS
>>185
また、鯖からkeep aliveを投げてもらっての応答ではDoze回避できないと思われるので、むしろ鯖からkeep aliveはない方がよさそう
（応答無しで切断と見なされ、session破棄されそう）
あとはクライアント側がDozeでもkeep aliveするようにsetAlarmClock()で短時間で起きるか（たしか時計アイコンが強制表示される）
そんなことしたらStoreから蹴られるだろうな
187: 2016/12/31(土)16:12 ID:a+zP8RTj(3/3) AAS
>>186
k-9使ってる人はグローバル設定-ネットワーク-バックグラウンド同期-常時利用にしてみてる？
まあk-9はIMAP idleではその設定が必須だからトラブってる人はいないか…
188: 2017/01/01(日)14:01 ID:+UjFEPBG(1) AAS
>>177
同期を15分にしたらどうだろうか。
189: 2017/01/02(月)01:21 ID:gMoxHbFE(1) AAS
Disable Dozeって7.0でも使えてる？
アップデートしようか迷ってる。せっかくこれのお陰でメール問題解決したから、7.0で使えないなら上げたくないな。
190: 2017/01/02(月)03:36 ID:yqp3XJt7(1) AAS
Gmailの通知が来ない状態ではどういう問題が起きているのか
LAN内のルータマシンにWiresharkを入れてアクアとimap.gmail.comとの間の通信を
キャプチャして調べようと思ったけど
なぜかDoze中も通知が来なくならない
ありがたいけどこれじゃ調べられない
通信がSSL(TSLv1.2)だから暗号化されていて完全には分からないけど
待ち状態になった後にアクア側からパケットが送られる場合(多分LOGOUT)も
Gmail側からパケットが送られる場合(多分タイムアウト)も
アクアは必ず「IMAPプッシュセッションの持続時間」ごとに新しいTCP接続を作っている
これだと通知が来なくならない
省7
191(1): 2017/01/03(火)11:58 ID:wZPPMN5s(1/2) AAS
Heartbeat Fixer for GCMを入れてポート5228をWiresharkで監視して
GCMの動作を調べてみた
Doze中のハートビートは
Heartbeat Fixer for GCMで何分に設定してもOFFにしても変化がなく、
1740秒(29分)間隔で端末側からパケットが送られていた
それに加えてメンテナンスウィンドウが来たらそのタイミングでもハートビートが送られた
上の方で、Heartbeat Fixer for GCMで通知が来るようになった後で
アンインストールしても通知が来る状態が維持されているという話があったので
初回インストール前だと挙動が違うのかもしれないが
俺も入れてしまっていたのでそれは確認できていない
省11
192: 2017/01/03(火)12:52 ID:xSbSEOU+(1) AAS
GCMを高にするオプション追加するとヘッダーに何か追加されるってデベロッパーサイトで見た気がしたけど
検索するの面倒だから気になる人は自分で探してくれｗ
193: 2017/01/03(火)13:19 ID:uRPKfbX2(1) AAS
外部ﾘﾝｸ:mslgt.hatenablog.com
194(1): 2017/01/03(火)15:02 ID:gnOXts3O(1) AAS
すまん長い
>>191
なにもGCMでやりとりするものがなくても、GCM鯖から15分くらいに一回パケットこない？
ExchangeやIMAP-IDLEとネットワーク的にはやり口似てる
keep aliveを15や30分毎にするけど、その間はsession繋がったままlisteningしていると仮定してるだけ
sessionをやたら短時間で破棄される環境だと、GCMもIMAP-IDLE同様切られて通知出なくなる
ネットワーク的にはExchange/IMAP-IDLE程度に脆弱
DozeでGCMが有利なのは、Google Play開発者サービスがシステムアプリの上、Doze除外されている常駐サービスのため
他アプリは定期的にkeep alive送りたいけどDozeで仮死になっちゃう
Google Play開発者サービスはDoze関係なくkeep alive送れるので、たとえsession切れてても張り直しする
省4
195(1): 2017/01/03(火)23:29 ID:wZPPMN5s(2/2) AAS
>>194
1740秒の間には特にパケット来なかったよ
Wiresharkのポート5228のキャプチャはこんな感じ
(デフォルト出力から、2カラム目にtcp.stream、3カラム目にtcp.time_deltaを追加して
長文規制対策でInfoの後半を消してある)
4738 5 1740.864185000 2017-01-03 05:22:44.71 mobile mobile-gtalk.l.google.com TCP 101 55335→5228
4739 5 0.039409000 2017-01-03 05:22:44.75 mobile-gtalk.l.google.com mobile TCP 99 5228→55335
4740 5 0.004986000 2017-01-03 05:22:44.75 mobile mobile-gtalk.l.google.com TCP 66 55335→5228
4800 5 1741.944733000 2017-01-03 05:51:46.70 mobile mobile-gtalk.l.google.com TCP 101 55335→5228
4801 5 0.038764000 2017-01-03 05:51:46.74 mobile-gtalk.l.google.com mobile TCP 99 5228→55335
省36
196(1): 2017/01/05(木)14:24 ID:g/T7zjzy(1) AAS
>>195
> 1740秒の間には特にパケット来なかったよ
ドキュメントと違いすぎる…。
NATなどでsessionが実は切れててとかではと思ったけど。
> 4740 5 0.004986000 2017-01-03 05:22:44.75 mobile mobile-gtalk.l.google.com TCP 66 55335→5228
> 4800 5 1741.944733000 2017-01-03 05:51:46.70 mobile mobile-gtalk.l.google.com TCP 101 55335→5228
ログ見ると約30分後端末からパケット何事もなく流れてるし…。
端末からkeep aliveしてその応答する以外は、GCMなにも手当してくれていないように見えるなあ。
経路理由でsession切れてたらGCMでも最大約30分無通知か。
この面はキャリアメール（SMSトリガー）しか信用ならないのが全く崩れないなあ。
省10
197: 2017/01/05(木)14:56 ID:AuL6q3Ox(1) AAS
こんなのだとGCM優先度高でも通知遅れるわけだ
198(1): 2017/01/05(木)15:14 ID:iLM3aIhu(1) AAS
>>196
Doze以前のGCMの実測調査は全部アテにならないってことだね・・・
199(1): 2017/01/06(金)23:56 ID:Jy2IYSCA(1/3) AAS
>>198
そこまでは言わない。
広範に複数環境での検証報告出てこないとなんとも。
ただ現実に互いに約30分無通信ログを見てしまうと、こりゃGCM高がベストプラクティスなんてとても言えん。
通話やSMSに大きく（最大約30分）劣る信頼性しかないことを、改めて認識させられたところ。
200(2): 2017/01/06(金)23:57 ID:Jy2IYSCA(2/3) AAS
>>199
一方で、端末も鯖もsession張れていると勘違いしたまま経路断なんてそうそうあるかと言えばそんなにはない。
ただIPv4枯渇のおかげでNATだらけ。
おかげで切れやすいので、ローカルIP配布のISPはこの面で、実は隠れた形でリスク高しと言ったところかな。
（既出の外部ﾘﾝｸ[html]:risurisu.seesaa.net参考）
これはDozeやGCMの問題ではなく、ネットワークのしかもNAT timeout問題なので、Google的には知らん顔だろう。
201: 2017/01/06(金)23:57 ID:Jy2IYSCA(3/3) AAS
>>200
そこはいい。
ただDozeのオンオフはユーザーに（少なくとも当分は）選択肢があるべき。
Dozeさえかからなければ、バッテリー捨てながらアプリにkeep aliveさせりゃいいんだから。
それは単にL以前に戻るだけとも言える。
ただ現状、具体的対策がDisableDoze/adb/rootになってしまうのは…。
202(1): 2017/01/07(土)00:15 ID:2CV1rina(1) AAS
>>200
WiFi接続ならそうそう経路断は起きないと思うけど
モバイルネットワークではよくあるよね
MVNOの短時間タイムアウトのことはそのリンク先にも書いてあるけど
キャリアでもいつの間にか外部IPアドレスが変わってることはよくある
(2chのIDがころころ変わったりする)から
その時には経路断になってるはず
それでプッシュが来なくなってるんだと思う
上下前次1-新書関写板覧索設栞歴
あと 305 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.016s