Problems with background activities or partial locks or something completely altogether?!

by Mariano Kamp » Mon, 02 Mar 2009 00:42:51 GMT


Sponsored Links
 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 ;)

--~--~---------~--~----~------------~-------~--~----~



Problems with background activities or partial locks or something completely altogether?!

by Jon Colverson » Mon, 02 Mar 2009 02:50:17 GMT


 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

--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


Problems with background activities or partial locks or something completely altogether?!

by Al Sutton » Mon, 02 Mar 2009 15:41:39 GMT


 Thread's should never be started in a BroadcastReceiver because the 
containg task ends when the onReceive method ends.

The suggestion at 
 http://developer.android.com/guide/practices/design/responsiveness.html is ;

"But instead of doing intensive tasks via child threads (as the life of 
a BroadcastReceiver is short), your application should start a Service 
< http://developer.android.com/reference/android/app/Service.html> ; if a 
potentially long running action needs to be taken in response to an 
Intent broadcast."

Just as Jon has done.

Al
 http://andappstore.com/ 





-- 

* Written an Android App? - List it at  http://andappstore.com/  *

======
Funky Android Limited is registered in England & Wales with the 
company number  6741909. The registered head office is Kemp House, 
152-160 City Road, London,  EC1V 2NX, UK. 

The views expressed in this email are those of the author and not 
necessarily those of Funky Android Limited, it's associates, or it's 
subsidiaries.


--~--~---------~--~----~------------~-------~--~----~



Problems with background activities or partial locks or something completely altogether?!

by Jon Colverson » Tue, 03 Mar 2009 00:41:40 GMT


 


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

--~--~---------~--~----~------------~-------~--~----~



Problems with background activities or partial locks or something completely altogether?!

by Jon Colverson » Tue, 03 Mar 2009 05:05:04 GMT


 


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

--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. onSaveInstanceState behaving differently when rotating the screen and anything else

Code?
----------------------------------------------------------------------
There are only 10 types of people in the world...
Those who know binary and those who don't.
----------------------------------------------------------------------









>

2. Multiple handsets, single Google account?

As I eagerly await the delivery of my N1 I'm trying to anticipate how
it will sit alongside my G1. Will I need to create a new Google
account or will my existing one work with both? Actually, what
triggered this thinking was a sharing request I just got from Latitude
on my G1. If I can just use the single account, and both handsets get
separated, where will latitude think I am? What about GTalk? I'm sure
other cases like this will arise...

--
Android Academy http://www.androidacademy.com

3. Problem with Search By Voice on Motorola Milestone

4. Emulator : INTERNET access problem

5. Market Access for Android-on-Freerunner Project

6. Frink programming language / calculating tool for Android

7. Eclipse - Connection with adb was interrupted