Hi I'm getting ANR (Application Not Responding) errors but I can't understand why. If I click "Wait" everything works perfectly and the ANR doesn't come back anymore.
Now, I do know that when using MediaPlayer as a service is good practice using .prepareAsync and the onPrepared() method rather than simple .prepare() and .start(). It doesn't lock the UI thread and works great.
The problem is that all my ANRs are not happening when opening files (you would guess higher processor there), but randomly when they are playing and when the cpu is at few % at most. As I mentioned earlier NOTHING is remotely close to being unresponsive and there is little left on the UI thread.
The only clue is that I don't get ANRs the first time I play a track, but only after it has been changed. I thought that the prepareAsync threads were colliding and I added a lock myself. no change.
I tried to release the media player each time before starting a new track. no change
I tried to reset, stop etc in many sequences. no change.
Has anybody experienced the same thing?
As a workaround, is there any way to automatically dismiss the ANR? I know it's not the answer but I can't find any options. I am on a rooted tablet (I compiled the ROM) and it is only for myself - no distribution
thanks
A standard Service actually runs on the main Thread, if you are seeing ANRs perhaps you should move the entire MediaPlayer to another Thread. To quote the documentation
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
You are already using prepareAsync(), but as you stated the error occurs while the MediaPlayer is running, not preparing. Without more detail on what exactly causes the ANR, I believe switching to a HandlerThread is your best option.
Related
When calling createCaptureSession this one takes around 200ms to comeback in my test device.
I thought this call was asynchronous, so it is very strange that it takes so long.
To mitigate the issue I am now calling it from a background thread in order to not block the UI while these 200ms. And for the call I am re-using the same thread (executor) that I am passing in the SessionConfiguration.
So far I've found no side effects. But I would like to know if it is fine to perform such call on a background thread, or I may encounter problems in specific use-cases, device models, android versions.
The problem that can be experienced there may be a problem due to the fact that the android device is single-core or a process that requires performance at that time. However, this is a problem caused by the device and user, not by the developer.
We know that there are no single core Android phones.
Threads do not cause any problems since they are software elements that come into play during this performance load. Only in case of load the processing is done a little later
After playing my libgdx-game for some time, it just freezes. the game loop is not being executed anymore and it does not react to any input; the game can just be killed.
Logcat says this:
The memory graph shows:
(The freeze starts at about 8m30s. Before this time the game is running normally.)
The question: What is happing here? What do I have to do to avoid this game crash?
Could you post more logcat? It's hard do gather any information as to what is causing the problem just by looking at it saying it's suspending all threads.
This usually happens when you run out of memory. Do you have peices of code which load stuff into memory? You may want to take a look at that. Just a possibility, but maybe you are running out of memory. I know what the memory graph shows, but I had a similar problem and I fixed it by optimizing some asset loading.
(you may want to use asset manager to handle memory optimization)
https://github.com/libgdx/libgdx/wiki/Managing-your-assets
If that is not the case, please post some code. (or more logcat)
I'm loading a bunch of images using AsyncTasks, creating bitmaps. Lots of recycling views going on etc. Without going into the gory details, I would like to know if there is any way I can get some realtime stats on threads that might be helpful. In particular what I am noticing is that the doInBackground runs really fast once it gets kicked off, but it seems they it takes a while for these tasks to run. So I was wondering how I can know how many threads are running at a given time. I have seen the dreaded 128 limit on thread exception with 10 in queue, but thats once there is an overload, I would like to be able to watch this as the program is running. Hopefully this visibility will tell me something. BTW, I did try bumping of the thread priority within the doInBackground() but again its really not that it is not fast once it runs, its that it does not get scheduled to run fast. I'm on Android Studio, what kind of tools are available?
When debugging and stopped on a breakpoint you can scroll through all the launched threads and their current execution points (the spinner on the left of the debug tab).
Knowing where your threads are started you can launch method profiling on this method and see how your threads are performing (a "timer" button on the left of the android tab).
I have a pretty big app that I am working on. Sometimes when I start it on 2.3 devices, the UI thread gets somehow stuck. I don't think it is one of my own tasks, but I just cannot figure out what it is. Is there any way that I can figure out what exact task is currently running in the UI Thread?
More info:
I'm running a Runnable on a Handler that uses the main Looper at some point, but run() never gets executed in those cases. I also get an ANR when I touch the screen then. I assume it must be related to the memory in some way because when I remove one of the background images, it feels like it gets stuck less. I do not get an OOM exception though.
Edit
I enabled logging for the main Looper. The last task that gets dispatched has what=1004. This is definitely not from me.
Looper: >>>>> Dispatching to Handler{406cbec0} null: 1004
Sorry for posting as answer (Not enough points for comment) but I believe naming your AsyncTasks and Threads and then using DDMS or any other Android profiling tool could possibly help solve your problem.
By figuring out the most performance/time consuming methods and threads, or possibly something that is overloading the memory (Examine the heap using DDMS).
Take a look at the following links:
http://developer.android.com/tools/debugging/ddms.html
http://developer.android.com/tools/debugging/debugging-tracing.html
Sorry if this wasn't any help.
I have a problem with my videogame in Android. It shuts down randomly without saying anything while I'm playing it for a while. Before, It didn't close but now somehow, is doing it.
After this, I optimized the code and got a great memory improvement but it keeps doing the same at the same frecuency, which makes me think that maybe is not a memory leak.
It is not an unhandled expcetion neither, because I have a try/catch capturing all the exceptions in my game loop.
So I was wondering what could trigger a force close in my Android videogame... what would you suggest?
Maybe is because the device becomes very hot.
Is it possible that in a long loop could decide to shut down because it is taking so long and without saying anything?
Those two are my main hipotesis right now. I don't have any clue what is going on.