We Keep Coding

How to know from which activity an error comes from my application in production?

My application is 2 months in production and I was checking the section that shows the play console crashing and I have been able to solve some problems, but there are some in which I do not know exactly what activity they come from, mi error is java.lang.IllegalStateException and when I press see more:
java.lang.IllegalStateException:
at androidx.work.impl.utils.ForceStopRunnable.run (ForceStopRunnable.java:115)
at androidx.work.impl.utils.SerialExecutor$Task.run (SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
at java.lang.Thread.run (Thread.java:919)
Caused by: android.database.sqlite.SQLiteCantOpenDatabaseException:
at android.database.sqlite.SQLiteConnection.nativeOpen (Native Method)
at android.database.sqlite.SQLiteConnection.open (SQLiteConnection.java:300)
at android.database.sqlite.SQLiteConnection.open (SQLiteConnection.java:218)
at android.database.sqlite.SQLiteConnectionPool.openConnectionLocked (SQLiteConnectionPool.java:737)
at android.database.sqlite.SQLiteConnectionPool.open (SQLiteConnectionPool.java:284)
at android.database.sqlite.SQLiteConnectionPool.open (SQLiteConnectionPool.java:251)
at android.database.sqlite.SQLiteDatabase.openInner (SQLiteDatabase.java:1386)
at android.database.sqlite.SQLiteDatabase.open (SQLiteDatabase.java:1331)
at android.database.sqlite.SQLiteDatabase.openDatabase (SQLiteDatabase.java:967)
at android.database.sqlite.SQLiteDatabase.openDatabase (SQLiteDatabase.java:955)
at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked (SQLiteOpenHelper.java:448)
at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase (SQLiteOpenHelper.java:391)
at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper$OpenHelper.getWritableSupportDatabase (FrameworkSQLiteOpenHelper.java:145)
at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper.getWritableDatabase (FrameworkSQLiteOpenHelper.java:106)
at androidx.room.RoomDatabase.beginTransaction (RoomDatabase.java:352)
at androidx.work.impl.utils.ForceStopRunnable.cleanUp (ForceStopRunnable.java:156)
at androidx.work.impl.utils.ForceStopRunnable.run (ForceStopRunnable.java:87)
Out of 750 users who have installed my application it happened to one 5 times, Should a bug that happened to a single user (of 750) be investigated or not?, And most importantly, how can I know exactly where the error came from?

When throwing an exception, put the user that is currently being accessed so you can track it down. Put as much info in the exception as possible that will help you figure out which item might be causing it.
https://stackify.com/best-practices-exceptions-java/
These are some good examples as well as good practices to follow. In those messages that are mentioned, add the user id or something that helps you identify what's going on. Learn to make custom exceptions and catch the most specific exceptions you can. Don't just catch Exception, its better to be specific about the exception your catching rather than casting a wide net.

android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy#aba286f is not valid; is your activity running?

All of sudden my app crashes in between smooth sailing.
Complete error:
at android.view.ViewRootImpl.setView(ViewRootImpl.java:679)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:342)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:93)
at android.widget.Toast$TN.handleShow(Toast.java:434)
at android.widget.Toast$TN$2.handleMessage(Toast.java:345)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
I am finding it very hard to debug . Please throw some light on how to debug it .Thanks for the help.
IMPORTANT NOTE
This is not a duplicate of
Error : BinderProxy#45d459c0 is not valid; is your activity running?.
I am not using any dialog in my app . Yes i am indeed using simple
Toasts . But its not clear whats causing the error....
UPDATE:This error is happening the activity that has TabbedLayout.I have removed all toasts,the error still persists.I have used Logs instead

This exception comes when trying to perform operation on main thread while thread does not exist. This happens when you are showing dialog in a activity/fragments but that class is already finished, so this exception come.
To handle this exception while showing any types of dialog check the isFinishing() status.

There might be context would be old window (Activity) where Activity configuration might be change and you may preserve old context which has no any window available right now.
That's why this could be occurred.
Please check your code is there any configuration change or Activity get refresh?
And your Toast class inside you are giving closed window or old window context which is not actually present.

SysUtils﹕ ApplicationContext is null in ApplicationStatus (WebView)

I can see something strange at WebView based app start. It doesn't affect the app at all but I'm curious why the error appears. Nothing crashes, everything seems to be ok, but the error...
Here is logcat
Loading com.google.android.webview version 42.0.2311.137 (code 2311137)
I/LibraryLoader﹕ Time to load native libraries: 2 ms (timestamps 3347-3349)
I/LibraryLoader﹕ Expected native library version number "",actual native library version number ""
V/WebViewChromiumFactoryProvider﹕ Binding Chromium to main looper Looper (main, tid 1) {2d3b4b2c}
I/LibraryLoader﹕ Expected native library version number "",actual native library version number ""
I/chromium﹕ [INFO:library_loader_hooks.cc(112)] Chromium logging enabled: level = 0, default verbosity = 0
I/BrowserStartupController﹕ Initializing chromium process, singleProcess=true
W/art﹕ Attempt to remove local handle scope entry from IRT, ignoring
E/SysUtils﹕ ApplicationContext is null in ApplicationStatus
W/chromium﹕ [WARNING:resource_bundle.cc(286)] locale_file_path.empty()
I/chromium﹕ [INFO:aw_browser_main_parts.cc(63)] Load from apk succesful, fd=34 off=6850672 len=3697
I/chromium﹕ [INFO:aw_browser_main_parts.cc(76)] Loading webviewchromium.pak from, fd:35 off:7953036 len:1161174
I/Adreno-EGL﹕ <qeglDrvAPI_eglInitialize:379>: QUALCOMM Build: 01/15/15, ab0075f, Id3510ff6dc
W/AudioManagerAndroid﹕ Requires BLUETOOTH permission
W/chromium﹕ [WARNING:data_reduction_proxy_config.cc(150)] SPDY proxy OFF at startup
W/art﹕ Attempt to remove local handle scope entry from IRT, ignoring
W/AwContents﹕ onDetachedFromWindow called when already detached. Ignoring
I/GAv4﹕ Google Analytics 4.5.0/7327 is starting up. To enable debug logging on a device run:
adb shell setprop log.tag.GAv4 DEBUG
adb logcat -s GAv4
I suppose the error comes from here:
https://chromium.googlesource.com/chromium/src/base/+/master/android/java/src/org/chromium/base/SysUtils.java
A few lines of WebView initialisation
...
// load url in webView
webView.loadUrl(webViewUrl);
webView.setWebViewClient(new MyAppWebViewClient());
// implement WebChromeClient inner class
// we will define openFileChooser for select file from camera
webView.setWebChromeClient(new WebChromeClient() {
...
What's going on?

What is happening here is:
The ApplicationStatus is not initialized yet, so the context cannot be obtained from it. This is a completely natural situation, so no error should be raised. Logging this as an error was an exaggeration from the coder.
However:
This does not cause any real problem, because the function tries to get a context object only to perform yet another check to assess the performance capabilities of the device. Since it sometimes fails to call the "isLowRamDevice()", it will just carry on performing the rest of the checks. So worst case scenario is not being able to detect a low-end phone at this point, and subsequent checks will be made.
Also it is completely normal that
"I see this error in a Lollipop device (Nexus 10) but not in a JellyBean device", because the function has an early return if it detects anything below KitKat. (// Any pre-KitKat device cannot be considered 'low-end')

java.lang.RuntimeException: Could not read input channel file descriptors from parcel

I am using crashlytics to track my app's crash. There is one bug which is quite hard to figure out. The stack trace from crashlytics is as below:
java.lang.RuntimeException: Could not read input channel file descriptors from parcel.
at android.view.InputChannel.nativeReadFromParcel(InputChannel.java)
at android.view.InputChannel.readFromParcel(InputChannel.java:148)
at android.view.InputChannel$1.createFromParcel(InputChannel.java:39)
at android.view.InputChannel$1.createFromParcel(InputChannel.java:36)
at com.android.internal.view.InputBindResult.<init>(InputBindResult.java:62)
at com.android.internal.view.InputBindResult$1.createFromParcel(InputBindResult.java:102)
at com.android.internal.view.InputBindResult$1.createFromParcel(InputBindResult.java:99)
at com.android.internal.view.IInputMethodManager$Stub$Proxy.windowGainedFocus(IInputMethodManager.java:851)
at android.view.inputmethod.InputMethodManager.startInputInner(InputMethodManager.java:1292)
at android.view.inputmethod.InputMethodManager.onWindowFocus(InputMethodManager.java:1518)
at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:3550)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:157)
at android.app.ActivityThread.main(ActivityThread.java:5293)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1265)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1081)
at dalvik.system.NativeStart.main(NativeStart.java)
I know there is one similar question about this here. But there is a bit different. And as statistics from crashlytics, the crash happens mainly in SAMSUNG android phone.
I am new to android and don't know why the crash happened and how to fix this kind of crash.
Any suggestion would be much appreciated.

Think it's a very wide area and there could be a lot of situations which can trigger this system level exception. But maybe this example of how it was fixed in a particular project can help someone.
I experienced a similar exception:
"Could not read input channel file descriptors from parcel" on Samsung phone:
java.lang.RuntimeException: Could not read input channel file descriptors from parcel.
at android.view.InputChannel.nativeReadFromParcel(Native Method)
at android.view.InputChannel.readFromParcel(InputChannel.java:148)
at android.view.IWindowSession$Stub$Proxy.addToDisplay(IWindowSession.java:690)
at android.view.ViewRootImpl.setView(ViewRootImpl.java:525)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:269)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:69)
at android.widget.Toast$TN.handleShow(Toast.java:402)
at android.widget.Toast$TN$1.run(Toast.java:310)
at android.os.Handler.handleCallback(Handler.java:730)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5103)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:737)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
at dalvik.system.NativeStart.main(Native Method)
It happened in a big old project which I got for maintenance and this floating bug occurred only after several hours. I spent quite some time on it and also read some related answers on SO regarding it and had no clue except it's a system level bug of Android, and there should be some extra data or duplicates of objects or big objects in memory etc:
https://code.google.com/p/android/issues/detail?id=32470
The last thing I could think about was SoundPool. It's not used a lot in the project - there are not more than 10 different sounds played from time to time. But it was the root cause! Sometimes there were floating exceptions from SoundPool "unable to load sample (null)". And it helped to realize that SoundPool was used in a wrong way:
public void play(int rscId) {
...
final int soundId = soundPool.load(mContext, rscId, 1);
...
soundPool.play(soundId, volume, volume, 5, 0, 1f);
So new id was generated and sound resource was reloaded each time application called play sound method! And after certain amount of time some non related exceptions started to occur until application crashed with the "Could not read input channel file descriptors from parcel" exception.
It's interesting that one of those non related exceptions was: "ExceptionHandled in unable to open database file (code 14)":
ExceptionHandled in unable to open database file (code 14)
android.database.sqlite.SQLiteCantOpenDatabaseException:
unable to open database file (code 14)
at android.database.sqlite.SQLiteConnection.nativeExecuteForCursorWindow
(Native Method)
at android.database.sqlite.SQLiteConnection.executeForCursorWindow
(SQLiteConnection.java:845)
And of course it has nothing to do neither with database nor with toasts/parcels. The fix for that particular situation was very easy: just preload all sounds as it's suggested in Android documentation:
http://developer.android.com/reference/android/media/SoundPool.html
"The loading logic iterates through the list of sounds calling the appropriate SoundPool.load() function. This should typically be done early in the process to allow time for decompressing the audio to raw PCM format before they are needed for playback.
Once the sounds are loaded and play has started, the application can trigger sounds by calling SoundPool.play()."
So I moved soundPool.load() out from play() method and the exception :
"Could not read input channel file descriptors from parcel" has gone as well as the exception "unable to open database file (code 14)".
public void play(int soundId) {
...
soundPool.play(soundId, volume, volume, 5, 0, 1f);
And soundPool.release(); soundPool = null should be called as well when it's not needed anymore. And maybe it also can have an effect on such exceptions, see details here
Could not read input channel file descriptors from parcel
Most probably it's not the exact situation for the original question but hope it can give some information to dig further. I.e. looking for some additional exceptions, swallowed exceptions, or wrong files/data handling.

I am looking for the answer for a long time such as the others facing at this exception.
As I see it, this crash can also be triggered by the unexceptional TextView or EditText which works with the InputMethodManager:
java.lang.RuntimeException: Could not read input channel file descriptors from parcel.
at android.view.InputChannel.nativeReadFromParcel(Native Method)
at android.view.InputChannel.readFromParcel(InputChannel.java:148)
at android.view.InputChannel$1.createFromParcel(InputChannel.java:39)
at android.view.InputChannel$1.createFromParcel(InputChannel.java:36)
at com.android.internal.view.InputBindResult.<init>(InputBindResult.java:68)
at com.android.internal.view.InputBindResult$1.createFromParcel(InputBindResult.java:112)
at com.android.internal.view.InputBindResult$1.createFromParcel(InputBindResult.java:109)
at com.android.internal.view.IInputMethodManager$Stub$Proxy.startInput(IInputMethodManager.java:697)
at android.view.inputmethod.InputMethodManager.startInputInner(InputMethodManager.java:1407)
at android.view.inputmethod.InputMethodManager.checkFocus(InputMethodManager.java:1518)
at android.view.inputmethod.InputMethodManager.restartInput(InputMethodManager.java:1286)
at android.widget.TextView.setText(TextView.java:4718)
at android.widget.TextView.setText(TextView.java:4656)
at android.widget.TextView.append(TextView.java:4330)
at android.widget.TextView.append(TextView.java:4320)
...
When TextView appending text, it will make text to Editable, and start InputMethodManager. But at this time, something goes wrong in the InputMethod process, and it leads to fail to create InputBindResult which reading error from the parcel.
In this case, the workaround is very simple: DO NOT call append on textview directly, use StringBuilder or SpannableStringBuilder to build text and call TextView.setText(text) instead!

Previous users have commented that this can be a hard bug to track down. I caused this by building a custom alert dialog (containing multiple TextView objects) inside of a while loop vice an if statement. The application crashed before displaying the dialog box(es).

I have meet this problem recently.
java.lang.RuntimeException: Could not read input channel file descr
iptors from parcel.
I search the log find following info:
01-01 09:07:52.164 5162 6777 W zygote64: ashmem_create_region failed
for 'indirect ref table': Too many open files
The problem is that I create HandlerThread repeatedly, but don't do it's quit() method, at last result in fd leaked.

ViewRootImpl$ViewRootHandler means you have view.post or view.postDelay.
and in the post method maybe requestFocus or Keyboard

How do I find this RuntimeException in Android (stack trace)?

I have this strack trace from the Developer Console on Google Play so I have no way to reproduce this exception cause I don't know what triggers it. The user also didn't leave any message, so...
java.lang.RuntimeException: Binary XML file line #17: You must supply a layout_height attribute.
at android.content.res.TypedArray.getLayoutDimension(TypedArray.java:491)
at android.view.ViewGroup$LayoutParams.setBaseAttributes(ViewGroup.java:5319)
at android.view.ViewGroup$LayoutParams.<init>(ViewGroup.java:5271)
at android.widget.AbsListView$LayoutParams.<init>(AbsListView.java:6398)
at android.widget.AbsListView.generateLayoutParams(AbsListView.java:6035)
at android.widget.AbsListView.generateLayoutParams(AbsListView.java:96)
at android.view.LayoutInflater.inflate(LayoutInflater.java:477)
at android.view.LayoutInflater.inflate(LayoutInflater.java:396)
at com.android.internal.view.menu.ListMenuPresenter$MenuAdapter.getView(ListMenuPresenter.java:253)
at android.widget.AbsListView.obtainView(AbsListView.java:2212)
at android.widget.ListView.measureHeightOfChildren(ListView.java:1244)
at android.widget.ListView.onMeasure(ListView.java:1155)
at android.view.View.measure(View.java:12863)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:4698)
at android.widget.FrameLayout.onMeasure(FrameLayout.java:293)
at com.android.internal.policy.impl.PhoneWindow$DecorView.onMeasure(PhoneWindow.java:2256)
at android.view.View.measure(View.java:12863)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1166)
at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2552)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4507)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:790)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:557)
at dalvik.system.NativeStart.main(Native Method)
How do I pinpoint the problem?

This is Android's internal error, nothing in your code. You don't even see your app's code in stack trace, and your app works on many other devices.
I'm getting similar occasional crash reports, and also similar crashes on some Android versions (using ACRA). I've seen "You must supply a layout_height attribute" unexpected crash a few times.
If you use ACRA or similar, sometimes you just get reports for which your app is not responsible at all.

Message says - "You must supply a layout_height attribute."
So, double check that all your components have layout_height attribute.
I also had mention "menu" in this stack. It is generated by system. Double check that your all menus have valid items (at least not zero items) all the time.