[Nexus 7 General] bftb0:
I think that "App Sucker" image is reporting data faithfully, but it's choice of statistic is leading to an unwarranted conclusion - given that the total time wakelocks were held seems to only be two minutes or so out of many hours. That seems to make the assumption that a huge chunk of the battery is used only when wakelocks are held - or that the amount of time the device these locks were held is irrelevant. (Or, to put it another way, would you care if Maps used 73% of the change if the total change was only 5% in 1000 hours?)

BTW, I thought I would tell you about a quick experiment I did the other day. It might help you in your investigation.

I set my tablet aside for about 150 minutes - off the charger, screen off. (This was roughly 10:35am - 1:05pm).

Then I woke it up and captured the kernel log (/proc/kmsg or "dmesg" output) and a logcat. I did this by hand (command line/terminal emulator), so I probably got that done within 2 or 3 minutes.

In the (Stock 4.2.2) kernel log, I see repetitive occurences of entry into LP0 mode: (background on Tegra SoC LPn modes)

<6>[141548.480341] Entering suspend state LP0
<6>[1415[b][color=red]48.482[/color][/b]222] Tegra: switched to LP cluster
<4>[141548.482430] partition 3d0 is left on before suspend
<4>[141548.482430] partition vde is left on before suspend
<4>[141548.482430] partition heg is left on before suspend
<4>[141548.482430] partition 3d1 is left on before suspend
<6>[1415[b][color=red]48.485[/color][/b]647] Tegra: switched to G cluster
<6>[141548.485791] Exited suspend state LP0
<6>[141548.485921] legacy wake status=0x0
<6>[141548.486145] tegra3 wake status=0x1
<6>[141548.486271] Resume caused by WAKE32, bcmsdh_sdmmc
<6>[1415[b][color=red]48.486[/color][/b]525] Suspended for [b][color=red]597.100 seconds[/color][/b]
<6>[141548.486956] wakeup wake lock: alarm
<6>[141548.492834] PM: early resume of devices complete after 5.636 msecs

Note that the timestamps in this kernel log can not be relied upon - apparently precisely because of the LP0 sleep. I surmise that the kernels' tick counter used for /proc/kmsg logging is suspended and therefore does not accumulate time in a wall-clock fashion; otherwise how could the device sleep for 597 seconds in only 4 milli-seconds?

Having captured the output of "dmesg" into a file "dmesg.txt" (and likewise the logcat into "logcat.txt"), I did a little hand-filtering of the output:

$ grep 'Tegra: switched to LP' dmesg.txt | wc -l
18

$ grep 'Suspended for' dmesg.txt |wc -l
19

$ grep 'Suspended for' dmesg.txt
<6>[141544.528940] Suspended for 5.813 seconds
<6>[141548.486525] Suspended for 597.100 seconds
<6>[141549.833844] Suspended for 5.610 seconds
<6>[141553.751664] Suspended for 114.785 seconds
<6>[141555.169992] Suspended for 366.895 seconds
<6>[141557.767079] Suspended for 111.202 seconds
<6>[141559.114371] Suspended for 3.868 seconds
<6>[141563.302312] Suspended for 344.820 seconds
<6>[141564.583528] Suspended for 62.516 seconds
<6>[141566.061274] Suspended for 188.582 seconds
<6>[141567.531674] Suspended for 7.695 seconds
<6>[141570.882663] Suspended for 595.651 seconds
<6>[141572.230025] Suspended for 8.666 seconds
<6>[141576.067748] Suspended for 87.744 seconds
<6>[141577.452742] Suspended for 368.048 seconds
<6>[141578.833047] Suspended for 139.359 seconds
<6>[141580.230604] Suspended for 9.878 seconds
<6>[141585.018340] Suspended for 373.786 seconds
<6>[141586.363370] Suspended for 12.157 seconds

$ grep 'Suspended for' dmesg.txt | awk 'BEGIN{s=0;}{s+=0.0+$4;}END{print NR,s;}'
19 3404.18

Now, 3404 seconds is only 3404/(150*60) = 38% of the time of my test... but I just checked and noticed that my kernel log file is exactly 128kB in length - so the kernel log buffer must have rolled over completely during that time, so I really only captured some fraction of the total time of sleep with that log. (The kernel log buffer fills too fast to record that much elapsed time).

But anyway - notice that many of the sleep intervals are several minutes long - once for nearly ten minutes straight!

In comparison, the logcat did capture the entire sleep interval (it had several *days* worth of info in it).

[l3452:] 02-24 10:35:07.692 481 563 I PowerManagerService: Going to sleep by user request...
[l3453:] 02-24 10:35:08.112 125 169 D SurfaceFlinger: Screen released, type=0 flinger=0x40d12318
...
[l3711:]02-24 13:05:46.952 481 496 I PowerManagerService: Waking up from sleep...
[l3712:] 02-24 13:05:47.222 481 600 D PowerManagerService-JNI: Excessive delay in au\
tosuspend_disable() while turning screen on: 269ms

Or in other words, the logcat capture only had 260 (3712-3452) entries in it for 150 minutes of that elapsed time - less than two entries per minute on average. And there were some notably large gaps. Below are a few excerpts from the logcat which are pairs of immediately adjacent entries in the logcat:

...
02-24 10:[color=green][b]35[/b][/color]:33.951 585 585 I wpa_supplicant: wlan0: WPA: Group rekeying completed with 00:18:39:cd:99:cb [GTK=CCMP]
02-24 10:[color=red][b]36[/b][/color]:53.731 6683 6683 I RlzPingService: Setting next ping for 1362335813737
...

02-24 10:[color=green][b]37[/b][/color]:00.868 6845 6845 W InvService: Dropping C2DM message for unknown or unstarted client: chromesync#1337300716
02-24 10:[color=red][b]38[/b][/color]:46.241 481 576 D ConnectivityService: Captive portal check NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "notmySSID", roaming: false, failover: false, isAvailable: true
...

02-24 10:[color=green][b]38[/b][/color]:47.261 481 576 D ConnectivityService: NetTransition Wakelock for WifiStateMachine released by timeout
02-24 10:[color=red][b]46[/b][/color]:59.856 913 4117 W Smack/Packet: notify conn break (IOEx), close connection
...

02-24 10:[color=green][b]50[/b][/color]:33.849 585 585 I wpa_supplicant: wlan0: WPA: Group rekeying com\
pleted with 00:18:39:cd:99:cb [GTK=CCMP]
02-24 10:[color=red][b]56[/b][/color]:42.611 913 2062 I EventLogService: Aggregate from 1361730402536 \
(log), 1361730402536 (data)
...

02-24 11:[color=green][b]07[/b][/color]:19.411 481 576 D ConnectivityService: handleInetConditionHoldEnd: net=1, condition=100, published condition=0
02-24 11:[color=red][b]17[/b][/color]:15.824 913 7118 W Smack/Packet: notify conn break (IOEx), close connection
...

Well - anyway : you get the idea - large gaps in time where literally *nothing* is happening. I think you should see the same sort of behavior if your tab is actually sleeping correctly.