To update my previous observations:
(1) I was "lucky" enough to get WiFi disconnection during a night on v5, it ate most of the charge and AccuBattery showed 180 mA consumption. I know the number is heavily averaged and not all night was in this state, but still its huge for 'sleeping' s7 with AOD and mobile data off, when it should be around 20 mA or 40 mA when AOD is on. DeviceCare does not show which app is to blame, just a rapid discharge curve. As the effect was observed on 2 different phones and both v4 and v5, I wonder why nobody else has mentioned significant background battery drainage during WiFi crashes.
(2) Turns out the strange charging behavior starting from 95% for turned off phone is similar for v4 too - the percentage difference between turned on and off state is noticeable at those numbers. While v5 almost always has difference about 6-15%, v4 has been staying within 1-2% after the initial turned-off full charge (excluding 95% and up).
As the battery percentage mismatch and stability seems to be a bit better in v4 with OneUI 2.1, maybe it would be easier to fix those bugs in this slightly older version before proceeding to newer and possible less compatible OneUI 2.5?
1) Battery overnight will discharge ALOT if you had the wifi issue, because the phone keeps looping the wifihal, on my wifi chip i dont face it, my overnight drain is few % on average. it gets worse the more social apps i add ofcourse. not many people looked into wifi crash to notice the drain if i have to guess, but yes it is 100% there based on old wifi crash logs ive seen.
2) the 2.1 or 2.5 does not matter with this mismatch, i had constant 1-2% mismatch on all versions since V1, higher mismatch happens randomly, hence why we still could not pin point this bug. some different measuring algorithm is causing issues in the health HAL if i have to guess, but not something i can fix yet.
the only time i had significant mismatch (8%) i got it down to 1/2% by just recharging my phone while its powered off for few cycles, that always got it down for me, if it helps
3) i dont know really, these bugs are common across all versions, they are not specific to any, but i prefer the 2.5 update because it fixed a much nastier issue which is overnight crashing (where the phone will just freeze and die overnight). this has never happened in V5 yet. the rest of the bugs are "common" whether we are on 2.0 2.1 or 2.5, they will be there until we find a fix
i rebase and update the version / security patch because it takes less than 30 minutes of work, finding and debugging these bugs on the other hand is what makes each release take over a month or so, especially due to lack of logging for the wifi crash , muting etc, issues i cant recreate on my device.
regarding to battery percantage.
I have found battery issue also persist in other rooms, such as nfe ported pie roms. when you go to the twrp they also have different battery percentages. this rom somehow reads battery percentage from root file and shows same percentage with twrp.
TWRP will always have a mismatch, this is since the galaxy S6, the mismatch bug we face in Q is the offline charging mismatch (when the phone is powered off and shows the charging animation) and that one actually causes issues, TWRP mismatch is fine and can be ignored, offline mismatch however no
------------------------------------------------------------------------------------------------------------------------------------------------------
For the charging mismatch i am almost 100% certain it is something wrong in the ramdisk, since Q has moved it to vendor, and ditched all device-specific / samsung-specific nodes from init.rc , we lack a ton, ive added most of them in V5 which may be the reason why the overnight crash was gone, but we still have more to go to figure out why 2 charging scenarios show up with different percentages,
for those that have significant gap (and i mean atleast 5% difference) it would help if you can send me your dmesg by following the logging kit, and then power off your phone, let it show offline charging, then hold the recovery combo and send me log_kmsg also via the logging kit.
this might give us some tips on what is being read