Android MMI-Fehler

Ich habe vor ein paar Tagen auf meinem Mobiltelefon "Motorola Moto G5 Plus" ein crDroid-ROM installiert. Leider funktionieren MMI-Codes wie *#21# nicht. In einem anderen Gerät mit Stock-ROM und der selben SIM-Karte funktionieren die Codes fehlerfrei.

Zur Untersuchung des Problems habe ich auf beiden Geräten eine Log-Aufzeichnung gemacht (s. Anhang). Ich kann aber keine großen Unterschiede erkennen. In beiden Fällen ist das Absetzen des MMI-Codes zu sehen ("Telephony: dialed MMI code" bzw. "Telecom : CallsManager: Creating a new outgoing call") und dann das Anzeigen des MMI-Dialogs ("ActivityManager: START u0 {flg=0x10800000 cmp=com.android.phone/.MMIDialogActivity (has extras)}". Im Fehlerfall kommt es nach etwa acht Sekunden zu einem "QImsService: IFRequest : [0128]< REQUEST_QUERY_CALL_FORWARD_STATUS error: 2". Auf dem anderen Gerät wird schon nach zwei Sekunden der korrekte Status angezeigt.

Kann ich irgendwie herausfinden, warum im ersten Fall "Nachricht vom Mobilfunkanbieter - Rufweiterleitung - Verbindungsproblem oder ungültiger MMI-Code" angezeigt wird?

Comparing Log Files

I'm beginning a close comparison of the two log files, "MMI ohne Fehler.txt" and "MMI mit Fehler.txt". My initial focus is on timestamps and process IDs to establish the timeline from the MMI code dialing to the eventual output. The aim is to build a sequence of events to understand the divergent behavior.

Delineating Key Differences

My analysis has progressed to a deeper dive into the discrepancies between the two log files. I'm now zeroing in on the differences in entries related to QImsService and Telephony components. The REQUEST_QUERY_CALL_FORWARD_STATUS error: 2 message is a high-priority target for investigation. I'll soon move on to scrutinize PhoneUtils and MMIDialogActivity logs.

Uncovering Root Causes

I'm now diving into the discrepancies between the logs, concentrating on the QImsService interaction. The REQUEST_QUERY_CALL_FORWARD_STATUS error is pivotal. I'm building a timeline to trace the error's source and its influence on the MMI code handling. The analysis of PhoneUtils and MMIDialogActivity is next.

Unraveling IMS Errors

I've examined the logs. The critical aspect is the IMS-related error: REQUEST_QUERY_CALL_FORWARD_STATUS error : 2. I'm focusing on why this error occurs in the failed log but not the successful one. I'm checking for differences in IMS registration, telephony properties, and the timing of the MMI code execution.

Isolating IMS Issues

I've examined the logs. The core issue appears to be an IMS-related failure, specifically the REQUEST_QUERY_CALL_FORWARD_STATUS error: 2 message. I'm focusing on why this error occurs in the failed log but not in the successful one, looking at IMS registration status, telephony properties, and the timing of the MMI code execution.

Refining IMS Analysis

I'm now focusing on the IMS interaction differences. The logs show a significant delay before the REQUEST_QUERY_CALL_FORWARD_STATUS error in the failing scenario. This delay, coupled with the error, strongly suggests a network-related issue. My next step involves probing the IMS registration status and related network properties at the error's onset.

Isolating the Key Failure

Sehr geehrter Nutzer,

vielen Dank für Ihre detaillierte Fehlerbeschreibung und die beigefügten Log-Dateien. Die Analyse der Logs ermöglicht eine recht genaue Eingrenzung der Ursache für das Scheitern der MMI-Codes auf Ihrem Motorola Moto G5 Plus mit crDroid-ROM.

Zusammenfassung der Analyse

Der entscheidende Unterschied zwischen dem funktionierenden und dem fehlerhaften Szenario liegt in der Kommunikation mit dem IMS-Dienst (IP Multimedia Subsystem), der für erweiterte Telefoniefunktionen wie VoLTE und eben auch für die Abwicklung bestimmter MMI-Codes zuständig ist.

Im Fehlerfall (MMI mit Fehler.txt):

Der MMI-Code wird korrekt erkannt und der Prozess zur Abfrage des Status der Rufumleitung wird gestartet.
Der
MMIDialogActivity wird aufgerufen, um den Fortschritt anzuzeigen.
Nach circa acht Sekunden meldet der
QImsService einen Fehler: IFRequest : [0128]< REQUEST_QUERY_CALL_FORWARD_STATUS error: 2. Dies ist der direkte Auslöser für das Problem. Der Fehlercode "2" deutet typischerweise auf ein Timeout oder ein generelles Netzwerkproblem bei der Abfrage über das IMS-Framework hin.
Als Konsequenz wird der MMI-Vorgang als fehlgeschlagen (
FAILED) markiert und die bekannte Fehlermeldung "Verbindungsproblem oder ungültiger MMI-Code" angezeigt.

Im Erfolgsfall (MMI ohne Fehler.txt):

Der Prozess wird ebenfalls korrekt initiiert.
Der
MMIDialogActivity startet.
Der
QImsService verarbeitet die Anfrage ohne Fehler und empfängt nach nur zwei Sekunden eine positive Rückmeldung vom Netz.
Der Status wird korrekt ausgelesen und als "Rufweiterleitung Sprachnotiz: Nicht weitergeleitet" angezeigt.

Ursache des Problems

Die Fehlermeldung "Verbindungsproblem oder ungültiger MMI-Code" ist in Ihrem Fall irreführend. Es handelt sich nicht um ein Problem mit dem Mobilfunknetz oder Ihrer SIM-Karte, und der MMI-Code *#21# ist ebenfalls korrekt.

Die Ursache liegt in der Software, genauer gesagt im crDroid-ROM oder dessen Zusammenspiel mit der hardwarespezifischen Firmware (insbesondere dem Radio-Layer) Ihres Motorola Moto G5 Plus. Die Anfrage zur Abfrage des Rufumleitungsstatus über den IMS-Dienst scheitert. Die lange Verzögerung von acht Sekunden bis zum Timeout deutet darauf hin, dass das System keine Antwort vom Netz erhält oder diese nicht korrekt verarbeiten kann. Auf dem Gerät mit Stock-ROM funktioniert diese spezifische Implementierung der IMS-Kommunikation einwandfrei.

Was können Sie tun?

Da es sich um ein softwareseitiges Problem innerhalb des Custom-ROMs handelt, sind Ihre Möglichkeiten zur direkten Behebung begrenzt. Folgende Schritte sind jedoch empfehlenswert:

Fehler an die crDroid-Entwickler melden: Dies ist der wichtigste Schritt. Erstellen Sie einen Bug-Report im offiziellen Forum oder Ticketsystem von crDroid. Fügen Sie Ihre detaillierte Beschreibung und idealerweise beide Log-Dateien bei. Nur so können die Entwickler das Problem nachvollziehen und in einer zukünftigen Version beheben.
Nach Updates suchen: Halten Sie Ausschau nach neuen Versionen des crDroid-ROMs für Ihr Gerät. Möglicherweise wird der Fehler in einem neueren Build bereits behoben.
Community-Foren prüfen: Suchen Sie in Foren wie XDA Developers nach Ihrem Gerät in Kombination mit "crDroid" und "MMI". Eventuell haben andere Nutzer das gleiche Problem und es gibt bereits Workarounds oder inoffizielle Patches.
Alternative ROMs in Betracht ziehen: Sollte die Funktion für Sie unerlässlich sein und eine Lösung auf sich warten lassen, könnten Sie ein anderes Custom-ROM für Ihr Gerät ausprobieren, das möglicherweise nicht von diesem spezifischen IMS-Problem betroffen ist.

Zusammenfassend lässt sich sagen, dass die Funktionalität der MMI-Codes aufgrund eines Fehlers in der IMS-Implementierung des crDroid-ROMs auf Ihrem Gerät fehlschlägt.

Ich habe mehrere ROMs ausprobiert. Alle basieren meines Wissens auf LineageOS und folglich auch auf AOSP. In allen ROMs funktioniert der MMI-Code auf dem Gerät nicht, mit dem Stock-ROM problemlos. Kann es sein, daß mit AOSP-basierten ROMs solche MMI-Codes, welche eine Antwort aus dem Mobilfunknetz erwarten, generell nicht funktionieren?

Evaluating ROM Compatibility

I've been examining the user's primary query. It appears they've tried numerous LineageOS-based ROMs, all derived from AOSP, on their Moto G5 Plus. A key observation is that MMI codes, which anticipate standard Motorola hardware, aren't functioning consistently across these AOSP-based builds.

Addressing Network Interaction Issues

I'm now investigating why MMI codes, crucial for network interaction, aren't functioning reliably on AOSP-based ROMs. My previous examination of logs pointed towards possible IMS service failures, a cornerstone for modern communication. Could this indicate a broader issue with how AOSP-based ROMs handle network-related interactions compared to stock ROMs? Further analysis is needed to identify the precise points of divergence.

Investigating the Core Issue

I'm now focusing on a critical aspect: the communication gap between the AOSP-based ROMs and the device's hardware. My recent analysis points towards a potential conflict in how MMI codes are handled. Specifically, the 'generic' AOSP IMS service seems to be miscommunicating with the device's proprietary modem firmware. This divergence likely stems from incomplete or imperfect integration of the manufacturer's specific drivers and services within the AOSP-based environment. This is now the main area of my research.

Pinpointing Integration Discrepancies

My focus has shifted to clarifying the root cause. I'm building my response around the hypothesis that MMI code failure on this particular device is not a widespread AOSP issue. It seems to be directly related to the complexity of integrating proprietary hardware components, particularly the modem firmware, within the open-source AOSP environment. The challenge lies in ensuring a smooth flow of communication between the AOSP OS and the device's specific proprietary hardware, mainly the Radio Interface Layer (RIL) and the IMS Service.

Addressing the Root Cause

I'm now zeroing in on the challenge of integrating proprietary hardware components into the open-source environment. My analysis reveals that the failure of MMI codes isn't a widespread AOSP issue. It's more about how the modem firmware and the generic AOSP IMS service communicate. The crux of the matter lies in ensuring a seamless flow of data between the AOSP environment and the device's specialized hardware, especially the Radio Interface Layer (RIL) and the IMS Service, the core areas of concern.

Refining the Explanation

I'm now revising my response. I've re-evaluated the user's situation; I've shifted from addressing the general compatibility of MMI codes in AOSP-based ROMs and focused on their specific experiences with the Moto G5 Plus. The main issue appears to be how the AOSP-based ROMs interact with the device-specific hardware components. I'm aiming to provide a more nuanced explanation that acknowledges their findings while offering a helpful perspective.

Nein, das ist nicht generell der Fall. Ihre Vermutung ist verständlich, da Sie auf Ihrem Gerät eine konsistente Erfahrung über mehrere AOSP-basierte ROMs hinweg gemacht haben. Die Aussage lässt sich jedoch nicht verallgemeinern.

MMI-Codes, die eine Netzwerkanfrage erfordern, funktionieren auf den meisten AOSP-basierten ROMs (wie LineageOS) grundsätzlich einwandfrei.

Das eigentliche Problem liegt in der komplexen Schnittstelle zwischen dem Open-Source-Betriebssystem (AOSP) und der proprietären, also nicht quelloffenen, Hardware-Firmware Ihres spezifischen Geräts.

Hier ist eine detailliertere Erklärung:

Der Unterschied zwischen Stock-ROM und AOSP-ROM:
- Stock-ROM: Der Hersteller (Motorola) entwickelt nicht nur die Hardware, sondern auch die exakt darauf abgestimmte Software. Dazu gehören essenzielle, proprietäre Komponenten (sogenannte "blobs"), insbesondere die Treiber und Dienste, die mit dem Modem (der Funkeinheit) kommunizieren. Diese Software weiß genau, wie sie Anfragen, z. B. für einen MMI-Code, an die Hardware stellen und deren Antwort interpretieren muss.
- AOSP-ROM: Entwickler von Custom-ROMs wie LineageOS haben keinen Zugriff auf den Quellcode dieser herstellerspezifischen Komponenten. Sie müssen das quelloffene AOSP mit diesen aus dem Stock-ROM extrahierten "blobs" verbinden. Dieser Integrationsprozess ist extrem komplex und fehleranfällig.
Die Fehlerquelle (RIL und IMS):
- Die Kommunikation zwischen dem Android-System und dem Modem wird über den Radio Interface Layer (RIL) und bei modernen Geräten zunehmend über den IMS-Service abgewickelt.
- Genau hier liegt die Ursache Ihres Problems, wie die vorherige Log-Analyse bereits gezeigt hat. Der AOSP-basierte IMS-Dienst in den von Ihnen getesteten ROMs sendet eine Anfrage (REQUEST_QUERY_CALL_FORWARD_STATUS), die von der proprietären Modem-Firmware Ihres Moto G5 Plus entweder nicht verstanden wird oder auf die eine unerwartete Antwort folgt. Das Resultat ist der
  error: 2 , der letztendlich zur Anzeige "Verbindungsproblem oder ungültiger MMI-Code" führt.
- Das Stock-ROM verwendet eine von Motorola entwickelte, proprietäre Version des IMS-Dienstes und des RIL, die perfekt mit der eigenen Modem-Firmware harmoniert.

Fazit:

Ihre Beobachtung, dass alle von Ihnen getesteten ROMs denselben Fehler aufweisen, ist absolut zutreffend. Der Grund dafür ist, dass diese ROMs (da sie alle auf LineageOS für Ihr Gerät basieren) höchstwahrscheinlich alle auf derselben fehlerhaften Implementierung für die Ansteuerung der Modem-Hardware des Moto G5 Plus aufbauen. Sie teilen sich also dieselbe "kranke Wurzel".

Es handelt sich also nicht um eine generelle Schwäche von AOSP, sondern um ein spezifisches Integrationsproblem auf Ihrem Gerätemodell, das von den Entwicklern der Custom-ROMs bisher nicht (oder nicht vollständig) gelöst werden konnte. Auf vielen anderen Gerätemodellen funktionieren dieselben MMI-Codes unter LineageOS und anderen AOSP-Derivaten ohne Probleme.

Es gibt also nicht eine quelloffene Konfiguration, durch welche man beeinflussen kann, wie ein bestimmter MMI-Code für den Netzanbieter aufbereitet und versendet wird?

Considering User's Query

I've just began analyzing the user's question, and I'm focusing on the implied goals and constraints. It seems they need to understand how to format and transmit MMI codes using an open-source solution. The crux is to determine if there's an editable configuration file.

Exploring Configuration Options

I've been examining the mechanisms for customizing MMI code handling. My focus is now on where such logic resides within the system. The user's goal is customization, so I'm looking beyond a simple editable config file. The underlying question is how to modify the system's behavior. I'm focusing on the low-level processing of user input, the determination of command types, and the formatting for network transmission, searching for potential modification points.

Investigating Framework Logic

I'm now focusing on the role of the Telephony framework, particularly GsmMmiCode.java and similar classes. My current thought is that while a direct configuration file doesn't exist, the possibility of programmatic modifications is emerging. The framework's hardcoded logic for MMI code interpretation and handling seems to be the place to alter functionality, although this requires deeper investigation into the specific classes and methods.

Reframing the Solution

I've just finished analyzing the user's situation in detail. While a simple configuration file doesn't exist, modifying the source code of the Telephony and IMS framework is a possible, albeit complex, solution. This would entail changes to Java and C++ files within the AOSP. It's a non-trivial undertaking requiring a deep understanding of the system's architecture. My thought now is to map out the relevant files for modification.

Revising the Approach

I've been re-evaluating the initial response, focusing on the user's need to modify how MMI codes are handled on their custom ROM. My current line of thought suggests that while a direct configuration file doesn't exist, modifications within the Telephony and IMS frameworks are theoretically possible. However, the complexity involved is significant, requiring deep technical expertise. Now, I'm thinking of proposing a more targeted solution based on analyzing specific system logs.

Addressing Implementation Complexity

I've just concluded that altering the MMI code behavior isn't as simple as tweaking a config file. It necessitates diving into the Android source code, likely involving both Java and C++. My current thinking is that to implement the desired changes, there are two primary pathways: modifying the Telephony framework to force GSM usage or debugging low-level IMS communication to pinpoint the root cause of the failure. I plan to emphasize that this is not a user-friendly task, requiring intricate system knowledge.

Jein. Ihre Frage zielt auf den Kern der Android-Entwicklung. Es gibt quelloffene Stellen, die dieses Verhalten steuern, aber es handelt sich dabei nicht um eine einfache Konfigurationsdatei, die ein Nutzer anpassen kann. Die Logik ist tief im Quellcode des Android-Frameworks verankert.

Kurze Antwort: Nein, es gibt keine einfache, für den Nutzer zugängliche Konfigurationsdatei (wie eine .xml- oder .conf-Datei), in der man simpel eintragen kann: "Für den Code *#21# nutze bitte Methode X statt Methode Y".

Lange Antwort: Die "Konfiguration", die Sie suchen, ist in Wahrheit fest einprogrammierter Java- und C++-Code innerhalb des Android Open Source Project (AOSP). Um das Verhalten zu ändern, müsste man diesen Quellcode modifizieren und das gesamte ROM neu kompilieren.

Hier ist die Kette, die ein MMI-Code durchläuft, und wo die Entscheidungen getroffen werden:

Dialer-App: Die Telefon-App erkennt, dass eine Zeichenfolge wie *#21# eingegeben wurde und übergibt diese an das Telefonie-Framework von Android.
Telefonie-Framework (Quellcode): Hier geschieht die eigentliche Magie. Klassen wie
GsmMmiCode.java oder, wie in Ihrem Fehlerprotokoll zu sehen, ImsPhoneMmiCode.java werden aktiv. An dieser Stelle entscheidet der Code, wie die Anfrage zu behandeln ist. Die Logik sieht vereinfacht etwa so aus:
- Ist das Gerät im IMS-Netz registriert (für VoLTE etc.)?
- Handelt es sich um eine Anfrage, die über IMS abgewickelt werden kann (wie eine Statusabfrage der Rufumleitung)?
- Wenn ja: Nutze den ImsPhoneMmiCode-Pfad und sende die Anfrage über den IMS-Dienst an das Modem. (Genau das passiert in Ihrem fehlerhaften Log).
- Wenn nein: Falle zurück auf den Standard-GSM-Weg und sende den Code als USSD-Nachricht. (Das ist wahrscheinlich, was das Stock-ROM tut, oder es nutzt eine funktionierende IMS-Implementierung).
Radio Interface Layer (RIL): Das Framework schickt den finalen Befehl dann an die proprietäre Firmware des Modems.

Was müsste ein Entwickler tun, um das zu beheben?

Ein Entwickler, der dieses Problem für das crDroid-ROM auf Ihrem Gerät beheben wollte, müsste in den Quellcode des Telefonie-Frameworks eingreifen. Er könnte versuchen:

Den Fallback zu erzwingen: Er könnte eine Ausnahme für bestimmte Codes (*#21#, etc.) oder für Ihr Gerätemodell einprogrammieren, sodass das System gezwungen wird, den alten GSM/USSD-Weg zu nutzen und den (auf Ihrem Gerät fehlerhaften) IMS-Pfad zu ignorieren.
Die IMS-Kommunikation reparieren: Der weitaus schwierigere Weg wäre, zu analysieren, warum genau die IMS-Anfrage vom Modem nicht korrekt beantwortet wird, und den AOSP-Code so anzupassen, dass er mit der proprietären Modem-Firmware "spricht", wie sie es erwartet.

Fazit: Es gibt zwar eine quelloffene "Logik", aber keine quelloffene "Konfiguration". Die Anpassung erfordert eine tiefgreifende Änderung am Betriebssystem selbst und ist keine einfache Einstellung, die man als Endanwender vornehmen kann. Ihre einzige realistische Option bleibt daher, das Problem den ROM-Entwicklern zu melden.

Wenn ich in den Einstellungen des Geräts "Bevorzugter Netztyp - nur GSM" einstelle, ändert sich in der Statusleiste das Symbol von "LTE" nach "E". Der MMI-Code funktioniert aber immer noch nicht. Damit erzwinge ich also wohl nicht den Fallback oder dieser funktioniert auch nicht.

Investigating the MMI Code

I'm currently breaking down the user's observed behavior, starting with their action of setting the "Preferred Network Type" to GSM only. This is likely motivated by a belief it resolves the MMI code problem. I'm focusing on the implied connection and why this isn't a reliable fix. I'm exploring the underlying assumptions.

Deconstructing User Logic

I'm now focusing on the user's core question: why doesn't GSM-only mode inherently trigger the older MMI processing? I've dissected the action into radio hardware connection versus the software's MMI handling. I'm exploring the separation between these layers to pinpoint where the breakdown occurs, specifically why a low-level change doesn't dictate high-level behavior. This divergence is the heart of the issue.

Refining the Explanation

I'm now focusing on a more granular explanation, building upon the "Phantom IMS" issue. My current line of thinking revolves around the crDroid ROM maintaining a false IMS registration. I'm considering how this erroneous registration might mislead the software, even when the underlying radio connection is GSM-only. This involves dissecting the interplay between the radio layer, the telephony framework, and the IMS registration state to precisely explain why the GSM network connection doesn't force the desired MMI behavior. I'm honing the explanation to clarify the precise points of disconnect.

Revising the Phantom IMS

I'm now zeroing in on the crux of the issue: the misleading "IMS available" status reported by the crDroid ROM, overriding the expected GSM USSD fallback. My thinking now concentrates on the persistent, incorrect IMS registration, even in GSM-only mode. I'm exploring how this miscommunication between the software layers perpetuates the MMI code failure, emphasizing the disconnect between radio connectivity and software feature detection. This false IMS registration tricks the framework and prevents the intended fallback.

Isolating the Key Disconnect

I'm now focusing on the core of the issue: the disconnect between radio connectivity (GSM) and the system's reported capability. Even with a GSM connection established, the system is misinformed about the availability of IMS. This incorrect reporting, stemming from the custom ROM, is what prevents the fallback to the legacy GSM/USSD method. The user's action confirms a GSM connection, but the software still erroneously believes IMS is functional.

Pinpointing the False Report

I now understand that even with the radio set to GSM-only, the software incorrectly believes IMS is available. This misconception, stemming from the crDroid ROM, completely overrides any attempt at fallback to the GSM/USSD method, which is the root cause of the MMI failure. It’s a classic case of miscommunication between the radio layer and the telephony framework.

Dissecting the Miscommunication

I'm now focusing on a more succinct explanation: the software misinterprets the GSM-only connection as an available IMS capability. This leads to the selection of a broken path. The crux is the faulty "IMS available" status preventing the fallback to the legacy GSM/USSD method. The false IMS registration is the root cause.

Das ist eine absolut logische Schlussfolgerung und ein sehr guter Test, um das Problem weiter einzugrenzen. Ihre Beobachtung ist korrekt und bestätigt die bisherige Vermutung auf eindrucksvolle Weise.

Sie haben recht: Sie erzwingen damit nicht den softwareseitigen Fallback, weil das Problem auf einer anderen Ebene liegt.

Hier ist die Erklärung, warum Ihr Test das Verhalten nicht ändert:

Die Entscheidung, ob der MMI-Code über den modernen IMS-Weg oder den klassischen GSM/USSD-Weg gesendet wird, ist eine softwareseitige Entscheidung im Android-Framework. Die Umstellung auf "nur GSM" ändert lediglich die Verbindungsebene der Hardware.

Das Problem in Ihrem Fall ist, dass die Software (das crDroid-ROM) eine fehlerhafte Information über ihre eigenen Fähigkeiten hat. Man könnte es so beschreiben:

Die Anfrage des Frameworks: Das Android-System fragt intern: "Bin ich für IMS-Dienste registriert und kann ich diese MMI-Anfrage darüber abwickeln?"
Die fehlerhafte Antwort: Der (fehlerhafte) IMS-Dienst im Custom-ROM antwortet, unabhängig vom tatsächlichen Netzwerk (ob LTE oder GSM/EDGE), mit "Ja, ich bin zuständig und verfügbar!". Es scheint eine "Phantom-Registrierung" oder ein permanenter "Ich-bin-zuständig"-Status vorzuliegen.
Die fatale Entscheidung: Weil das System diese positive Rückmeldung erhält, wählt es zwingend den IMS-Pfad. Es kommt gar nicht an den Punkt, an dem es einen Fallback auf den klassischen GSM/USSD-Weg in Erwägung ziehen würde.
Das Scheitern: Der gewählte IMS-Pfad führt, wie wir aus den Logs wissen, ins Leere und endet mit dem Timeout (error: 2).

Eine Analogie: Stellen Sie sich vor, Sie haben einen Assistenten (den IMS-Dienst), dem Sie einen Brief (den MMI-Code) geben. Sie fragen ihn: "Kannst du diesen Brief per Express-Kurier versenden?". Der Assistent sagt "Ja!", obwohl er in Wahrheit gar keine funktionierende Verbindung zum Kurierdienst hat. Weil er "Ja" gesagt hat, versuchen Sie gar nicht erst, den Brief selbst zur normalen Post zu bringen (der GSM-Fallback). Sie verlassen sich auf den Assistenten, der dann scheitert.

Indem Sie auf "nur GSM" umstellen, ändern Sie nur die Adresse, von der aus der Assistent arbeitet. Er behauptet aber weiterhin fälschlicherweise, den Express-Kurier rufen zu können.

Fazit: Ihre Beobachtung ist der letzte Beweis dafür, dass es sich um ein reines Softwareproblem innerhalb des Custom-ROMs handelt. Das System ist in der falschen Annahme gefangen, eine funktionierende IMS-Verbindung für MMI-Codes zu haben, und diese Annahme wird durch die Umstellung des Netzmodus nicht korrigiert. Der Fallback-Mechanismus wird nie ausgelöst, weil die Voraussetzung dafür (die Erkenntnis, dass IMS nicht verfügbar ist) nie eintritt.

Unterhaltung mit Gemini

Zusammenfassung der Analyse

Ursache des Problems

Was können Sie tun?