[Android] Adding content settings provider for notification channels

chrome/browser/notifications/notification_content_settings_provider_android.cc

+// Copyright 2017 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.
+
+#include "chrome/browser/notifications/notification_content_settings_provider_android.h"
+
+#include "base/android/jni_android.h"
+#include "base/android/jni_string.h"
+#include "base/logging.h"
+#include "base/strings/string_util.h"
+#include "chrome/browser/content_settings/host_content_settings_map_factory.h"
+#include "chrome/browser/profiles/profile.h"
+#include "components/content_settings/core/browser/content_settings_details.h"
+#include "components/content_settings/core/browser/content_settings_utils.h"
+#include "components/content_settings/core/browser/host_content_settings_map.h"
+#include "components/content_settings/core/common/content_settings.h"
+#include "components/content_settings/core/common/content_settings_pattern.h"
+#include "jni/NotificationSettingsBridge_jni.h"
+#include "url/gurl.h"
+#include "url/url_constants.h"
+
+using base::android::AttachCurrentThread;
+using base::android::ConvertUTF8ToJavaString;
+using base::android::ScopedJavaLocalRef;
+
+namespace {
+
+// A Java counterpart will be generated for this enum.
+// GENERATED_JAVA_ENUM_PACKAGE: org.chromium.chrome.browser.notifications
+enum NotificationChannelStatus { ENABLED, BLOCKED, UNAVAILABLE };
+
+}  // anonymous namespace
+
+NotificationContentSettingsProviderAndroid::
+    NotificationContentSettingsProviderAndroid()
+    : should_use_channels_(
+          Java_NotificationSettingsBridge_shouldUseChannelSettings(
+              AttachCurrentThread())) {}
+
+NotificationContentSettingsProviderAndroid::
+    ~NotificationContentSettingsProviderAndroid() = default;
+
+std::unique_ptr<content_settings::RuleIterator>
+NotificationContentSettingsProviderAndroid::GetRuleIterator(
+    ContentSettingsType content_type,
+    const content_settings::ResourceIdentifier& resource_identifier,
+    bool incognito) const {
+  // TODO(crbug.com/700377) return rule iterator over all channels
+  return nullptr;
+}
+
+bool NotificationContentSettingsProviderAndroid::SetWebsiteSetting(
+    const ContentSettingsPattern& primary_pattern,
+    const ContentSettingsPattern& secondary_pattern,
+    ContentSettingsType content_type,
+    const content_settings::ResourceIdentifier& resource_identifier,
+    base::Value* value) {
+  if (content_type != CONTENT_SETTINGS_TYPE_NOTIFICATIONS ||
+      !should_use_channels_) {
+    return false;
+  }
+  GURL primary_url = GURL(primary_pattern.ToString());
+  DCHECK(primary_url.is_valid());
+  JNIEnv* env = AttachCurrentThread();
+  const std::string origin = primary_url.spec();
+  ScopedJavaLocalRef<jstring> jorigin = ConvertUTF8ToJavaString(env, origin);
+  ContentSetting setting = content_settings::ValueToContentSetting(value);
+  switch (setting) {
+    case CONTENT_SETTING_ALLOW:
+    case CONTENT_SETTING_BLOCK: {
+      auto channel_status = static_cast<NotificationChannelStatus>(
+          Java_NotificationSettingsBridge_getChannelStatus(env, jorigin));
+      if (channel_status == NotificationChannelStatus::UNAVAILABLE) {
+        bool result = Java_NotificationSettingsBridge_createChannel(
+            env, jorigin, setting == CONTENT_SETTING_ALLOW /* enabled */);
+        return result;

[raymes, 2017/05/18 00:39:37]

nit: probably we should return true here regardless. I don't think there is a
reason to fall through to the pref provider even if this fails

[awdf, 2017/05/19 17:59:57]

Turns out we can't create channels as blocked, at least for now (I'll forward
you some context). 

So we may need to store initially-blocked channels in user prefs, until the user
enables them in site settings, at which point we can create a channel and return
true. I'd like to do this by making the new code resilient to
channel-initialization failing and have it fallback to user prefs, rather than
assuming channel creation will always work/fail in different scenarios, and then
having to adapt if/when it becomes possible to create blocked channels.

I appreciate that having multiple providers handle the same origin complicates
things, but with the precedence ordering of the content settings providers, I
don't see why this shouldn't work (but maybe I'm missing something).

[raymes, 2017/05/22 00:37:41]

That's really unfortunate :( Personally I think we will be compromising too much
if we had to store some settings in content settings and some in android
settings. We're dealing with a feature that is already adding complexity to the
system and this would require more complexity - both in the code and in the user
experience. 

In any case, let's land this CL and continue that discussion separately (if you
can CC me in on the relevant threads, that would be great :). For now I would
prefer to return true here to ensure that we don't touch the pref provider on
Android O. Coordinating settings from 2 providers may have other complications.
As we work out the high level direction we can dig into how we want to move
forward in the code.

+      } else {
+        DCHECK(!(setting == CONTENT_SETTING_ALLOW &&
+                 channel_status == NotificationChannelStatus::BLOCKED));
+        DCHECK(!(setting == CONTENT_SETTING_BLOCK &&
+                 channel_status == NotificationChannelStatus::ENABLED));
+        return true;
+      }
+    }
+    case CONTENT_SETTING_DEFAULT:
+      Java_NotificationSettingsBridge_deleteChannel(env, jorigin);
+      return true;
+    default:
+      // We rely on notification settings being one of ALLOW/BLOCK/DEFAULT.
+      NOTREACHED();
+      return true;
+  }
+}
+
+void NotificationContentSettingsProviderAndroid::ClearAllContentSettingsRules(
+    ContentSettingsType content_type) {
+  // TODO(crbug.com/700377): If |content_type| == NOTIFICATIONS, delete
+  // all channels.
+}
+
+void NotificationContentSettingsProviderAndroid::ShutdownOnUIThread() {
+  RemoveAllObservers();
+}