Hrm. I've definitely tested on multiple Samsung devices -- and since you say it works fine on the S26 Ultra, it seems device-specific.

Are you able to get crash logs (or, really, any information from one of the bad sessions, like adb logcat output as it happens) off of the S9 Ultra? And just for comparison's sake, if you connect a *different* controller via Bluetooth, does it work on the Tab S9 Ultra?

Complete noob on android. How would I find the crash logs?

Just to add more intrigue, just got a USB c to USB c cable and used that with the dual sense and the tab s9 ultra. And he app works fine... its literally just via Blutooth we seek to have a problem

Originally posted by Packetdancer:

Hrm. I've definitely tested on multiple Samsung devices -- and since you say it works fine on the S26 Ultra, it seems device-specific.

Are you able to get crash logs (or, really, any information from one of the bad sessions, like adb logcat output as it happens) off of the S9 Ultra? And just for comparison's sake, if you connect a *different* controller via Bluetooth, does it work on the Tab S9 Ultra?

Not sure if you'd see my reply

You can use Android Studio or adb logcat to grab the logs from the device.

What version of Android is this tablet using?

I have the same issue, im on an s24 ultra though

I am also on an tab s9 ultra and the current build is still broken

The app Steam Link (com.valvesoftware.steamlink) encountered a critical exception, was abruptly terminated by the Android operating system (Killed due to signal 9), and instantly forced the system to generate a splash screen to try restarting it.

Here is the exact anatomy of why and how the app crashed:

1. The Smoking Gun: ConcurrentModificationException
The exact root cause of the failure is explicitly spelled out in this Java runtime stack trace:

Plaintext
05-19 15:19:44.764 27572 27572 E AndroidRuntime: FATAL EXCEPTION: SDLActivity
05-19 15:19:44.764 27572 27572 E AndroidRuntime: Process: com.valvesoftware.steamlink, PID: 27572
05-19 15:19:44.764 27572 27572 E AndroidRuntime: java.util.ConcurrentModificationException
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1111)
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at java.util.ArrayList$Itr.next(ArrayList.java:1064)
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at android.hardware.input.InputDeviceSensorManager$InputSensorEventListenerDelegate.removeSensor(InputDeviceSensorManager.java:283)
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at android.hardware.input.InputDeviceSensorManager.unregisterListenerInternal(InputDeviceSensorManager.java:515)
...
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at org.libsdl.app.SDLJoystickHandler.setSensorsEnabled(SDLControllerManager.java:568)
What it means: A ConcurrentModificationException happens when a block of code loops through an object list while another background thread suddenly edits or removes items from that same list simultaneously.

Why it happened here: Steam Link runs on a framework called SDL (Simple DirectMedia Layer). The app was actively setting up a stream and initializing your PS5 Controller (DualSense Wireless Controller). During initialization, the code attempted to loop through the device’s hardware tracking sensors (gyroscope/accelerometer). While looping, the sensor listener registrations updated at the exact same millisecond, corrupting the array index loop and instantly crashing the thread.

2. The Result: Android Kills the Process
Immediately following the Java error, the OS kernel steps in and terminates the app's instance (PID: 27572) to protect system stability:

Plaintext
05-19 15:19:44.780 27572 27572 I Process : Sending signal. PID: 27572 SIG: 9
05-19 15:19:44.810 1602 1602 I Zygote : Process 27572 exited due to signal 9 (Killed)
05-19 15:19:44.808 2636 5691 I WindowManager: WIN DEATH: Window{d03471d u0 com.valvesoftware.steamlink/com.valvesoftware.steamlink.SteamLink}
What it means: SIG: 9 is a hard force-kill (kill -9). The Android OS drops all surfaces, clears out the app's assigned memory structures (libprocessgroup), and marks the window status as WIN DEATH.

3. The Recovery: Panic Auto-Restart
Because you were actively looking at the app when it crashed, the phone's Activity Manager automatically attempted an emergency launch to mask the crash:

Plaintext
05-19 15:19:44.838 2636 3837 D WindowManager: prepareSync ..., win=Window{22c63e5 u0 Splash Screen com.valvesoftware.steamlink}
05-19 15:19:44.845 2636 2709 I ActivityManager: Start proc 27868:com.valvesoftware.steamlink/u0a441 for top-activity...
What it means: The phone instantly generated an empty Splash Screen window (22c63e5) to cover the display so you wouldn't see an ugly desktop stutter. Simultaneously, it spun up a brand new process identity (PID: 27868) to reload Steam Link from scratch.

4. Hardware Decoder Errors (Side Effect)
During the crash/restart scramble, Android's internal video decoding pipeline threw some red flags:

Plaintext
05-19 15:19:44.812 1759 27846 E QC2Buf : allocate: failed to alloc graphic block ... Error: 22
05-19 15:19:44.812 1759 27846 W QC2V4l2Codec: [avcDLowLat_111] Graphic output-buf allocation failed!
What it means: The device's hardware chip decoder (Qualcomm's video decoder) was caught off guard when the app died right as it was establishing the stream video buffer channel. It temporarily failed to allocate memory slots (Error: 22) because the dead process hadn't finished releasing its previous graphic boundaries.

FWIW, the paste of ChatGPT output is not super useful -- *logs* are usually useful, but the rest just sort of clutters it up.

Originally posted by iamlegendinjapan:

05-19 15:19:44.764 27572 27572 E AndroidRuntime: FATAL EXCEPTION: SDLActivity
05-19 15:19:44.764 27572 27572 E AndroidRuntime: Process: com.valvesoftware.steamlink, PID: 27572
05-19 15:19:44.764 27572 27572 E AndroidRuntime: java.util.ConcurrentModificationException
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1111)
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at java.util.ArrayList$Itr.next(ArrayList.java:1064)
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at android.hardware.input.InputDeviceSensorManager$InputSensorEventListenerDelegate.removeSensor(InputDeviceSensorManager.java:283)
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at android.hardware.input.InputDeviceSensorManager.unregisterListenerInternal(InputDeviceSensorManager.java:515)
...
05-19 15:19:44.764 27572 27572 E AndroidRuntime: at org.libsdl.app.SDLJoystickHandler.setSensorsEnabled(SDLControllerManager.java:568)

Can you please provide the full stack trace here? This is exactly the issue that was fixed in 1.3.29.

Can you also post the Steam logs\streaming_log.txt from the host when you stream with the controller disconnected or connected over USB?

The logs were going in so fast because of the Bluetooth clutter. I'll see what I can get. Yes, it is the Samsung tab S9 ultra from your other question. Still new to ADB myself. I downloaded the package directly from the pinned forum and also the play store.

https://drive.google.com/drive/folders/1QiYxBkxnuV59DdVO3IP6fFZXRFuV1awl?usp=sharing Here are the logcat files with and without a controller.

I tried getting the steamlink stereamling_log files but the files inside com.valvesoftware.steamlink/files is empty both on local storage and sd card. show hidden files is on.

streaming_log.txt will actually be on the host machine, fwiw -- so in C:\Program Files (x86)\Steam\logs on Windows, or ~/.steam/steam/logs/ on Linux, etc.

thanks. uploaded to same folder. the previous is with the controller. the other is without

Originally posted by iamlegendinjapan:

thanks. uploaded to same folder. the previous is with the controller. the other is without

Thank you! We think we have a fix, can you please try installing this custom build and let us know if it works for you?
https://www.libsdl.org/tmp/steamlink-1.3.29-s9-ultra-fix.apk

FWIW, if this works, what it means is that the Tab S9 Ultra is sending sensor events on a thread *other* than the main thread. Which is *not* what Android is supposed to do -- and isn't what the Galaxy S21, Galaxy Tab A7, or any other Samsung device I've been able to test on does -- but which *would* cause the same concurrency issue even with the fix that's in 1.3.29.