Makes WebAPK handle NOTIFICATION_PREFERENCES intents

chrome/android/webapk/shell_apk/AndroidManifest.xml

 <?xml version="1.0" encoding="utf-8"?>
 <!-- Copyright 2015 The Chromium Authors. All rights reserved.
      Use of this source code is governed by a BSD-style license that can be
      found in the LICENSE file.
 -->
 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
     xmlns:tools="http://schemas.android.com/tools"
     package="{{ manifest_package }}"
     android:versionCode="1"
     android:versionName="1.0" >
@@ skipping 12 matching lines @@
                 <action android:name="android.intent.action.MAIN" />
                 <category android:name="android.intent.category.LAUNCHER" />
             </intent-filter>
             <intent-filter>
                 <action android:name="android.intent.action.VIEW"></action>
                 <category android:name="android.intent.category.DEFAULT"></category>
                 <category android:name="android.intent.category.BROWSABLE"></category>
                 <data android:scheme="https" android:host="{{ scope_url_host }}" android:pathPrefix="/"></data>
             </intent-filter>
         </activity>
+        <activity android:name="org.chromium.webapk.shell_apk.NotificationSettingsLauncherActivity">
+            <intent-filter>
+                <action android:name="android.intent.action.MAIN"/>
+                <category android:name="android.intent.category.NOTIFICATION_PREFERENCES"/>
+            </intent-filter>
+        </activity>
         <meta-data android:name="runtimeHost" android:value="{{ runtime_host }}" />
+        <meta-data android:name="hostNotificationPreferencesHandler"

[Yaron, 2016/07/25 14:28:27]

I'm thinking that it would be nice to limit the number of new manifest fields we
introduce. If we do need to add them, then we should try and add them with some
generality to try and limit the number of variables. This would make it easier
to push new versions and not depend on new server releases (to populate those
variables).

Since this will be rare, it's ok to me if it's not the most optimal. Can we
instead add logic to the runtime_library to scan the host browser's manifest for
a NOTIFICATION_PREFERENCES handler and intent to that? Or is that even necessary
- could you just send this intent (act=android.intent.action.MAIN,
cat=android.intent.category.NOTIFICATION_PREFERENCES) at the host browser
package?

Alternatively, we could add a "MainActivity" class. Then a requirement for
webapk host is that your main activity must be able to handle this intent.

[pkotwicz, 2016/07/25 18:23:25]

I changed the intent to be sent solely to the browser package. It seems to work

+                   android:value="{{ host_notification_preferences_handler }}" />
         <meta-data android:name="startUrl" android:value="{{ start_url }}" />
         <meta-data android:name="name" android:value="{{ name }}" />
         <meta-data android:name="scope" android:value="{{ scope_url }}" />
         <meta-data android:name="displayMode" android:value="{{ display_mode }}" />
         <meta-data android:name="orientation" android:value="{{ orientation }}" />
         <meta-data android:name="themeColor" android:value="{{ theme_color }}" />
         <meta-data android:name="backgroundColor" android:value="{{ background_color }}" />
         <meta-data android:name="iconUrl" android:value="{{ icon_url }}" />
         <meta-data android:name="webManifestUrl" android:value="{{ web_manifest_url }}" />
         <service
@@ skipping 19 matching lines @@
             android:process=":webapk_sandboxed_process1"
             android:exported="true"
             tools:ignore="ExportedService"/>
         <service android:name="org.chromium.webapk.shell_apk.WebApkSandboxedProcessService2"
             android:isolatedProcess="true"
             android:process=":webapk_sandboxed_process2"
             android:exported="true"
             tools:ignore="ExportedService"/>
     </application>
 </manifest>