Develop Reference

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)

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.

InputConnectionWrapper is not finalized and is causing a memory leak in Android

In certain situations, I create an EditText, pass the value to another Fragment, and then call removeAllViews on the ViewGroup that the EditText belongs to remove EditText.
The problem is that the InputConnectionWrapper associated with the EditText is still occupying memory.
In the above Heap Dump, the InputConnectionWrapper is allocated over 300 and takes up considerable memory.
However, with the Heap Dump enabled, there is only one EditText in the Activity, and it is judged that the InputConnectionWrapper is not created due to the corresponding EditText.
To close the InputConnectionWrapper, I tried the following function.
TextKeyListener.clear(editText.getText());
editText.setHint(null);
editText.removeTextChangedListener(this);
editText=null;
// The ViewGroup will then execute removeAllViews.
However, the InputConnectionWrapper seems to be allocated more over time as it is not finalized.
What is the reason InputConnectionWrapper will not be finalized?

I ran into the same issue found via LeakCanary giving me a chain of InputConnectionWrapper'd wrapping an EditText.
It looks like this is a bug in Android code that was fixed in Marshmallow. When I upgraded my min API version from 21 (Lollipop) to 23 (Marshmallow), the problem went away.

Android SIGSEV 11 fast scroll of ViewPager

I'm getting
A/libc(26509): Fatal signal 11 (SIGSEGV) at 0x0000000c (code=1), thread 26509 (ct.universaldev)
sometimes when scrolling ViewPager with Fragment's very fast. The app is compatible only with 4.0+ devices, also I don't out of memory (tracked with MAT and Little Eye) and using largeHeap attribute. Also it doesn't look like I'm having memory leaks (at least significant).
I don't receive any Java errors/exceptions before this one. How can I even understand what is the reason if this problem?

I was intercepting touch events in my Fragment subclasses using OnTouchListener attached to their top views. In this listener I was doing some "strange" stuff with event finally storing a local copy of MotionEvent object which was released in OnTouchListener's finalize method. After "decoding" native stacktrace I found out that crashed appeared sometimes on MotionEvent.release() method call. I refactored my code making that OnTouchListener unnecessary and that solved the problem.