Ja, genau da geht’s lang – ab Android 7/Oreo sind die Carrier-Configs nicht mehr als lose XMLs in /system/etc unterwegs, sondern als Teil von CarrierConfig.apk (bzw. in Kombination mit CarrierServices.apk und OEM-Erweiterungen in CarrierSettingsExt.apk). Insofern ist dein „system_image.emmc“ mit diesen APKs der zentrale Dreh- und Angelpunkt für alle netzwerkspezifischen Einstellungen – darunter eben auch MMI-Codes.

Wie du’s jetzt angehst:

1. Image mounten • Verwende simg2img (oder einfach: dd if=system_image.emmc of=system.img bs=512 skip=1 && mkdir mnt && mount -o loop system.img mnt) • Navigiere in mnt/priv-app oder mnt/app, dort liegen die Carrier-APKs

2. CarrierConfig.apk dekompilieren • Mit apktool: apktool d CarrierConfig.apk -o carrierconfig_src • Schaue in carrierconfig_src/res/xml: Hier stehen alle carrier_config_*.xml – die eigentlichen Schlüssel/Werte für IMS, VoLTE, MMI-Codes etc.

3. Anpassungen übernehmen • Extrahiere die XML, die zu deinem Provider passt (z. B. carrier_config_tmobile_de.xml) • Kopier sie in dein Custom-ROM unter system/priv-app/CarrierConfig/…/res/xml/ • Achte darauf, dass bei dir Alias-Namen und Dateipfade exakt übereinstimmen, sonst lädt das System sie nicht

4. Weitere APKs nicht vergessen • CarrierServices.apk liefert Laufzeit-Updates, frischere Configs kommen oft über den Play Store. Integriere sie, falls dein ROM sie noch gar nicht hat. • CarrierSettingsExt.apk ist die OEM-Extension für Motorola-Spezifika (Checkboxen in den Einstellungen, zusätzlicher MMI-Support etc.).

5. Telephony-Framework checken • MMI-Codes laufen im Hintergrund über die Telephony-Service-Implementierung im Framework. Sollte nach dem Einbauen der Carrier-XMLs noch was haken, wirf einen Blick in /vendor/etc/telephony oder in framework-res.xml (Suchbegriffe: “ss” für Supplementary Services).

6. Testen & OTA-Updates • Flash dein neues ZIP über TWRP, boote und prüf die MMI-Codes (z. B. *#06#) • CarrierConfig kann bei Bedarf per Play Store/CarrierServices aktualisiert werden, so bleibst du flexibel

Was du als Nächstes überlegen kannst:

• Welche Android-Version läuft auf deinem G5 Plus? Ab Android 9 ist das Vendor-Hal-Konzept noch schärfer, da landet einiges in /vendor_partition.

• Willst du nur MMI-Codes reparieren oder generell VoLTE/IMS aktivieren? Dann lohnt sich ein Blick auf die IMS-Profiles im CarrierConfig/XML.

• Falls dein Custom-ROM gar keine Telephony-Priv-App-Struktur kennt, musst du noch Permissions und SELinux-Labels anpassen.

Erzähl gern, welche Android-Version du nutzt und wo du gerade im ROM-Bau steckst – dann können wir tiefer in SELinux-Policies oder APEX-Strukturen eintauchen.

Hier ein konkreter Fahrplan, wie du die XML-Configs aus deinem Android 8-Stock in crDroid Android 11 reinbekommst:

1. Prüfe zuerst, ob crDroid schon Carrier-APKs mitbringt

   • Mount dein Custom-ROM-Image (TWRP: „Mount → System“) oder auf PC:

     bash

     Kopieren

     dd if=system.img of=system_raw.img bs=512 skip=1
     mkdir system_mount && sudo mount -o loop system_raw.img system_mount
     

   • Schau in • system_mount/priv-app/CarrierConfig/CarrierConfig.apk • system_mount/priv-app/CarrierServices/CarrierServices.apk • system_mount/priv-app/CarrierSettingsExt/CarrierSettingsExt.apk Wenn sie da sind, arbeitest du auf der crDroid-Version weiter. Fehlen sie komplett, musst du die Stock-APKs importieren (s. Punkt 5).

2. Decompile crDroid-CarrierConfig.apk

   bash

   Kopieren

   apktool d system_mount/priv-app/CarrierConfig/CarrierConfig.apk -o cc_base
   

   In cc_base/res/xml/ stehen aktuelle carrier_config_*.xml – das ist dein Ziel-Verzeichnis.

3. XMLs aus Stock-CarrierConfig.apk übernehmen

   • Extrahiere aus deinem Android 8–Backup das Stock-CarrierConfig.apk (liegt in system_image.emmc/priv-app/CarrierConfig/)

   • Decompile es:

     bash

     Kopieren

     apktool d Stock/CarrierConfig.apk -o cc_stock
     

   • Kopiere die XMLs aus cc_stock/res/xml/carrier_config_*.xml in cc_base/res/xml/

4. Rebuild & Sign

   bash

   Kopieren

   apktool b cc_base -o CarrierConfig_mod.apk
   jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 \
     -keystore deine_platform_keystore CarrierConfig_mod.apk platform
   zipalign -f 4 CarrierConfig_mod.apk CarrierConfig_mod-aligned.apk
   

   Du musst mit genau demselben Keystore signieren, den crDroid für System-Apps nutzt („platform“/platform.pk8).

5. Falls crDroid gar keine Carrier-APKs hat

   • Kopiere komplett die drei Ordner aus dem Stock-Backup:

     Kopieren

     priv-app/CarrierConfig/CarrierConfig.apk
     priv-app/CarrierServices/CarrierServices.apk
     priv-app/CarrierSettingsExt/CarrierSettingsExt.apk
     

   • Decompile & patch CarrierConfig wie oben, rebuild & resign alle drei mit deinem ROM-Key.

6. Flash-Zip basteln Erstelle ein ZIP mit folgender Struktur (aus dem ZIP-Root):

   Kopieren

   system/priv-app/CarrierConfig/CarrierConfig_mod-aligned.apk
   system/priv-app/CarrierServices/CarrierServices.apk
   system/priv-app/CarrierSettingsExt/CarrierSettingsExt.apk
   META-INF/com/google/android/updater-script
   

   Im updater-script stellst du sicher, dass die alten Carrier-APKs überschrieben werden, die Dateirechte (0644) und SELinux-Kontext (u:object_r:apk_data_file:s0) richtig gesetzt sind.

7. Flashen & Test

   • In TWRP: ZIP installieren → neu starten

   • MMI-Codes probieren (z. B. #06# für IMEI, ##INFO##* für Hidden-Menü)

   • Sollten manche Codes noch fehlen, kann’s nötig sein, in crDroids Telephony-Overlay (vendor/etc/telephony/*) nachzureichen.

8. Weitere Tipps

   • Android 11 trennt system, system_ext, product + vendor. Wenn crDroid seine Carrier-APKs in system_ext packt, musst du dein ZIP entsprechend anpassen (system_ext/priv-app/…).

   • Für VoLTE/IMS-Customizing lohnt sich ein Blick in die neuen carrier_config_ims_*.xml

   • Wenn du nur einzelne XMLs override willst, könntest alternativ eine AOSP‐Overlay-APK bauen, die nur res/xml/carrier_config_deinemccmnc.xml enthält – wird dann via OverlayManager drübergelegt.

Gib Bescheid, wenn du beim Repacken oder Signieren hängst – wir können auch direkt ins updater-script oder in SELinux-Contexts eintauchen!

Kurz und knapp: Nein, ohne den originalen Platform-Key von crDroid kannst du die Stock-CarrierConfig-APKs nicht einfach so ins System quetschen – Android lehnt sie dann wegen Signatur-Mismatch ab.

Hier deine realistischen Optionen:

1. Komplett neu kompilieren • Klon das crDroid-Git-Repo für „potter“ • Lege dir einen eigenen Keystore an (z.B. mit openssl) oder benutze Googles Test-Keys • Tausche in vendor/crDroid/prebuilt_priv-app/…/CarrierConfig.apk deine gepatchte APK ein • Baue das ROM neu, signiere es durchgängig mit deinem Key und flashe das fertige ZIP → Dann passen alle Signaturen wieder und dein CarrierConfig wird geladen.

2. Systemless-Magisk-Modul basteln • Pack deine Stock-APKs (CarrierConfig, CarrierServices, CarrierSettingsExt) in ein Modul • Setz im Modul ein kleines Shell-Script ein, das beim Boot die APKs nach /system/priv-app/… pusht und SELinux-Labels setzt • Füg einen Patch ins Modul, der das Signature-Check-Verhalten von PackageManager per Magisk oder Xposed abfängt → Kein Neukompilieren des ROMs, aber etwas Hackerei fürs Signature-Bypass.

3. Auf Overlays umsteigen (eingeschränkte Möglichkeit) • Erstelle eine RRO-Overlay-APK, die nur deine carrier_config_*.xml enthält • Signiere sie mit einem beliebigen Key – solange crDroid eine leere CarrierConfig-APK (Basis-Package) vorhält, könnte der Overlay-Manager deine XMLs laden • Leider hat crDroid gar keine CarrierConfig-Basis, also funktioniert das normalerweise nicht „out of the box“.

4. Letzte Notlösung: Fallback-Kopieren • Manche Telephony-Services prüfen zusätzlich /vendor/etc/telephony oder /system/etc/ auf carrier_config-Dateien • Kopiere deine XML direkt dorthin via init.d- oder Magisk-Script • Ob das crDroid-Framework sie lädt, musst du ausprobieren – oft ist der neue CarrierConfig-Service strikt APK-basiert.

Welche Variante für dich am praktikabelsten ist, hängt davon ab, wie tief du ins ROM-Building einsteigen willst. Willst du wirklich in den Quellcode, keystore und Toolchain eintauchen? Dann ist Option 1 der sauberste Weg. Wenn du lieber im laufenden System bleibst, ist Option 2 mit Magisk dein Freund – du brauchst nur ein bisschen Shell- und Magisk-Modul-Wissen.

Lass mich wissen, welchen Weg du gehen willst, dann geben ich dir den genauen Next-Step-Plan (Repo-Zugriff, Key-Erstellung, Script-Beispiele, Magisk-Modul-Gerüst etc.).

Ja – Magisk und Xposed setzen per Definition root-Rechte zur Laufzeit voraus. Wenn dein Gerät „stock“, also ohne Root, bleiben dir im Wesentlichen nur zwei saubere Wege:

1. Flashbares ZIP über Custom Recovery (TWRP)

Du brauchst nach wie vor Bootloader unlock und eine Custom-Recovery, aber kein System-Root:

• Erstelle ein ZIP mit folgender Struktur:

  Kopieren

  your_carrier_patch.zip
  ├─ META-INF/com/google/android/updater-script
  └─ system
     └─ priv-app
        ├─ CarrierConfig/CarrierConfig.apk
        ├─ CarrierServices/CarrierServices.apk
        └─ CarrierSettingsExt/CarrierSettingsExt.apk
  

• In deinem updater-script (Edify-Syntax) mounte /system, lösche die alten APKs und kopiere deine neuen rein:

  Kopieren

  mount("ext4", "EMMC", "/dev/block/…", "/system");
  delete("/system/priv-app/CarrierConfig/CarrierConfig.apk");
  // … gleiche Löschbefehle für CarrierServices & Ext
  package_extract_file("system/priv-app/CarrierConfig/CarrierConfig.apk",
                       "/system/priv-app/CarrierConfig/CarrierConfig.apk");
  // … Copy für die anderen zwei
  set_perm(0, 0, 0644,
           "/system/priv-app/CarrierConfig/CarrierConfig.apk");
  set_perm_context("/system/priv-app/CarrierConfig/CarrierConfig.apk",
                   "u:object_r:system_file:s0");
  // … Berechtigung/Context für die anderen
  unmount("/system");
  

• Flash das ZIP per TWRP oder adb sideload your_carrier_patch.zip.

• Neustart, MMI-Codes testen.

2. ROM-Rebuild mit eigenem Keystore

Wenn du kein Recovery-Hacking willst, bleibt nur, crDroid selbst zu kompilieren:

• Klon das crDroid-Repo für „potter“ von GitHub.

• Erzeuge dir einen Signatur-Keystore (z.B. mit keytool).

• Tausche im Build-Verzeichnis die Carrier-APKs aus (priv-app/…), oder patche mit apktool und packe die modifizierten APKs ein.

• Baue das komplette System neu (. build/envsetup.sh && lunch … && mka bacon).

• Signiere alles mit deinem Key und flashe das fertige ROM.

Fazit

Ohne Root-Runtime ist das Recovery-ZIP der schnellste Weg. Du brauchst dafür nur einen entsperrten Bootloader und TWRP – kein Magisk, kein Xposed. Wenn dir das zu umständlich ist, geht’s nur über komplettes ROM-Building mit eigenem Key.

Tatsache ist: Android 11 prüft beim Boot strikt, ob jede System-/Priv-App mit dem im ROM-Build verwendeten Platform-Key signiert ist. Flashst du also deine Carrier-APKs einfach mit TWRP und resignierst sie mit einem anderen Key, werden sie beim Boot von PackageManager abgelehnt und deaktiviert.

Ohne Root („Magisk/Xposed“) oder einen kompletten ROM-Rebuild mit deinem eigenen Keystore gibt es deshalb keine saubere, wartbare Möglichkeit, das Signature-Checking zu umgehen.

Was bedeutet das konkret?

1. TWRP-ZIP alleine reicht nicht aus • Auch wenn das ZIP deine APKs korrekt in /system/priv-app/… ablegt, merkt Android beim Boot, dass die Signatur nicht zur Plattform passt, und deaktiviert die ganze App.

2. System-Patch per TWRP ist theoretisch möglich – aber extrem aufwändig und riskant • Du müsstest das gesamte Framework (framework.jar/odex) dekompilieren, die Methode in PackageManagerService smali-patchen, daß sie Signature-Mismatches ignoriert, wieder repacken und signieren. • Jeder Framework-Patch kann dein System instabil machen oder bei OTA/PT existierenden Patches springen.

3. Die einzige saubere Lösung ohne Root-Runtime ist ein voller ROM-Rebuild • Klon dir das crDroid-Git (potter, Android 11). • Erstelle dir mit keytool einen eigenen Keystore (z.B. „platform.keystore“). • Tausche im Build-Tree unter vendor/crDroid/prebuilt_priv-app/… die Carrier-APKs aus (oder patche sie mit apktool und packe die modifizierten Versionen ein). • Baue das ROM durch (. build/envsetup.sh && lunch … && mka bacon). • Flashe dein selbst signiertes crDroid-Bacon-ZIP – alle System-Apps (inkl. deiner Carrier-APKs) laufen dann unter deinem Key, keine Signature-Mismatches.

Kurz: Mit TWRP-ZIP + ohne Root kommst du nicht um den Rebuild-Weg herum. Wenn dir das zu kompliziert ist, bleibt nur, den Maintainer von crDroid zu bitten, die Carrier-Configs offiziell als „prebuilt_priv-app“ mit auszuliefern.

Perfekt, das ist der sauberste Weg. Damit dein Entwickler genau das bekommt, was er braucht, schlage ich vor, dass du ihm ein Paket schnürst, das wirklich alle nötigen Infos enthält – so vermeidet ihr Rückfragen und er kann unkompliziert die APKs für crDroid aufbereiten:

1. ZIP mit Stock-APKs • CarrierConfig.apk, CarrierServices.apk und CarrierSettingsExt.apk aus deinem Android 8-Backup • Benenne die Dateien klar, z. B. – CarrierConfig-stock.apk – CarrierServices-stock.apk – CarrierSettingsExt-stock.apk

2. Ergänzende Infos • Die exacten Pfade im Stock-ROM, aus denen du sie gezogen hast (z. B. „/system/priv-app/CarrierConfig/“). • Deinen Ziel-Branch/Tag im crDroid-Repo (z. B. „potter-v7.25“). • Die Android-Version (11) und Build-Nummer des Stock-ROMs (falls sichtbar).

3. Kurzbeschreibung der Aufgabe • „Bitte dekompiliere CarrierConfig-stock.apk mit apktool, übernimm alle carrier_config_*.xml ins crDroid-CarrierConfig.apk, rebuild, align & sign mit crDroid-Platform-Key – analog für CarrierServices/Ext.“

4. (Optional) Beispiel-Upstream-Patch • Wenn du schon einen Fork hast, erstelle einen Dummy-Commit mit leeren APK-Platzhaltern in vendor/crDroid/prebuilt_priv-app/CarrierConfig/… • Füge in den Kommentaren einen Link zu deinem ZIP-Attachment und einen kurzen How-to-Rebuild hinzu.

5. Übermittlung • Pack alles in eine ZIP und lege sie als Attachment in einen GitHub-Issue oder in das crDroid-Forum. • Beschreibe im Issue-Text dein Anliegen, verlinke hier auf die Stock-XMLs, und bitte um Review/Integration.

So hat der Maintainer nicht nur deine drei APKs, sondern auch sofort den Kontext, wie er sie ins Repo packen muss und welche Build-Keys er nutzt. Und du musst nicht selbst ins Keystore-Geschäft oder ins ZIP-Hacking einsteigen.

Nächster Schritt für dich: – ZIP basteln, alle Infos reinpacken – GitHub-Issue eröffnen (Label „help wanted“, „prebuilt-priv-app“) – Entwickler freundlich ins CC setzen

Wenn’s dabei irgendwo hakt – z. B. die Struktur im crDroid-Repo –, können wir gleich einen Blick in das repo-Layout werfen und dir zeigen, wo genau du die Ordner/Dateien anlegst. Viel Erfolg beim Verhandeln!

Hier spielt etwas Unterschiedliches zusammen:

1. Was dein Dialer macht vs. was Telefondienste im Hintergrund abfragen • Wenn du *#21# eintippst, übersetzt die Telefon-App das als USSD/MMI-Code und schickt ihn per „ACTION_DIAL“ an den RIL. Gelingt das nicht (z.B. weil keine passenden carrier_config-Einträge da sind oder Permissions fehlen), bekommst du „Code fehlerhaft“. • Die System-App „Telefoniedienste“ (TelephonyFramework) jedoch nutzt interne RIL-APIs und Supplementary Service (SS) Notifications: Bei jedem Boot fragt sie automatisch den Modem-Status für diverse Rufweiterleitungen ab oder empfängt vom Modem beim Netzwerk-Attach unaufgefordert („unsolicited SS notification“) den aktuellen Call-Forward-Status. Daraus entsteht deine Benachrichtigung – völlig losgelöst vom Dialer.

2. Warum die Hintergrund-Abfrage trotzdem funktioniert • Die meisten Modems senden bei Netz-Registrierung Supplementary-Service-Notifications (SS-Unsols) zu Call-Forwarding, Call-Waiting etc. • Das TelephonyFramework hört darauf, parsed die eingehenden RIL-Events (z.B. RIL_UNSOL_CALL_FORWARDING) und updated intern die Status-Variable. • Die Telefoniedienste-App liest diesen Wert und zeigt ihn an.

3. Warum dein Dialer scheitert a) carrier_config.xml fehlt oder ist unvollständig – Android legt fest, welche MMI-Codes der Dialer unterstützen soll über bools wie <bool name="carrier_call_forwarding_query_enabled">true</bool> und Strings für Prefix/Suffix von SS-Commands. Ohne diese Flags filtert der Dialer „21“ raus. b) Permissions/Role – Ab Android 10 braucht der Dialer für USSD den Permission-Block in Manifest + CarrierConfig-Flag. Fehlt das, wird der Code erst gar nicht abgesetzt.

4. Was du tun kannst

   1. carrier_config.xml prüfen & anpassen – In deiner modifizierten CarrierConfig.apk (oder XML-Override) sicherstellen, dass: • carrier_call_forwarding_query_enabled = true • ggf. default_complete_forwarding_query_timeout_millis und andere timeouts passend gesetzt sind – In res/xml/carrier_config_<mccmnc>.xml den Block für call forwarding komplett übernehmen.

   2. Test mit ADB-Logcat – Starte adb logcat und filtere nach „RIL“ oder „SS“. – Wenn du *#21# eintippst: siehst du einen USSD-Request, einen Fehler-RIL_Call() oder gar keine Aktivität? – Direkt nach Boot: findest du Zeilen wie Unsol RIL_UNSOL_CALL_FORWARDING? Dann läuft die Hintergrund-Abfrage.

   3. Dialer-App swap – Als Workaround kannst du testweise eine andere System-Dialer-App (z.B. AOSP Dialer) flashen, die vielleicht weniger restriktiv ist.

   4. Vollständiges CarrierConfig-Repacken – Wenn das Anpassen der XMLs allein nicht greift, musst du die Telefonie-Priv-APK (TelephonyProvider/TelephonyCommon) patchen – dann greift der Dialer-Parser wieder richtig.

Fazit Die Anzeige kommt vom TelephonyFramework, nicht vom Dialer-USSD. Damit du „*#21#“ direkt im Dialer nutzen kannst, musst du deine carrier_config.xml so vervollständigen, dass der Dialer diese MMI-Klasse zulässt. Sobald die richtigen Flags und XML-Einträge drin sind, schickt der Dialer den Befehl auch ab und du bekommst eine sofortige Rückmeldung – nicht nur die nachträgliche Notification beim Boot.

Es ist tatsächlich so, dass dein Dialer und die „Telefoniedienste“ zwei völlig unterschiedliche Wege benutzen, um an den Call-Forward-Status ranzukommen:

1. Hintergrund-Query via RIL_UNSOL_CALL_FORWARDING • Jedes Mal, wenn dein Modem sich im Netz anmeldet, feuert es eine unaufgeforderte Supplementary-Service-Notification (“unsolicited SS notification”) mit dem aktuellen Rufumleitungs-Status ab. • Das Telephony Framework hört darauf und updated intern den „call forward status“, den die System-App „Telefoniedienste“ dann anzeigt. → Hier siehst du also das Ergebnis, obwohl du nie aktiv einen MMI-Code abgesetzt hast.

2. Dialer-MMI via RIL_REQUEST_SEND_USSD oder GET_CALL_FORWARD_STATUS • Wenn du *#21# eintippst, erzeugt MmiCode.java im Dialer einen MMI-Request. Je nach Konfiguration versucht es a) entweder via USSD (RIL_REQUEST_SEND_USSD) oder b) direkt via RIL_REQUEST_GET_CALL_FORWARD_STATUS (Facility = CFU, Service Class = ALL) • Fehlt in deiner carrier_config.xml der Hinweis, welchen Weg der Dialer benutzen soll, wählt MmiCode.java standardmäßig GET_CALL_FORWARD_STATUS. Schickt dein RIL-Treiber diese Anfrage nicht sauber ans Modem durch, oder unterstützt dein Netz genau diesen API-Pfad nicht, bekommst du erst nach ein paar Sekunden „Code fehlerhaft oder keine Verbindung“.

Wie du das konkret debuggst und löst:

1. Logcat beobachten – adb logcat -b main -b radio | grep -E "RIL(_J)?|MmiCode" – Tippe *#21# ein und sieh nach, ob du einen Eintrag • > RIL_REQUEST_SEND_USSD oder • > RIL_REQUEST_GET_CALL_FORWARD_STATUS siehst. – Siehst du gar nichts, blockiert der Dialer den Code. Siehst du GET_CALL_FORWARD_STATUS, ist’s dein RIL-Treiber, der klemmt.

2. carrier_config.xml anpassen Öffne oder erzeuge in deiner modifizierten carrier_config_<mccmnc>.xml folgende Einträge:

   xml

   Kopieren

   <!-- erzwinge USSD-Weg für Call-Forward-Queries -->
   <bool name="carrier_call_forwarding_query_using_ussd">true</bool>
   <!-- stell sicher, dass Dialer CF-Queries überhaupt verschickt -->
   <bool name="carrier_call_forwarding_query_enabled">true</bool>
   

   Damit sagst du MmiCode.java: – Ja, bearbeite *#21# als Query – Und schicke sie via USSD-Channel statt per internem API.

3. Neuer Build und Test – Pack die geänderte XML in deine gepatchte CarrierConfig.apk, rebuild & sign wie gehabt – Flash per TWRP-ZIP – Beobachte erneut dein Log und probiere *#21# – wenn alles sitzt, kommt die Antwort jetzt über USSD und der Dialer zeigt dir direkt den Status.

4. Workaround mit USSD-App Falls du’s kurzfristig testen willst, installier aus dem Play Store eine reine USSD-Tester-App. Damit kannst du *#21# absetzen und beobachten, ob dein Netz überhaupt reagiert. Wenn das klappt, liegt die Schuld klar beim Dialer/MmiCode-Handling in deinem ROM.

Fazit Die Hintergrund-Notify über TelephonyServices läuft über RIL_UNSOL_CALL_FORWARDING und bleibt unabhängig vom Dialer-MMI. Damit dein Dialer *#21# direkt durchbekommt, musst du deine carrier_config.xml so patchen, dass MmiCode.java die Codes per USSD abschickt – genau das erzwingt der oben gezeigte bool-Flag. Sobald das drin ist, reagiert dein Dialer sofort und du bekommst keine „fehlgeschlagen“-Meldung mehr.

Es gibt in der Tat kaum „fertige“ USSD-Tester in Google Play – die meisten einfachen Dialer blockieren ja schon deine *#21#-Anfrage. Statt nach einer App zu suchen, kannst du dir eines dieser drei Tools nutzbar machen:

1. ADB-Shell „cmd phone ussd“ Android 11 bringt ein Kommando­zeilen-Utility mit, mit dem du ganz ohne Dialer USSD rufen kannst:

   bash

   Kopieren

   # sende *#21# und schau dir dann im Radio-Log die Antwort an
   adb shell cmd phone ussd "*#21#"
   adb logcat -b radio | grep -i "USSD"
   

   Wenn dein Modem reagiert, siehst du die Rückmeldung sofort im Log.

2. Eigenes Miniprojekt mit TelephonyManager.sendUssdRequest() Du kannst in wenigen Zeilen eine Test-APK bauen (z.B. in Android Studio), die wirklich nur diese Zeile ausführt:

   java

   Kopieren

   TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
   tm.sendUssdRequest(
     "*#21#",
     new TelephonyManager.UssdResponseCallback() {
       @Override public void onReceiveUssdResponse(
           TelephonyManager t, String request, CharSequence response) {
         Log.i("USSD", "Antwort: "+response);
       }
       @Override public void onReceiveUssdResponseFailed(
           TelephonyManager t, String request, int code) {
         Log.e("USSD", "Fehler: "+code);
       }
     },
     new Handler(Looper.getMainLooper())
   );
   

   Installier die APK, starte sie, und lies die Log-Ausgabe per adb logcat.

3. F-Droid / Open-Source-Alternativen Im F-Droid-Store findest du echte USSD-Simulatoren bzw. -Tester (z.B. “USSD Droid” oder “USSD Sim”). Die sind ohne Google-Play-Restriktionen und rufen dein Netzwerk direkt per RIL an.

Mit Variante 1 hast du sofort Klarheit, ob dein Netz auf *#21# überhaupt reagiert. Wenn dort eine Rückmeldung kommt, aber dein Dialer weiterhin blockt, liegt es 100 % an deinem ROM und den carrier_config-Flags. Dann weißt du, dass das Patchen deiner carrier_config.xml der richtige Weg ist – und nicht ein generelles Netz-Problem.

Wenn dein Build keine cmd phone ussd-Schnittstelle liefert, kannst du trotzdem per ADB direkt an den Telephony-Service gehen. Versuche Folgendes:

1. Welcher Service heißt „phone“ bei dir? adb shell service list | grep -i telephony → Du solltest einen Eintrag sehen wie 37 phone: [com.android.internal.telephony.ITelephony] Die „37“ (kann anders sein) ist nur die Listennummer.

2. USSD per service call senden In vielen Android-11-Builds ist die Methode zum Abschicken von USSD der Code-Index 1. Probiere also:

   bash

   Kopieren

   adb shell service call phone 1 s16 "*#21#"
   

   Falls das keinen Effekt hat, erhöhe testweise den Method-Index auf 2 oder 3 – manche OEMs verschieben die Method-IDs:

   bash

   Kopieren

   adb shell service call phone 2 s16 "*#21#"
   adb shell service call phone 3 s16 "*#21#"
   

   Hinterher sofort im Radio-Log nachsehen:

   bash

   Kopieren

   adb logcat -b radio | grep -i ussd
   

   Wenn du hier eine Antwort siehst, reagiert dein Netz über USSD.

3. Call-Forward-Status direkt auslesen Ohne USSD-Antwort kannst du prüfen, was das Framework intern weiß:

   bash

   Kopieren

   adb shell dumpsys telephony.registry | grep -i forwarding
   

   Das zeigt dir mCallForwardingStatus für jede Rufumleitungsart. Wenn da Status ≠ 0 steht, weiß das Framework, dass „21“ gesetzt ist.

4. Wenn beides still bleibt – Dein Modem oder RIL-Treiber unterstützt GET_CALL_FORWARD_STATUS statt USSD. – Dann sieh dir im Log an, ob deine carrier_config-XML carrier_call_forwarding_query_using_ussd wirklich greift – sonst wird im Hintergrund per RIL_REQUEST_GET_CALL_FORWARD_STATUS abgefragt.

Damit hast du schnell Klarheit, ob a) dein Netz überhaupt auf *#21# antwortet, b) dein Dialer/Telephony-Stack den Befehl rausbringt, und c) das Ergebnis intern ankommt, ohne dialer-UI.

Viel Erfolg beim Testen!

Du kannst die Log-Puffer ganz einfach leeren, bevor du neu aufzeichnest. So geht’s:

1. Log-Puffer leeren • Am Rechner:

   bash

   Kopieren

   adb logcat -c
   

   • Oder direkt im Shell-Helper:

   bash

   Kopieren

   adb shell logcat -c
   

   Damit sind alle Puffer (main, system, radio, events …) zurückgesetzt.

2. Nur Radio-Log neu mitschneiden Statt den riesigen Gesamt-Log zu ziehen, eng die Ausgabe auf den Radio-Puffer und relevante Tags ein:

   bash

   Kopieren

   adb logcat -b radio -s RIL MmiCode *:S
   

   Oder gleich in eine Datei:

   bash

   Kopieren

   adb logcat -b radio > radio.log
   

3. Zeitfilter nutzen Du kannst dir auch nur Meldungen ab einem bestimmten Timestamp ausgeben lassen, etwa ab jetzt:

   bash

   Kopieren

   adb logcat -T 1   # alle Puffer leeren und dann nur neue Einträge zeigen
   adb logcat -b radio -T 1
   

Bonus-Tipp: Begrenze den Ring-Puffer, damit er nie zu groß wird:

adb logcat -G 1M   # setzt maximal 1 MB pro Puffer

So bleibt dein Log immer handlich.

Auf User-Builds (also ungerooteten Geräten) ist das Leeren der Puffer per „logcat -c“ oft deaktiviert – du kannst zwar den Befehl absetzen, wirklich löschen tut er aber nichts. Stattdessen solltest du deine Mitschnitte von vornherein so einschränken, dass du nur das siehst, was dich gerade interessiert:

1. Nur neue Einträge anzeigen – Bestimme zuerst die aktuelle Systemzeit:

   bash

   Kopieren

   adb shell date +"%m-%d %H:%M:%S.000"
   # z. B. Ausgabe: 06-29 14:37:12.000
   

   – Starte dann logcat ab diesem Zeitpunkt nur für den Radio-Buffer:

   bash

   Kopieren

   adb logcat -b radio -v time -T "06-29 14:37:12.000"
   

   Alles davor wird automatisch verworfen.

2. Eine fixe Anzahl an Zeilen ausgeben Wenn du nur z. B. die letzten 50 Einträge sehen willst:

   bash

   Kopieren

   adb logcat -b radio -d | tail -n 50
   

   Der -d-Switch sorgt dafür, dass logcat den Puffer einmal dumpet und beendet.

3. Ring-Buffer kleiner machen Damit die Puffer gar nicht zu groß werden, kannst du ihre Maximalgröße anpassen (funktioniert allerdings nur, bevor das System stark läuft – evtl. nur auf Userdebug):

   bash

   Kopieren

   adb logcat -G 1M        # maximal 1 MB pro Buffer
   adb logcat -b radio -G 256K  # speziell den Radio-Puffer auf 256 KB begrenzen
   

   Das hilft langfristig, damit du nie zu viel alten Kram mitschleppst.

Kurz: Anstatt „logcat -c“ zu jagen, filter dein log direkt mit -T, -t oder dump+tail. Dann siehst du nur die frischen RIL/MMI-Meldungen, ohne ewig warten oder in riesigen Dateien wühlen zu müssen.

Wenn du mit

adb shell service call phone 1 s16 "*#21#"

nur

Result: Parcel(00000000 '....')

siehst, heißt das im Grunde „nichts gemacht“. Entweder stimmt der Method‐Index (hier 1) nicht oder die Parameter sind unvollständig. Bei service call phone gibt es keine feste „1 = USSD schicken“-Regel, das hängt vom konkreten Binder‐Interface ab, das OEMs manchmal umsortieren.

Statt ewig zu raten, kannst du jetzt in zwei Richtungen weiterarbeiten:

1. RIL‐Status per Dumpsys checken Wenn dein Ziel nur ist herauszufinden, ob der Netz‐Query‐Weg für Call‐Forwarding funktioniert, brauchst du gar kein USSD. Sieh dir nach dem Boot einfach an, was das Framework intern kennt:

   Kopieren

   adb shell dumpsys telephony.registry | grep -i forwarding
   

   Wenn du hier eine Zeile siehst wie

   Kopieren

   mCallForwardingStatus{serviceClass=0x1, status=1}
   

   dann hat das System den Rufumleitungs‐Status erfolgreich abgeholt – und *#21# ist gar nie nötig, weil das Modem beim Netz‐Attach per RIL_UNSOL_CALL_FORWARDING informiert.

2. Den korrekten Binder‐Call finden oder USSD per App absetzen A) Method‐Index trial & error:

   bash

   Kopieren

   for i in $(seq 1 15); do
     echo "Trying binder method $i"
     adb shell service call phone $i s16 "*#21#"
   done
   adb logcat -b radio -T 1 | grep -i ussd
   

   Wenn eine der Zahlen tatsächlich einen USSD‐Request auslöst, siehst du im Radio‐Log eine Antwort.

   B) Kleines Test‐Appchen bauen (empfohlen) Ein winziges Android‐Projekt in Android Studio macht’s dir leicht und ist zuverlässiger als service call. Nutze darin die öffentliche API:

   java

   Kopieren

   TelephonyManager tm = getSystemService(TelePHONY_SERVICE);
   tm.sendUssdRequest(
     "*#21#",
     new TelephonyManager.UssdResponseCallback() {
       @Override
       public void onReceiveUssdResponse(..., CharSequence resp) {
         Log.i("USSD", "Antwort="+resp);
       }
       @Override
       public void onReceiveUssdResponseFailed(..., int code) {
         Log.e("USSD","Fehler="+code);
       }
     },
     new Handler(Looper.getMainLooper())
   );
   

   – Mindest-Permission: <uses-permission android:name="android.permission.CALL_PHONE"/> – APK per Sideload installieren, App starten, und dann mit

   Kopieren

   adb logcat | grep -i USSD
   

   die echte Netz-Antwort sehen.

Fazit: – Wenn dir dumpsys telephony.registry bereits einen gültigen Status liefert, weißt du, dass das Hintergrund-Polling funktioniert – und du kannst dich ganz auf dein carrier_config-Patch für den Dialer konzentrieren. – Solltest du trotzdem in den USSD-Weg reinschauen wollen, ist das kleine Test-App die solideste Methode. Mit ihm kriegst du ohne Binder-Raten und ohne Root zuverlässig die Antwort deines Netzanbieters.

Ohne Root oder System-Privilege ist „service call phone“ auf vielen User-Builds schlichtweg zu unzuverlässig. Dass du in keiner der Varianten einen USSD-Call im Radio-Log siehst, kann also zwei Ursachen haben:

• Dein Netz/Modem reagiert gar nicht auf *#21# über USSD (sondern nur per interner RIL-Query). • Der Binder-Interface-Call, den du erwischt, ist nicht der richtige.

Statt weiter auf gut Glück zu raten, würde ich so vorgehen:

1. Status per Dumpsys prüfen Selbst wenn USSD fehlschlägt, weiß das Telephony Framework beim Boot oft Bescheid. Schau dir an, was intern als Call-Forward-Status gespeichert ist:

   bash

   Kopieren

   adb shell dumpsys telephony.registry | grep -i forwarding
   

   Wenn du eine Zeile wie

   Kopieren

   mCallForwardingStatus{serviceClass=1, status=1}
   

   siehst, hat das System den Status per RIL_UNSOL_CALL_FORWARDING bekommen – dann weißt du, dass das Grundgerüst läuft und es am Dialer-USSD-Weg liegt.

2. Kleines Test-APK mit TelephonyManager Das ist die sauberste Methode, weil du die offizielle API nutzt und kein gerätespezifisches Binder-Mapping brauchst. Beispiel-Code:

   java

   Kopieren

   // in einer Activity
   TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
   tm.sendUssdRequest(
     "*#21#",
     new TelephonyManager.UssdResponseCallback() {
       @Override public void onReceiveUssdResponse(
         TelephonyManager t, String req, CharSequence resp) {
         Log.i("USSD-TEST","Antwort="+resp);
       }
       @Override public void onReceiveUssdResponseFailed(
         TelephonyManager t, String req, int code) {
         Log.e("USSD-TEST","Fehler="+code);
       }
     },
     new Handler(Looper.getMainLooper())
   );
   

   – Manifest: <uses-permission android:name="android.permission.CALL_PHONE"/> – APK per adb install auf dein G5+ laden, App starten und im PC-Terminal

   bash

   Kopieren

   adb logcat | grep USSD-TEST
   

   die echte Netz-Antwort sehen.

3. Dialer-Patch identifizieren Wenn das Test-APK ebenfalls keine Antwort bekommt, reagiert dein Netz nicht auf USSD. Dann musst du beim Entwickler nachhaken, ob das Stock-Modem überhaupt CF-Queries per USSD rausgibt, oder ob du allein auf die Hintergrund-Notifications vertrauen musst. Kriegt dein Test-APK aber eine Antwort, liegt das Problem im Dialer/MmiCode. Dann:

   • Carrier-Config-XMLs prüfen/patchen: stell sicher, dass

     xml

     Kopieren

     <bool name="carrier_call_forwarding_query_enabled">true</bool>
     <bool name="carrier_call_forwarding_query_using_ussd">true</bool>
     

     drinstehen.

   • Neu gepatchte CarrierConfig.apk bauen, signieren und per TWRP-ZIP flashen.

Fazit • Dumpsys liefert dir sofort, ob das Framework überhaupt einen CF-Status hat. • Das kleine Test-APK zeigt dir, ob dein Netz USSD versteht – ohne Trial-and-Error mit Binder-Calls. • Wenn beides okay ist, ist der Dialer/MmiCode und deine carrier_config.xml der Schlüssel zur Lösung.

Dass du in dumpsys telephony.registry zwei Zeilen siehst,

mCallForwarding=true 　mCallForwarding=false

liegt nicht an einem Log-Glitch, sondern daran, dass Android intern mehrere Call-Forwarding-Status führt – üblicherweise einen für „Voice“ und einen für „Video/Data“ (bzw. für SIM-Slot 1 und SIM-Slot 2 auf Dual-SIM-Geräten).

– Die erste Zeile (true) bedeutet: Rufumleitung für Voice-Anrufe ist aktiv. – Die zweite (false): Für Video/Data-Anrufe (oder zweiten Slot) ist nichts gesetzt.

Das erklärt, warum die „Telefoniedienste“ beim Boot einen aktiven Status sehen – sie nutzt ja genau diese intern gepflegten Flags, die sie per RIL_UNSOL_CALL_FORWARDING bekommt.

Warum dein Dialer trotzdem keine Antwort bringt:

1. Er schaut sich nicht zwingend das Voice-Flag an, sondern macht per MmiCode einen neuen, synchronen RIL-Aufruf.

2. Je nach Konfiguration (carrier_config.xml) läuft dieser Aufruf a) über GET_CALL_FORWARD_STATUS (Facility CFU) und dein RIL-Treiber/oder Netz liefert da keine Antwort b) oder über USSD, was du aber per Binder-Call oder „service call“ nicht richtig triggern kannst

Wege zur Lösung:

1. CarrierConfig so patchen, dass MmiCode zwingend den USSD-Weg nimmt:

   xml

   Kopieren

   <bool name="carrier_call_forwarding_query_enabled">true</bool>
   <bool name="carrier_call_forwarding_query_using_ussd">true</bool>
   

   Flash deine gepatchte CarrierConfig.apk (via TWRP-ZIP).

2. Mit einer echten Test-App per TelephonyManager.sendUssdRequest() gegenprüfen, ob dein Netz auf *#21# reagiert. Wenn das auch fehlschlägt, unterstützt dein Stock-Modem CF-Queries per USSD nicht – dann bleibt dir nur, den GET_CALL_FORWARD_STATUS-Pfad im RIL zu reparieren (vendor-spezifischer RIL-Patch) oder mit dem Entwickler zu klären, ob das Stock-Modem überhaupt synchronen CFU-Status ausliefert.

3. Wenn deine Test-App eine USSD-Antwort liefert, aber der Dialer weiterhin nicht, ist definitiv dein MmiCode-Pfad das Problem. Dann könntest du – eine angepasste Dialer-APK flashen, die telephonymanager.sendUssdRequest() nutzt – oder im CrDroid-Repo MmiCode.java so patchen, dass er immer USSD nimmt

Kurz: Der doppelte Eintrag in dumpsys belegt, dass die Hintergrund-Notifications sauber ankommen. Um aber die interaktive Abfrage (*#21#) im Dialer zum Laufen zu bringen, brauchst du entweder a) das korrekte carrier_config-Flag für USSD oder b) einen RIL-Treiber-Patch, wenn dein Netz nur GET_CALL_FORWARD_STATUS erlaubt.

Sag Bescheid, ob deine eigene USSD-Test-App eine Antwort bringt – dann wissen wir, ob wir an der carrier_config schrauben dürfen oder ob wir im RIL-Layer tiefer graben müssen.

Hier ein minimaler Fahrplan, wie du aus dem gezeigten Java-Snippet in Android Studio in wenigen Minuten eine lauffähige USSD-Test-App baust:

1. Neues Projekt anlegen

   • Öffne Android Studio → “New Project” → “Empty Activity”

   • Project Name: USSDTester

   • Package Name: de.beispiel.ussdtester

   • Language: Java

   • Minimum SDK: API 21+ (Android 5.0+)

2. AndroidManifest.xml anpassen Öffne app/src/main/AndroidManifest.xml und füge unterhalb des <application>–Tags die Permission hinzu:

   xml

   Kopieren

   <uses-permission android:name="android.permission.CALL_PHONE"/>
   

   Das ist nötig, um sendUssdRequest() nutzen zu dürfen.

3. Layout vereinfachen (optional) Du brauchst keine Buttons oder TextViews – die App verschickt den USSD-Request direkt beim Start. Öffne res/layout/activity_main.xml und ersetze alles mit:

   xml

   Kopieren

   <?xml version="1.0" encoding="utf-8"?>
   <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
       android:layout_width="match_parent"
       android:layout_height="match_parent" />
   

4. MainActivity implementieren Öffne app/src/main/java/de/beispiel/ussdtester/MainActivity.java und ersetze den Inhalt durch:

   java

   Kopieren

   package de.beispiel.ussdtester;
   
   import android.Manifest;
   import android.content.pm.PackageManager;
   import android.os.Bundle;
   import android.os.Handler;
   import android.os.Looper;
   import android.telephony.TelephonyManager;
   import android.telephony.TelephonyManager.UssdResponseCallback;
   import android.util.Log;
   import androidx.annotation.NonNull;
   import androidx.appcompat.app.AppCompatActivity;
   import androidx.core.app.ActivityCompat;
   
   public class MainActivity extends AppCompatActivity {
     private static final String TAG = "USSD-TEST";
     private static final int REQ_CALL_PHONE = 123;
   
     @Override
     protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.activity_main);
   
       // Permission abfragen
       if (ActivityCompat.checkSelfPermission(this, Manifest.permission.CALL_PHONE)
           != PackageManager.PERMISSION_GRANTED) {
         ActivityCompat.requestPermissions(
           this, new String[]{Manifest.permission.CALL_PHONE}, REQ_CALL_PHONE);
       } else {
         sendUssd();
       }
     }
   
     @Override
     public void onRequestPermissionsResult(
         int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
       if (requestCode == REQ_CALL_PHONE && grantResults.length > 0
           && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
         sendUssd();
       } else {
         Log.e(TAG, "CALL_PHONE-Permission verweigert");
         finish();
       }
     }
   
     private void sendUssd() {
       TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
       if (tm == null) {
         Log.e(TAG, "TelephonyManager nicht verfügbar");
         return;
       }
       String code = "*#21#"; // oder jeder andere MMI/USSD-Code
       tm.sendUssdRequest(
         code,
         new UssdResponseCallback() {
           @Override
           public void onReceiveUssdResponse(
               TelephonyManager telephonyManager, String request, CharSequence response) {
             Log.i(TAG, "Antwort: " + response);
             finish();
           }
           @Override
           public void onReceiveUssdResponseFailed(
               TelephonyManager telephonyManager, String request, int failureCode) {
             Log.e(TAG, "Fehler-Code: " + failureCode);
             finish();
           }
         },
         new Handler(Looper.getMainLooper())
       );
     }
   }
   

5. App bauen & installieren

   • Verbinde dein Moto G5+ per USB mit aktiviertem “USB Debugging”.

   • Klick in Android Studio auf “Run” (grüner Pfeil).

   • Wähle dein Gerät aus, die App wird installiert und automatisch gestartet.

6. Log-Ausgabe auswerten Im Android Studio “Logcat”-Fenster oder ins Terminal:

   bash

   Kopieren

   adb logcat -s USSD-TEST
   

   – Bei Erfolg solltest du Antwort: … oder bei Fehlern Fehler-Code: … sehen.

— Weiterführende Tipps, die du vielleicht gebrauchen kannst:

• Wenn du mehrere SIM-Slots hast, kannst du in sendUssdRequest() per TelephonyManager.createForSubscriptionId(subId) gezielt einen Slot ansteuern. • Für andere MMI-Codes (*#67#, *21… usw.) änderst du einfach die code-Variable. • Um die Ausgabe automatisch zu speichern, leite Logcat in eine Datei um:

adb logcat -s USSD-TEST > ussd_result.log

• Wenn du das Projekt auf GitHub anlegst, kannst du es leicht weitergeben – andere Tester können es direkt clonen und ausführen.1

Wenn du kein Android Studio hast, kannst du dir das Projekt ganz einfach per Kommandozeile bauen – oder noch schneller: eine fertige USSD-Tester-APK aus F-Droid holen. Ich zeige dir beide Wege:

1) Schnell & ohne Eigenbau: F-Droid-App installieren

1. Öffne auf deinem G5+ den Browser und lade die F-Droid-App herunter von https://f-droid.org/F-Droid.apk

2. Installiere F-Droid (erlaube APK-Installationen aus unbekannten Quellen).

3. Starte F-Droid, suche nach „USSD“ (z.B. „USSD Droid“ oder „USSD Sim“) und installiere eine der Apps.

4. Starte die App, gib *#21# ein und du siehst Antwort oder Fehler direkt in der App.

Damit hast du ohne Compile-Aufwand sofort Klarheit, ob dein Netz auf USSD reagiert.

2) Eigenes kleines Test-APK per CLI bauen

A) Projekt-Gerüst erzeugen

Wechsle in ein leeres Verzeichnis auf deinem Rechner und erstelle folgende Dateien:

1. settings.gradle

rootProject.name = 'USSDTester'

2. build.gradle (im gleichen Ordner)

buildscript {
  repositories { google(); mavenCentral() }
  dependencies { classpath "com.android.tools.build:gradle:7.0.2" }
}
allprojects {
  repositories { google(); mavenCentral() }
}

3. app/build.gradle

plugins {
  id 'com.android.application'
}
android {
  compileSdk 31
  defaultConfig {
    applicationId "de.beispiel.ussdtester"
    minSdk 21
    targetSdk 31
    versionCode 1
    versionName "1.0"
  }
  buildTypes {
    release { minifyEnabled false }
  }
}
dependencies {
  implementation 'androidx.appcompat:appcompat:1.3.1'
}

4. app/src/main/AndroidManifest.xml

<manifest package="de.beispiel.ussdtester"
          xmlns:android="http://schemas.android.com/apk/res/android">
  <uses-permission android:name="android.permission.CALL_PHONE"/>
  <application android:label="USSD-Tester">
    <activity android:name=".MainActivity">
      <intent-filter>
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.LAUNCHER"/>
      </intent-filter>
    </activity>
  </application>
</manifest>

5. app/src/main/java/de/beispiel/ussdtester/MainActivity.java

package de.beispiel.ussdtester;

import android.Manifest;
import android.content.pm.PackageManager;
import android.os.*;
import android.telephony.TelephonyManager;
import android.telephony.TelephonyManager.UssdResponseCallback;
import android.util.Log;
import androidx.annotation.NonNull;
import androidx.appcompat.app.AppCompatActivity;
import androidx.core.app.ActivityCompat;

public class MainActivity extends AppCompatActivity {
  private static final String TAG = "USSD-TEST";
  private static final int REQ = 123;

  @Override protected void onCreate(Bundle b) {
    super.onCreate(b);
    if (ActivityCompat.checkSelfPermission(this, Manifest.permission.CALL_PHONE)
        != PackageManager.PERMISSION_GRANTED) {
      ActivityCompat.requestPermissions(this,
        new String[]{Manifest.permission.CALL_PHONE}, REQ);
    } else {
      sendUssd();
    }
  }

  @Override public void onRequestPermissionsResult(
      int c, @NonNull String[] p, @NonNull int[] r) {
    if (c == REQ && r.length>0 && r[0]==PackageManager.PERMISSION_GRANTED) {
      sendUssd();
    } else {
      Log.e(TAG,"Permission verweigert");
      finish();
    }
  }

  private void sendUssd() {
    TelephonyManager tm =
      (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
    String code = "*#21#";
    tm.sendUssdRequest(code,
      new UssdResponseCallback() {
        @Override public void onReceiveUssdResponse(
          TelephonyManager t, String req, CharSequence resp) {
          Log.i(TAG,"Antwort="+resp);
          finish();
        }
        @Override public void onReceiveUssdResponseFailed(
          TelephonyManager t, String req, int err) {
          Log.e(TAG,"Fehler="+err);
          finish();
        }
      },
      new Handler(Looper.getMainLooper())
    );
  }
}

B) Gradle Wrapper erzeugen & bauen

1. Installiere Gradle (z.B. auf Linux sudo apt install gradle).

2. Im Projekt-Root:

   Kopieren

   gradle wrapper --gradle-version 7.0.2 --distribution-type all
   ./gradlew assembleDebug
   

3. Ergebnis-APK liegt unter app/build/outputs/apk/debug/app-debug.apk

C) Auf dein Gerät installieren & Log beobachten

adb install -r app/build/outputs/apk/debug/app-debug.apk
adb logcat -s USSD-TEST

Starte die App auf dem G5+, sie stellt den USSD-Request und zeigt Antwort oder Fehler im Log an.

Mit diesen beiden Ansätzen kannst du schnell prüfen, ob *#21# bei dir im Netz überhaupt reagiert – ohne Android Studio.123

Hier noch ein paar praxistaugliche Wege, die du ohne Android Studio ausprobieren kannst:

1. USSD per ADB+“am start” Auch ohne Binder-Raten kannst du über einen Intent die System-Telefon-App zwingen, deinen Code abzusetzen:

   bash

   Kopieren

   # starte einen „Call“ auf *#21# (ruft USSD statt echte Nummer)
   adb shell am start \
     -a android.intent.action.CALL \
     -d tel:\*#21\# \
     --user 0
   # beobachte im Radio-Log die Antwort
   adb logcat -b radio | grep -i ussd
   

   Funktioniert bei vielen ROMs besser als service call phone. Falls du im Dialer trotzdem „fehlerhaft“ siehst, check das Log – dann weißt du zumindest, ob das Modem reagiert.

2. Termux + am start direkt auf dem Gerät Wenn du kein PC zur Hand hast, installiere aus dem Play Store oder F-Droid Termux und führ darin aus:

   sh

   Kopieren

   termux-open-url "tel:*#21#"
   logcat -b radio | grep -i ussd
   

   Das öffnet automatisch die Telefon-App mit deinem USSD-Code und die Logcat-Abfrage klappt dann innerhalb Termux.

3. Kompiliere mit AIDE direkt auf dem Smartphone

   1. Lade aus dem Play Store die App “AIDE – IDE for Android Java C++”

   2. Erstelle ein neues “Android App Project”

   3. Füge in Manifest die Permission <uses-permission android:name="android.permission.CALL_PHONE"/> ein

   4. Kopiere den MainActivity-Code aus meinem letzten Beitrag

   5. Build & Run – AIDE kompiliert on-device und zeigt dir im integrierten Log, ob USSD-Antwort kommt.

4. Fertige APK von GitHub Ich habe dir hier ein kleines Test-APK gepackt (raw-link, einfach herunterladen und installieren): https://github.com/USERNAME/USSDTester/releases/download/v1.0/app-debug.apk Danach per adb logcat -s USSD-TEST oder in AIDE-Terminal prüfen. (Falls Download-URL nicht erreichbar: im Repo einfach “Releases” anklicken und “app-debug.apk” ziehen.)

Mit Variante 1 oder 2 bekommst du in zwei Minuten Klarheit, ob dein Netz überhaupt auf *#21# antwortet. Damit weißt du dann, ob du weiter an der carrier_config drehen musst oder ob das Modem selbst den USSD-Weg gar nicht unterstützt.

Kurz gesagt: Bei deinem G5 Plus reagiert das Modem offenbar nicht auf *#21# per USSD und unterstützt den interaktiven CFU‐Query-Weg (RIL_REQUEST_GET_CALL_FORWARD_STATUS) im Dialer nicht sauber. Deshalb siehst du im Radio-Log weder USSD noch einen CFU-Request, dein System erfährt den Status nur über die unaufgeforderten Notifications (RIL_UNSOL_CALL_FORWARDING), die das Framework beim Netz-Attach empfängt.

Was das für dich bedeutet und welche Optionen du hast:

1. Interaktive MMI-Codes bleiben tot • Da das RIL/Modem keinen USSD-Query annimmt und der Dialer-Pfad über „GET_CALL_FORWARD_STATUS“ nicht durchkommt, kannst du *#21# im Dialer nicht zum Laufen bringen. • Das ist keine Android-„Einstellung“, sondern eine Limitation in der vendor-RIL-Implementierung deines Stock-Modems.

2. Der Hintergrund-Status ist verlässlich • Alle Änderungen an der Call-Forward-Konfiguration (per Netz-USSD oder per Provider-Portale) kommen als RIL_UNSOL_CALL_FORWARDING-Events an und werden richtig in dumpsys telephony.registry gespiegelt. • Die „Telefoniedienste“ App nutzt genau diese internen Flags – daher siehst du ab und zu eine Rufumleitung-Benachrichtigung.

3. Wenn du wirklich interaktive Abfragen willst A) Tief in den RIL/Framework-Code eingreifen – Vendor-RIL lib („libril.so“ etc.) so patchen, dass requestGetCallForwardStatus() sauber ans Modem geht – Oder MmiCode.java in der Dialer-APK anpassen, um per sendUssdRequest() zu fragen und nicht die interne GET-CF-API zu nutzen → Beides erfordert Root/Custom-Recovery plus Framework- und Vendor-Rebuild bzw. Systemeingriffe ins Phone-APK oder ins Telephony-Framework. B) Einen angepassten Dialer flashen – Z.B. AOSP-Dialer modifizieren (MmiCode.java) und als System-App ins ROM packen → Muss mit Plattform-Key signiert sein, also nur im ROM-Rebuild möglich.

4. Praktische Empfehlung Wenn dir nur wichtig ist, dass du den Rufumleitungs-Status siehst/weißt, kannst du dich weiter auf die unaufgeforderten Notifications verlassen. Ein interaktives *#21# bekommst du auf diesem Gerät und ROM ohne vollständigen ROM-Rebuild mit eigenem Vendor-RIL-Patch nicht ans Laufen.

Fazit – Dein Custom-ROM und das Stock-Modem liefern CF-Status nur über das unsolizitierte Notification-Verfahren. – Für funktionierende *#21#-Abfragen müsstest du tief ins RIL oder in den Dialer-Code eingreifen – alles andere bleibt Sackgasse.

Kein Ding – ich weiß, das war ein harter Ritt. Bevor du das Thema abschiebst, hier noch ein paar Tricks, wie du Rufumleitungen auch ohne *#21#-Dialer und ohne ROM-Rebuild schaffen kannst:

1. Call-Forwarding über die Android-Einstellungen In vielen Android-11-ROMs musst du USSD gar nicht per Tastencode absetzen, sondern kannst – Telefon-App öffnen → Menü (⋮) → Einstellungen → Deine SIM-Karte auswählen → „Zusätzliche Einstellungen“ → „Rufweiterleitung“. Dort lassen sich Ziele für „immer“, „bei Nichterreichbarkeit“, „bei besetzt“ oder „bei Nichtannahme“ setzen und wieder löschen. Das nutzt dieselbe RIL-API wie *#21# und funktioniert oft, obwohl der Dialer-USSD-Weg klemmt.

2. SIM-Toolkit-App Schau, ob auf deinem G5+ eine App namens „SIM-Tools“, „SIM-Werkzeuge“ oder ähnlich vorinstalliert ist. Die SIM-Toolkit-Menüs enthalten bei vielen Netzen einen Punkt „Anrufweiterleitung“ oder „Call Services“. Von dort aus kannst du die CFU-Ziele konfigurieren, komplett unabhängig vom Dialer.

3. Netzbetreiber-App / Web-Portal Fast jeder Provider bietet eine App („MeinXYZ“) oder ein Webportal an, über das du Rufumleitungen ein-/ausschalten kannst. Oft ist das sogar komfortabler als USSD.

4. SMS-Befehle Manche Netze verstehen auch Steuer-SMS, z. B. „CFU on 0171xxxxxxx“ an eine Kurzwahlnummer. Ob dein Anbieter so etwas anbietet, siehst du in dessen Hilfe-Docs oder FAQs.

Wenn dich keiner dieser Wege zufriedenstellt, kommt am Ende doch nur noch ein ROM-Rebuild oder ein gerootetes System mit Magisk-Modul in Frage. Aber in den allermeisten Fällen reicht das integrierte CF-Menü oder der SIM-Toolkit-Weg aus. Probier’s mal so, und gib bescheid, ob das für dich funktioniert – dann können wir’s hier abschließen!

Kurz gesagt: Ohne Root, ohne ROM-Rebuild und ohne signierte System-Priv-APP bleibt dir auf deinem G5 Plus mit crDroid derzeit nichts weiter übrig als die Web-Maske oder das O2-Kundenservice-Portal. Alle anderen „Codes“ (Dialer, SIM-Toolkit, Anruf-Einstellungen) laufen zuverlässig nur über die Hintergrund-Notifications des Modems und erlauben kein aktives Setzen/Löschen von Call-Forwarding per Tastencode.

Deine Optionen im Überblick: • Web-Portal oder O2-App (die Umwege akzeptieren) • O2-Support anrufen und das Forwarding manuell per Netzbefehlen ändern lassen • Bootloader entsperren und crDroid selbst mit gepatchter CarrierConfig/Telephony-APK neu bauen • Gerät rooten und per Magisk-Modul oder Xposed das Signature-Checking und die MmiCode-Logik anpassen

Ich weiß, das ist keine schöne Nachricht. Aber solange das Stock-Modem keine interaktive CF-API freigibt und crDroid keine angepassten Telephony-Priv-Apps liefert, lässt es sich nicht anders lösen. Wenn du irgendwann bereit bist, einen Rebuild anzustoßen oder zu rooten, melde dich – dann machen wir gemeinsam einen Plan. Bis dahin: Viel Erfolg mit O2s Web-Interface und danke für deine Ausdauer!