Android crash happening in some background apps - android

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.

Related

Fail to initialize resources in android app - then NullPointerException

So, I have this android application and even some users. As I have a crash report system, I can see when someone's app crashes and the cause.
It appears that, though rarely, the app crashes randomly with NullPointerException when it tries to change some attributes(rotation, text, etc..). I make sure everything is set first thing in the onViewCreated method(using Fragments) like this:
private TextView orientationView;
orientationView = this.getActivity().findViewById(R.id.orientationView);
Using this ^^ example, I then try to hide/show this view and get an exception as it appears to be null sometimes, which is what I struggle to figure out why.
orientationView.setVisibility(View.VISIBLE); // app crashes when orientationView is null
Being a newbie in android development, I am not sure if it is a good practice, but in some of the fragments, I set all the previously initialized resources to null in the onDestroyView method, but the one that crashes the most doesn't have this method implemented, which make me to believe that somehow the resources are just not found/initialized in some rare occasions and I fail to change them later with an exception.
Could someone help me figure this out :) (more description could be provided, if needed)

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

NullPointerException inside Context.getDrawable

So I just released a new beta today with no changes to this piece of code. Strangely enough I got a new crash I've never seen before reported on Crashlytics. It has only happened to 2 users from two different manufacturers on Android 6 and 7. So it isn't a huge deal yet but I would still like to get it fixed.
Anyone have any idea what might be the issue here?
Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.CharSequence android.content.res.StringBlock.get(int)' on a null object reference
at android.content.res.AssetManager.getResourceValue(AssetManager.java:206)
at android.content.res.Resources.getValue(Resources.java:1540)
at android.content.res.Resources.getDrawable(Resources.java:918)
at android.content.Context.getDrawable(Context.java:463)
at android.support.v4.content.ContextCompatApi21.getDrawable(ContextCompatApi21.java:30)
at android.support.v4.content.ContextCompat.getDrawable(ContextCompat.java:372)
Thanks.
Here is the code that causes the issue:
#Override
public Drawable getDefaultPlaceholderImage() {
return ContextCompat.getDrawable(this, R.drawable.default_placeholder);
}
I have the similar crashes at some devices (Samsung GT-I9505, Android 5). The error happens while parsing xml of the image. The cause of the error is the number with two points in the xml (it was "1.84.63" in my xml). Try to create all xml of images by another converter (for example, Vector Asset Studio).

JNI Callback to Java on non UI thread

I have created a thread in java that does some processing passes the data to legacy C++ using JNI. The C++ code performs some tasks on a separate thread and then returns, at this point I want to callback from JNI into the Java thread rather then the main interface thread. The code seems to build and run without errors, but when CallVoidMethod is called to call back into Java nothing happens, no exceptions or errors, it does seem to invoke the Java code.
I am calling AttachCurrentThread which seems to work and detach at the end, the calls to find the method all seem to succeed. Has anyone got any ideas or have I got the wrong idea?
There is no silver bullet to fix such problem; you could have any of the miriad little things go wrong. I would suggest to start counterintuitively with some code that does not work. Set the method ID deliberatly wrong; see how the system behaves differently. Set the object reference (or class reference, if it is a static method) to an unexpected object, or a non-existing object; see what happens when the object reference is not globalized... You've got the idea.

Parcel.readException passing an object to remote service

I wrote a remote service that the clients can log on with the usual mechanisms of IPC provided by Android and the binding seems to work. The problem arises when I go to call a method in which I have to pass an object as a parameter because I get this "curious" exception:
10-19 15:09:04.601: ERROR/AndroidRuntime(2985): FATAL EXCEPTION: main
10-19 15:09:04.601: ERROR/AndroidRuntime(2985): java.lang.NullPointerException
10-19 15:09:04.601: ERROR/AndroidRuntime(2985): at android.os.Parcel.readException(Parcel.java:1253)
10-19 15:09:04.601: ERROR/AndroidRuntime(2985):at android.os.Parcel.readException(Parcel.java:1235)
10-19 15:09:04.601: ERROR/AndroidRuntime(2985): at it.domod.commons.interfaces.DeviceManager$Stub$Proxy.sendCommand(DeviceManager.java:121)
It seems to be thrown from the proxy class generated from the .aidl file.
The more strange thing is that the object seems to be passed correctly but probably there is something wrong around. Any idea?
I've been encountering this issue as well and after a bit of poking around found the problem. I'm going to post my solution in case it helps others found drifting in the same boat.
Firstly debugging the remote thread doesn't work in Eclipse unless you enable debugging on the remote service. To do this I needed to run the app and put a breakpoint in my first activity that just binds the service, once the service is up and running I open the DDMS window in eclipse and select the remote thread and press the debug button. Now it's possible to jump back to the java window and add your breakpoints into the remote service and have them triggered.
From there I found my problem was actually I was trying to operate on a null pointer object in my stub function in the remote process which in turn injected a parcel exception for nullpointerexception in the result it was returning and looks like what this original question is asking about.
My solution was simply to test the object wasn't null before using it :)
i.e. I added the 'if' statement as you'd expect in the implementation of the stub function...
if( myobject != null )
{
myobject.dosomething()
}

Categories

Resources