Shiftphone 8 - fieser Software-Bug nach OS-Update (Ton & Akku-Laden)

sito9999

Member
Original poster
26 November 2024
5
Hallo zusammen,

ich möchte kurz schildern das die Probleme mit dem kompletten Tonausfall und der Ladeproblematik nicht an der Hardware liegen.
Ich habe zwei Shiftphone 8. Anfang des Jahres habe ich bei beiden ein Shift-OS-Update gemacht. Danach fingen die Probleme an.

Seit dem treten folgende Fehler auf (auf beiden Shiftphone8):
Sporalischer Ton Komplettausfall nach Bluetooth-Verbindung oder Kopfhörer-Verwendung. Abhilft bringt nur ein Neustart. Des weiteren Ladeprobleme.
Das Gleiche Ladekabel funktioniert mal, manchmal funktioniert es nicht. Hier hilft auch nur Neustart des Gerätes, dann geht es wieder
(mit dem gleichen Kabel was vor dem Neustart nicht funktioniert hat).

Vor dem Shift-Update hatte ich diese Probleme NIE! Ob eine Abhilfe seitens Shift erfolgt bin ich skeptisch.
Ich habe die sogar die Sub-PCB-Platine und das USB-C-Modul gewechselt. Hat nicht geholfen.

KEINE Veränderung. Es liegt nicht an der Hardware!
Es wäre zu merkwürdig, das zwei Geräte, die nicht geöffnet wurden, plötzlich den gleichen Fehler aufweisen!
Update auf ShiftOS 6.7 G brachte auch keine Besserung!!!
Frage an die Community: Kann man die letzten zwei OS-Updates rückgängig machen?

P.S.: Das ganze nervt so sehr das ich nun auf der Suche nach einem neuen Handy bin, das auch funktioniert!
Schade, ich wollte ein nachhaltiges Gerät für die nächsten 10 Jahre und bekomme nur Ärger! So ist es leider unbrauchbar!

Gruss SiTo!
 
  • Like
Reaktionen: yeeehaaw
Hi,

ich meine ich hätte schon was zu den Bluetooth Thema gelesen, und das Shift da aktuell dran ist..

"Rückgängig machen" glaube ich eher nicht, wenn dann könnte es eher darauf hinauslaufen, dass du das Gerät komplett neu flasht inkl. Zurücksetzen, wie es beim Wechsel von L auf G der Fall ist, das könntest du höchstens mal testen, allerdings alles ohne Gewähr.
 
  • Like
Reaktionen: JueMei und R.E.D.
Hallo zusammen,

ich kann das Problem bestätigen und habe es per adb bis zur Ursache verfolgt — es ist ein
Software-Fehler im Bluetooth-Stack, keine Hardware.

Gerät/Build: SHIFTphone 8, ShiftOS 6.7 G (SOS.6.7.20260712, Patch-Level 2026-08-05)

Symptom bei mir: Bluetooth fällt in unregelmäßigen Abständen komplett aus (bei mir ohne
Ton-Bezug, weil gerade kein Audio lief — der beschriebene Tonausfall passt aber exakt dazu,
siehe unten). Neustart hilft vorübergehend.

Befund: Der Prozess com.android.bluetooth stürzt mit SIGABRT ab — ein Heap-Fehler
(Double-Free) in der Qualcomm-Bibliothek libbluetooth_qti.so, immer beim **Trennen einer
BLE/GATT-Verbindung** (Kopfhörer aus, Uhr außer Reichweite o. ä.). Der Stack startet neu,
verbindet sich wieder, stürzt beim nächsten Trennen erneut ab — eine Crash-Loop im
~40-Sekunden-Takt, bis Bluetooth „tot" wirkt. Wenn dabei gerade Audio über A2DP läuft,
reißt es die Tonausgabe mit — das dürfte der hier beschriebene Tonausfall sein.

Alle 17 Abstürze im DropBox-Puffer meines Geräts haben dieselbe Signatur:

Code:
Abort message: 'Scudo ERROR: invalid chunk state when deallocating address 0x…'
Thread: "btu message loop"
#05 osi_free_and_reset(void**)                    libbluetooth_qti.so
#06 bta_gattc_clcb_dealloc(tBTA_GATTC_CLCB*)      libbluetooth_qti.so
#07 bta_gattc_close(tBTA_GATTC_CLCB*, …)          libbluetooth_qti.so
#08 bta_gattc_sm_execute(…)                       libbluetooth_qti.so
libbluetooth_qti.so BuildId: 2eb136439d21d6d2e57157055aec57f1

Der Fehler ist nicht deterministisch (Race beim Verbindungsabbau) — deshalb trifft es nicht
jede Trennung und wirkt „sporadisch". Bei mir sind die Auslöser eine Garmin fenix 6X Pro und
ein Shokz OpenComm2, es ist aber geräteunabhängig.

Workaround bis zum Fix: Bluetooth aus, wenn ungenutzt. Und wenn es passiert: Bluetooth in
den Schnelleinstellungen aus/ein reicht — ein kompletter Neustart ist nicht nötig.

An das SHIFT-Team: vollständiger adb-Bugreport und alle 17 Crash-Dumps liegen bei mir und
gehen parallel an den Support — bei Bedarf gerne per PN. Ich teste auch gerne einen
Beta-/Hotfix-Build.

Viele Grüße
 
Hallo zusammen,

ich kann das Problem bestätigen und habe es per adb bis zur Ursache verfolgt — es ist ein
Software-Fehler im Bluetooth-Stack, keine Hardware.

Gerät/Build: SHIFTphone 8, ShiftOS 6.7 G (SOS.6.7.20260712, Patch-Level 2026-08-05)

Symptom bei mir: Bluetooth fällt in unregelmäßigen Abständen komplett aus (bei mir ohne
Ton-Bezug, weil gerade kein Audio lief — der beschriebene Tonausfall passt aber exakt dazu,
siehe unten). Neustart hilft vorübergehend.

Befund: Der Prozess com.android.bluetooth stürzt mit SIGABRT ab — ein Heap-Fehler
(Double-Free) in der Qualcomm-Bibliothek libbluetooth_qti.so, immer beim **Trennen einer
BLE/GATT-Verbindung** (Kopfhörer aus, Uhr außer Reichweite o. ä.). Der Stack startet neu,
verbindet sich wieder, stürzt beim nächsten Trennen erneut ab — eine Crash-Loop im
~40-Sekunden-Takt, bis Bluetooth „tot" wirkt. Wenn dabei gerade Audio über A2DP läuft,
reißt es die Tonausgabe mit — das dürfte der hier beschriebene Tonausfall sein.

Alle 17 Abstürze im DropBox-Puffer meines Geräts haben dieselbe Signatur:

Code:
Abort message: 'Scudo ERROR: invalid chunk state when deallocating address 0x…'
Thread: "btu message loop"
#05 osi_free_and_reset(void**)                    libbluetooth_qti.so
#06 bta_gattc_clcb_dealloc(tBTA_GATTC_CLCB*)      libbluetooth_qti.so
#07 bta_gattc_close(tBTA_GATTC_CLCB*, …)          libbluetooth_qti.so
#08 bta_gattc_sm_execute(…)                       libbluetooth_qti.so
libbluetooth_qti.so BuildId: 2eb136439d21d6d2e57157055aec57f1

Der Fehler ist nicht deterministisch (Race beim Verbindungsabbau) — deshalb trifft es nicht
jede Trennung und wirkt „sporadisch". Bei mir sind die Auslöser eine Garmin fenix 6X Pro und
ein Shokz OpenComm2, es ist aber geräteunabhängig.

Workaround bis zum Fix: Bluetooth aus, wenn ungenutzt. Und wenn es passiert: Bluetooth in
den Schnelleinstellungen aus/ein reicht — ein kompletter Neustart ist nicht nötig.

An das SHIFT-Team: vollständiger adb-Bugreport und alle 17 Crash-Dumps liegen bei mir und
gehen parallel an den Support — bei Bedarf gerne per PN. Ich teste auch gerne einen
Beta-/Hotfix-Build.

Viele Grüße
Danke für die Logs!

Ich glaube ich habe einen potentiellen Fix dafür und würde dir gerne einen Test-Build zum Verifizieren schicken, da du das Problem gut nachstellen kannst.
Wenn du diesen installierst, ist das Gerät aber nichtmehr zertifiziert, bis wir das nächste OTA zertifizieren und ausliefern.

Sobald ich den Build fertig habe, würde ich ihn hier posten.

Wegen konstanter Belastung durch AI-Agenten, mussten wir leider unser Code-Repository hinter ein Login stecken, bis wir dafür eine halbwegs ordentliche Lösung haben.
Deswegen verlinkte ich stattdessen den zugänglichen Code von Qualcomm.

Ca. auf diesem Stand habe ich die folgende Änderungen angewandt:
- https://git.codelinaro.org/clo/la/p...system/bt/-/tree/LA.QISI.14.0.r1-03900-qssi.0

Diff:
   while (!p_clcb->p_q_cmd_queue.empty()) {
     auto p_q_cmd = p_clcb->p_q_cmd_queue.front();
     p_clcb->p_q_cmd_queue.pop_front();
+
+    // If the current command is already in the queue, also clear it.
+    if (p_clcb->p_q_cmd == p_q_cmd) {
+      p_clcb->p_q_cmd = NULL;
+    }
+
     osi_free_and_reset((void**)&p_q_cmd);
   }

   if (p_clcb->p_q_cmd != NULL) {
     osi_free_and_reset((void**)&p_clcb->p_q_cmd);
   }

p_clcb->p_q_cmd zeigte noch auf die Adresse des bereits freigegebenen p_q_cmd und nicht auf NULL und wurde deswegen doppelt freigegeben.

Ich habe auch weitere Stellen abgesichert und das doppelte Queuen von Kommandos hoffentlich verhindert.

Hier ist der gesamte Patch:
Diff:
diff --git a/bta/gatt/bta_gattc_utils.cc b/bta/gatt/bta_gattc_utils.cc
index 5373310e2b..10e474905c 100644
--- a/bta/gatt/bta_gattc_utils.cc
+++ b/bta/gatt/bta_gattc_utils.cc
@@ -266,6 +266,12 @@ void bta_gattc_clcb_dealloc(tBTA_GATTC_CLCB* p_clcb) {
   while (!p_clcb->p_q_cmd_queue.empty()) {
     auto p_q_cmd = p_clcb->p_q_cmd_queue.front();
     p_clcb->p_q_cmd_queue.pop_front();
+
+    // If the current command is already in the queue, also clear it.
+    if (p_clcb->p_q_cmd == p_q_cmd) {
+      p_clcb->p_q_cmd = NULL;
+    }
+
     osi_free_and_reset((void**)&p_q_cmd);
   }
 
@@ -446,8 +452,11 @@ void bta_gattc_continue(tBTA_GATTC_CLCB* p_clcb) {
         VLOG(1) << __func__ << " Waiting p_clcb " << p_clcb;
         return;
       case MTU_EXCHANGE_NOT_DONE_YET:
-        if (p_clcb->p_q_cmd == NULL)
+        if (p_clcb->p_q_cmd != NULL) {
+            p_clcb->p_q_cmd = NULL;
+        } else {
             p_clcb->p_q_cmd_queue.pop_front();
+        }
         bta_gattc_sm_execute(p_clcb, p_q_cmd->hdr.event, p_q_cmd);
         return;
     }
@@ -490,6 +499,11 @@ BtaEnqueuedResult_t bta_gattc_enqueue(tBTA_GATTC_CLCB* p_clcb, tBTA_GATTC_DATA*
     return ENQUEUED_READY_TO_SEND;
   }
 
+  // If the command is already active, do not queue it.
+  if (p_clcb->p_q_cmd == p_data) {
+    return ENQUEUED_READY_TO_SEND;
+  }
+
   VLOG(1) << __func__ <<
       "Already has a pending command to executer. Queuing for later "
           << +p_clcb->bda.ToString().c_str()
 
Hier ist der Build: https://storage.shift-friends.community/s/ykPb9KtBn7y7rd6

Nochmal zur Sicherheit: Der Build ist nicht zertifiziert.
Das heißt, dass gewisse Apps, die ein zertifiziertes System erfordern, nicht funktionieren werden.

Ansonsten kann das OTA via lokaler Installation installiert werden.
Sicherheitspatch-Level: 2026-09-05