SEVERE BUG: SystemUI service for SamsungDeX crashes after not responding, TaskBar and other interface elements are frozen until restart

Hi Everybody!

I am writing here because I am desperate in succeeding to find any attention from Samsung about a problem which destroys UX on Samsung DeX that firstly presented itself in Android Pie, extended to Android 10 and survived many patches including the recent ones.

I am on Samsung tablet (Galaxy Tab S4), but also the newer tabs are affected. So we are speaking of Samsung DeX for Tablets here. The current version is 3.7.02.1, but it manifested down to 2.5.x.x; it occurs too iften to ignore it and basically it ruins my User Expierence.

Over 2 years of using my device I created at least dozen cases in my regional Samsung Tech Support; submitted dozens of case reports in Samsung Members, many were very accurate and detailed, with logs attached. Also I submit every time it occurs with a short description and logs attached, and this makes hundreds of reports. Even while writing this text (up to this moment) it occurred twice!

I have no idea why these reports never reaches Samsung DeX developer teams, obviously something is broken with Samsung services or Samsung decided to ignore the problem. So I write here for a small chance that the actual guys working on Samsung DeX will notice this and fix it, or spread the word until it reach the proper guys. If you can do that, please help and spread this among your contacts. The support years are ending soon for my tablet and this critical bug still NOT solved, so there is a big chance to be left with a buggy d3vice on my hands after all the years and this s…cks.

{Bug description}

SystemUI process on Samsung DeX seems to stop receiving events, its buffers overwhelm ans it crashes with a message box “SystemUI process stopped responding, Wait, Close, Submit Error report”.

This may happen first time anywhere from dozen of minutes till days of using with typical values of an hour; more often it happens when entering text into boxes, unlocking device, and opening notifications and general interaction with items placed on TaskBar (even simply scrolling icons of open apps left and right).

Interaction first becomes laggy with microfreezes, and very soon they become noticeable and finally all becomes non responsive. Most often this limits to the elements on TaskBar and TaskBar itself, while the other apps currently open not affected (I can interact). But about 25% of cases it also spreads itself to every open app, so I cannot interact. Several times it required force rebooting to recover, twice or thrice it rebooted on itself without asking me.

After rebooting (the buffers are refreshed and empty) there seems no evidence of the bug! Until it first appears, and when it does, it repeats really often - often enough not to allow for any meaningful working!
This whole situation result in too often reboots and hence, inability to sustain a stable workspace with open docs, apps, etc. , rendering the whole idea of Samsung DeX useless.

Now I have to admit, I have many apps installed so since there are more elements added to the TaskBar and more notification events than a normal User might have, the buffers overwhelms too fast for this bug to manifest in reasonable time. Maybe Samsung tagged this bug as “not important” after not being able to reproduce it on minimal configuration (no apps installed) but this is natural as minimal configuration produces least number of events so there is nothing to overwhelm!

My device though, never runs in low memory conditions, it is 256Gb/6Gb model, so typically I have 1 - 1,5 gigs if free memory (2,2 just after reboot).

My Samsung account is qcplab@gmail.com - in case the proper guys are reading this, you may check the cases submitted and logs attached to this ID.

On your request I can do more logs.

Thank you everybody who read this and is able to help.

P.S.: what is NOT helpful, are the advices to “reboot your device, clear cache, reinstall apps causing trouble, not using buggy features, factory reset” and other of this sort.

Hi,

This is developer community where developers who make their app compatible with DeX can discuss with each other. It is hard to get solution of your issue from here.

You can try to post your issue in Samsung Community or reach out to support team through Samsung DeX > Support > Contact us. Hopefully you will get better and faster response from here.

Thank you.

Hi! Thank you for your reply and kind advice.

I wrote the bug description here to draw attention of devs community in a hope that signal about this bug may spread within the community and with actual developers who work in Samsung, eventually reaching the goal.

I am not looking for a solution, I am making it visible.

Hi community,

This a small but important update about the issue:

Frequency of the bug manifestations decreases by a lot, if VPN connection is NOT constantly used.
I have tried many VPN providers, the apps which install local VPN profiles, that run local or remote services via the VPN profile. I noticed that most frequent manifestations occurs with heavily featured services like OpenVPN written in Java; the same OpenVPN written in C++ decreases number of manifestations decreases by order of magnitude!

So the bug has to be something about Java implementation of VPN services. Maybe Java itself.

Hi Community,

I recorded trace logs for all the categories available there in Developers mode, the traces contain 7 distinct System UI for Samsung DeX service crash events. The trace file is huge of course, so instead of putting it here, I rather uploaded it to Mega for your availability. The password to ZIP coincides with my Samsung account email found in the first post.

The direct link to download is: https://mega.nz/folder/3A0mTYpK#l0ZGEKIEJ1v0icNamAl_8g

I will keep the link indefinitely.

Well,

After considering more deeply positive correlation between frequency of the bug manifestation and downloading/streaming activities using VPN, or high-level languages using computationally intensive tasks, as you know these produces lots of unique event handlers during operation… I have a feeling that it might be somehow connected with entropy issue of Android (you can google it, it is interesting hypothesis!).

Indeed, the actions and scenarios which typically result in this bug manifestation, usually suggest event-rich, media, streaming operations - lots of those, and most are using random number generator, effectively reducing entropy. And it is known that when the entropy pool is empty, any interaction with interface is halted!

However, I tried the entropy level available with 3C software (my device is not rooted, but the monitoring feature does not require a root), it is usually around 25% and only goes as low as 20% when the manifestation happen.

But on the other hand, for reading operations (there is a separate threshold in the entropy pool for reading and writing ones), this device only has 64 values which appears far too small, against 894 for write operations). The entropy level calculator in 3C only shows common level both for reading and writing operations so maybe depletion of small reading pool is hidden in space of large writing pool?

Who knows, maybe this issue was resolved if the reading value was set to 256 or 512? 3C app can do that, but this does require a root.

If anybody has a rooted device with DeX, it would be interesting to test!

I leave this post as a hint for what is happening inside the rabbit hole of this miraculous bug)

Thank you for reading!

Hi again,

After manually analyzing for days the recorded with Logcat system logs, I have isolated most common warning which appears there when another manifestation happens:

InputMethodManager.peekInstance() is deprecated because it cannot be compatible with multi-display. Use context.getSystemService(InputMethodManager.class) instead.

java.lang.Throwable
at android.view.inputmethod.InputMethodManager.peekInstance(InputMethodManager.java:1147)
at com.android.internal.widget.FloatingToolbar$FloatingToolbarPopup.getViewPortVisibleHeight(FloatingToolbar.java:2253)
at com.android.internal.widget.FloatingToolbar$FloatingToolbarPopup.calculateCoords(FloatingToolbar.java:2296)
at com.android.internal.widget.FloatingToolbar$FloatingToolbarPopup.access$3000(FloatingToolbar.java:389)
at com.android.internal.widget.FloatingToolbar$FloatingToolbarPopup$5.onTouch(FloatingToolbar.java:635)
at android.widget.PopupWindow$PopupDecorView.dispatchTouchEvent(PopupWindow.java:2857)
at android.view.View.dispatchPointerEvent(View.java:14643)
at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:6539)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:6326)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5764)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5817)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5783)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5939)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5791)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:5996)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5764)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5817)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5783)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5791)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5764)
at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:8976)
at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:8837)
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:8790)
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:9112)
at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:194)
at android.view.InputEventReceiver.nativeConsumeBatchedInputEvents(Native Method)
at android.view.InputEventReceiver.consumeBatchedInputEvents(InputEventReceiver.java:183)
at android.view.ViewRootImpl.doConsumeBatchedInput(ViewRootImpl.java:9052)
at android.view.ViewRootImpl$ConsumeBatchedInputRunnable.run(ViewRootImpl.java:9139)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:999)
at android.view.Choreographer.doCallbacks(Choreographer.java:797)
at android.view.Choreographer.doFrame(Choreographer.java:725)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:984)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:237)
at android.app.ActivityThread.main(ActivityThread.java:8107)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:496)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1100)

It repeats over and over. It seems, some calling function uses a wrong type of call and this ruins DeX. After that, typical errors are:

Input receiver: Attempted to finish an input event but the input event receiver has already been disposed.

See full journal at:

https://drive.google.com/file/d/1XK4GrlOfaCSlOBRtQkW0UFLf6F4TyWAK/view?usp=drivesdk