FORUMS
Remove All Ads from XDA
Honor 7x
Win an Honor 7X!

[APP][SVC][Mar 8, 2010] BattLineSvc V2.1 / Battery Indicator Line in Title Bar

894 posts
Thanks Meter: 61
 
By thx1200, Inactive Recognized Developer on 1st March 2010, 04:17 AM
Post Reply Email Thread
31st March 2010, 09:34 AM |#101  
Senior Member
Thanks Meter: 8
 
Donate to Me
More
Quote:
Originally Posted by thx1200

I don't understand your chart. Can you elaborate?

The chart is pretty simple
Each line has the following data:
1. The date and time of the battery level sample
2. The battery level showed at that time on the status screen, afer tapping the taskbar (if a sample was missed - ??? would be shown)
3. If BattLineSVC was installed it would show ++ (if not it would show --)
4. if Co0kieMonster HomeTab was installed it would show ++ (if not --)
(if nothing was instaled - both BattLineSvc and Co0ki'sHT would show --)

As can be seen - when BattLineSvc is installed, the battery percentage drop 2-3 percent per hour.

The measurements taken for BattLineSvc were done at the same place (so there's no issue with different levels of celular reception), with all other wireless comm in the "off" position, and with the device mostly in "suspend" mode (just to take out every possible variable).
 
 
31st March 2010, 09:35 AM |#102  
Senior Member
Thanks Meter: 8
 
Donate to Me
More
Quote:
Originally Posted by thx1200

Well, honestly, you will see at least one post on EVERY application of somebody who claims battery loss. lol.

That said, I do take these reports seriously, but I just don't see any way BLS is causing this.

Can all of you with battery issues confirm that the Forced Update Interval is set to 0?

Yep. Forced update is set to 0.
31st March 2010, 09:41 AM |#103  
Senior Member
Thanks Meter: 8
 
Donate to Me
More
Quote:
Originally Posted by thx1200

4-5 days of life??? What device are you using? i haven't seen that kind of battery life from any smart phone before.

Considering the fact I practically use this device as a PDA, with no PhoneCalls, no SMSs, and very little internet use, I believe you can see how it lasts 4-5 days.

Internet usage however "costs" greatly in battery life -
1 hour of normal internet broesing "costs" about 30% of battery.

And just to be clear - The measurements taken for BattLineSvc were done at the same place (so there's no issue with different levels of celular reception), with all other wireless comm in the "off" position, and with the device mostly in "suspend" mode (just to take out every possible variable).
31st March 2010, 10:03 AM |#104  
Senior Member
Thanks Meter: 8
 
Donate to Me
More
Quote:
Originally Posted by thx1200

Here's the guts of BLS...

Code:
 g_mq = CreateMsgQueue(L"AvianWavesBattLineSvcPwrNotifQueue", &mqopt);
  if (g_mq)
  {
    g_pn = RequestPowerNotifications(g_mq, PBT_TRANSITION | PBT_POWERSTATUSCHANGE | PBT_POWERINFOCHANGE);
    if (g_pn)
    {
      while (WaitForSingleObject(g_mq, INFINITE) == WAIT_OBJECT_0) 
      {
        // Eat the power notification
        ReadMsgQueue(g_mq, &buf, sizeof(DWORD) * 16, &numberRead, -1, &flags);

        // Refresh the battery on any power change (we repeat several times since sometimes the battery level does not refresh in sync with the status change
        RefreshBatteryStatus();
        g_nowRepeat = 1;
        if (g_battTimerNowProc == 0)
        {
          g_battTimerNowProc = SetTimer(0, 0, 2000, battTimerNowProc);
        }
      }
    }
    g_pn = NULL;
  }

The following seems problematic to me:
Quote:
Originally Posted by thx1200

Code:
while (WaitForSingleObject(g_mq, INFINITE) == WAIT_OBJECT_0)
Sleep indefinitely until the OS gives us a message on the message queue.

Considering the fact that MSN sais:
<http://msdn.microsoft.com/en-us/library/ms687032(VS.85).aspx>
The WaitForSingleObject function can wait for the following objects:

Change notification
Console input
Event
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

I would have dropped that completly and would have changed:

Quote:
Originally Posted by thx1200

Code:
ReadMsgQueue(g_mq, &buf, sizeof(DWORD) * 16, &numberRead, -1, &flags);
We don't care what the message is because we perform the same action on any message, so we just do a ReadMsgQueue to eat the message, but don't use the data in the buffer.

to:
while (1){
if (ReadMsgQueue(g_mq, &buf, sizeof(DWORD) * 16, &numberRead, <INFINITE>, &flags)){....

and you know what . . .
your assumption that the battery level hardware is jittering and producing thousands of messages unnecessarily might also be possible.
you know, those little volemeters and ampermeters installed in these devices might have accuracy problems, and stability problems,
and might be effected by environmental RF transmissions (and considering a phone is an RF transmitter . . .)

Maybe you should dump a "debug mode" log of all the messages with the batt level and time you received the notification,
just to check that theory.
1st April 2010, 08:27 AM |#105  
thx1200's Avatar
OP Inactive Recognized Developer
Flag Raleigh, North Carolina
Thanks Meter: 61
 
More
Quote:
Originally Posted by pupakota

damn, 2000 only? set it for minimum 30000(upd: 10k..)...almost realtime is not good idea for such long line...2k is not especially needed, imo.
(just observation, nothing more).

I didn't put the code for the timer. That timer kills itself on entry if g_nowRepeat < 0, so it only iterates twice. This is done to do three measurements when the device resumes from sleep. Once immediately, and then two more two seconds apart. After that, it's done.
1st April 2010, 08:34 AM |#106  
thx1200's Avatar
OP Inactive Recognized Developer
Flag Raleigh, North Carolina
Thanks Meter: 61
 
More
Quote:
Originally Posted by Som30ne

while (1){
if (ReadMsgQueue(g_mq, &buf, sizeof(DWORD) * 16, &numberRead, <INFINITE>, &flags)){....


Good call. I see that dwTimeout can be set to INFINITE. I didn't notice that before. That might work well.

Just FYI, WaitForSingleObject is all over the place when you look for sample code with RequestPowerNotifications. That's where I got that idea from. Now that I've read the MSDN page on ReadMsgQueue, I agree with you that it's unnecessary.

I'm fairly confident it won't make a noticible difference considering the massive amount of code out there that uses it in this case, but every few cycles you can trim off the CPU, the better. :)
1st April 2010, 08:35 AM |#107  
thx1200's Avatar
OP Inactive Recognized Developer
Flag Raleigh, North Carolina
Thanks Meter: 61
 
More
Quote:
Originally Posted by Som30ne

Maybe you should dump a "debug mode" log of all the messages with the batt level and time you received the notification,
just to check that theory.

Also a good idea. I shall do that when I get some time to revisit this project again (maybe this weekend, maybe several weeks from now) ;)
1st April 2010, 07:10 PM |#108  
Senior Member
Thanks Meter: 8
 
Donate to Me
More
Quote:
Originally Posted by thx1200

Also a good idea. I shall do that when I get some time to revisit this project again (maybe this weekend, maybe several weeks from now) ;)

Im glad to see you took my remarks and Ideas seriously.
Id be looking forward for the modified (hopefully - loggable) version.
(if a loggable version will be available, I promise I would post a log of the app on my device)

Thanks in advance.
2nd April 2010, 09:42 AM |#109  
thx1200's Avatar
OP Inactive Recognized Developer
Flag Raleigh, North Carolina
Thanks Meter: 61
 
More
Quote:
Originally Posted by Som30ne

Im glad to see you took my remarks and Ideas seriously.
Id be looking forward for the modified (hopefully - loggable) version.
(if a loggable version will be available, I promise I would post a log of the app on my device)

Thanks in advance.

Even when I'm confident in my code, I'm always happy to be proven wrong because it means I've learned something new. :) I don't want to be a programmer with his head in the sand because of stubborness. :)

I look forward to seeing if any of these small changes help, or, more importantly, if the log reveals anything about how BLS is behaving that we haven't considered yet.
3rd April 2010, 08:35 AM |#110  
Hi thx1200,

again a screenshot while charging the battery. Happy to use this app.
Top right is NOT 95% battery, it is CPU needed performance at this moment.
Top right second is the drain of the battery at this moment....
4th April 2010, 10:00 AM |#111  
thx1200's Avatar
OP Inactive Recognized Developer
Flag Raleigh, North Carolina
Thanks Meter: 61
 
More
Quote:
Originally Posted by mike2nl

Hi thx1200,

again a screenshot while charging the battery. Happy to use this app.
Top right is NOT 95% battery, it is CPU needed performance at this moment.
Top right second is the drain of the battery at this moment....

I'm sorry, I don't understand. What's going on in that picture that I should take note of?
Post Reply Subscribe to Thread

Tags
battery, service, status, title bar, titlebar

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes