Comment 27 for bug 1337200

OK, Pat's upower log also by and large just reflects the kernel events. We discussed that on IRC, and we think that there's two different issues here:

 * The main problem is that system-settings subscribes to D-BUS signals (from upower), and then goes to sleep. When it wakes back up, it receives all the queued signals from dbus-daemon, as the semantics of D-BUS is to not lose signals. These can't be "filtered out" on the D-BUS side. What system-settings could do is to unsubscribe from D-BUS before suspending, and re-subscribing after resuming.

 * This problem is mitigated by upower 0.99, as that suppresses change events if the values didn't actually change. As the udevadm monitor log shows, the Android kernel is really dumb here -- it sends out change signals for all devices every 10 s even if nothing changed (like the AC). Due to using a PropertyChanged signal (which does value comparison and is only sent on actual changes) instead of the raw "DeviceChanged" signals (which are an one-to-one reflection of the original uevents) we filter out about 3/4 of the original events. I. e. upower itself still wakes up just as often as 0.9 (as that happens through the kernel), but affects userspace much less.