I write and adapter view to display images, include this I added two extra button to move right and left. I created drawable xml for both button, so while executing code at runtime it's producing following error :
D/AndroidRuntime(3682): Shutting down VM W/dalvikvm( 3682):threadid=1:
thread exiting with uncaught exception (group=0x41bad300)
E/AndroidRuntime(3682): FATAL EXCEPTION: main
E/AndroidRuntime(3682): java.lang.StackOverflowError
E/AndroidRuntime(3682):at android.util.SparseArray.get(SparseArray.java:82)
E/AndroidRuntime(3682):at android.util.SparseArray.get(SparseArray.java:73)
E/AndroidRuntime(3682):at android.content.res.StringBlock.get(StringBlock.java:69)
E/AndroidRuntime(3682):at android.content.res.AssetManager.getResourceValue(AssetManager.java:201)
E/AndroidRuntime(3682):at android.content.res.Resources.getValue(Resources.java:1009)
E/AndroidRuntime(3682):at android.content.res.Resources.getDrawable(Resources.java:658)
E/AndroidRuntime(3682):at android.graphics.drawable.StateListDrawable.inflate(StateListDrawable.java:173)
does any one have idea about it...if I refer normal drawable image then it work properly.
StackOverflowError can happen when too much data is managed in one single task. For example, this could be if you got an endless loop or handling too much data transfer inside a loop. This is one of the reason, there could be more.
see this example of handling stackOverflowError with a database:
http://wiki.webratio.com/index.php/How_to_solve_the_java.lang.StackOverflowError
additionally, I found this post in stackoverflow:
Stack overflows from deep recursion in Java?
But without seeing some code, it´s hard to find the issue, so please post some...
Related
I'm facing a very annoying android crash that happens in around 1% of PRODUCTION the sessions with the app ALWAYS in the background.
Fatal Exception: android.app.RemoteServiceException: Attempt to invoke virtual method 'int com.android.server.wm.TaskDisplayArea.getDisplayId()' on a null object reference
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2054)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:250)
at android.app.ActivityThread.main(ActivityThread.java:7755)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:958)
From this stack is clear that it comes from an internal android MainLooper operation... but the lack of extra information difficult for me to discover WHAT exactly
does anyone know what is this problem and how to solve it?
There's not a whole lot we can do with this level of information. The only thing I can see is this:
android.app.RemoteServiceException: Attempt to invoke virtual method 'int com.android.server.wm.TaskDisplayArea.getDisplayId()' on a null object reference
At some stage, your code is calling (or using a library which calls) getTaskDisplayArea() in com.android.server.wm. This returns null. It then tries to use this to getDisplayId().
(The rest of the error lines there just indicate it's not in the main thread)
It's likely that wherever you're using the TaskDisplayArea (or the library that calls it) is being called when the UI has been destroyed or has yet to be created.
The rarity indicates it probably is a total background restart of your UI/display elements... if I had to guess maybe caused by Android OS memory cleanup triggers while multitasking, or the user changing orientation repeatedly, etc etc.
If you give more details about where you've used the com.android.server.wm code or layouts you can probably get more help for how to make this background-thread-proof. Depending on what you're actually doing you might end up just catching the exception & retrying later, but some views will allow you to post info to the main thread and I don't know if TaskDisplayArea does.
In my case, I found that the project had a notification icon file in res/drawable-v24/ic_launcher_foreground.xml. The crashing stopped when I moved the .xml associated with v24 in the drawable res folder.
I am facing a crash of my Android app with the stack trace below.
What puzzles me is that the same code with the same variable values (tried with the debugger) does not crash on Android 8 and 9, only on 7.0 / 7.1. The reason is self-explanatory: there's some redrawing triggered from a class (VoipCallsManager) that is not done over the UI thread, but why this is not triggered on newer Android?
E/FatalExceptionKalliope: Uncaught Exception
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:6898)
at android.view.ViewRootImpl.invalidateChildInParent(ViewRootImpl.java:1083)
at android.view.ViewGroup.invalidateChild(ViewGroup.java:5205)
at android.view.View.invalidateInternal(View.java:13660)
at android.view.View.invalidate(View.java:13624)
at android.view.View.invalidate(View.java:13608)
at android.widget.ImageView.setImageDrawable(ImageView.java:531)
at android.support.v7.widget.AppCompatImageView.setImageDrawable(AppCompatImageView.java:100)
at it.myapp.MainActivity.onSoftPhoneChangeSettings(MainActivity.java:2582)
at it.myapp.stefanotest.VoipCallsManager.isActive(VoipCallsManager.java:187)
at it.myapp.call.MakeCall.executeUseCase(MakeCall.java:53)
at it.myapp.call.MakeCall.executeUseCase(MakeCall.java:15)
at it.myapp.UseCase.run(UseCase.java:40)
at it.myapp.UseCaseHandler$$Lambda$0.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
2019-02-12 19:09:52.340 6961-7055/it.myapp I/intouchste: Uncaught Exception Only the original thread that created a view hierarchy can touch its views.
The stack trace indicates UseCase is a thread and started by the ThreadPoolExecutor, so it is the correct behavior to throw the exception. You can wrap that code with runOnUiThread() to avoid this problem.
However why it doesn't crash on other versions? If you really want to dig to the bottom, you can make a deliberate crash at that place, e.g., divide by zero. So you can have a stack trace on other devices. You can compare with the one you listed here, probably you can find it is not started in a thread.
I'm using crashlytycs and recently i begin to get such exception, but i don't know how to reproduce it on my application.
I know how to fix it. The fix is to use runOnUiThread, but i don't know the point where this exception happens.
When i got exception, i see the line of it in logs, but this one is different, because exception occurs in android class, not mine. Can you give me some advices about where can i search for this exception. I'm not changing ui in asyncTask background. I use volley for networking.
Error Log:
Fatal Exception: android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:7406)
at android.view.ViewRootImpl.invalidateChildInParent(ViewRootImpl.java:1113)
at android.view.ViewGroup.invalidateChild(ViewGroup.java:4595)
at android.view.View.invalidate(View.java:11301)
at android.view.View.invalidate(View.java:11250)
at android.widget.TextView.updateAfterEdit(TextView.java:7817)
at android.widget.Editor.finishBatchEdit(Editor.java:1330)
at android.widget.Editor.endBatchEdit(Editor.java:1313)
at android.widget.TextView.endBatchEdit(TextView.java:6084)
at com.android.internal.widget.EditableInputConnection.endBatchEdit(EditableInputConnection.java:82)
at android.view.inputmethod.BaseInputConnection.finishComposingText(BaseInputConnection.java:292)
at com.android.internal.widget.EditableInputConnection.finishComposingText(EditableInputConnection.java:199)
at android.view.inputmethod.InputMethodManager.checkFocusNoStartInput(InputMethodManager.java:1448)
at android.view.inputmethod.InputMethodManager.onWindowFocus(InputMethodManager.java:1500)
at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:4211)
at android.os.Handler.dispatchMessage(Handler.java:110)
at android.os.Looper.loop(Looper.java:193)
at android.os.HandlerThread.run(HandlerThread.java:61)
I was going through following tutorial: http://www.dreamincode.net/forums/topic/190013-creating-simple-file-chooser/#viewSource
Inside the FileChooser class there is one exception beeing supressed, since there is nothing within the catch clause. So I decided to add following statement to the catch clause:
Log.e(ACTIVITY_SERVICE, e.getCause().toString());
For some reason this always causes the app to crash (NullPointerException). When I don't do any logging, except for a a simple syso print, then I don't get any exception and the app does't crash either. Then it works fine. I'm new to the whole Android Framework and just want to understand why this is happening.
Thanks to Ingo's and CommonsWare's hints I came to the conclusion, that following line caused the exception:
EDIT:
In fact it was the start of the foreach loop, which iterates over all subdirectories and files of a given directory. I didn't know, that this would cause a NPE, if the list you want to iterate on is actually null. For some reason I thought that the loop would be automatically skipped in this case.
I have a program that works with multiple threads.
For each I set uncaught exception handler th.setUncaughtExceptionHandler (new AppExceptionInterloper ()), but it displays "thread exiting with uncaught exception (group = 0x4001d800)" as a localized problem. Why it appears at the log and not in the class AppExceptionInterloper?
same error i have got just now. You must have forgotten to catch the ecxeption in any try-catch like Arrayindexoutofbound or JSONecxeption like wise. I have used the array and got the JSON as the result from the webservice. I forgot to put the JSONEcxeption in it.when i caught it.
When you see the stack trace you will find the "Caused by: java.lang.ClassCastException" or some thing like another exception in your case. Do catch it. You will get your code run.