It turns out SystemClock.elapsedRealtime() is horribly wrong on a real
device (or at least mine). After turning my phone off then running an
app that just prints out the value for this, it came out to
870495360. On the emulator it's a much nicer number. Having said
that, it still works fine if
I'm starting the AlarmManager from a BOOT_RECEIVED broadcast and it
works like a charm. I've noticed, however, that it requires a restart
to take effect because it's triggered from a broadcast. In light of
this I also start the AlarmManager from the onCreate() of my activity
so that the user
AuxOne wrote:
I've read that Alarms/Services set from the Activity are destroyed
when the Activity is.
I don't know where you have seen that, but I am not aware of such a
limitation. Got a link?
The only times I know of when alarms get nuked are:
-- on a reboot, all alarms go poof!
-- if the
It just occurred to me that if I create it from a static context it
shouldn't really die with the Activity. That's what I used to be
doing, but later I switched it to an instantiated class. I'll see what
happens.
On Mar 27, 9:12 am, AuxOne tyler.thack...@gmail.com wrote:
I'm starting the
AuxOne wrote:
It just occurred to me that if I create it from a static context it
shouldn't really die with the Activity.
AFAIK, AlarmManager alarms are not dependent upon the particular
component that created them.
--
Mark Murphy (a Commons Guy)
http://commonsware.com |
Then maybe it's the Service that is dependent? All I know is it works
after reboot, but not after immediately installing (and starting Alarm
from Activity). It's a 1 hour+ timer.
On Mar 27, 9:18 am, Mark Murphy mmur...@commonsware.com wrote:
AuxOne wrote:
It just occurred to me that if I
AuxOne wrote:
Then maybe it's the Service that is dependent? All I know is it works
after reboot, but not after immediately installing (and starting Alarm
from Activity). It's a 1 hour+ timer.
Like I said, I am not aware of any such limitation. As I wrote, the only
times I know of when alarms
I can't say I've had these problems with my code - I have the
alarmmanager set to wake my app up every 'x' minutes (the pending
intent kicks off a service) and from there I open an HTTP connection
to a server. The server holds a PARTIAL wake lock so the phone
doesn't go back to sleep immediately.
So perhaps it would suffice to just Thread.sleep() for 30 seconds
after WakeLock is set, to wait for the Wifi. I'll experiment with that.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
You need a partial wakelock and internet permission.
On Mar 24, 3:56 pm, AuxOne tyler.thack...@gmail.com wrote:
I have a Service/AlarmManager set to go off ever hour; as seen
at:http://github.com/commonsguy/cw-advandroid/tree/master/SystemServices...
The Alarm triggers a Socket connection to
Thanks for your reply.
I have the permission (it works on a short timer), and the WakeLock
(as seen at the link in the OP).
Perhaps I'm using the lock incorrectly? Could anyone confirm? Most of
the lock code is here:
The wi-fi lock sounds interesting, but I'd need it to work with the
cellular network as well. Can I lock both? Actually, a lot of my
testing is probably happening over wi-fi since for some reason my Dev
1 Phone doesn't like my ATT iPhone SIM card for data connections.
Perhaps it really does work
AuxOne wrote:
The wi-fi lock sounds interesting, but I'd need it to work with the
cellular network as well. Can I lock both?
Cellular data should be always on, if I understand correctly.
Within the doWakefulWork function I instantiate a class and call one
of its methods. It ultimately
I have Threads because when the Alarm triggers I want to do two
separate things, although they don't necessarily have to be at the
*same* time so I'll remove the Thread.
For the WiFi lock I'm acquiring and releasing two locks now. Is that
about right?
My WiFi lock looks like:
PowerManager mgr =
AuxOne wrote:
For the WiFi lock I'm acquiring and releasing two locks now. Is that
about right?
My WiFi lock looks like:
PowerManager mgr =
(PowerManager)context.getSystemService(Context.WIFI_SERVICE);
lockWifi = mgr.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,
LOCK_NAME_WIFI);
If this is something that's supposed to be going on 24x7, since keeping
the WiFi radio on all that time will drain the battery pretty good, I
think you're more going to need to just hang tight in your
doWakefulWork() until WiFi connectivity is restored.
It is indeed 24x7. What do you mean by
AuxOne wrote:
If this is something that's supposed to be going on 24x7, since keeping
the WiFi radio on all that time will drain the battery pretty good, I
think you're more going to need to just hang tight in your
doWakefulWork() until WiFi connectivity is restored.
It is indeed 24x7. What
Just to let you know, I experimented with FULL_WAKE_LOCK. Not only did
it not turn on the screen as it said it would, which is a good thing I
guess, but it also doesn't seem to lock as effectively as the
PARTIAL_WAKE_LOCK. Both seem to go into a deep sleep around 15-20 min
of use and then WiFi
18 matches
Mail list logo
