[Background Sync] Use GcmNetworkManager to start the browser for sync events.

chrome/android/java/AndroidManifest.xml

Index: chrome/android/java/AndroidManifest.xml
diff --git a/chrome/android/java/AndroidManifest.xml b/chrome/android/java/AndroidManifest.xml
index 1fef19f4a72c9b7c12047e1d1d338f73e280a99e..5af3d4e020988a89cc81e8554534b5c3677a153b 100644
--- a/chrome/android/java/AndroidManifest.xml
+++ b/chrome/android/java/AndroidManifest.xml
@@ -44,6 +44,7 @@ by a child template that "extends" this file.
     <uses-permission android:name="android.permission.NFC"/>
     <uses-permission android:name="android.permission.READ_SYNC_SETTINGS"/>
     <uses-permission android:name="android.permission.READ_SYNC_STATS"/>
+    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>

[Yaron, 2015/09/24 16:13:17]

Also, where is it used? Within play services?

[iclelland, 2015/09/24 17:11:50]

Yes, it's only used within play services -- the NetworkScheduler verifies that
the app has this permission before it allows a task which persists across
reboots to be scheduled.

See
https://developers.google.com/android/reference/com/google/android/gms/gcm/On...

(The permission itself is usually used to get an app to receive the
ACTION_BOOT_COMPLETED intent, but we're not using it for that. I presume that
the check inside of GCM is to ensure that you're not trying to "cheat" by having
play services tell you when the device rebooted, if you don't have that
permission yourself.)

[jkarlin, 2015/09/24 18:08:47]

Ian: I thought we agreed that this permission had to go?

[iclelland, 2015/09/24 18:33:04]

Maybe I misunderstood -- I thought we agreed that we needed to get someone with
deeper Android understanding to review it, before deciding whether or not to
dump it.

Without this permission, we *cannot* register GCM tasks that persist across a
reboot. If a sync is scheduled, with the device offline, and the user restarts
the phone, it will be lost (applies to periodic, eventually, as well as
one-shot). We won't be able to trigger the sync event until the user manually
starts the browser again.

If that's acceptable (or a different CL), or it's at least preferable to adding
the permission, then we can remove it, and the setPersistent() call that
requires it.

[jkarlin, 2015/09/24 18:38:34]

That's right, my mistake.
I think it'll come down to whether or not the permission is part of a bucket
that we already have permission for.

[iclelland, 2015/09/24 18:56:19]

My understanding is that that permission does not trigger any permission dialog,
on install or on upgrade; it's a non-dangerous permission, and doesn't fall into
any of the buckets.

     <uses-permission android:name="android.permission.RECORD_AUDIO"/>
     <uses-permission android:name="android.permission.USE_CREDENTIALS"/>
     <uses-permission android:name="android.permission.VIBRATE"/>
@@ -550,14 +551,14 @@ by a child template that "extends" this file.
             </intent-filter>
         </receiver>
 
-        <!-- Service Worker Background Sync service listener -->
+        <!-- Service Worker Background Sync GCM scheduler task -->
         <service android:name="org.chromium.content.browser.BackgroundSyncLauncherService"
-            android:exported="false" />
-        <receiver android:name="org.chromium.content.browser.BackgroundSyncLauncherService$Receiver">
+            android:permission="com.google.android.gms.permission.BIND_NETWORK_TASK_SERVICE"
+            android:exported="true">
             <intent-filter>
-                <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
+                <action android:name="com.google.android.gms.gcm.ACTION_TASK_READY" />
             </intent-filter>
-        </receiver>
+        </service>
 
         <service android:name="org.chromium.chrome.browser.prerender.ChromePrerenderService"
             android:exported="true"