Issue 122: App never terminate
Reported by DevBinn...@gmail.com, May 21, 2012
What steps will reproduce the problem?
1. Launch App, and close it (any time)
2. App process is still running (check shell: top or DDRM)
3. Toast (refreshing) appears every now and then

What is the expected output? What do you see instead?
App should terminate. or be in com state. (it consumes battery)
Output: App still running - refresh note appears every now and then.

What version of the product are you using? On what operating system?
V8.2

Impact High.
May 25, 2012
Project Member #1 daniele.gobbetti
(No comment was entered for this change.)
Labels: -Priority-Medium Priority-Critical
Jun 3, 2012
Project Member #2 abdu.e...@gmail.com
Problem still occurs on the newest version of mixare (0.92) The fix is probably to call system.close or something like that, instead of the finish call in the mixview, when pressing the back button. I will work on this on Monday.
Labels: Version-AndroidRelease0.9
Jun 4, 2012
Project Member #3 abdu.e...@gmail.com
This issue is fixed in this branch https://github.com/abduegal/mixare/commit/94d870b7744300affd548a18e7244ef3439ca758

I added a finish method when the back button is pressed in the mixview. And also made sure that plugins are unloaded correctly with it.
Status: Started
Jun 4, 2012
#4 DevBinn...@gmail.com
Hi Abduegal,

I tested your fixed for this issue, and the issue seems to be their yet.

"adb.exe shell -d top -m 5"
output: org.mixare is still alive.

the threads running are:
main ->
      android.os.messageQueue
      android.os.looper
      ...

So it seems that the downloadmanger thread is the one causing the issue.
it never stops and keeps the VM waiting for it to terminate.

Regards

Jun 5, 2012
Project Member #5 abdu.e...@gmail.com
Hi,
Thanks for noticing. I was not able to find the error, these are the threads that are still running after I close mixare.

main ->
   android.os.MessageQueue
   android.os.MessageQueue
   android.os.Looper
   android.app.ActivityThread
   java.lang.reflect.Method
   java.lang.reflect.Method
   com.android.internal.os.ZygoteInit$MethodAndArgsCaller
   com.android.internal.os.ZygoteInit
   dalvik.system.NativeStart

There is also an activitythread and a looper active, based on this; I think that an activity is not closed (finish method not called). I also did some tests with the download manager, and these threads are still running even when I outcomment the "		    executor.execute(this);" call. Based on that I think that the downloadmanager is not the cause of this issue.

What do you think?
Jun 5, 2012
#6 develo...@gmail.com
Hi,

Yes you are right.
Base on the documentation of MessageQueue, it seems that there is a thread waiting to be called or removed.
http://developer.android.com/reference/android/os/MessageQueue.IdleHandler.html
http://developer.android.com/reference/android/os/MessageQueue.html#removeIdleHandler(android.os.MessageQueue.IdleHandler)

The problem seems to be the way the thread terminates. (even if it's not executed, it's being "created" and maybe not ever terminating)

So it's one of the following: 
1- SensorManager (which it seems to be it)
2- DownloadManager (possible, since it sometime does not terminate and stays active after closing)
3- Location Manager. 
4- Timer (I monitored this, and It's unlikely to be the one)

I'll try to unregister these managers, and add onDestroy (which it's unreliable and can be not called during destruction)


Jun 5, 2012
#7 develo...@gmail.com
Check Thread "Pool-1-thread-1" and "android.hardware.SensorManager$sensorThread"

And Pool-1-thread-1 has DownloadManager thread class running!

Both are alive after closing the app, which means that both "sensor and downloadManager" are the one who cause the app to never terminate.
Jun 5, 2012
#8 DevBinn...@gmail.com

I fixed the downloadManager thread shutdown issue.
Instead of using "request.take();" which waits infinitely, use "request.poll(timeLimit);"
  
https://github.com/DevBinnooh/mixare/commit/46700de4b5ee601f497fac5b12189deb8d48b23a

The issue still there, "MessageQueue" is also causing it to never terminate.
I'm not sure where we are using "MessageQueue" and why it's not closing.
Could it be the sensors?
Jun 9, 2012
#9 DevBinn...@gmail.com
Have fixed notification appearance after closing the app,
and unregistered all locationListener. and Enforced stop of operation after closing the app, which reduce battery consumption ALOT. 

https://github.com/DevBinnooh/mixare/commit/67bd3674e3d7b79bd6ddf84f17419c9602388783

Still the app is not fully terminated because there is sensor listeners that has not been disabled.
After investigating MessageQueue, it Seems that it holds "messages" from 
"org.mixare.lib", which I'm not sure what it's causing it or how to unregistered for receiving them.

does the last plugin loader commit fix that issue?

Jun 11, 2012
Project Member #10 abdu.e...@gmail.com
Hi, 
the last plugin loader commit does not fix that issue. 
And the org.mixare.lib package contains POJO objects and static library methods. So the issue should be somewhere in MixView.
Jun 11, 2012
#13 DevBinn...@gmail.com
After investigation, I found out that it's android bug that is beyond our scope.
It happens since they moved to "SensorEventListeners" class, (they were on "SensorListener").

This fact effect "some" devices, that app will be running in the background till android needs to allocate new memory space. 

The sensor messages that are holding the app from terminating can be retrieved by
"Looper.myQueue()"

and apparently, it contains messages from the two sensors and targeting the sensor manager. It seems unregistering these sensors and "nulling" sensor manager does not stop messages from coming in.

Luckily, if onDestroy() is called, it deallocate "MixViewDataHolder" and force the app to stop consuming cpu.
"adb.exe -d shell "top -m 5" shows 0-1% of mixare cpu consumption, which is far great than the random frequency that was before shutting down the downloadManager and the allocation of mixViewDataHolder.

So, for now we can say that V0.9.3 has work around on this issue, and issue will be paused till android dev provide a fix for unregistering sensors.