[Moto X General] hachamacha:
Yesterday, I finally got around to updating (via the sbf) my xt1060 (Dev model) from 4.4.2 to 4.4.4. On 4.4.2 using anything on the device like an app that shows cpu usage ("quick stats" , etc, or wakelock detecter, or gsam's) I showed ~1-4% at most times unless something was obviously happening.

On 4.4.4, those "app-based" ways I used above all tend to show a dark gloomy picture of about ~30% System usage (CPU) with wakelocks (mostly location services based) galore. The thing that made me suspicious about it possibly just being a problem with how the apps (API's etc) are viewing CPU usage was noticing that the actual "lifetime" of the battery was a bit better on 4.4.4 than on 4.4.2. Last night I left the phone laying around after noticing it was at 80%, and this morning it only drained to 77%. So how the heck could that be if those apps were showing the correct numbers?

I decided to try using only 'linux-based' (or 'android-based') tools like "top" from adb rather than GUI apps from the play store. This morning, with the screen on or off, with adb attached from my PC, I could see that the average top CPU usage on mine is about 1% except of course when I'm doing something. It just makes me wonder about whether something changed in the API that is not giving straight readings to those apps using it. The only thing I've really done on 4.4.4 to reduce battery usage a bit is to flash back the 4.4.2 baseband because 4.4.4 was giving me a poor signal which is usually going to translate to more battery usage, but aside from getting better radio signal , the battery usage seems good. I'm guessing it's better (for me) than 4.4.2.

So I'm wondering if some of these cases are people being "swayed" by the perhaps incorrect readings from the usual battery metric apps that are used that for some reason don't work right with 4.4.4 on the moto x. Also: Wakelocks: All my zillions of wakelocks all add up to about 7 minutes in a single day, so none of those are of much interest to me. If the GUI apps were telling the truth, then I'd just want to know which UserSpace apps are causing the OS to have wakelocks, but my theory right now based on battery life which is good, makes me want to move along and use something like "top" (use it from terminal emulator from your phone if you've got it).

Of course: I'm not saying many, some, of you don't have battery problems, not at all. I'm sure you do, but I thought I'd toss this out as another way to get metrics that doesn't involve directly anything unique to 4.4.4. Also: When you're spending GUI time trying to figure out anything on a phone, all you're doing is creating a) wakelock-city, b) cpu usage , and of course, c) using battery like nuts, which skews results like mad.

Cheers.

Edit: It just dawned on my that if anyone tries using $top from an adb shell on say, windows, that it'll likely never match a standard terminal (curses-based) definition and will be hard to read, so use these qualifiers (change them to what works for you). -m (switch for number total process to monitor by top cpu) and -n (switch for how many times to refresh before exiting since non-standard terminal won't interpret 'q'/quit correctly). Thus: The command might look like this:

adb shell
$su
# top -m 20 -n 10
// and that command would show the top 20 cpu-eating processes with how much cpu etc, and show them ~10 times before exiting

General Info: I'm rooted so some of you won't be able to do this , but if you can get an adb shell, you can do it from your own account without su. I flashed the 4.4.4 sbf after getting rid of the "wipe userdata" option from the .xml file so really, mine should be a worst-case scenario since old userdata is generally not good for things. I've changed almost nothing since flashing since all my apps and their data survived the flash. I'm in southern California in a good reception area and that 4.4.4 radio was showing pretty bad reception (although you never know, it might just have been "showing it") but 4.4.2 radio (after I reflashed only the radio from an older SBF) shows the decent (usually good to excellent) radio reception I had before this update.