[BetterBatteryStats] chamonix:
That is for sure a hell of a detailed analysis. I'm always happy to see users trying to understand the tools they use.

With this kind of approach you will certainly get the most of your smartphone.

The active time graphs looks pretty different indeed. I can only assume as I know the differences in the code. It would be great if you could provide those graphs again for another run together with a dump of the series so that we can verify my theory.

For the left part of the graph: the stock graph suggests that the phone was asleep more often thatn BBS. On the other hand BBS shows hair thin awakes suggesting that there have been a lot of very short wakeups that are not shown in stock because of interpolation. The only way to make sure that my interpretation is correct would be to look a a dump of the serie and confirm that during that time the sampling rate was high with a lot of samples showing awakes for a few ms (those would be interpolated out by the stock graph)

For the right part of the graph: the only explanation I have for the long period shown as awake on the stock graph is that this is an interpolation error. The stock battery graph has a logic of connecting the dots (BBS does do that). That means that if there are two samples in a row a "awake" the stock graph would connect them as a bar. This is no problem is sampling happens often but there is no guarantee for that. If two samples are two hours apart and both at "awake" they would get connected and that's what I believe happened here (as the battery level curve is pretty flat during that time I think that is what happened).

Well the ratio is not bad but you still have roughly 2 hours out of two days as potential for optimization (see details below)

The reason is the preferences you use for showing the percentages (I assume you are set to show percent of awake). For reading with longer screen on times that setting is too optimistic as it would account wakelocks occuring while the screen was on (those do not really cause awake as they occur in the time when you using the phone cause the awake).

The main issues with potential I see are in the partial wakelocks:

Event Log Service (Google Services): 8 h 11 m 30 s (29490 s) Count:906 165,0%
AlarmManager (Android-System): 6 h 7 m 11 s (22031 s) Count:4491 123,3%
FacebookService (com.facebook.katana.Facebook): 2 h 54 m 35 s (10475 s) Count:180 58,6%
SyncManagerHandleSyncAlarm (Android-System): 2 h 14 m 16 s (8056 s) Count:1276 45,1%
KpiLogger (Android-System): 1 h 18 m (4680 s) Count:2436 26,2%
FDCompleteTime (UID): 50 m 28 s (3028 s) Count:1025 16,9%
backupdb (com.whatsapp.WhatsApp): 32 m 56 s (1976 s) Count:5 11,1%
*sync* (com.google.android.apps.reader.Google Reader): 20 m 44 s (1244 s) Count:94 7,0%

Unfortunately we have no real grip on Event Log Service (I have a theory though an am working on a proof of concept) so we will take that as a side effect for now. It should get lower once we reduce the other wakelocks.

AlarmManager: unfortunately you were using BBS 1.4.2 and the alarms are part of the dump since 1.5 so you should update and we can have a look at those in the next run.

FacebookService: 180 Wakeups in about 60 hours is a wakeup every 20 minutes. That's pretty expensive. You could try to reduce that by e.g. turning off the sync of the contacts and maybe changing the update interval. Unfortunately facebook is known to be battery inefficient.

SyncManagerHandleSyncAlarm is probably related to the high sync caused by google reader and even more Whatsapp: Whatsapp is bad because if forces you to sync the contacts (if you uncheck it is gets re-checked back). Until a fix for that is provided I don't see any way to get rid of the high cost of that app except dropping it. Google reader has a setting to sync often read feeds hourly. If this is checked you could try removing it to lower the overhead.

KpiLogger seems to be a tool logging some performance data. As it is pretty expensive you should try to find out if it can be frozen.

FDCompleteTime: it looks like fast dormancy is causing frequent wakelocks. You could try to disable it and see if it has a positive effect. FD is supposed to have positive effects on battery if running in harmony with the provider but is also known to do no good if your provider has no implementation of it. I also assume that your RILJ wakeups are caused by FD.

Are you using google's backup service to backup your settings? if yes moving to another way of backing up your data (e.g. titanium for local backups) may have a positive effect on the wakelock caused by WhatsApp.

I'm looking forward to the next runs.

If would be great if you could confirm on KpiLogger and maybe provide a short description for me to take it up as a KB article.