This is my current thinking too. I found a method in the PowerManagerService called "dump" that would be the perfect tool to help me out here (it lists all currently held wakelocks - along with other interesting items), but the method isn't exposed via the IBinder interface. If anyone knows of a secret code (or whatever) that can cause this method to be invoked....
On Jan 9, 5:28 am, MrChaz <[email protected]> wrote: > Maybe your app running it coincidently causing a problem with > something in the SenseUI widgets - they do fancy stuff with messages > etc don't they? > > On Jan 9, 3:32 am, Doug <[email protected]> wrote: > > > > > Hello, > > > I have an app that works on any version of Android from 1.5 up - this > > makes it compatible with the HTC Hero. Problem is, the Hero stays > > "awake" 100% of the time when its running. > > > For some strange reason (and this has only been reported to me by Hero > > users, although other devices could be having the same problem) the > > Hero will just *not* go to sleep when my app is running. The > > "Settings -> About Phone -> Status -> Awake Time" always shows the > > same value as "Up Time" when my app is running. The definition of > > this value seems to be "What percentage of the uptime has the phone > > NOT been in deep-sleep". > > > I've done a decent amount of searching on this problem. I see plenty > > of evidence that its a known issue with many apps (even some of HTC's > > own components) and that its been at least partially addressed by a > > firmware update late last year, but there doesn't appear to be any > > documentation as to what actually causes the problem. > > > So I spent a considerable amount of time analyzing my app and > > reworking large chunks of code that just might have been causing > > problems. No luck. > > > A bit about the app: > > * It is set up to run on phone boot > > * It registers its own ContentProvider > > * It has receivers for Phone status (calls), Data connectivity, > > Bluetooth availability, incoming SMS messages, and the apps own > > broadcasts > > * It has a "service" component that is started with the "startService > > (Intent)" call. The service shuts itself down when it's completed its > > work > > * It uses both Handler messages, and Broadcast Intents to communicate > > events of interest. > > * The service will spawn one or two worker threads to do its bidding, > > when the workers are done they will stop. > > * The app sets alarms to be woken up periodically (default once per > > hour) so it can connect to a server to check for updated data. > > * Because the background worker threads use HTTP to connect to > > servers, they are "protected" by WakeLocks (a wake-lock is acquired > > when the task begins, and is released when the task completes) > > * There is not a single "sleep" anywhere in the code (I've read > > elsewhere that "sleeping" is disapproved of) > > * I have logging from logcat showing that the background threads, > > service and WakeLocks are correctly releasing themselves and stopping > > * "Spare Parts" shows that the "Partial Wake" usage of my app is > > actually very low (sometimes doesn't even register on the list) > > > From a previous post by Diane: > > > > When no wake locks are held, the CPU will not run at all, and time has > > > effectively stopped for most scheduling (that is scheduling based on > > > SystemClock.uptimeMillis(), which is what most things like Handler and > > > Java > > > timeouts use). > > > So, given that my app isn't holding any WakeLocks, I don't understand > > what could be causing the phone to remain "awake" (screen off) when my > > app is not doing anything. Unless there is a WakeLock being held > > somewhere... that the mere startup of my app causes to be 'acquired'. > > > If anyone has any ideas - feel free to voice them. > > > If anyone can comment on whether they have encountered (and resolved) > > this problem I'd be grateful to hear from you too. > > > If anyone has any ideas as to whether an app (or system component) can > > keep the phone awake without it being visible to Spare Parts.... you'd > > be my hero (pun intended) > > > Doug
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
