Hi,
Step-by-step:
1- Open apk;
2- Turn off screen;
3- Wait some minutes;
4- Turn on screen and unlock it;
5- Blank screen and the message: "Application XXX is not responding. Force shutdown?"
Regards,
Diego
Android: Software is crashing on deactivate
31 October, 2011 - 21:19
#1
Android: Software is crashing on deactivate
1 November, 2011 - 01:00
#2
Thanks Diego, I'll pass this to the Android team.
15 December, 2011 - 14:38
#3
Hi,
Any update?
Diego
19 December, 2011 - 16:58
#4
Hi Deigo,
I have seen this on some devices while testing. Will look into it. I think there is an issue already on Jira to address this problem
19 December, 2011 - 17:21
#5
I have asked around about this problem and it looked to be of an intermittent nature. Anyway, its on my todo list and will give it a shot today. Thankyou for pointing it out.
Cheers,
Abi Waqas
19 December, 2011 - 18:08
#6
Hi Abi,
doing a little search in Jira and forum, i figured out that this is not the only post about this problem. My guess is that it happens when the app activity is no longer visible (answer a phone call for example), not only paused.
Any device, any android version.
Best regards,
Diego
19 December, 2011 - 18:36
#7
Hi Deigo,
After a bit of digging around and testing, I came to know that this is related to threading and there is no specific course of events to successfully reproduce it as I said in my previous comment that this bug is of some intermittent nature. However, I also came to know that this problem is fixed and the fix is available in the latest nightly. I have had a shot on it before writing this comment and I tried to with call, miss call, message, locking screen manually and automatic lock and it worked correctly. The nightly I tried it on is 111219-1213 on a mac. I heard that if I use MoSync 2.7, then I have to face this threading problem. I didn't try it on 2.7 for now and just believed the guys :)
We are trying our best to continuously improve MoSync. I would suggest you to update yourself with the latest nightly and this problem should go away.
Cheers,
Abi Waqas
19 December, 2011 - 18:55
#8
Hi Abi,
The last version I tested was MoSyncWindows-111210-0011.exe. I'm following github and Jira. The only commit after 10/12/2011 was the Panic one. How accurate is Jira and GitHub ?
I will test the the 19th snapshot till the end of the day and I'll keep you posted.
Thanks for your patience and commitment,
Best regards,
Diego
20 December, 2011 - 12:13
#9
Github and Jira are accurate to the full extent. However, you might find some issues which are on Jira but are fixed. Those are from the google issue tracker as we have now moved all the issue from Google issue tracker across to Jira. We are continuously working on Jira to make it really up-to-date. Its our utmost desire to help the community in every single possible way and the only thing which may hinder us to do so is time my friend.
9 January, 2012 - 15:00
#10
Hi Abi,
Happy 2012...
Ok. Bad news. This build is crashing more than 2.7 release one. I've installed on 20 users (android 2.1 / 2.2) and they're all reporting crashing (Force Shutdown) issues. In 2.7, the problem was only when reactivating the application. In this build, if a create a runTimerEvent (w/ just one iteration) and the callback executes a slow operation (for example, a 2 minute for(;;) ), the app crashes. I've changed this to IdleListeners, but same symptom.
Regards,
Diego
16 January, 2012 - 17:48
#11
Hi Diego,
This is bad. Is it all all possible to reproduce with a stripped down app?
Perhaps the app crashes because Android shuts it down if it hogs the processor too much?
Is it possible for you to grab the logcat output and post it? Do you have the Android SDK installed? Then you can use: adb logcat
This can help a lot in finding the problem.
Best regards, Mikael
16 January, 2012 - 21:25
#12
Hi Mikael,
1- In fact, last time i checked, any MAUI (I don't use NativeUI or web) had this problem. I thought it was a refresh problem after bringing the old activity up. I've noticed that last build has an "if isRunning", that's why I'm waiting for a stable nightly build to check again.
2- I'm afraid not. The for(;;) just easy to reproduce, but any mosync app crashes if the device is heavily used by any other app (most common issue is after answering the phone or leaving the app running while charging from one day to the next one).
3- I will install the SDK in a regular machine (i use VMWare ESXi). Btw, it could be easier if I debug the mosync lib. I asked Abi for a working dev environment. Maybe one day.
Regards,
Diego
18 January, 2012 - 10:23
#13
Hi Diego, thanks for the info. I will try to reproduce the problem.
And yes, debugging could be better.
Best regards, Micke
20 January, 2012 - 16:51
#14
Hi again Diego,
I have tried to reproduce using a painting app where I removed the call to maWait in the event loop, making the app consume more processing time.
Used the steps you had:
1- Open apk;
2- Turn off screen;
3- Wait some minutes;
4- Turn on screen and unlock it;
5- Blank screen and the message: "Application XXX is not responding. Force shutdown?"
I don't get the "Not reponding" error. Perhaps my app is not comsuming enough processing time? I will now leave it running over the weekend and see what happens.
You said any MAUI app has the problem. Is there any specific MANU example app you have used that I can test?
Have you had time too investigate the Android log (using logcat) ?
What kind of processing is your app doing when not used? Is it processing intensive?
Best regards, Micke
23 January, 2012 - 10:52
#15
Hi Diego,
I have had the paining app running over the weekend. It was stopped once, but I don't think it stopped because the app was not responding, rather because it was killed by the OS in a normal way.
Will try to put in a tight loop and see what happens.
Best, Mikael
23 January, 2012 - 11:53
#16
Hello again,
I have done more tests. Tried blocking loops from seconds to 5 minutes. The app did not crash in any of the tests. In one test I started the blocking loop, exited to home screen, and locked the phone. The loop exited after 5 min with no error (used locat debug output).
I wonder what exactly causes "Application XXX is not responding. Force shutdown?" Have seen this error on many occation, both in MoSync apps and in Android apps I have been working on. I would guess the error occurs when the Android event functions block for some reason. Will do some googling for it.
Best, Mikael
23 January, 2012 - 12:17
#17
Hello Diego,
Done some research and found this page
http://developer.android.com/guide/practices/design/responsiveness.html
In section "What Triggers ANR?" (ANR = Application Not Responding), it says:
"In Android, application responsiveness is monitored by the Activity Manager and Window Manager system services. Android will display the ANR dialog for a particular application when it detects one of the following conditions:
- No response to an input event (e.g. key press, screen touch) within 5 seconds
- A BroadcastReceiver hasn't finished executing within 10 seconds"
I ran my test program again (a painting app that makes a blocking loop when touching the screen), this time producing lots of touch events while in the blocking loop. This time I got an ANR dialog, with a Force close button.
If there is a lengthy operation in your app that prevents input events from being processed, that can be the cause of the ANR problem.
Another possible cause is long running code called by a BroadcastReceiver. In MoSync/Android, these are some of the most important places BroadcastReceivers are used:
- Bluetooth events
- SMS events
- EVENT_TYPE_SCREEN_STATE_ON/OFF events
- EVENT_TYPE_CLOSE events
For example, if the application takes a long time to process an EVENT_TYPE_SCREEN_STATE_OFF event, that will cause an ANR.
Does this info help you in any way?
Beast regards, Mikael
23 January, 2012 - 14:41
#18
Hi Mikael,
Thanks for helping. I couldn't setup the test environment yet but I'll have it done by the end of the week. This problem occurs specially w/ the nightly build, not the 2.7 release, let's say, 2.7 has 1 ANR per day and NBuild, 1 ANR per hour.
Regarding the responsiveness. That's really a problem, right? 'Cos an impatient user + 6 second task could kill the app. EVENT_TYPE_SCREEN_STATE_OFF is also a problem (i've noticed that some users increased the locking time to deal w/ it).
I'm running right now the logcat. Let's see what happens.
So, let's face some workarounds....
1) EVENT_TYPE_SCREEN_STATE_OFF: could be solved implementing the suggestion of always ON (ok, piggy...);
2) Input Event: The problem is that runtime doesn't create the event in queue, correct?
Regards,
Diego
23 January, 2012 - 17:18
#19
Hi Diego,
Yes this is a problem. I will talk to Android runtime developers at MoSync and see what they say.
Since MoSync has no threads, it can become problematic to handle long computation tasks. Using a timer and process a bit at time is one solution, but can be awkward to implement.
As for EVENT_TYPE_SCREEN_STATE_OFF, I am not sure what always ON would mean?
Regarding input events, MoSync code runs in a separate thread, not on the main Android UI thread. In theory, input events should be posted to the MoSync event queue even when there is a blocking loop running in MoSync code. But it seems somewhere things slow down or stop working, and the Android OS detects that events are not processed and fires the ANR dialog.
Best, Micke
23 January, 2012 - 19:32
#20
Hi,
Gimme an email address to send you adb log file.
Regards,
Diego
24 January, 2012 - 08:49
#21
Hi Diego, my email address is mikael.kindborg at mosync.com
I will take a look at the log file.
Regards, Micke
24 January, 2012 - 20:11
#22
Hey Guys, I think this may be a related issue. I've been trying to record a video of a MoSync complete installation - from bare OS through to app running in Android emulator. I've done this twice now - once with Windows XP and once with Windows 7, but each of them running in a VMWare box.
Everything is cool up to the point where I start the app in my AVD - it never starts. I get an error 'Activity Idle timeout for History Record' and the the fully qualified name of the app. My guess is that this isn't starting in a timely fashion, but I just get left with a blank screen.
On one hand, I'm not too worried - I don't have this problem on my normal development machine, and I've not had it on my Nexus One. If it is limited to VMWare installations then it is less serious. On the other hand, it could be symptomatic of another problem, which made me think of this thread.
Any ideas? Is this related?
Thanks
Sam
24 January, 2012 - 21:02
#23
Hi,
Ok. Time to create the "build box". What's the dev environment you're using to build android runtime? Last time I had problems building winmobile runtime (project was not correctly upgraded to VS2010). Which OS, SDK, ... ?
Regards,
Diego
24 January, 2012 - 21:55
#24
I'll try to get a definitive answer tomorrow, but I'm installing VS2010 onto my Windows 7 VMWare box. Lets try together.
25 January, 2012 - 15:34
#25
Win7 32 or 64? Business?
Diego
25 January, 2012 - 16:15
#26
I'm trying Windows 7 64-bit Professional, with VS2010, although I've installed VS2005 as well in case I need it for anything. Still churning through the downloads and installations from the guide.
26 January, 2012 - 23:45
#27
Sam,
1- I think 64bit env is not a good choice. Someone once said there's a problem running mosync on 64bit OS.
2- What's the expected behaviour if I start downloading something and the device deactivates screen? MoSync is closing the connection. How do I transfer a large amount of data? Using resume? Well, I'm not sure about this, cos I also use a Timer watchdog and there are rumors that timers crash when deactivating.
Regards,
Diego
28 January, 2012 - 18:48
#28
I run Windows 7 64-bit and its not a problem, but I *do* think you have to have a 32-bit Java installed.
You're going to have to keep the screen alive somehow. I think MoSync will kill the connection, and it probably should, as it is better than killing battery and user's bank balance. Is there any other way to get the data down, other than by one massive download?
30 January, 2012 - 13:19
#29
Ok Sam ...
Windows 7 x64 SP1 PTBR...
1- ruby workfile.rb base
.git not found. C:/mb/MoSync-trunk/intlibs/idl-common [] get_gcc_version_string(gcc) Error: Could not find gcc version. C:/mb/MoSync-trunk/rules/error.rb:19:in `error': Could not find gcc version. (RuntimeError) from C:/mb/MoSync-trunk/rules/gcc.rb:33:in `get_gcc_version_string' (...) from C:/mb/MoSync-trunk/rules/task.rb:147:in `invoke_subdirs_ex' from C:/mb/MoSync-trunk/rules/task.rb:144:in `invoke_subdirs' from workfile.rb:106 from C:/mb/MoSync-trunk/rules/targets.rb:35:in `call' (...) from C:/mb/MoSync-trunk/rules/targets.rb:118:in `invoke' from workfile.rb:188
2- doxygen ...
------------------------------------------------ Copies the doxygen html files to Eclipse ------------------------------------------------ C:\mb\MoSync-trunk\docs>mkdir \mb\eclipse\com.mobilesorcery.sdk.help\docs\html\ Já existe uma subpasta ou um arquivo \mb\eclipse\com.mobilesorcery.sdk.help\docs\html\. Arquivo nÆo encontrado - html 0 arquivo(s) copiado(s) a tool related error occured.
Well, in windows XP these errors don't exist. Is it a win7 problem? I read that symbian has issues w/ windows Vista
Regards,
Diego
16 February, 2012 - 13:03
#30
Hi again Diego,
We have solved the problem with a MoSync app crashing on Android when locking the screen while it is running. This is fixed now and should go into the uncoming 3.0 release.
Just wanted to let you know this.
Best regards, Mikael
16 February, 2012 - 14:17
#31
Hi Mikael,
Great news! Thanks for the update. I'm following jira's and github progress and I know you're doing all you can to release 3.0 as soon as possible.
I also realized that you're having troubles consolidating jira's opened bugs (this one, has to entries, 82 and 1651). I guess all sw devs have this problem. If you find a solution, let me know.
Best regards!
Diego
16 February, 2012 - 17:17
#32
Release of 3.0 is now scheduled for Feb 22 :-)
23 February, 2012 - 11:28
#33
Hi All,
MoSync 3.0 is out now with a bulk of fixes and new stuff. You can download it and play around. There is also a surprise package called MoSync Reload (beta) which is a cool thing to try. On Jira side, we are trying our best to catch up and you shall see some progress in coming days. Have fun.
3 March, 2012 - 20:03
#34
Hi,
update: MoSync 3.0 fixes the crash when returning to app, but the problem after installing persists.
Platform: Android 2.x, 3.x
MoSync: 2.7, 3.0
Step-by-step: Install the APK, run, press home (dont quit app!), install an APK upgrade, press run from install tool. I get a blank screen.
Regards,
Diego
Btw: Fantastic job this 3.0 !! Congrats!
6 March, 2012 - 15:40
#35
Thanks for reporting Diego, I have opened a Jira issue for the bug:
http://jira.mosync.com/browse/MOSYNC-2007
Best regards, Micke
8 March, 2012 - 20:17
#36
Micke,
thanks. Btw, I'm still facing problems returning to the app after answering a phone call. This time I get a black screen, but no Force Close.
Android 2.2 / Defy / Mosync 3
I will try to get a log to send you.
Regards,
Diego
9 March, 2012 - 10:09
#37
Thanks Diego, I have reported this on the issue tracker:
http://jira.mosync.com/browse/MOSYNC-2020
What happens when the phone is ringing is a test case that I guess is easy to overlook and is seldom tested. Thanks for spotting this.
Best regards, Micke
15 March, 2012 - 21:36
#38
Micke,
I think this is related...
LG-C660h / Android 2.3.4 (Kernel 2.6.35.10) / MoSync 3.0
1) Install APK
2) Press Run or Close and Run from menu.
3) Black screen.
In order to run, I need to Force Shutdown from Applications menu.
Attached, 1st try (after the force shutdown). It runs and I close app using maExit. 2nd try, is the next run that leads to the black screen.
Btw, I dont face this problem w/ MoSync 2.7
Regards,
Diego
| Attachment | Size |
|---|---|
| lge-1st.try_.txt | 128.08 KB |
| lge-2nd.try_.txt | 123.82 KB |
15 March, 2012 - 23:01
#39
Hi,
same problem with VIA WM8650 (Android 2.2).
Regards,
Diego
19 March, 2012 - 14:18
#40
Thanks Diego for the update, I have included the new info in the issue.
Best regards, Micke
21 March, 2012 - 15:06
#41
Hi,
same problem running and black screen of post #38 with MoSync 3 + Defy+ (GB).
Defy (Froyo) runs ok.
Diego
22 March, 2012 - 10:17
#42
Thanks, people are investigating this problem now.
Best, Micke
26 March, 2012 - 21:12
#43
Hi,
log from my Defy+
Regards,
Diego
| Attachment | Size |
|---|---|
| ok - defy2.zip | 87.65 KB |
| anr - defy3.zip | 95.99 KB |
27 March, 2012 - 21:14
#44
Micke,
now I have a non working source code for you.
Environment: Android Simulator 2.3.3, API level 10, SDCard 1gb, Skin HVGA, Max VM App Heap Size: 24Mb, Device RAM Size 256
I've also attached my resources, since i'm starting to believe it's a resource problem (maLoadProgram still crashes).
This program does not crash neither with 512Mb RAM Size nor commenting setFullScreen.
I'm sending to your email the source code.
Regards,
Diego
29 March, 2012 - 11:56
#45
Hi Diego,
Many thanks for the test app. I ran it but could not make it crash/hang. Can you outline the steps you used to reproduce the error?
I ran the app on emulator 2.3.3 (level 10), and on a Nexus One that has 2.3.6.
Used latest MoSync 3.0.1 release candidate to test: www.mosync.com/miles/MoSyncWindows-120329-0919.exe
What I tested:
- Phoning the device while app is running, worked to go back to app, both after anwering call and declining call.
- Tested to quit (exit) the app with the back key 4 times and restart, this worked.
- Tested to go to the home screen, then back to the app 4 times, this worked.
If you send your test procedure I will try to reproduce.
Best regards, Micke
29 March, 2012 - 22:23
#46
Hi Micke,
The app I sent you must be tested with android simulator 2.3.4 + 256Mb RAM. The procedure is simple. Run. wait for 1,2,3,4,5 and then press back. Repeat these steps 10, maybe 20, times and you'll see that it hangs on number 1. In fact, it hangs on maCreateImageFromData from Font.setResource, but I suppose this is a colateral damage from other part. Another point is that maSetFullscreen should be on. Increasing to 512 also does not reproduce the problem. Have you tested the force close O.S. send when reaching low memory?
This app does not crash neither on Xperia X10 w/ GB 2.3.3, nor Defy Frodo 2.2
Best regards,
Diego
30 March, 2012 - 16:51
#47
Hi Diego,
Tested in emulator as specified, and after about 10 restarts the app exits with a segment fault:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
Full sequence displayed, 1,2,3,4,5, crash occured when exiting app. When started again, it ran normally.
I have seen this problem with another app, see this forum thread.
This will take some time to debug. It could be some out of memory problem, corrupting memory, an unhandled malloc fail or someting.
The force close message, you mean a message Android OS sends to the app when memory gets low. I don't think MoSync currently handles that. Will experiment with that. Thanks for pointing it out.
30 March, 2012 - 19:15
#48
Hi Micke,
Thanks for your answer. I know some deletes are missing, but i'm sure that wont be the problem. My guess is we face here an initialization problem, cos I get this error opening the app right after turning the phone on and installing it. The device we tested (Defy+) has no memory issues (you may look the logcat).
Well, anyway, i'll stop using this thread and any other problems on the other one.
Best regards,
Diego