[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
On Mar 2, 9:42 am, Mariano Kamp mariano.k...@gmail.com wrote: So how does that work? Here's how nanoTweeter works (slightly abbreviated): The alarm BroadcastReceiver's onReceive() acquires a WakeLock and stores it in a static field so that the Service can access it later. It then starts a Service using Context.startService(). The Service's onStart() creates a Handler for the main thread and then creates and runs a new Thread. That Thread does the important work then releases the WakeLock and calls Service.stopSelf() on the main thread via the Handler that was set up earlier. I pretty much copied the model that the built-in Alarm app uses: http://android.git.kernel.org/?p=platform/packages/apps/AlarmClock.git;a=tree;h=refs/heads/release-1.0;hb=release-1.0 -- Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
Thank you Jon. And why do you use startService instead of binding to it, get the interface, calls something, and get rid of the binding? I was under the impression that startService would be for something that runs in the background like playing an audio file. 2009/3/2 Jon Colverson jjc1...@gmail.com On Mar 2, 9:42 am, Mariano Kamp mariano.k...@gmail.com wrote: So how does that work? Here's how nanoTweeter works (slightly abbreviated): The alarm BroadcastReceiver's onReceive() acquires a WakeLock and stores it in a static field so that the Service can access it later. It then starts a Service using Context.startService(). The Service's onStart() creates a Handler for the main thread and then creates and runs a new Thread. That Thread does the important work then releases the WakeLock and calls Service.stopSelf() on the main thread via the Handler that was set up earlier. I pretty much copied the model that the built-in Alarm app uses: http://android.git.kernel.org/?p=platform/packages/apps/AlarmClock.git;a=tree;h=refs/heads/release-1.0;hb=release-1.0 -- Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
You can't use bindService from a broadcast receiver, since the receiver might not be around long enough for your bind callback to happen. On Mon, Mar 2, 2009 at 12:11 PM, Mariano Kamp mariano.k...@gmail.com wrote: Thank you Jon. And why do you use startService instead of binding to it, get the interface, calls something, and get rid of the binding? I was under the impression that startService would be for something that runs in the background like playing an audio file. 2009/3/2 Jon Colverson jjc1...@gmail.com On Mar 2, 9:42 am, Mariano Kamp mariano.k...@gmail.com wrote: So how does that work? Here's how nanoTweeter works (slightly abbreviated): The alarm BroadcastReceiver's onReceive() acquires a WakeLock and stores it in a static field so that the Service can access it later. It then starts a Service using Context.startService(). The Service's onStart() creates a Handler for the main thread and then creates and runs a new Thread. That Thread does the important work then releases the WakeLock and calls Service.stopSelf() on the main thread via the Handler that was set up earlier. I pretty much copied the model that the built-in Alarm app uses: http://android.git.kernel.org/?p=platform/packages/apps/AlarmClock.git;a=tree;h=refs/heads/release-1.0;hb=release-1.0 -- Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
Hey Marco, actually I tried that and hit a ReceiverCallNotAllowedException [1] . But after using the ApplicationContext this seems to work fine. Cheers, Mariano [1] http://lampwww.epfl.ch/~linuxsoft/android/android-m5-rc15/docs/reference/android/content/ReceiverCallNotAllowedException.html On Mar 2, 2009, at 9:14 PM, Marco Nelissen wrote: You can't use bindService from a broadcast receiver, since the receiver might not be around long enough for your bind callback to happen. On Mon, Mar 2, 2009 at 12:11 PM, Mariano Kamp mariano.k...@gmail.com wrote: Thank you Jon. And why do you use startService instead of binding to it, get the interface, calls something, and get rid of the binding? I was under the impression that startService would be for something that runs in the background like playing an audio file. 2009/3/2 Jon Colverson jjc1...@gmail.com On Mar 2, 9:42 am, Mariano Kamp mariano.k...@gmail.com wrote: So how does that work? Here's how nanoTweeter works (slightly abbreviated): The alarm BroadcastReceiver's onReceive() acquires a WakeLock and stores it in a static field so that the Service can access it later. It then starts a Service using Context.startService(). The Service's onStart() creates a Handler for the main thread and then creates and runs a new Thread. That Thread does the important work then releases the WakeLock and calls Service.stopSelf() on the main thread via the Handler that was set up earlier. I pretty much copied the model that the built-in Alarm app uses: http://android.git.kernel.org/?p=platform/packages/apps/AlarmClock.git;a=tree;h=refs/heads/release-1.0;hb=release-1.0 -- Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
On Mar 2, 8:11 pm, Mariano Kamp mariano.k...@gmail.com wrote: And why do you use startService instead of binding to it, get the interface, calls something, and get rid of the binding? I was under the impression that startService would be for something that runs in the background like playing an audio file. You need to use startService any time you want the lifetime of the Service to be longer than the lifetime of whatever is starting it. As Marco mentioned, BroadcastReceivers are always supposed to be short- lived. -- Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
Jon, ok, I see a big plus for this approach. For a simple trigger interaction I don't have to define a service interface with a fake trigger method. I am still a bit unhappy about passing in the wake lock using a static variable, but well, I'll still go for this approach then. Thank you, Dianne and Marco for your help. Cheers, Mariano On Mon, Mar 2, 2009 at 5:41 PM, Jon Colverson jjc1...@gmail.com wrote: On Mar 2, 9:42 am, Mariano Kamp mariano.k...@gmail.com wrote: So how does that work? Here's how nanoTweeter works (slightly abbreviated): The alarm BroadcastReceiver's onReceive() acquires a WakeLock and stores it in a static field so that the Service can access it later. It then starts a Service using Context.startService(). The Service's onStart() creates a Handler for the main thread and then creates and runs a new Thread. That Thread does the important work then releases the WakeLock and calls Service.stopSelf() on the main thread via the Handler that was set up earlier. I pretty much copied the model that the built-in Alarm app uses: http://android.git.kernel.org/?p=platform/packages/apps/AlarmClock.git;a=tree;h=refs/heads/release-1.0;hb=release-1.0 -- Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
One thing you might want to try is to grab the wakelock in the
receiver itself, not in the thread. The way it is now, it's
theoretically possible for the receiver to exit and the phone to go
back to sleep before your threads ever gets a chance to run.
On Sun, Mar 1, 2009 at 9:27 AM, Mariano Kamp mariano.k...@gmail.com wrote:
And btw. I should have mentioned that the 30 minutes sleep is a placeholder
for the real action. In my case that would be downloading stuff from the
net. But to show that it doesn't depend on the workload and make it more
abstract I just put a sleep in there.
On Sun, Mar 1, 2009 at 6:20 PM, Mariano Kamp mariano.k...@gmail.com wrote:
Marco,
thanks for taking the time to respond.
(a) If you look at the code ( http://pastie.org/403831) you'll see that
it is in fact a custom log file (see class Persistent Log). The reason
behind that is to be able to have a look at the problem over a longer period
of time as it doesn't occur all the time. The default log seems to be a ring
buffer holding just the log for a couple of minutes and is not of much help
in this respect.
(b) The receiver is triggered by an alarm (see the full code) and spawns
of a Thread immediately.
From the pastie code mentioned above:
Intent i = new Intent(context, MyReceiver.class);
PendingIntent pi = PendingIntent.getBroadcast(context, 0, i, 0);
AlarmManager alarmManager = (AlarmManager)
getSystemService(ALARM_SERVICE);
alarmManager.setRepeating(AlarmManager.RTC_WAKEUP,
(System.currentTimeMillis() + 1000),
60 * 60 * 1000, pi);
Cheers,
Mariano
On Sun, Mar 1, 2009 at 6:13 PM, Marco Nelissen marc...@android.com
wrote:
It looks like the output you posted is from your custom log file, so
the first thing I'd do is to look at the system log to make sure that
the problem isn't in your custom logging code.
Also, doing anything lengthy in a broadcast receiver is a Bad Idea,
and keeping the device awake while you're doing it is a Really, Really
Bad Idea. If you need to do something every 30 minutes, you should
schedule an alarm, not sleep for 30 minutes with a wakelock held.
On Sun, Mar 1, 2009 at 8:42 AM, Mariano Kamp mariano.k...@gmail.com
wrote:
Hi,
I don't really know how to phrase my question as I don't know what
the
problem is. The symptom is that scheduled background activities are not
completed and I want to know why that is and how I can further
debug/solve
it.
This is happening with NewsRob and the background synchronization
that
loads articles from Google Reader at a scheduled interval. To debug it
I
meanwhile created a synthetic sample that shows the behavior too. A
Thread
is started once an hour, acquires a partial wake lock, logs something,
sleeps for 30 minutes and then releases the partial wake lock and logs
again.
So it should look something like this:
28 04:02: onReceive
28 04:02: In aquire
28 04:32: After release
28 being the day of the month followed by the time and message.
Unfortunately it doesn't look like that all the time ;-) (Blank
Lines and
comment added for readability).
28 05:02: onReceive
28 05:02: In aquire
28 05:32: After release
28 06:02: onReceive
28 06:02: In aquire
After release missing
28 07:02: onReceive
28 07:02: In aquire
After release missing
28 08:02: onReceive
28 08:02: In aquire
After release missing
28 09:02: onReceive
In aquire missing
After release missing
So I suspect I do something wrong with the partial wake lock? But
what?
And even if that is the case what should happen then? Shouldn't it
continue
to run when a button on the device is pressed?
So here is the full sample code: http://pastie.org/403831
And here is the relevant method:
public void onReceive(final Context context, Intent intent) {
PersistentLog.log(onReceive, context);
new Thread(new Runnable(){
public void run() {
PowerManager pm = (PowerManager)
context.getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl =
pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, SomeTag);
wl.acquire();
PersistentLog.log(In aquire, context);
SystemClock.sleep(30 * 60 * 1000);
wl.release();
PersistentLog.log(After release, context);
}
}).start();
}
Any ideas?
Cheers,
Mariano
ps. Yes, I've seen the typo. Thanks for not bringing it up ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
Thanks for not giving up on me ;-)
I thought about that, but the log shows that I acquired the lock and then
nothing more happens.
Also I would need to use a Thread.join() in the onReceive Method to wait for
the thread to finish, which would lead to a long execution of the
onReceive() method.
If you think my arguments are wrong and still believe this is a valid
approach I can give it a shot. Otherwise I would rather wait a little bit
for other suggestions as this problem doesn't occur frequently (but often
enough to annoy the NewsRob users) enough to trigger it in a short period of
time and therefore I can basically just try one approach per day, actually
night ;-)
On Sun, Mar 1, 2009 at 6:35 PM, Marco Nelissen marc...@android.com wrote:
One thing you might want to try is to grab the wakelock in the
receiver itself, not in the thread. The way it is now, it's
theoretically possible for the receiver to exit and the phone to go
back to sleep before your threads ever gets a chance to run.
On Sun, Mar 1, 2009 at 9:27 AM, Mariano Kamp mariano.k...@gmail.com
wrote:
And btw. I should have mentioned that the 30 minutes sleep is a
placeholder
for the real action. In my case that would be downloading stuff from the
net. But to show that it doesn't depend on the workload and make it more
abstract I just put a sleep in there.
On Sun, Mar 1, 2009 at 6:20 PM, Mariano Kamp mariano.k...@gmail.com
wrote:
Marco,
thanks for taking the time to respond.
(a) If you look at the code ( http://pastie.org/403831) you'll see
that
it is in fact a custom log file (see class Persistent Log). The reason
behind that is to be able to have a look at the problem over a longer
period
of time as it doesn't occur all the time. The default log seems to be a
ring
buffer holding just the log for a couple of minutes and is not of much
help
in this respect.
(b) The receiver is triggered by an alarm (see the full code) and
spawns
of a Thread immediately.
From the pastie code mentioned above:
Intent i = new Intent(context, MyReceiver.class);
PendingIntent pi = PendingIntent.getBroadcast(context, 0, i, 0);
AlarmManager alarmManager = (AlarmManager)
getSystemService(ALARM_SERVICE);
alarmManager.setRepeating(AlarmManager.RTC_WAKEUP,
(System.currentTimeMillis() + 1000),
60 * 60 * 1000, pi);
Cheers,
Mariano
On Sun, Mar 1, 2009 at 6:13 PM, Marco Nelissen marc...@android.com
wrote:
It looks like the output you posted is from your custom log file, so
the first thing I'd do is to look at the system log to make sure that
the problem isn't in your custom logging code.
Also, doing anything lengthy in a broadcast receiver is a Bad Idea,
and keeping the device awake while you're doing it is a Really, Really
Bad Idea. If you need to do something every 30 minutes, you should
schedule an alarm, not sleep for 30 minutes with a wakelock held.
On Sun, Mar 1, 2009 at 8:42 AM, Mariano Kamp mariano.k...@gmail.com
wrote:
Hi,
I don't really know how to phrase my question as I don't know what
the
problem is. The symptom is that scheduled background activities are
not
completed and I want to know why that is and how I can further
debug/solve
it.
This is happening with NewsRob and the background synchronization
that
loads articles from Google Reader at a scheduled interval. To debug
it
I
meanwhile created a synthetic sample that shows the behavior too. A
Thread
is started once an hour, acquires a partial wake lock, logs
something,
sleeps for 30 minutes and then releases the partial wake lock and
logs
again.
So it should look something like this:
28 04:02: onReceive
28 04:02: In aquire
28 04:32: After release
28 being the day of the month followed by the time and message.
Unfortunately it doesn't look like that all the time ;-) (Blank
Lines and
comment added for readability).
28 05:02: onReceive
28 05:02: In aquire
28 05:32: After release
28 06:02: onReceive
28 06:02: In aquire
After release missing
28 07:02: onReceive
28 07:02: In aquire
After release missing
28 08:02: onReceive
28 08:02: In aquire
After release missing
28 09:02: onReceive
In aquire missing
After release missing
So I suspect I do something wrong with the partial wake lock? But
what?
And even if that is the case what should happen then? Shouldn't it
continue
to run when a button on the device is pressed?
So here is the full sample code: http://pastie.org/403831
And here is the relevant method:
public void onReceive(final Context context, Intent intent) {
PersistentLog.log(onReceive, context);
new Thread(new Runnable(){
public void run() {
PowerManager pm =
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
On Sun, Mar 1, 2009 at 9:43 AM, Mariano Kamp mariano.k...@gmail.com wrote: Thanks for not giving up on me ;-) I thought about that, but the log shows that I acquired the lock and then nothing more happens. Except in the last example you gave, where it doesn't even get to the acquire. Also I would need to use a Thread.join() in the onReceive Method to wait for the thread to finish, which would lead to a long execution of the onReceive() method. I was thinking you would acquire the lock in the receiver, but free it in your thread. The receiver wouldn't actually have to wait for the thread to finish. If you think my arguments are wrong and still believe this is a valid approach I can give it a shot. Otherwise I would rather wait a little bit for other suggestions as this problem doesn't occur frequently (but often enough to annoy the NewsRob users) enough to trigger it in a short period of time and therefore I can basically just try one approach per day, actually night ;-) Another possibility is that your process simply gets killed during the 30 minute period. Since the activity manager doesn't know about your thread, it may conclude that your process is idle and decide to kill it to free up resources. You can tell if this happens by looking at the system log, but in any case you should probably do the actual work in a service, rather than using a plain Thread. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Problems with background activities or partial locks or something completely altogether?!
I don't think it's valid to start a Thread in a BroadcastReceiver. The system doesn't know anything about that thread, so it wouldn't know that it's supposed to keep the process hosting it around. My app nanoTweeter does similar background polling and I acquire the WakeLock in the BroadcastReceiver and then start a Service. That service releases the lock when it's done. -- Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
