Develop Reference

Android crash happening in some background apps

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.

Crash due to Hierarchy view only on Nougat

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.

Getting java.lang.IllegalStateException: Binder has been finalized! from a home screen widget

I have an Android app that has a home screen widget. When I add one with a particular configuration I get an error "AppName has stopped". Logcat reveals the following crash log:
E/System: java.lang.IllegalStateException: Binder has been finalized!
at android.os.BinderProxy.transactNative(Native Method)
at android.os.BinderProxy.transact(Binder.java:748)
at android.security.IKeystoreService$Stub$Proxy.abort(IKeystoreService.java:1373)
at android.security.KeyStore.abort(KeyStore.java:529)
at android.security.keystore.AndroidKeyStoreCipherSpiBase.finalize(AndroidKeyStoreCipherSpiBase.java:744)
at android.security.keystore.AndroidKeyStoreRSACipherSpi$PKCS1Padding.finalize(Unknown Source:0)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:250)
at java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:237)
at java.lang.Daemons$Daemon.run(Daemons.java:103)
at java.lang.Thread.run(Thread.java:764)
I tried to debug that every way I could think of (enabling breakpoints on exceptions, stepping through my code that's executed before the exception, etc.) to no avail. The exception seems to be coming not from my code but from another process that I don't have access to. How do I fix this problem?

After some experimenting I found that the exception happened after this line:
rv.setInt(R.id.task_item_color_header, "setBackgroundColor", Color.parseColor(color));
Turned out that in some cases color (which is a String) does have a value but it's "null". That causes a crash when trying to set a non-existing color as the background to a RemoteView. However, since RemoteView's values are not set directly but are rather delegated to the OS to set, the crash occurred in another process.
So, if you have a similar problem - check the values that you try to set on your RemoteViews

Writing to log causes App to crash?

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.

Eclipse Logcat window cuts off exception stack traces

My logcat window in Eclipse only displays the first few lines of the StackTrace for each exception. This means that I often can't see where an exception occured. Is there any way to change this setting?

If you're referring to the "...12 more lines..." part, you only see that for exceptions that were the cause of another exception. If the top part of the stack trace is the same as the earlier trace, the full set of frames is only shown for the outermost exception, and the other traces get the "..." treatment.
Put another way, the chunk of a trace that isn't shown is a duplicate of a trace that appeared earlier in the exception cause chain. For example, suppose I have code where the method main() calls one(), which calls two(), and so on. four() throws an exception. two() catches it and re-throws it. The exception will look like this:
java.lang.RuntimeException: re-throw
at Foo.two(Foo.java:14)
at Foo.one(Foo.java:7)
at Foo.main(Foo.java:3)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.RuntimeException: first
at Foo.four(Foo.java:23)
at Foo.three(Foo.java:19)
at Foo.two(Foo.java:12)
... 3 more
The "caused by" exception says "... 3 more" rather than explicitly listing one(), main(), and dalvik.system.NativeStart.main. So to get the full trace of the initial exception, you would start by reading its trace, then continue at the trace above.
Note there is no overlap -- two() appears in both, but in the "first" trace it's on the call to three(), and in the "re-throw" trace it's on the throw instruction.

you can overload all the log methods (log.d, log.i, log.e, etc) with (String tag, String msg, Throwable tr) parameters, where the third parameter is the exception. This will give you the full stacktrace in logcat
http://developer.android.com/reference/android/util/Log.html

If your code calls a method which produces too tall of stack you can (and should) handle the exception in your code and output whatever is relevant to logs.
If you have no exception handling whatsoever and you don't even know where in your code should you be putting such a handler then the problem is entirely elsewhere - you should be handling exceptions a bit better than that.