Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6200397
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 24, 20262026-05-24T04:21:36+00:00 2026-05-24T04:21:36+00:00

Is the thread in the onReceive method eligible for garbage collection before it ever

  • 0

Is the thread in the onReceive method eligible for garbage collection before it ever completes?

@Override
public void onReceive(final Context context, Intent intent) {
    final int alarmId = intent.getExtras().getInt(EXTRA_ALARM_ID);
    Log.i(TAG, "/onReceive with an alarmVo.id of " + alarmId);

    // RUN MY THREAD
    new Thread(new Runnable() {
        @Override
        public void run() {
            AlarmUtil.setNextAlarm(context, alarmId);
        }
    }).start();
}

From what I understand from here:
http://developer.android.com/reference/android/content/BroadcastReceiver.html it is, but I’m not quite sure.

“anything that requires asynchronous operation is not available, because you will need to return from the function to handle the asynchronous operation, but at that point the BroadcastReceiver is no longer active and thus the system is free to kill its process before the asynchronous operation completes. “

If it gets garbage collected, then how do I work around this? What should be my approach?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-24T04:21:36+00:00Added an answer on May 24, 2026 at 4:21 am

    No. Any Thread object that has been started via the start() method that has not yet completed acts as a garbage-collection root… neither it nor anything it strongly references is eligible to be garbage collected until its run() method completes.

    See also these answers:

    • When wil the new Thread() without reference be garbage collected
    • Java Thread Garbage collected or not

    EDIT:
    Now that you’ve added additional context to your question things are a bit clearer. The problem is this case is something entirely different than garbage collection. In the case of a statically published BroadcastReceiver (defined in an application’s manifest with the <receiver> tag), Android is free to kill its process after onReceive(Context, Intent) returns. Your async operation wouldn’t stop due to a GC, it would stop due to Android killing the process that is hosting it.

    As for your approach, it all depends on what you are trying to accomplish. If the code you want to execute in your BroadcastReceiver can be ran synchronously then that would be the easiest approach. I’m assuming that isn’t possible though. In that case, this portion of the docs seems to apply (emphasis mine):

    Once you return from onReceive(), the BroadcastReceiver is no longer active, and its hosting process is only as important as any other application components that are running in it. This is especially important because if that process was only hosting the BroadcastReceiver (a common case for applications that the user has never or not recently interacted with), then upon returning from onReceive() the system will consider its process to be empty and aggressively kill it so that resources are available for other more important processes.

    This means that for longer-running operations you will often use a Service in conjunction with a BroadcastReceiver to keep the containing process active for the entire time of your operation.

    So, either run your receiver code synchronously or use a Service to keep your asynchronous operation alive long enough to complete.

    (Of course this all applies only if you are statically registering your receiver in an otherwise inactive app. If you are dynamically registering it from within some other active component (say, an Activity), then that component could manage your async operation. See this answer for more info on that.)

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

Inside of the onReceive(Content context, Intent intent) method of my public class MediaButtonIntentReceiver extends
class Thread { public: Thread ( DWORD (WINAPI * pFun) (void* arg), void* pArg)
Thread class has run method to implement the business logic that could be executed
Do Thread Id's change when a context switch (due to any reason) happens?
I am using a simple BroadcastReceiver and onReceive method to intercept text messages as
I am using an Intent to Broadcast data from a AsyncTask thread back to
I created a broadcast receiver to start activity onReceive like this: public class BroadcastReceiver1
Can Thread.getContextClassLoader() be null ? The javadoc is not really clear. Should a library
Can Thread.Abort interrupt a thread that is sleeping (using, say, Thread.Sleep(TimeSpan.FromDays(40)) ? Or will
I was browsing this thread , which has good recommendation but a bit too

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.