1

I have a mainactivity and a service. The mainactivity prepare data to the service. After the service consumed the data, it broadcasts a request to mainactivity, mainactivity prepare some new data and pass to service...

The mainactivity allows user to manipulate the data. The mainactivity will be killed after sometimes when if it is not in foreground.

[Problem 1]: I am a bit confused here, i think the mainactivity is still here, but its UI thread and view is cleared? So I cannot use the UI thread to read value from view and then send data to service?

[Problem 2]: How can I detect the mainactivity being killed and the service can then switch to prepare data itself?

[Problem 3]: How can I force the system to 'kill?' the mainactivity so I can debug the program?

thanks

Update: I read that graph may time but still i cannot fully understand the behavior. In fact, my question is more like this: From task manager, my app has 1 activity and 1 services and consumed 20MB ram. After half an hour, my app has 1 activity and 1 services and consumed 1.5MB ram. Obviously, something happened to the activity, what is that? Please be noted: my activity use UI thraad loop for preparing data to service. On stop / on resume has no impact on UI thead of activity, then how can i know when will the UI thread activity be killed?

Update: i tested with logcat, (add log message when onpause/onstop/ondestroy called..), however, none is called while the app memory drop down from 20mb to 1.5mb.

05-21 23:33:27.709: I/mytag(32012): called onResume

05-21 23:33:30.606: I/mytag(32012): called onPause

05-21 23:33:31.596: I/mytag(32012): called onStop

[up to this point, the app manager shows my app using 20mb memory]

05-21 23:36:05.176: D/skia(32012): purging 144K from font cache [8 entries]

05-21 23:36:05.246: D/dalvikvm(32012): GC_EXPLICIT freed 1240K, 52% free 4329K/8839K, external 1716K/2137K, paused 54ms

05-22 00:00:10.226: D/dalvikvm(32012): GC_EXPLICIT freed 933K, 53% free 4226K/8839K, external 1684K/2137K, paused 85ms

05-22 00:36:10.166: D/dalvikvm(814): GC_EXPLICIT freed 56K, 49% free 2775K/5379K, external 1625K/2137K, paused 61ms

[up to this point, the app manager shows my app using 1.5mb memory]

I waited half an hour, and i did not get any more logcat text, test ended.

I want to detect that system clear up my app memory, but it does not trigger any 'onpause, /onstop etc', how can i detect it, and then tell the service to do something? thanks

manhon
  • 683
  • 7
  • 27

1 Answers1

1

Please take a look at the Activity lifecycle.

http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Answers to 2 and 3 reside there (implement something for onStop or onDestroy to "tell" the service that the activity is being killed/etc). OnDestroy is the only time when something is "truly" about to be killed.

As for number one, I don't fully understand your question, so maybe you could explain it better? My only thought on number one is that you are dealing with orientation changes recreating the activity (which can cause some problems depending on how you create/add your views).

EDIT: From the link posted above..

-If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.

-If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.

-If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.

Zerkz
  • 686
  • 1
  • 6
  • 25
  • I read that graph many time but still i cannot fully understand the behavior. In fact, my question is more like this: From task manager, my app has 1 activity and 1 services and consumed 20MB ram. After half an hour, my app has 1 activity and 1 services and consumed 1.5MB ram. Obviously, something happened to the activity, what is that? – manhon May 20 '13 at 14:37
  • I have edited my answer. It's hard for us to really tell specifically without your code. – Zerkz May 20 '13 at 16:49
  • thanks for advice, but i tested with logcat, (add log message when onpause/onstop/ondestroy called..), however, none is called while the app memory drop down from 20mb to 1.5mb. – manhon May 21 '13 at 15:31
  • Did you investigate this? 05-21 22:48:37.391: W/dalvikvm(28304): Unable to resolve superclass of Lcom/example/myapp/myService$2; (84) 05-21 22:48:37.391: W/dalvikvm(28304): Link of class 'Lcom/example/myapp/myService$2;' failed 05-21 22:48:37.391: E/dalvikvm(28304): Could not find class 'com.example.myapp.myService$2', referenced from method com.example.myapp.myService.setTts 05-21 22:48:37.391: W/dalvikvm(28304): VFY: unable to resolve new-instance 516 (Lcom/example/myapp/myService$2;) in Lcom/example/myapp/myService; – Zerkz May 21 '13 at 15:50
  • sure, i found this, http://android.foxykeep.com/dev/how-to-fix-the-classdefnotfounderror-with-adt-17, but i cant see the relationship, hence i remove the tts inside the services, and the catlog error disappeared. please refer to edited post for new logcat info, thanks a lot, and sorry for that – manhon May 21 '13 at 16:40
  • Please look at this post http://stackoverflow.com/questions/11473849/android-app-doenst-call-ondestroy-when-killed-ics – Zerkz May 21 '13 at 18:19
  • thank a lot for your link, I am thinking of this method: I will try to use the service to send a broadcast to activity, where the activity will broadcast back to service. In short, I do periodic checking from service on activity. Do you think this is a workable solution? thanks for your advice. – manhon May 25 '13 at 04:07