Android: Integrates native and java SystemMonitor.

base/system_monitor/system_monitor_android.cc

Index: base/system_monitor/system_monitor_android.cc
diff --git a/base/system_monitor/system_monitor_android.cc b/base/system_monitor/system_monitor_android.cc
index c86076d2a84baaaf1a20ec489ddbffdc46af7e7d..3ec6f24b83e2f5485275e5cd3520423812cd304e 100644
--- a/base/system_monitor/system_monitor_android.cc
+++ b/base/system_monitor/system_monitor_android.cc
@@ -3,12 +3,27 @@
 // found in the LICENSE file.
 
 #include "base/system_monitor/system_monitor.h"
+#include "jni/SystemMonitor_jni.h"
 
 namespace base {
+namespace android {
+
+static bool g_is_battery_charging = false;
+void OnBatteryChargingChanged(JNIEnv* env,
+                              jclass clazz,
+                              jboolean is_charging) {
+  g_is_battery_charging = is_charging;
+  SystemMonitor::Get()->ProcessPowerMessage(SystemMonitor::POWER_STATE_EVENT);
+}
+
+}  // namespace android
 
 bool SystemMonitor::IsBatteryPower() {
-  NOTIMPLEMENTED();
-  return true;
+  return base::android::g_is_battery_charging;

[Satish, 2012/10/04 11:09:51]

Since IsBatteryPower() is a querying API, I think it is simplest to implement
the java side of it without having to register a power status listener. i.e. the
java SystemMonitor class could have an IsBatteryPower() method that does

    public static boolean isBatteryPower(Context context) {
        Intent intent = context.registerReceiver(null, new
IntentFilter(Intent.ACTION_BATTERY_CHANGED));
        int plugged = intent.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1);
        return plugged == BatteryManager.BATTERY_PLUGGED_AC || plugged ==
BatteryManager.BATTERY_PLUGGED_USB;
    }

[bulach, 2012/10/04 11:16:32]

hmm, I'm not sure if that would save us anything..
IsBatteryPower() is not really a querying API, it's a private method withing
SystemMonitor that is called after SystemMonitor::Get()->ProcessPowerMessage
(from line 16)..

so the java side would still have to register the listener to call the function
above, and then this one would have to call up to JNI again...

does it make sense?

[Satish, 2012/10/04 11:31:07]

Ah yes I missed the part about informing power status change events. Yes we do
need registration.

The global variable here doesn't look right though.. just to store state that
gets used during the ProcessPowerMessage call. Can it be added as a parameter to
ProcessPowerMessage ? I see the windows implementation has a separate function
as well and it queries windows directly, whereas we are trying to save a JNI
call by storing state here which doesn't look as clean. We can either add it as
a parameter to ProcessPowerMessage or make a JNI call and store the battery
state in the java SystemMonitor object.

What do you think?

[bulach, 2012/10/04 13:58:50]

Yes, good point about the global variable.
rather than going through another JNI, since we can get the value right here,
it's now storing in SystemMonitor itself.. this way, there's a cleaner interface
from the java to native side, i.e., it passes the bool and then calls
ProcessPowerMessage internally...
wdyt?

+}
+
+bool SystemMonitor::RegisterSystemMonitor(JNIEnv* env) {
+  return base::android::RegisterNativesImpl(env);
 }
 
 }  // namespace base