I made some small changes to my android app (moved a library locally, upgraded gradle plugin to last, ...) and now if I use "minifyEnabled true", my app freezes at start:
I/WindowManager: Input event dispatching timed out sending to
net.myapp/net.myapp.view.mView. Reason: Waiting to send non-key event
because the touched window has not finished processing certain input
events that were delivered to it over 500.0ms ago. Wait queue length:
5. Wait queue head age: 5520.8ms.
And if I touch the screen, I get:
I/InputDispatcher: Dropped event because it is stale.
Besides that, I cannot see anything in the logs.
Setting minifyEnabled to false works. How can I find the exact source of the problem?
So, trying to understand the reason of my problem, I removed proguard. Then I had the methods limit of dex (random errors saying it could not find methods and classes of my app) and moved to multidex and everything solved.
So I'm not sure this was the problem, but if it may help someone you can refer to this: https://developer.android.com/studio/build/multidex.html#mdex-gradle
Related
On my Android application develop with Firemonkey 10.4.1, I see a lot of ANR in my Google Play Console.
The first one is :
Input dispatching timed out (Waiting to send non-key event because the
touched window has not finished processing certain input events that
were delivered to it over 500.0ms ago. waitqueue length = 1, head.seq
= 14881924, Wait queue head age: 6480.1ms.)
And the second one :
Input dispatching timed out (9a5f6ef
com.xxx.myapp/com.embarcadero.firemonkey.FMXNativeActivity
(server) is not responding. Waited 10003ms for
FocusEvent(hasFocus=true))
My app contain a TMapView, show bitmap downloaded from my server (or take and upload). I change the loading method by a thread instead of task, but it's same.
I don't have any detail on how to get it. When I test in Android 32/64 I never got a ANR.
Does something exist to trace these error ? a event where I can add log ?
This problem sounds really weird and it looks is somehow my mistake but isn't
I use crashlytics to keep logs and track exception of the usage of my app
for that i created a lib in the log4j interface which simple calls the crashlytics methods for log events.
On the first version of my lib i add an extra Crashlytics.logException() to every logger.error() in my code. After using it for a while i noticed that this behavior wasn't what i want and I removed the Crashlytics.logException()
BUT CRASHLYTICS KEPT SHOWING EXCEPTIONS ON THAT
I'm really confuse with that and for a long time i thought i was doing something wrong, but after debuging the code thousands of times i came to think that there is something beyond what i see
there is no metion of Crashlytics.logException() in my code, and somehow i still manage to see many errors in my crashlytics dashboard
can someone help me with that?
what events might generate a non-fatal issue on crashlytics dashboard
attach:
- https://pastebin.com/Rbu1ySpd this is the core class of my log lib
- whenever i want to log an even i do `logger.log("something");' in a very log4j way
We have an android app that uses soap to communicate with an API implemented in C++ with gsoap. The android application uses the ksoap2-android library for soap communications.
When the android app runs on an actual device and communicates over wifi everything seems to work as it should. However when run in the emulater (virtualized x86 image) requests with longer replies often fail with a ProtocolException unexpected end of stream.
This error and because it only tends to happen with long responses let me to the believe that on the gsoap side the socket gets closed to soon. I have tried somethings.
default accept_flags on the gsoap side didn't work
explicitly remove SO_LINGER flags from accept_flags in gsoap, didn't solve the issue (I was worried it might set linger with a timeout of zero which would result in exactly my problem)
explicitly specify the SO_LINGER flag in the accept flags and a timeout of 10, didn't solve the issue
Then i tried adding a sleep for 1 second right before shutdown in gsoaps tcp_disconnect function. That solved the problem but sleeping is no good ofcourse.
As sleeping is not a good solution I ended up using select which seems to work ok but I'm not 100% confident in this solution.
Here is the actual code change. These are the last lines of the tcp_disconnect function in stdsoap2.cpp. The tcp_select call is what I have added.
if (soap_valid_socket(soap->socket) && !(soap->omode & SOAP_IO_UDP))
{
tcp_select(soap, soap->socket, SOAP_TCP_SELECT_RCV | SOAP_TCP_SELECT_ERR, 5);
soap->fshutdownsocket(soap, soap->socket, SOAP_SHUT_RDWR);
soap->fclosesocket(soap, soap->socket);
soap->socket = SOAP_INVALID_SOCKET;
}
return SOAP_OK;
}
Is this the right solution?
I'm working on an app that is recording data via Bluetooth, but it intermittently crashes after hours of collecting data (making it hard to track down the bug).
The logcat output isn't very helpful:
http://i.imgur.com/EalnX.png
There are no exceptions thrown and no clues for what caused the process to be terminated.
How can I figure out what went wrong? Is there an exception being thrown that isn't being shown by logcat? How can I track this bug down?
Signal 9 is SIGKILL, which will terminate a process immediately (no handlers inside the process will run). From the log line, the process is killing itself, so its not an external agent that is issuing the SIGKILL.
My guess (and its really a guess) is that the memory management code running inside your process (as part of the infrastructure, not code that you wrote) is deciding that you've exhausted some resource and the only recourse is to die. I would expect there to be more messages before this point is reached in the log, so it may be worth browsing the log history to see if there are useful warnings from the process before this point.
The line immediately before this is a GC log, which implies that some sort of memory resource is running low. But it looks like the heaps are not full, so failing allocations seems unlikely. You can still get allocation failures if the object being allocated was too large to fit on the heap, or fragmentation prevented it from being allocated. I'd expect to see more relevant log messages in this case, though.
I think capturing more of the log (perhaps filtering it by your app's PID if necessary) will help you make progress.
In my case there was no warnings or any clues in the log.
Eventually I found that my problem was that one of the activities I was going into (lets say Activity X) was registering to a broadcast receiver but never unregistered from it.
Therefor by closing the activity (Activity X) and coming back to it caused registering Again to the same broadcast receiver - which caused the mess!
Simply adding unregisterReceiver(mybroadcast); (in Activity X) solved it.
(I added mine to onDestroy. make sure you unregister in the right location).
And if you are super desperate I recommend seeing this slide share which explains Android crash debugging your errors.
this problem happens when using RXjava and not implement the onError callback method
If I wish to debug some code for a UI event, e.g.
public boolean onTouchEvent(MotionEvent me)
{
// code to be debugged
}
... and I hold onto this thread (UI):
After 5 seconds I will get this warning: Key dispatching timed out sending to com.hos/com.hos.MyActivity ... null to Window ...
After 20 seconds I will get: Key dispatching timed out sending to com.hos/com.hos.MyActivity ... null to Window ... Continuing to wait for key to be dispatched
After 35 seconds I will get: Key dispatching timed out sending to com.hos/com.hos.MyActivity ... null to Window ... timed out expired process next Key & find new target
At this point, not only is my application frozen but so is the phone. Quite often I need to wait for the ANR and sometimes hard restart the phone.
Is there a way to debug this code for more than 35 seconds without freezing the app / phone?
If your processing may take more than milliseconds to process you may want to consider launching the processing in another thread which has access to a handler in the main thread.
Once you are done processing, you can then pass a message over to your handler which will then execute on the UI thread. This will help prevent those errors from coming up as well as make debugging your code easier.
If you are looking for an automated UI testing framework, perhaps you could look into integrating Robotium into your project.