Database Info

[TEST]Battery Tests on Stock Galaxy S

First of all full credit goes out to sapiensbryan for giving me permission to post this from his blog.
I'm putting up here for everyone's information because I think this could be of use to us. There was only one link to one of the battery test videos on YouTube that I saw on XDA but not the complete test results or graph I am posting here, if I'm wrong I'm sure somebody will let me know.
I think a lot of us have forgotten or never knew how our phones battery reacted under these situations when it was running completely stock. I never had all this info and basically only knew how long my phone lasted on a charge.
Now we have a reference point as to how our modded ROM's are compared to stock.
Thanks again bryan for the work on this
___________________________________________________________________
A few friends, blog readers and twitter followers asked me about the battery life of Samsung Galaxy S in the past few days. Me too was interested to know what is the battery performance under extreme usage. Besides, I’m sure potential customers would like to see some statistics so that they can stop wondering about the battery performance of Samsung Galaxy S.
Therefore, I performed 4 battery tests 5 battery tests in the past 30+ hours 40+ hours and finally we have some answers to the battery related questions. Below are the objectives of all 4 battery tests I did :-
* Test 1: Find out how long will the battery last (from 100% battery level to 0%) when connecting to an active Wifi Connection
* Test 2: Find out how long will the battery last (from 100% battery level to 0%) when connecting to an active 3G Data Connection
* Test 3: Find out how long will the battery last under continuous movie playing
* Test 4: Find out how long we need to fully charge the battery after it’s completely flat (0% battery level)
* Just added 1 more Music Playing (Test 5).
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Samsung Galaxy S Battery Test Final Battery Test Results (now with Music Playing result)
General settings for all 4 tests
* Lowest brightness level
* Medium speaker volumn
* The screen is always lit throughout the tests
* Not running any screen saver
Test 1: Active Wifi Connection
* 1. Connect to an online radio via Wifi connection
* 2. Let it run until the phone switches off when the battery is depleted
Result: The phone was running for 9 hours 57 minutes before switching off itself.
Test 2: Active 3G Data Connection
* 1. Connect to an online radio via 3G Data connection
* 2. Let it run until the phone switches off when the battery is depleted
Result: The phone was running for 4 hours 47 minutes before switching off itself.
Test 3: Continuous Movie Playing
* 1. Continuously play some movies using the default movie player
* 2. Let it run until the battery level reaches 10%
Result: The phone was running for 6 hours 29 minutes before the battery level reached 10%. Movie player will stop running when the battery level falls to 10%. 6 hours 29 minutes of continuous playing time is more than enough to play 3 sets of movies at normal length.
Test 4: Charging Time
* 1. Fully charge the phone using original Samsung Travel Charger after the battery was completely depleted
Result: The phone needs 3 hours 47 minutes to get fully charged after the battery was completely depleted.
Below is the video documenting all the 4 battery tests :-
YouTube Video of First Four Tests
Test 5: Continuous Music Playing
* 1. Continuously play some songs via earphone using the default music player
Result: The phone was running for 13 hours 9 minutes and we still have 39% battery level. That’s about playing 263 songs of 3 minutes long each
Below is the video documenting the Music Playing test :-
YouTube Video of Music Test
I hope the results of the above battery tests are useful and help to clear doubts regarding Samsung Galaxy S battery performance. Now at least we have an idea how will the battery perform under extreme usage. As for normal usage, the phone should be able to last for the whole day under occasional Internet surfing, email checking, photo & video shooting, viewing video and listening to songs.

Not too bad, considering the screen never turned off.

ryude said:
Not too bad, considering the screen never turned off.
Click to expand...
Click to collapse
+1 it may not be a big deal to most but I thought this had some good info like the simple charging of the battery from dead to full. I don't even recall actually. And Whoah what a difference from wifi to using 3g.

Not bad...

LifeTab P9514 - New tablet

Hey folks,
ALDI brings the LifeTab P9514 to market.
What do you think?
Since i dont have 8 post i cant post the link here ^^
But a search on google with LifeTab P9514 should get enough results
Thanks

here is the link:
http://www.aldi-sued.de/de/html/offers/2827_30433.htm
What do you think? Is it good to buy?
or better a xoom?

I'm picking up 2 !!!!!
Even advertised on RTL News!
Chip Magazine great rating, best in price range, etc.

I do not think it is better than the Xoom, esp as MEDION stated on their Facebook page that the LifeTab won't have Gorillaglass and no IPS panel.
The pricetag is however most awesome, esp as you get 3g and everything in it plus extra headphones and a bag.
If they will have a unlockable bootloader, I'm all for it

what are the chances that the lifetab will be updated to ICS? that's really the only thing that keeps me from buying it at the moment.

MEDION said on their facebook page the update is coming, could not tell a time though.

Yeah i got one
They had like 7 pieces at store. And i got the first one
I will try to root it now and get CWM working

Androidpit posted a short Hands on Video:
http://www.androidpit.de/de/android...Tolles-Geraet-ab-heute-bei-Aldi-fuer-399-Euro (in German)
sounds pretty nice, but I think, I'll wait for the Transformer Prime.

JeanMo said:
Yeah i got one
They had like 7 pieces at store. And i got the first one
I will try to root it now and get CWM working
Click to expand...
Click to collapse
Tis what my group is doing (we're working on the 9.7" but close!)

Nice, we have a guinea-pig here!
Can you say something about the screen/glass?
Also, any chance to open the bootloader in adb? Medion wasn't too verbose on that point (they only said it's locked, but that's the case on the other tegra2 tablets too).
Oh, and on Facebook they say it hasnt 1GB ram? Could you verify that?

i didnt try to root it yet. But the tablet has Potential. Evrything runs smooth. The glass is a bit ugly and doesnt feels like an ipad or htc but its okay.
I am gonna try to root it now.. we will see what happens

Can you instann ConnectBot and just run "free" in a local shell? You should not need root for it.
Edith: meh, just tried on stock SE rom on an xperia -- no "free" :/

free doesnt work. Too bad.
Google doesnt show any technique how other people rooted a device at first.
So any tips? ^^

Could you install https://market.android.com/details?id=com.james.SmartTaskManagerLite or https://market.android.com/details?id=zausan.zdevicetest and look the RAM up?

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Thats what i got

first but problem -.- i cant connect to it via adb
it says no device found .. hmm

Code:
Bus 001 Device 007: ID 0408:b009 Quanta Computer, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0408 Quanta Computer, Inc.
idProduct 0xb009
bcdDevice 99.99
iManufacturer 1 Medion
iProduct 2 P9514
iSerial 3 37c618941209397
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 8 MTP
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x001c 1x 28 bytes
bInterval 6
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 66
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 9 Mass Storage
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07 EP 7 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
if someone is intrested in

lsusb looks like it supports mass storage, nice
for adb:
- did you enable usb debugging on the device?
- did you start adb as root/sudo? you will have to kill all running adb instances to retry

Well i couldnt get i mounted yet but i dont care about it so far.
And yes i know how to use adb ^^
I hope i will find a clue soon :-\

Heh, just wanted to be sure
Let us know when you find something

[Q] Help pinpointing my battery drain

So I have the latest CleanROM R7 on my phone, I did a clean install. I've been using it for some time before this issue came up. I've been getting some serious battery drain for the past couple weeks. Before I turned on usb fast charge my battery was draining faster than my car charger could charge it. Android OS, Google Services, and Android System are my 3 top battery suckers before the screen (with normal use). I'm using the latest d2 firmware found here: http://invisiblek.org/d2firmware.html
I think a lot of it may have to do with the new google maps update, but I have to believe there is a way I can fix this without having to turn off any location services or anything like that. I was using them before with no problem. It has been a couple weeks now so I don't believe it has anything to do with being in a weak signal area, or anything that might be unique to a very specific circumstance since I has been continuous throughout the weeks.
If anyone can help me pinpoint the battery drain it would be much appreciated!
Here is a screen of my battery stats
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Edit: Sorry, didn't realize that image would be so small, it says the battery is at 60% and 2:53:19 on battery.

I suggest installing BetterBatteryStats. There is an xda free version available if you search. Let it run for several hours then post the "Dump to txt" file as an attachment or via Pastebin. If you install BBS, check your Kernel Wakelocks and Partial Wakelocks to see what apps are being so disruptive.

SlimSnoopOS said:
I suggest installing BetterBatteryStats. There is an xda free version available if you search. Let it run for several hours then post the "Dump to txt" file as an attachment or via Pastebin. If you install BBS, check your Kernel Wakelocks and Partial Wakelocks to see what apps are being so disruptive.
Click to expand...
Click to collapse
Oh, I've had BBS installed for quite some time now, I was just never too sure how to use it. Didn't realize I could dump to text. Attached is the text dump!
Edit: Sorry, in my haste I only looked at this text file after posting. I just noticed it has only been running for and hour. I'll let it run longer and post the results later.

skytbest said:
Oh, I've had BBS installed for quite some time now, I was just never too sure how to use it. Didn't realize I could dump to text. Attached is the text dump!
Edit: Sorry, in my haste I only looked at this text file after posting. I just noticed it has only been running for and hour. I'll let it run longer and post the results later.
Click to expand...
Click to collapse
Just in that 1hr 15 min span, I can see you should configure some settings in either Maps or Settings/Sync. All your highest wakelock counts are Google service related based on the name. Although they're low in percentage, that's the best I can muster. For Maps, I always turn off Location Reporting. I usually keep my GPS unchecked so some of these will not completely go away if you keep GPS enabled all the time. As for the ones relating to Sync, I'm not to sure what can cause these since I keep Contacts, Gmail, and Calendar checked and everything else disabled.
NlpWakeLock (Google Services): 4 m 44 s (284 s) Count:231 6.3%
NlpCollectorWakeLock (Google Services): 2 m 59 s (179 s) Count:473 3.8%
WakefulIntentService[GCoreUlr-LocationReceiverService] (Google Services): 41 s (41 s) Count:843 0.9%
GOOGLE_C2DM (Google Services): 3 s (3 s) Count:479 0.1%
NlpLocationReceiverService (Google Services): 2 s (2 s) Count:596 0.1%
WakefulIntentService[GCoreUlr-LocationReportingService] (Google Services): 2 s (2 s) Count:238 0.1%
CDMA (Phone): 2 s (2 s) Count:394 0.0%
SyncLoopWakeLock (Android System): 1 s (1 s) Count:401 0.0%
StartingAlertService (Android System): 1 s (1 s) Count:167 0.0%
GpsLocationProvider (Android System): 1 s (1 s) Count:119 0.0%
Checkin Service (Google Services): 1 s (1 s) Count:339 0.0%
ServiceStateTracker (Phone): 1 s (1 s) Count:181 0.0%
VibratorService (Phone): 1 s (1 s) Count:183 0.0%
AlarmManager (Phone): 1 s (1 s) Count:219 0.0%
Icing (Google Services): 1 s (1 s) Count:343 0.0%
WakefulIntentService[GCoreUlr-ExternalChangeService] (Google Services): 1 s (1 s) Count:605 0.0%
Click to expand...
Click to collapse

SlimSnoopOS said:
Just in that 1hr 15 min span, I can see you should configure some settings in either Maps or Settings/Sync. All your highest wakelock counts are Google service related based on the name. Although they're low in percentage, that's the best I can muster. For Maps, I always turn off Location Reporting. I usually keep my GPS unchecked so some of these will not completely go away if you keep GPS enabled all the time. As for the ones relating to Sync, I'm not to sure what can cause these since I keep Contacts, Gmail, and Calendar checked and everything else disabled.
Click to expand...
Click to collapse
Thanks. I've been running it for a while longer now and I tried to catch it as close to it dying as my schedule allows right now. Seems like it is still the Google Services that are the main culprits. It is really annoying that this is the case. Do you know if this is a recent problem in the latest update (probably the new Google Maps)? I've always had the location setting on and never had a problem until now. I use Google Maps really often and don't want to turn these off.
I also notice DeskSMS is up there but it certainly isn't as significant as Google Services.
Thanks again for your help.

Also, do the kernel wake locks tell you anything? Looks like PowerManagerService is at the top there.

skytbest said:
Also, do the kernel wake locks tell you anything? Looks like PowerManagerService is at the top there.
Click to expand...
Click to collapse
I'm not the best at reading/interpreting these so other input is always welcome. From what the BBS knowledge base tells me, PowerManagerService is generic and it represents your Partial Wakelocks. Looking at the Partial Wakelocks tab would prove more beneficial. As I look at your txt, your battery drain (for the most recent txt) could be due to Maps given all the location tags and Maps activity that you say you do. I'm thinking the Google Services is doing damage behind the scenes. Google auto-pushes updates to this at will so you're not seeing much help from them. Do you have Location Reporting enabled in Maps?

SlimSnoopOS said:
I'm not the best at reading/interpreting these so other input is always welcome. From what the BBS knowledge base tells me, PowerManagerService is generic and it represents your Partial Wakelocks. Looking at the Partial Wakelocks tab would prove more beneficial. As I look at your txt, your battery drain (for the most recent txt) could be due to Maps given all the location tags and Maps activity that you say you do. I'm thinking the Google Services is doing damage behind the scenes. Google auto-pushes updates to this at will so you're not seeing much help from them. Do you have Location Reporting enabled in Maps?
Click to expand...
Click to collapse
Yes, I do. I'll try turning this off for a bit and see if there is any draw back in my day-to-day. I'm not exactly sure what this setting affects, just other Google apps won't be able to see my location?

skytbest said:
Yes, I do. I'll try turning this off for a bit and see if there is any draw back in my day-to-day. I'm not exactly sure what this setting affects, just other Google apps won't be able to see my location?
Click to expand...
Click to collapse
It mostly deals with Google Now since it's always checking for your location in the background.
Sent from my SCH-I535 using Tapatalk 4

[Q] Miscellaneous battery usage in 5.0.2

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I made a home made build of omni ROM. And I'm getting "Miscellaneous" in Battery stats. It's eating up hell lot of battery. Any idea on how to fix this inside the code ?

You can hide it changing from userdebug to user in the buildprop

Read below.
There is no "Misc bug" or "WiFi Bug" related to misc
Its really simple and basic and is in no way "drain".* All your battery stats are guessed calculations. They're never accurate. They never have been and never will be.
Basic version
Here's how battery stats work.*
In android, there is a file. It lists "power consumption" for certain things.*
For example (and these numbers are made up for simplicity)
WiFi disconnected = 4mA
WiFi connected = 10mA
So if your phone has been connected to WiFi for 10 hours, it calculates that 10 hours @ 10mA = x% of battery used.*
However, what if you're in your bedroom for 10 hours? The router is in your living room. Actually your WiFi is using 20mA because of the weal signal. Well, this magic file cannot account for that. There is no "WiFi connected but user is in bedroom = 20mA" entry in the file.*
Battery stats actually have no link to actual battery usage. Its just a guess. Battery stats knows how much battery has been used and using its magic file, makes an educated guess at how much % battery has been used by each thing.*
So your battery has depleted by 50%. 25% is WiFi connected at 10mA. But your WiFi was actually using 20mA because of distance. Battery stats cannot know this. So you actually have 25% missing in battery stats. That's what miscellaneous was created for. To show that there was a difference between battery stats guess and actual battery use from the battery.*
Its the same for screen brightness, cell signal, CPU usage etc. The file knows very little. Battery stats is very inaccurate
Google actually removed miscellaneous from stock ROMs due to people who don't understand, calling it a WiFi bug. However it still exists in aosp.*
Advanced version
How battery stats work
The Battery stats UI shows the percentage of battery that device elements are responsible for using, which is based on a couple of things.
1./data/system/batterystats.bin
2./system/frameworks/frameworks-res.apk/res/xml/power_profile.xml
These things contribute in the following way:
1.From the moment Android detects that a close-to-full charge has completed, batterystats.bin records how long the device elements are running
3.This xml file is where the information about how much power, each device element “uses”
The battery stats UI looks at batterystats.bin to see how long each element has been running (and in what state) since the last charge, applies the value (in mV) for each element stored in power_profiles.xml and comes up with a calculation of the % of battery each element is using.
It simply knows the total mV used by adding up all the element values and the time in state to work out the percentages.
Here is a really basic example…
power_profile.xml from the SNexus 5
Code:
*<item name="none">0</item> <item name="screen.on">82.75</item> <item name="screen.full">201.16</item> <item name="bluetooth.active">51.55</item> <item name="bluetooth.on">0.79</item> <item name="wifi.on">3.5</item> <item name="wifi.active">73.24</item> <item name="wifi.scan">75.48</item> <item name="dsp.audio">0.1</item> <item name="dsp.video">0.1</item> <item name="gps.on">76.23</item> <item name="radio.active">185.19</item> <item name="radio.scanning">99.2</item>
batterystats.bin
Code:
*** screen.on = 2 h
*** bluetooth.active = 3 h
*** bluetooth.on = 7 h
*** wifi.on = 6 h
*** wifi.active = 4 h
So, if….
Code:
*** screen.on = 165.5
*** bluetooth.active = 154.65
*** bluetooth.on = 5.53
*** wifi.on = 21
*** wifi.active = 292.96
*** Total = 639.64
Then…*
Code:
*** screen.on = 26%
*** bluetooth.active = 24%
*** bluetooth.on = 1%
*** wifi.on = 3%
*** wifi.active = 46%
*** Total = 100%
That was a basic example of how the Battery Stats UI makes it’s calculations.* Notice how the total is 100%? Well in KK and earlier this was the case.* The Battery Stats UI calculated to 100%.* So even if you had only used 50% of your battery, it would show that device elements had used 100% of your 50% used battery.
This meant that as it always had to add up to 100%, it didn't have to be particularly accurate.* It takes the values and calculations it knows about and works the portion of that 100% each known value has taken.* It knows that 639.64 is 100% therefore wifi at 292.96 must be 46%....
Since Lollipop, it has changed and makes it more difficult for battery stats UI to be so blase about its accuracy.* Now it attempts to show you what "actual" percentage of battery has been used.* For example, if 50% of your battery has been used, the total of percentage used by device elements will also show as 50%.* However, now that the total % of elements might not match the total % of battery used, it is much harder to hide how inaccurate battery stats actually are.
So to elaborate on that further, lets say that your Nexus 5 battery is 4720 mV in capacity.* The actual battery % in status bar is calculated by reading the actual current battery reading from the battery itself and working out the %, so in the example above, 14% battery has been used (639.64 is 14% of 4720 - or more accurately 13.55%)
So...*
Code:
*** screen.on = 3.6%
*** bluetooth.active = 3.4%
*** bluetooth.on = 0.05%
*** wifi.on = 0.5%
*** wifi.active = 6%
*** Total = 13.55%
Why are they never accurate?
So battery % in status* bar takes a reading from the actual battery, but battery stats just add up what they recorded multiplied by the Power_profile.xml values.
Looking at the power_profile.xml file, you'll see for example, wifi - there is an "on" value and an "active" value.* There are just 2 states.* However, what if your router is in your living room and you are in the bedroom?* WiFi Active may not be 76.23 at all.* Due to weak signal, it may be 150....* But battery stats is not aware that it may be using 150....* So it calculates using 76.23
This is where it gets a little more complicated.* Lets go back to these calculations, but factor in the new 150 value for bedroom wifi active
batterystats.bin
Code:
*** screen.on = 2 h
*** bluetooth.active = 3 h
*** bluetooth.on = 7 h
*** wifi.on = 6 h
*** wifi.active = 2 h
wifi.active.InBedroom = 2 h
So, if….
Code:
*** screen.on = 165.5
*** bluetooth.active = 154.65
*** bluetooth.on = 5.53
*** wifi.on = 21
*** wifi.active = 152.46
wifi.active.InBedroom = 300
*** Total = 799.14
So that is what ACTUALLY happened.* But Battery Stats doesn't know.. because the power_profile.xml does not really have the InBedroom entry at all.* So battery stats shows that a total 639.64 of battery has been used, however the physical battery reports that 799.14 has been used.* So the battery % in the status bar is 100% - 17%, = 83%....* 17% has been used but our earlier stats (that don't show the fake inbedroom value) show the total used is only 13.55% - there is a discrepancy here...
Well, since lollipop, that discrepancy has to be accounted for to make the battery stats appear more accurate, so the 159.50 difference that is unaccounted for (The Wifi InBedroom), now will appear as "Miscellaneous".* This makes battery stats show that 17% total battery has been used, to match the status bar and not 13.55% as per the total added up from Power_profile.xml...*
THis is not just the case with WiFI, but with everything from Screen brightness, to bluetooth to cell reception.
Why does misc show on some roms and not others
You may remember a while back that people were reporting the WiFi bug to google..* Well, simply - they probably got fed up and hid misc in Stock ROMS.* No stock roms on the Nexus 5 show misc anymore.* They just have calculations that no longer add up in total to the amount of % used of your battery
Some people have accused google of "hiding" the bug.* What we're saying is that there is NO BUG and they hid misc, which is what caused people to think there was a bug in the first place.
The Misc battery report is still in AOSP code, however some roms have also decided to hide it, such as SlimRoms for example.
You can see their changes here:
From Google: https://github.com/SlimRoms/packages_apps_Settings/commit/e6793771cedb47aed72f1c64f870b70357746938
Custom ROM feature: https://github.com/SimpleAOSP-Lolli...mmit/d025994f90722139dfcf236f275e05236ec47491
Here is an example on SlimLP with the option turned on and off
Summary
There is no such thing as a "misc bug" or "WiFi bug".* Android tries to calculate the amount of battery used by each device element, based on a very finite list of values.* Since the values are pre-determined in a file, it is not an accurate refelection of reality.* When these values in reality are higher than the file, it makes the Battery Stats show a lower % than reality being used by the elements (most easily seen in wifi).* To make the elements total match the actual % used from the battery, Misc was created to fill in that discrepancy - However, since people thought it was a bug due to lack of understanding, it has since been hidden.* But it is not a bug.
Click to expand...
Click to collapse

Always-On Speed - a new app that shows speed and time with always-on display

This thread is no longer updated, use this link instead: https://forum.xda-developers.com/gear-s3/themes/fitness-apps-speed-pace-heart-rate-t3709791/
I’ve developed an app for the Samsung Gear S and Gear S2 that shows speed (km/h, mi/h or m/s) and time with always-on display. It consumes a lot less power (about 17% an hour at full brightness) than any existing fitness app and has several features that prevent screen burn-in. It was designed for long-distance cycling and running. The name of the app is “Always-On Speed” and you can find it under "Health/Fitness" or "Utilities" in the Gear app store. I hope you like it!!
Description:
This application shows the speed and time while keeping the device awake. It does not log your activity. Please read the information below before using the app.
Make sure that GPS is enabled before starting the app. In order to turn on GPS, start or start and stop a workout in the S Health app or enable GPS manually on your smartphone.
• The app cannot enable GPS on your phone automatically.
• The app is only as accurate as your phone's GPS.
• Touch the speed indicator three times at an interval of at least one second to change the unit of speed (km/h → mi/h → m/s). The app will remember your choice next time you launch it.
There are several features that reduce power consumption (currently at ~17% per hour):
• The rotating bezel on the Gear S2 can be used to adjust the screen brightness. Note: in bright sunlight the brightness level locks at 100% and cannot be adjusted.
• Only one type of subpixels is used at a time, either red, green or blue.
• As soon as you stop moving, the device will start vibrating every 10 seconds. The app will close automatically after 1.5 to 3 minutes of inactivity.
Features that prevent screen burn-in:
• Numbers move up and down the screen.
• Tap the time indicator to change the font color from green to alternating red and blue. Note: red or blue text has very poor readability in bright sunlight.
• Font size changes.​
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

The app has undergone multiple bug fixes and code optimizations. A demo version has been released.

Check out Always-On Speed Pro - a new app that shows speed, heartrate, time, duration and distance traveled, elevation/altitude, and battery percentage! Note: I don't know about other Gear smartwatches, but the Gear S2 is not particularly great when it comes to monitoring heart rate; if the readings are way off, do not blame the app -- it merely displays the numbers provided by the OS. For higher accuracy, start the app before starting your ride or when you heart rate is ~60 bpm.
Always-On Speed Pro is meant to complement Always-On Speed. I use the latter during shorter rides and the former during longer rides.
All Always-On apps are now on sale (50% off or the lowest price allowed by the store, depending on the country) until September 11th.
___
Here is the full description of Always-On Speed Pro:
The application shows the following metrics:
• Speed in km/h, miles/h, or m/s. Update interval: 1 second. Accuracy: the faster you go, the more accurate the numbers are. The accuracy is very good at speeds above 20 km/h or 12 mph.
• Heart rate in beats per minute. Update interval: every few milliseconds. Accuracy: varies; restart the app if way off. Google "Gear [your model] heart rate accuracy" for more info.
• Current time in hours and minutes. Update interval: every second.
• Duration of travel in hours and minutes. Update interval: 10 seconds; pauses during stops.
• Distance travelled in kilometers or miles. Update interval: 10 seconds; pauses during stops. Accuracy: ±5%.
• Elevation/altitude (height above sea level) in meters or feet. Update interval: 1 second. Accuracy: ±3 meters (±10 feet) with clear sky, lower with clouds or if the GPS unit is under layers of clothes.
• Battery percentage. Update interval: 90 seconds. Wait one minute for the first reading.
Please read the following information before using the app:
• Tap the speed indicator three times at an interval of at least one second to change the unit of speed (km/h → mi/h → m/s). The app will remember your choice next time you launch it.
• Toggle heartrate sensor on and off by tapping the heartrate indicator.
• The display stays on until you quit the app.
• The app does not log your activity.
• Double tap on a metric to zoom in. Double tap again to zoom out.
• Make sure that GPS is enabled before starting the app. The app cannot enable GPS on your phone automatically. In order to turn on GPS, start or start and stop a workout in the S Health app or enable GPS manually on your smartphone.
There are several features that reduce power consumption (currently at ~25% per hour on the Gear S2):
• The rotating bezel on the Gear S2 can be used to adjust the screen brightness. Note: in bright sunlight the brightness level locks at 100% and cannot be adjusted.
• Only one type of subpixels is used at a time, either red, green or blue.
• As soon as you stop moving, the device will start vibrating every 10 seconds so that you don't forget to close the app after finishing your ride.
Features that prevent screen burn-in:
• Numbers slowly move up and down the screen.
• Tap the time indicator to change the font color from green to alternating red and blue. Note: red or blue text has very poor readability in bright sunlight.
Click to expand...
Click to collapse

Released version 2.0 of both Always-On Speed and Always-On Speed Pro, now showing the average and maximum speed for the last 60 seconds!

It is cool that there is an app can shows speed with AOD.