Hi,
we are having real troubles with app freezes right now and since we are running out of ideas, we would need your help. You can read the more detailed introduction to our problem or just head to the issue below. |======= Introduction =======| me and my team are working with mono for android since version 0.9 and really value the benefit of having only one source code for at least two completely different systems. However, the latest stability issues - who- and whatever is responsible for them - give us no choice but to face the question: stay with mono for android or try android native. I really would like to know what sort of apps you all develop and what kind of requirements you have regarding stability and lifetime. Our software has to run for several hours straight, guiding truck drivers through their daily work by showing them what to do and where to go using third party navigation and functionality like geofencing or even Bluetooth connection to the trucks tachograph while they are constantly trying to keep the TCP connection to our servers and store every valuable data possible in a database file. I am wondering how many are there, who are trying to accomplish something similar with mono for android on non-rooted consumer android phones without having the troubles we do. The biggest issue for us is, that the app sometimes just freezes and there is nothing you can do to bring it back. Android won't even show the ANR (because of a divided by zero exception). It seems that the version of android and the type of hardware can make a difference on the time until it freezes. For instance, I took two identical Samsung Galaxy Notes, one with android 2.3.6 and one with 4.0.4. I need about 30 minutes to get the 2.3.6 to freeze but it takes me hours, 5 to 6, to freeze the 4.0.4 (by doing the same steps, of course). Trying the same on a Galaxy Tab 2, 4.0.3: about 30min. HTC Sensation, 2.3: never froze in tests, but sometimes in the field. I read that disabling the multicore support can help and it does - all the tests are being made with that option enabled (v7a) - but that is simply not enough. Now, I don't want to point fingers, is it android, mono for android or my code, I honestly can't tell why this is happening but I can say this much: |======= Issue =======| We spent a lot of time trying to figure out what the reason could be for the freeze and found some odd behavior. First, the background: the app consists basically of one service that does all the work and one activity that draws the custom ui. The ui, images and rectangles, is generated by the service and handed over to the activity through the IBinder interface. When the ui needs to be updated, the service sends a message to the activity's Messenger using a Handler object (never keep ui refs in a service). And somewhere in the activity's handling method, the app could freeze. At least the DDMS shows some sort of stack on the main thread that would lead to this conclusion. All other threads just say Native.Start...something. But there is no error, no stack trace and no logging at all. The process has died - sometime I can read that in log cat. Gref count is about 300, heap size 2-5MB, lref count somewhere between 0 and -10k. So I think it is not a leak or a deadlock within my code. After each ui update, I call System.GC.Collect() and I provoked deadlocks to see what it would look like. The ui freeze is exactly the same but other background threads will keep working and logging, it does not kill the process. I also tried accessing the same resource from different threads at the same time but this always ended up in an exception and a restart of the application. When a debugger is attached and the app freezes, it stops but the app stays in that freeze. No restart. The odd thing, when I inserted old school debugging lines into every method to find out where exactly the app freezes, it just didn't. I removed the lines and the app froze again, inserted them - no freeze. Same with profiling. This could just be very bad luck or maybe something to look closer to. What else could I do to track down that problem? Thank you for reading Christian
_______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
