Keep screen on when there is an active WebRTC session on Android.

content/browser/power_save_blocker_android.cc

 // Copyright (c) 2012 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 "content/browser/power_save_blocker_impl.h"
 
 #include "base/logging.h"
+#include "content/browser/android/content_video_view.h"
+#include "content/public/browser/browser_thread.h"
 
 namespace content {
 
 class PowerSaveBlockerImpl::Delegate
-    : public base::RefCounted<PowerSaveBlockerImpl::Delegate> {
+    : public base::RefCountedThreadSafe<PowerSaveBlockerImpl::Delegate> {
+ public:
+  Delegate(PowerSaveBlockerType type) : type_(type) {}

[sky, 2013/05/21 23:54:38]

nit: explicit

[wjia(left Chromium), 2013/05/22 02:17:51]

Done.

+
+  // Does the actual work to apply or remove the desired power save block.
+  void ApplyBlock();
+  void RemoveBlock();
+
  private:
-  friend class base::RefCounted<Delegate>;
+  friend class base::RefCountedThreadSafe<Delegate>;
   ~Delegate() {}
+
+  // The counter of requests from clients for type
+  // kPowerSaveBlockPreventDisplaySleep.
+  static int blocker_count_;
+  const PowerSaveBlockerType type_;
+
+  DISALLOW_COPY_AND_ASSIGN(Delegate);
 };
 
+int PowerSaveBlockerImpl::Delegate::blocker_count_ = 0;
+
+void PowerSaveBlockerImpl::Delegate::ApplyBlock() {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
+  if (type_ != kPowerSaveBlockPreventDisplaySleep)
+    return;
+
+  if (blocker_count_ == 0)
+    ContentVideoView::KeepScreenOn(true);

[joth, 2013/05/21 23:56:08]

Having PowerSaveBlocker depend on ContentVideoView seems a  random dependency.
And as this is static, it relies on the (possibly null?) static instance inside
ContentVideoView to get to the activity to find the window is awkward; it would
be better if PowerSaveBlocker instances could be associated with a specific
android view, and then you would  add/remove View.KEEP_SCREEN_ON flag to that
view only.
That's a pretty major change to PowerSaveBlocker though I imagine, and I can't
think of anything less brittle to suggest.

[wjia(left Chromium), 2013/05/22 02:17:51]

Yeah, we could iterate later.

[joth, 2013/05/24 18:07:00]

I realized part of the answer - the screen_on state should be handled via
ViewAndroid and/or WindowAndroid. In terms of correctness, perhaps the nicest
thing would be every time a ApplyBlock() call is made we create a small View
instance with the KEEP_SCREEN_ON flag and attach to the window, and
RemoveBlock() releases that View. This way it plays nicely with any other usage
of the flags that an application may have (i.e. we don't want to remove the flag
from the window if the application is also keeping it on for another reason we
don't know about)

The only remaining question then is from here (effectively, from the
PowerSaveBlocker c'tor) how do we find the appropriate WindowAndroid to attach
to? I think that implies a cross platform change to always pass the window (or
view) into said c'tor.

+  ++blocker_count_;
+}
+
+void PowerSaveBlockerImpl::Delegate::RemoveBlock() {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
+  if (type_ != kPowerSaveBlockPreventDisplaySleep)
+    return;
+
+  --blocker_count_;
+  if (blocker_count_ == 0)
+    ContentVideoView::KeepScreenOn(false);
+}
+
 PowerSaveBlockerImpl::PowerSaveBlockerImpl(PowerSaveBlockerType type,
-                                           const std::string& reason) {
-  // TODO(wangxianzhu): Implement it.
+                                           const std::string& reason)
+    : delegate_(new Delegate(type)) {
   // This may be called on any thread.
-  NOTIMPLEMENTED();
+  BrowserThread::PostTask(
+      BrowserThread::UI, FROM_HERE,
+      base::Bind(&Delegate::ApplyBlock, delegate_));
 }
 
 PowerSaveBlockerImpl::~PowerSaveBlockerImpl() {
+  BrowserThread::PostTask(
+      BrowserThread::UI, FROM_HERE,
+      base::Bind(&Delegate::RemoveBlock, delegate_));
 }
 
 }  // namespace content