Original topic:

The Central Issue of DeX on Galaxy Tab S Series tablets: TaskBar not responding, SystemUI crashes

(Topic created on: 2/10/21 10:54 AM)

Hi Samsung and the Community!

As Samsung DeX project develops, it is still in early development stage. As fans of Samsung, we all may excuse many things here and there, unless there is a bug which roots all other bugs and prevents more people from entering Samsung DeX experience, effectively destroying the very idea of DeX: a true mobile Desktop.

Other mobile solutions are next to Samsung with full-scale OS. Hence, it is especially important to address the issue described below, and the name for it is: SCALABILITY.

As a Samsung enthusiast, I followed the way Samsung pioneered and handicrafted my Samsung DeX working environment with tedious tuning and carefully selecting apps. Right at the moment, I have hundreds of apps installed on my 6GB/LTE Android Galaxy Tab S4 tablet. Yes, I have made a "system of my dream", but... I cannot use it.

The problem is the DeX central service "System UI for SamsungDeX", which starts to lag as more and more apps are added to the system. Since this service is really "central", it roots all interactions with User, draws apps windows, TaskBar, CommandPanel, and all the interface elements which populate the apps dock, collects every event, responds to User tapping and routes reactions.

At certain number of installed apps however, lagging becomes heavy, and then it may freeze absolutely! No tapping here and there helps; waiting indefinitely is a no option, but finally the service crashes with:

"SystemUI for Samsung DeX stopped responding. Abort, Restart, Send a Report".

[*if "Show error message permanently" option is not activated, one cannot see the message, rather TaskBar is reloading silently, however, it only starts a new iteration and freeze again; in fact, the more user taps the more it freezes see: https://drive.google.com/file/d/1_j3mc7ue2yfXBTkk18flJIKItH7uGUQn/view?usp=drivesdk*]

I have submitted many reports (each with short description about each case: what was the task when it crashed, the working set, how it reacted, and attached system journals to each of the reports - one who has access rights can find the journals linked to my Samsung account: qcplab@gmail.com.

Since its first manifestation on Android Pie 9.0 OneUI 1.5, up to nowadays with Android 10 OneUI 2.1, Samsung provided many updates but none fixed the issue.

Now, my wife purchased S6 tablet and after a while, she also started to get this trouble with SystemUI.

At first I though it is a bug of some app, but much(!) testing drived me away from this assumption. This is really a problem of scalability of DeX itself, maybe it has some buffers or what which overflow with too many events, and it cannot process them in time? It seems that SystemUI runs on a first single core and not in the higher priority, so any other task occupying the core, will prevent TaskBar and all the SamsungDeX interface from normal responding? Or it is a simple QuickTime interface bug that drops events from user to a wrong target? I dunno.

The service can be restarted though, but this indeed, does not help, because it gives only temporary relief and soon(er or later) it returns. As the only way to naturally "flush the buffers" is to reboot the device, I have to reboot often: too often to leave some time for any meaningful work. And when it does manifest itself, the lagging is so heavy that it takes lots of time just to save docs...

Now I have from 3 to 8 manifestations per typical working day.  But it might do that 8 times in half an hour as well. Therefore I can call SamsungDeX anything but a professional solution as advertised by Samsung. My enthisuasm is about to end soon, if not fixed with the next planned update.

Okay, now I have collected logs, traces and observations I would like to share. Who knows, maybe this post will catch eyes of "proper guys to address".  My general guides on how to hunt this bug:

First: you will never catch this bug on minimal test configuration; it requires some event-rich content, and some loads of apps (as every app hooks in a way to the System, increasing load).

Second: using streams which consume lots of random numbers from the entropy pools (reading request threshold=64 and writing request threshold=894 on my device), like apps which ciphers data on the flow, encrypting/decrypting greatly influences the chance to trigger the manifestations;

Third: using network intensively, especially combined with VPN (but not necesserily) increases chances to trigger a manifestation.

Once the TaskBar in SamsungDeX starts lagging, increasing tapping density (or draw meaningless lines on the interface), significantly raises probability of getting a whole-interface freeze, and if you continue tapping, the message from Android.

Once it happens a single time, you are in a vicious loop "lagging - freeze - message about SystemUI not responding - restarting the service - TaskBar reloading ... new iteration".

I have recorded full system traces in highest level of detail for 7 manifestations within 20 minutes. The file is huge, so I uploaded it to a public share, one can collect it here: 


(ZIP file password: qcplab@gmail.com)

I have created a thread on SamsungDevelopers forum, specially dedicated to this issue, where one can find more up-to-date tech information (and discussion is welcome):


I do hope that Samsung will fix this finally and after 1.5 years of waiting, us user would not be left behind without a chance for a fix and further updates with devices bugged like they are now.

Summary about my device configuration:

Rooted: NO

Modified in any other way: NO

Using non-Google /Samsung side-loaded apps: NO

Typical free RAM available as shown by OS: 1.5/6 Gb

True free RAM (unused, un-allocated, un-associated as FreeMem() reports): 0.4/6Gb

Typical free RAM available immediately after reboot as shown by OS: 2.5/6Gb

Typical processor load level, all cores at 1.8 GHz: 70-80% (4 cores can clock up-to 2.4 GHz) during usual work like browsing Chrome, working in Word, watching YouTube etc.

Using any Themes or decorative shells (by Samsung or Third-Parties): NO

1 Reply

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.

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: