[BetterBatteryStats] Tungstwenty:
Definitely a better name than "exclusive KWLs"; I with I had remembered that option (and I did think for some time before settling with exclusive). Perhaps an even better name would be "discrete KWL stats" (?), because the KWLs themselves work exactly the same as before, it's just the measurements that are presented in a different way.

The challenge here is that it's a) kernel dependent and b) it somewhat bends a concept which is for sure a well established standard in the whole android and even linux community (even if linux also supports hibernation, perhaps other types of KWLs, etc.) For it to become a de-facto standard, even in a narrower community (say, android only), it would have to be endorsed by the real kernel gurus or a committee of some kind, assuming it exists. Not by some guy that just wrote a piece of code in a couple of days.

As I mentioned before, this was initially just another fun puzzle for me (I hadn't ever compiled or even looked at kernel sources before), and is therefore nothing more than a proof of concept right now, even if already usable in a way.

About detection of what is being read, I see a couple of alternatives.

Currently, in Siyah, the numbers follow the existing \t-separated format, and a flag controls which of the 2 sets of stats is output on /proc/wakelocks. No way to tell which ones are being given.

However, in addition, I though I should create 2 additional pseudo-files from which you could read explicitly stats A or B irrespective of the setting. Meaning, a "feature-aware" reader would know better and instead of reading the standard file, would probe directly /proc/wakelocks-total or /proc/wakelocks-exclusive (or discrete). If BBS attempts to find those files and they exist, it can choose which to read.

Yet another option I remembered a while ago (this one was not implemented because it *requires* changes in the probing apps, unlike the other one where an alias is fooling it), would be to create an alternate /proc file, ideally also agreed upon by the kernel-developer community, where you'd have something like "/proc/wakelocks-extended", and which could contain additional columns and present on each line the entire set of stats (normal + discrete). An app aware of this optional feature of kernels, such as a future BBS or other apps, would be able to interpret this richer set of stats and provide reports as it deems useful for the user.

In summary, currently there's a very rough way to do this, on top of Siyah, but I would definitely push this to some sort of kernel committee before spreading usage of something that's definitely rough. That's why there's a flag - users can currently turn it on or off to fool BBS and others, if they are curious about the actual time a certain KWL was preventing sleep.

From these options, I'd say that if the community would indeed want to push for an android standard, the best way would probably be to create the alternate, richer /proc/wakelocks-extended and define which additional columns, which order, etc. to put in there.

In practice, you could currently insert in BBS the logic to look for wakelocks-total and wakelocks-exclusive and fall-back to the regular wakelocks file, since it's a kernel that doesn't have this. But if other kernels are to adopt, some better organization would be due I think. Just look at your naming suggestion as an example - much better that what I came up with.

Documentation, following kernel standards (?) would also need to be done by someone in the field, although I can definitely explain my reasoning and even the way I implemented it.

Less data is indeed a positive thing but I wouldn't be surprised if it also has some negative aspects (?), apart from the obvious one which is the confusion. Your approach when advising people about how to reduce wake times is usually to start with the thing that stands out the most, right? This is true even when you can tell upfront that there's also something else in there (e.g. the 2nd biggest PWL) but you think it's not worth looking at it before solving the 1st one.

With these current alternate stats, the "wake time hitch-hikers" are really invisible from the "exclusive" stats, as if they didn't exist. But after you've done the first iteration to eliminate the top KWL, the others will start showing (unless they were correlated with the first one, like wlan_wake + wlan_rx_wake, in which case reducing one usually also eliminates the other).

About the "screen on" comment, I'm not sure I understand your point. So here's what I discovered when fixing "main":

When the screen is on, "main" is active (but time stat at 0 and therefore not visible in BBS, although it's on the file - as I explained before). And while main is active, all KWL "preventing-sleep" time is not increasing, irrespective of whether they're active or not. This is true for both sets of stats, exclusive or regular. It was already like this for regular stats, and naturally it now also extends to the discrete ones. I'm not sure whether this is good or bad / if it would be useful to also have the lock time even while awake, even if for completeness.

If that "standard" implementation choice is indeed the wider output, there's room to add yet these other time counters as in "KWL active time including while screen was on" (with 2 different slots - regular and discrete). Ultimately it's a matter of checking what does bring added-value for this tool's purpose (or others for other stuff), and whether kernel coders agree to introduce the overhead (pretty negligible, I suppose) of counting some more fields.

Still about screen on, something else to think about could be counting or not C/WC/EC while screen is on. As I mentioned before, the time isn't increased even for locked KWLs, but these counts do get updated, even when main is active. I suppose this is not relevant for the discrete stats (as "main" will pretty soon become the "POWER_CULPRIT" and therefore hide all other KWL activities) but on regular stats the counts will increase as when the screen is off.

True. Even if all the standardization and kernel adoption issues were overcome, ultimately it's still an uncertainty whether this is indeed useful or merely a fun idea but with not much practical benefit.

Perhaps for the time being you might think a field trial with a couple of people, more or less experienced in stats analysis and running Siyah, could use for some time a version of BBS that does attempt to read /proc/wakelocks-total and /proc/wakelocks-exclusive and dumps them in additional sections on the file, while being entirely hidden from the GUI. Does it make any sense, in order to assess the utility?

If my memory doesn't fail me, my initial moment of clarity about hacks for power analysis were even focused on the PWLs, before imagining I'd be able to look at *scaaaaary kernel code*.

My idea was to patch the java code to do something very similar on the PM service, so it wouldn't count time or occurrences if another PWL was already keeping the device awake. Pretty similar to this on KWL, I guess.

But I ended up never going forward with it, and really I have the impression that correlation (which is the big thing this might help with) is likely much more frequent in KWLs (take the Wifi driver for instance) than on PWL. Just a hunch, of course, which could be totally wrong.

As for the 777 situation you mention, I'm not familiar with it but given your description I suppose it would fall on the current KWL logic - not overlapping. Perhaps on the java side (ROM) they didn't bother creating a grouping for each of the PWLs under a single "PowerManager" KWL, but rather delegate every individual one to the kernel - probably through the interface that exists at /sys/power/wake_(un)lock that allows userland to write names to both files in order to instruct the kernel to create+lock / unlock+destroy KWLs with those names.

Let me know if I missed something you wanted me to clarify, and also what's your opinion on what I mentioned as options.