App never terminate

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by DevBinn...@gmail.com on 21 May 2012 at 6:12

[GoogleCodeExporter]

Original comment by daniele.gobbetti on 25 May 2012 at 8:14

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

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.

Original comment by abdu.e...@gmail.com on 3 Jun 2012 at 8:20

• Added labels: Version-AndroidRelease0.9

[GoogleCodeExporter]

This issue is fixed in this branch 
https://github.com/abduegal/mixare/commit/94d870b7744300affd548a18e7244ef3439ca7
58

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.

Original comment by abdu.e...@gmail.com on 4 Jun 2012 at 8:45

• Changed state: Started

[GoogleCodeExporter]

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

Original comment by DevBinn...@gmail.com on 4 Jun 2012 at 6:09

[GoogleCodeExporter]

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?

Original comment by abdu.e...@gmail.com on 5 Jun 2012 at 8:59

[GoogleCodeExporter]

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#removeIdleHa
ndler(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)

Original comment by develo...@gmail.com on 5 Jun 2012 at 5:33

[GoogleCodeExporter]

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.

Original comment by develo...@gmail.com on 5 Jun 2012 at 5:38

[GoogleCodeExporter]

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/46700de4b5ee601f497fac5b12189deb8d48
b23a

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?

Original comment by DevBinn...@gmail.com on 5 Jun 2012 at 11:39

[GoogleCodeExporter]

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/67bd3674e3d7b79bd6ddf84f17419c960238
8783

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?

Original comment by DevBinn...@gmail.com on 9 Jun 2012 at 8:08

[GoogleCodeExporter]

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.

Original comment by abdu.e...@gmail.com on 11 Jun 2012 at 12:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by DevBinn...@gmail.com on 12 Jun 2012 at 12:21