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()
}
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 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
I am new to android development. In the overriden onCreate() method of my activity, I perform some operations. For ex. check if SharedPreference is already available and then route to other activity. How do I perform exception handling on this onCreate() method. Is it the right way to wrap the contents in a try catch and display the error dialog on exception?
If the exceptions are not handled properly, in my case the onCreate() method, the app crashes with message:
Unfortunately your application stopped working
On searching in the internet, I found that UncaughtExceptionHandler could be used to handle it. Any sample implementation and how to call it from all my activities would be helpful.
THat's the wrong way to go about it. Instead, go into your logcat. Read the stack trace of the exception. Figure out what you did wrong. Fix it. Just catching exceptions is a horrible practice unless you're catching a specific exception for a specific reason- its very unlikely your app is in a state where it can continue correctly. Don't be lazy, track down your bug and fix it.
With something like this you can catch a generic Exception in your onCreate() method:
#Override
protected void onCreate(Bundle arg0) {
super.onCreate(arg0);
try {
// do whatever you need
} catch (Exception e) {
e.printStackTrace();
}
}
Exception catching can be used with many goals. An interesting one is to catch particular expected exceptions to fix some problems (for example setting a generic value into a variable otherwise null after occurring an error).
The general purpose however is to avoid that an error causes a problem or in the worst case a crash of your application. Depending oh what kind of software you are developing, a crash may represents a little problem (like in an Android app), a very big one (like in airplane's softwares or power plants' softwares).
We can identify two kind of exceptions.
The first type are those exceptions specific to definite problems. They have to be declared into methods signature, so you are encouraged or obbligated to manage these exceptions and their relative problems. These exceptions represent an error that should probably occur during particular code execution, like a parsing error, or an input output error. For this type of problems we have particular exceptions, to catch and easily manage them (for example as previously said to init a variable with a default value after an error).
The second type of those exception represents instead some generic problems that can occur during program execution. They are a big and generic set and generally their probability of occurring is low. For this reason you are not obbligated to manage them. The main example of this type is the general Exception class.
So an catching an Exception is not the right approach to solve a bug, as suggested by Gabe Sechan.
Catching a generic Exception in the main() Java method can be a way, for example, to show a default human readable error to the user if nothing else is available.
Or could be a way to keep the failing of the current operation reducing crash probability.
Now, in Android we can't act directly on the main() method. onCreate() method is executed and exited so catching here a generic Exception has no much sense. Obviously it depends also on what you do in your onCreate() method and what you want to do if an error occurs. You could do some strange stuff (is very defined what you should do in the onCreate() method) and you could need to manage a big set of problems only showing an error, so it has more sense catch only a generic Exception than a lot of particular exceptions to make the same thing in each catch block.
If you want to achieve this goal (a message showed for all the errors occurred during onCreate() execution, made Activity by Activity) this is the right approach.
If instead what you want to achieve is to intercept all of the errors that are generated during all of your app execution, a good approach could be the UncaughtExceptionHandler, that act similarly to catch a generic Excepetion into a Java main() method. At this level an interesting approach is described here.
For more infos about exceptions you can read this and this.
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 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.