What happens to an Android thread after the Activity that created it is destroyed?

In my Android app, the main Activity will sometimes start a Thread to load data from a server. This thread modifies the app's database and edits some important files. AFAIK, it would appear that this thread continues to execute. What will happen to this thread if the Android gets into a low memory situation and decides to kill the entire Application? Will there ever be a situation were this thread might die prematurely? If so, is there any way I can see that the thread is being killed, and do something about it?

I'm asking because this thread modifies important data in the database, and if it is suddenly开发者_JAVA百科 killed, the application could stop functioning properly.

---

AFAIK, it would appear that this thread continues to execute.

This is true but you have no guarantee of how long the thread will stay alive.

What will happen to this thread if the Android gets into a low memory situation and decides to kill the entire Application?

This is actually a fairly rare case in my experience but it will depend on the device's available memory and the user's behaviour, for example they use the device heavily and start multiple apps.

Will there ever be a situation were this thread might die prematurely?

Yes

If so, is there any way I can see that the thread is being killed, and do something about it?

No

I'm asking because this thread modifies important data in the database, and if it is suddenly killed, the application could stop functioning properly.

What you describe could be classed as something which is 'mission critical'. As the other two answers have pointed out, a Service would be a more robust way of doing things as a Service is one of the last things to be 'killed' in a low memory situation. Using START_REDELIVER_INTENT may help in resuming what it was doing.

In any case, if you have a 'mission critical' operation, you need to design your code for full recovery such as the use of transactions and the possibility of rollbacks in case of errors.

---

It sounds like you should move the db updating to a Service. Once an Activity goes to the background, Android assumes its process can be killed off if necessary and restarted later without ill effect. See Application Fundamentals for more info.

---

You should be using a service:

Because a process running a service is ranked higher than a process with background activities, an activity that initiates a long-running operation might do well to start a service for that operation, rather than simply create a worker thread—particularly if the operation will likely outlast the activity.

Take a look here: http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html#Lifecycle (where the text I pasted originates)

---

I might be digging out an old thread, but nobody mentioned one important thing.

Every time you use a database and modify multiple rows, you should make use of transactions to ensure that data stays valid in case of any kind of failure (which might be for example a termination of a thread, a socket exception etc.).

    try{
        db.beginTransaction(); 

        //Do whatever you need to do...    

        db.setTransactionSuccessful();
    }catch(SQLiteException e){
        Log.e("SQLite","Error while updating rows: " + e.getMessage());
    }finally{
        db.endTransaction(); //Commit (if everything ok) or rollback (if any error occured). 
        db.close(); //Close databse;
    }