Interesting, so our current method is to do just what you said -- start a foreground service and acquire a wakelock. But we only do it if our network request takes longer than n seconds (to avoid always showing foreground notifications). We still hit the issue. Other Googlers have told me I may be running into some race condition that happens with foreground services and doze.
Thank you for the detailed info about how those modes work though -- it certainly de-mystifies the network problems!
> Interesting, so our current method is to do just what you said -- start a foreground service and acquire a wakelock. But we only do it if our network request takes longer than n seconds
This won't work. One of the less documented properties of Doze Mode is it's ability to sever your network connections. It can already be in action before you start downloading message contents. It can also kick in during the download. If you want reliable delivery, you have to take wake lock and enter foreground mode immediately after getting GCM push.
Look up, what is WakefulBroadcastReceiver, and why it used to be necessary. The class itself is deprecated (because implicit broadcasts are largely obsolete), but it shows, how one can miss opportunity to take a wake lock, causing entire application to be caught in deep CPU sleep. Google promises, that GCM will bring you out of Doze Mode, but I am not sure, if that also applies to wake lock. Your app may be sleepy because of failure to timely take wake lock, causing it to miss time window when Doze is temporarily lifted by GCM.
Thank you for the detailed info about how those modes work though -- it certainly de-mystifies the network problems!