-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Root Is this even possible?
- Thread starter Steven58
- Start date
-
- Tags
- motorola droid x
Any chance of your putting up a donation email?
Man, my family (especially my wife) has been hounding me about this, lol (or to put ads in or charge 99-cents for the app)...
Your thanks and support is payment enough.
FragDroidX
Android Expert
Any chance of your putting up a donation email?
What he said. You really deserve something for the many hours you must be putting into this. Please let us donate!
Any chance of your putting up a donation email?
Thanks guys!
I'll check into seeing if I can create a donate link that I could redirect the proceeds to a worthy cause (I'm thinking animal shelter)--my wife would be happy with that alternative too
.
Steven's been keeping it to himself (he told me I wasn't allowed to tell anyone else!
).edit: since it was his idea, of course.
Steven's gonna ban me for thanking you for the above .
.
VoidedSaint
Resident Ninja
you know i like the battery monitor
the only issue i have is the fact that whenever i get a txt with it on, it doesnt show the blinking light for it, and where my phone is on vibrate at work and it doesnt really vibrate at all(cant figure out why) it vibrates on phone calls and voicemails and thats about it, but other than that this is a great app scary alien
the only issue i have is the fact that whenever i get a txt with it on, it doesnt show the blinking light for it, and where my phone is on vibrate at work and it doesnt really vibrate at all(cant figure out why) it vibrates on phone calls and voicemails and thats about it, but other than that this is a great app scary alien
Thank you for the feedback and kind words!
I don't normally have the vibration setting turned-on for incoming SMS text notifications, but I just tested this (BTW, my phone is rooted, stock (no custom ROMs or themes)) with the vibration setting turned on (and using the stock "Text Message" app):
1. running BattMonX w/60 second polling-interval, using root-only LED-always-ON setting, screen turned OFF: result, SMS text came in, phone vibrated, blinking green LED, standard SMS notification sounded (all of this happened simultaneously)
2. running BattMonX w/60 second polling-interval, not using root-only LED-always-on setting, screen turned OFF: result, SMS text came in, phone vibrated, standard SMS notification sounded immediately -- LED did not turn green and blink immediately because the app was "asleep" (i.e., Android was not giving it CPU cycles because the phone was off (I verified this from the logcat log)).
BattMonX will step-aside when it gets the SMS text notification and cancel its last notification API call for the LED to allow the SMS text to come in and take control of the LED. So, if Android has put the phone in a quiesced state (low battery consumption, etc.) it doesn't seem to always wake-up my app...so this might be happening in your case too.
I would think that if you are rooted and using the LED-always-on feature, you should see any immediate notifications (LED change, vibration, and sound if applicable) since the only thing my app is doing in this mode is tweaking the brightness files to keep the LED on (i.e., I'm not actually using the notification API, so there's nothing "in front" of the SMS text notification). Another great reason to have root and to use this new LED-always-ON feature
.This is on-par with exactly my experiences and testing without the vibration setting on, so I'm not sure what is going on with your phone...
Are you rooted, custom ROM, themed, running different SMS client? (not sure that knowing the answers to these would lead me to know anything new or different, lol, but different environments might lead to different behavior).
Anyone else having an SMS notification vibration issue and/or wanna test this out too?
I'll keep thinking about this and searching for ways to have my app not get quiesced by Android without creating a CPU or battery-consumption penalty (this is the last thing I want--I want and made my app to be as lightweight and straightforward as possible).
Cheers!
Wow, I had to re-type my response a couple of times, lol because of what I found / see in (re-)testing this
(for about the last half-hour).I do see some "weirdness" in my log file regarding the white LED color (and I'm seeing basically the same things you are reporting)...
Let me get back to you...(hopefully soon).
Meh, I'm an idiot--the "weirdness" I was seeing was being caused by things I was doing, lol (using the LED color tester to force different LED colors to watch them change to the configured white LED color).
Okay, let me tell you what I think you were doing and what I think is happening:
1. You set the discharging color to white (root-only)
2. You turned off the screen
3. The LED turned blue (that's what color mine goes to, I'm betting / hoping yours does/did too (simply for the sake of consistency and trouble-shooting, that is))
I believe (and my testing bears this out), if you wait long enough (usually, the length of whatever the polling-interval is set to), the LED will turn to white as you configured it.
Let me know if you see this.
The wait time for the LED to change from the "turned-off-blue-color" to white (or actually, whatever color it is that you've selected) is dependent on two things:
1. The length of the polling interval (you might get lucky and not have to wait that long if you are closer to the end of the current polling interval anyway) for the battery state to be checked and the LED set to its assigned color.
2. If the screen is off and Android is "sleeping" (quiescing) app processing (as I described in my reply to VoidedSaint above), you might have to wait longer until Android doles-out some CPU cycles for BattMonX to resume processing. Hopefully, this is only a minute or two longer than normal.
Additionally, as part of the most recent change to the app to make it more responsive, while I still only check the battery state every "polling-interval" seconds, I actually check for other events (SMS texts, screen on/off, preference changes, etc.) every 30 seconds.
I noticed just a few minutes ago that the app on my phone had lost track of the screen on/off intent notifications and was not reacting to or reporting to screen on/off changes. This is something I believe I can easily fix, but this might have also contributed to the wait/delay in you seeing the LED change.
Make sense? Whew! Its really hard describing all of the possible conditions under which the app might work (never mind coding it to actually work properly).
Cheers!
(using the LED color tester to force different LED colors to watch them change to the configured white LED color).Okay, let me tell you what I think you were doing and what I think is happening:
1. You set the discharging color to white (root-only)
2. You turned off the screen
3. The LED turned blue (that's what color mine goes to, I'm betting / hoping yours does/did too
(simply for the sake of consistency and trouble-shooting, that is))I believe (and my testing bears this out), if you wait long enough (usually, the length of whatever the polling-interval is set to), the LED will turn to white as you configured it.
Let me know if you see this.
The wait time for the LED to change from the "turned-off-blue-color" to white (or actually, whatever color it is that you've selected) is dependent on two things:
1. The length of the polling interval (you might get lucky and not have to wait that long if you are closer to the end of the current polling interval anyway) for the battery state to be checked and the LED set to its assigned color.
2. If the screen is off and Android is "sleeping" (quiescing) app processing (as I described in my reply to VoidedSaint above), you might have to wait longer until Android doles-out some CPU cycles for BattMonX to resume processing. Hopefully, this is only a minute or two longer than normal.
Additionally, as part of the most recent change to the app to make it more responsive, while I still only check the battery state every "polling-interval" seconds, I actually check for other events (SMS texts, screen on/off, preference changes, etc.) every 30 seconds.
I noticed just a few minutes ago that the app on my phone had lost track of the screen on/off intent notifications and was not reacting to or reporting to screen on/off changes. This is something I believe I can easily fix, but this might have also contributed to the wait/delay in you seeing the LED change.
Make sense? Whew! Its really hard describing all of the possible conditions under which the app might work (never mind coding it to actually work properly
).Cheers!
Metfanant,
I neglected to address the other thing you mentioned about other colors that didn't work... Did you mean colors that you selected from the menus or colors that you tested in the LED Color Tester?
Cheers!
Uploaded version 2.2 of the app to the Market last night. Here's the highlights:
- added more strategies for making the app more responsive when screen off & unplugged (I implemented a partial wakelock for one minute after the screen is turned off)
- added 'Set LED Colors by Percent Charged' feature (i.e., you can assign a different color to each 10% range of battery percent-charged)
- added 'Rainbow Mode' (under Fun Stuff) to cycle through the various LED colors
- added 'Keep CPU On' feature to allow you keep the CPU awake/on when the screen is turned off (this is only true when monitoring is active); *** Warning *** this will consume more battery!
- added preset-color buttons to LED color tester (easier to test main colors)
You might have noticed that I last posted about v1.8...what happened to the versions 1.9 through v2.1? Well, here's the scoop:
- v1.9 was just a very minor update to not display percent signs in menu items that was causing FCs in some Milestone phones running non-stock ROMs (CM XML parser apparently behaves differently than stock Android)
- v2.0 was the original release of what is now v2.2; I had to rescind v2.0 to fix a loop (and the FCs) caused when using the color none/off under certain circumstances
- v2.1 was a re-publish of v1.9 until I could fix the FC issue in v2.0
Let me know if you have any questions. Hope you enjoy this new version.
Cheers!
- added more strategies for making the app more responsive when screen off & unplugged (I implemented a partial wakelock for one minute after the screen is turned off)
- added 'Set LED Colors by Percent Charged' feature (i.e., you can assign a different color to each 10% range of battery percent-charged)
- added 'Rainbow Mode' (under Fun Stuff) to cycle through the various LED colors
- added 'Keep CPU On' feature to allow you keep the CPU awake/on when the screen is turned off (this is only true when monitoring is active); *** Warning *** this will consume more battery!
- added preset-color buttons to LED color tester (easier to test main colors)
You might have noticed that I last posted about v1.8...what happened to the versions 1.9 through v2.1? Well, here's the scoop:
- v1.9 was just a very minor update to not display percent signs in menu items that was causing FCs in some Milestone phones running non-stock ROMs (CM XML parser apparently behaves differently than stock Android)
- v2.0 was the original release of what is now v2.2; I had to rescind v2.0 to fix a loop (and the FCs) caused when using the color none/off under certain circumstances
- v2.1 was a re-publish of v1.9 until I could fix the FC issue in v2.0
Let me know if you have any questions. Hope you enjoy this new version.
Cheers!
New version just published. Lots of new goodies!
Here's the change log:
Version 2.3 - 14-Mar-2011:
- support option to display status bar notification icon with battery percent charged
- support option to turn off use of LED battery state indication
- more accurate app behavior for Moto Droid-class phones via 1% charge delta vs. original 10% delta
- support blink action for monitor-by-percent charged mode (screen off only)
- additional logic to try to support other phones like Sony Ericsson Xperia x10 family
- lots of app cleanup; re-organized preferences / settings menus
Check it out and let me know what you think!
Cheers!
Here's the change log:
Version 2.3 - 14-Mar-2011:
- support option to display status bar notification icon with battery percent charged
- support option to turn off use of LED battery state indication
- more accurate app behavior for Moto Droid-class phones via 1% charge delta vs. original 10% delta
- support blink action for monitor-by-percent charged mode (screen off only)
- additional logic to try to support other phones like Sony Ericsson Xperia x10 family
- lots of app cleanup; re-organized preferences / settings menus
Check it out and let me know what you think!
Cheers!
Sorry I didn't reply earlier...not getting timely forum email notifications...weird..
There are a few slight changes...and I think minor fixes (its all been a blur, lol).
It probably wouldn't hurt just in case you run into an issue...that way I'll now you are running the same one that I published (your version was very close though...it might not have had the battery status icons for the dark status bar though...).
Already working on v2.4
(based on some suggestions and a couple of other things)Cheers!
lol... I've -- created -- a -- MONSTER!
(and his name be "Steven" ).I actually haven't even pushed it to my phone yet...still coding...
I can send you my 5.25" floppy disks containing Zork I, II, and III for my 1984 Kaypro II...will that help?
Okay guys, new v2.4 version is up .
This version has some new features that I hope you'll like and lots of minor revisions and improvements.
Enjoy!
RECENT CHANGES (version 2.4 - 26-Mar-2011):
- app should now work on all Android devices by using system intents (now the default setting) vs. reading battery status files (still supported)
- supported low-battery condition sound or vibrate alert
- supported high battery temperature monitoring similar to low-battery monitoring (especially useful for those who overclock or tether)
- notification changes: make app launch when pull-down notification selected; option to allow notification to be cleared; add battery temperature & voltage to notification shade details
- make low-battery & high-temp monitoring independent from the two main monitoring modes
- show change log at first/fresh install
- revised menus to reference 'status' instead of 'LED' to indicate support of both status bar icon and LED
- fixed issue w/LED color none/off not showing status bar notification
- supported logging of trace messages to SD card file for debugging if needed
- added donate button (happy now, Steven?)
- lots of minor fixes and improvements
.This version has some new features that I hope you'll like and lots of minor revisions and improvements.
Enjoy!
RECENT CHANGES (version 2.4 - 26-Mar-2011):
- app should now work on all Android devices by using system intents (now the default setting) vs. reading battery status files (still supported)
- supported low-battery condition sound or vibrate alert
- supported high battery temperature monitoring similar to low-battery monitoring (especially useful for those who overclock or tether)
- notification changes: make app launch when pull-down notification selected; option to allow notification to be cleared; add battery temperature & voltage to notification shade details
- make low-battery & high-temp monitoring independent from the two main monitoring modes
- show change log at first/fresh install
- revised menus to reference 'status' instead of 'LED' to indicate support of both status bar icon and LED
- fixed issue w/LED color none/off not showing status bar notification
- supported logging of trace messages to SD card file for debugging if needed
- added donate button (happy now, Steven?
)- lots of minor fixes and improvements
- added donate button [COLOR="Red"](happy now, Steven?
- lots of minor fixes and improvements
Very!
Very!
lol... I'm going to try to put up a "donate" version of the app on the Market and on the Amazon Market / App Store (whatever its called) so you don't have to monkey with entering any information when donating.
Sucks that I have to basically build and maintain a separate version / copy of the app to do this. Oh, well...