[Custom ROM] Nightly Builds CyanogenMod 7 (Android 2.3.7)

  • 7.187 Antworten
  • Letztes Antwortdatum
@ all:

Neue maniac-Nightly: https://github.com/downloads/maniac...an/cm-7-20120612-UNOFFICIAL-jordan-signed.zip



@ maniac:

Behebt den Home-Tasten-Bug wie von Dir vorhergesagt. An dieser Stelle nochmal ein dickes Danke für den wirklich tollen Support!


Hätte da aber auch noch was zum Knobeln für gewiefte Dev´s...:

Gibt es eine Möglichkeit, Telefonie- (nicht Daten-!) Roaming zuverlässig zu unterbinden?
Hintergrund: Ich wohne quasi mit einem Bein in den NL, und während ich oben im Haus gute Netzabdeckung von deutscher Seite habe, komme ich aus dem Keller regelmäßig mit T-Mobile NL wieder raus. Manuelle Netzwahl verzögert das ganze zwar, ist aber keineswegs zuverlässig.
Ich stelle mir da ein Häkchen unter "Mobilfunknetze" in den Settings vor, am besten noch mit einem Statusleisten-Toggle...

Ist das machbar, oder stehen Android-Limitationen dem im Weg?

Gruß

Christoph
 
  • Danke
Reaktionen: Unr3aL67, unregistered und smi
Also wenn ich bei mir das Netz manuell ausgewählt habe, dann bleibt das auch so. Ganz egal wie weit ich von Österreich aus nach Deutschland vordringe. Dann gibt's halt einfach keinen Empfang mehr. Bei mir hat das noch nie auf ein anderes Netz gewechselt...

Greetz, Unr3aL67
 
Gazman schrieb:
Hätte da aber auch noch was zum Knobeln für gewiefte Dev´s...:

Gibt es eine Möglichkeit, Telefonie- (nicht Daten-!) Roaming zuverlässig zu unterbinden?
...
Ist das machbar, oder stehen Android-Limitationen dem im Weg?
Also das geht, aber nicht über Android , sondern mit einem SIM-Kartenleser und einem entsprechenden Tool!

Damit kann man auf der SIM Netze in "verboten"-Listen eintragen bzw. aus den "bevorzugten" Netzen entfernen ... ganz zu Anfang der GSM-Telefonie mussten wir das im Telefonladen oft für unsere Kunden machen... damals musste man vor einem Urlaub auch erst mal die Netze dort eintragen damit man im Ausland telefonieren konnte!

gruß

PS: Natürlich kann man das auch im Handy einbauen ... also früher gab es in den ersten guten Telefonen oft entsprechende Menüpunkte zur Verwaltung solcher Netzkennzahlen auf der SIM ... aber ob der Bedarf dafür groß genug ist um das einbauen zu wollen ... ?
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: Gazman
ABBolle schrieb:
Moin!

Ich habe eigentlich ein Problem mit Talk, aber da ich nicht ausschließen kann, dass es durch CM bedingt ist, weile ich erst mal hier nachfragen...
Ich sehe zur Zeit immer mal wieder nicht, wer von meinem Kontakten online ist. Ich bin noch immer online und werde auch von anderen als online gesehen.
Hat einer ein ähnliches Problem oder eine Idee, wie ich mir helfen könnte?

Gesendet von meinem MB525 mit der Android-Hilfe.de App

morgen!

ich hab das problem auch, aber sagen wir mal unregelmäßig und nicht wirklich reproduzierbar. bei mir hängts nicht ausschließlicht mit wlan zusammen auch beim normalen mobilfunk tritt das auf.
ich weiß nur dass ich das problem mit der stock rom nicht hatte und dass es erst beim umstieg auf CM7 (stable und nix nightly) aufgetreten ist!

es ist zwar zweitweise nervig -weil nach ca 20min online sein kommen die anderen kontakte dann ohnehin online-, aber ich löse das problem dann indem ich den kontakten irgendeine msg schicke, dann werden sie sofort als online angezeigt.
 
maniac103 schrieb:
Hmm, richtig offensichtliches ist da nicht drin. Weil ich gerade den CM-Bugreport dazu gelesen habe: Kannst du, wenn das das nächste mal passiert, mal den Terminal-Emulator starten, 'netcfg', 'ifconfig' und 'ip route' aufrufen und die Ausgaben mal posten?

Hi Maniac,

heute ist es wieder mal passiert (allerdings etwas variiert: keine grauen Balken und W-lan lief, nur mobilfunktnetz wurde nicht mehr gefunden, Flugmodus an/aus hat geholfen)

Nochmal logcat und hier die Terminal-Ausgabe:
Code:
 export PATH=/data/local/bin:$PATH
$ export PATH=/data/local/bin:$PATH
$ netcfg
lo       UP    127.0.0.1       255.0.0.0       0x00000049
usb0     DOWN  0.0.0.0         0.0.0.0         0x00001002
usb1     DOWN  0.0.0.0         0.0.0.0         0x00001002
sit0     DOWN  0.0.0.0         0.0.0.0         0x00000080
ip6tnl0  DOWN  0.0.0.0         0.0.0.0         0x00000080
rmnet0   DOWN  0.0.0.0         0.0.0.0         0x00000080
rmnet1   DOWN  0.0.0.0         0.0.0.0         0x00000080
rmnet2   DOWN  0.0.0.0         0.0.0.0         0x00000080
rmnet3   DOWN  0.0.0.0         0.0.0.0         0x00000080
rmnet4   DOWN  0.0.0.0         0.0.0.0         0x00000080
psd_data10 DOWN  0.0.0.0         0.0.0.0         0x00000080
muxtest_net DOWN  0.0.0.0         0.0.0.0         0x00000080
tiwlan0  DOWN  0.0.0.0         0.0.0.0         0x00001002
$ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:934 errors:0 dropped:0 overruns:0 frame:0
          TX packets:934 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:47164 (46.0 KiB)  TX bytes:47164 (46.0 KiB)
 $ ip route
$ ip route
$
Wie gesagt, leicht veränderte Situtation, da kein Neustart nötig war und die Empfangsbalken weg waren und nicht wie sonst (da, aber grau).

1.Log: Cache vom Verbindungsproblem
2.Log: Wiederherstellen des Empfangs durch Flugmodus an/aus
 

Anhänge

  • 2012-06-13-09-17-55.txt
    552,6 KB · Aufrufe: 503
  • 2012-06-13-09-20-45.txt
    133,6 KB · Aufrufe: 397
wieselmuff schrieb:
Hi Maniac,

heute ist es wieder mal passiert (allerdings etwas variiert: keine grauen Balken und W-lan lief, nur mobilfunktnetz wurde nicht mehr gefunden, Flugmodus an/aus hat geholfen)
Ok, weggeflogen ist die Verbindung, weil die Datenverbindung ausgefallen ist:

Code:
06-13 09:01:31.046 D/GSM     (2416): Poll ServiceState done:  oldSS=[0 home o2 - de o2 - de 26207  GPRS CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false] newSS=[1 home null null null  Unknown CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false] oldGprs=0 newGprs=1 oldType=GPRS newType=unknown
06-13 09:01:31.046 D/GSM     (2416): RAT switched GPRS -> unknown at cell -1
15 Sekunden später kommt sie aber eigentlich wieder:
Code:
06-13 09:01:46.389 D/GSM     (2416): Poll ServiceState done:  oldSS=[1 home null null null  Unknown CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false] newSS=[0 home o2 - de o2 - de 26207  GPRS CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false] oldGprs=1 newGprs=1 oldType=unknown newType=GPRS
06-13 09:01:46.389 D/GSM     (2416): RAT switched unknown -> GPRS at cell 15529

Allerdings bekommt er die Daten-Verbindung nicht neu aufgebaut:
Code:
06-13 09:01:46.374 D/RILJ    (2416): [5789]< GPRS_REGISTRATION_STATE {2, null, null, 1}
06-13 09:03:23.600 D/RILJ    (2416): [5795]< GPRS_REGISTRATION_STATE {2, null, null, 1}
06-13 09:03:27.577 D/RILJ    (2416): [5800]< GPRS_REGISTRATION_STATE {3, null, null, 3}
2 heißt "Searching", 3 ist "Registration denied". Bei letzterem bleibt's dann auch. Da deine Telefonverbindung auch nicht wieder hochgekommen ist (Registration State = 13 = 'Registration denied + Emergency call possible'), bin ich mir ziemlich sicher, dass das ein Provider-Problem war, was durch Neuauthentifizierung (d.h. Neueingabe der PIN) gelöst wurde.

Wie gesagt, leicht veränderte Situtation, da kein Neustart nötig war und die Empfangsbalken weg waren und nicht wie sonst (da, aber grau).
Ok. Die Terminal-Ausgabe brauch ich nur, wenn die Balken dauerhaft grau werden.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: wieselmuff
wieselmuff schrieb:
Wie gesagt, leicht veränderte Situtation, da kein Neustart nötig war und die Empfangsbalken weg waren und nicht wie sonst (da, aber grau).

@wieselmuff: da haben wir wohl etwas aneinander vorbeigeredet. Bei mir ist das dann weiss, was soviel heisst, wie prinzipiell steht eine Verbindung, aber nicht zu den Google Servern..

Offenbar hast du ja PIN Abfrage an. Hast du mal probiert, die als Workarround auszumachen? Ich hab sie nämlich aus, und in der Form, wie du es beschreibst, hatte ich das noch nicht.
 
Ich hab das Problem auch ... mal mit grauen Balken, mal mit weißen Balken ... Hin. Dann geht NICHTS mehr ohne Neustart oder Flugmodus. Gruselig finde ich es wenn sogar der Flumodus /aus/an nichts bringt oder das DEFY sich weigert diese Umschaltung vorzunehmen ... dann geht einfach die empfangsanzeige NICHT weg und der Flugmodus reagiert NICHT ... Ausschalten dauert dann auch ewig (oder eben akku raus)

Ich vermute ja auch das dieses Problem durch O2 ausgelöst wird, aber das DEFY geht damit nicht gracefully um ... sowas sollte zu Fehlermeldungen führen, aber nicht das Gerät "tot" stellen.

gruß
 
ok, direkt nochmal passiert.
Erst normale Verbindung und mit Tapatalk ge"surft".
Dann in die Tasche gesteckt und 1 Min. später wurde kein Balken angezeigt, dann konnte ich zusehen, wie versucht wurde eine Verbindung aufzubauen: Erst das kleine x für Kein Netz, dann weiße Balken... Energiewidget 2G/3G Umschalter hat nicht mehr reagiert... dann wieder leere Balken, dann versucht in den Flugmodus zu wechseln, aber das Flugzeug kam nicht, sondern die leeren Balken wurden weiter angezeigt.
Erst ein Neustart behob das Problem.

Lieben Gruß.
 

Anhänge

  • 2012-06-13-12-35-40.txt
    530,1 KB · Aufrufe: 403
  • 2012-06-13-12-36-54.txt
    92,1 KB · Aufrufe: 199
  • Danke
Reaktionen: bitboy0
wieselmuff schrieb:
ok, direkt nochmal passiert.
Erst normale Verbindung und mit Tapatalk ge"surft".
Dann in die Tasche gesteckt und 1 Min. später wurde kein Balken angezeigt, dann konnte ich zusehen, wie versucht wurde eine Verbindung aufzubauen: Erst das kleine x für Kein Netz, dann weiße Balken... Energiewidget 2G/3G Umschalter hat nicht mehr reagiert... dann wieder leere Balken, dann versucht in den Flugmodus zu wechseln, aber das Flugzeug kam nicht, sondern die leeren Balken wurden weiter angezeigt.
Erst ein Neustart behob das Problem.

Lieben Gruß.

Ja, da ist ganz offensichtlich der Moto-RIL-Stack gestorben:

Code:
06-13 12:38:34.522 D/RILJ    ( 2416): [7027]< RADIO_POWER error: com.android.internal.telephony.CommandException: GENERIC_FAILURE
RADIO_POWER ist der RIL-Call, der für den Flugmodus verwendet wird, und der Moto-RIL-Stack hat auf diese Anforderung sinngemäß 'Geht nicht, da ist irgendein Fehler passiert' geantwortet. Das Framework probiert's noch ein paar mal, bekommt aber immer die selbe Antwort.
Man sieht, dass das Ganze seinen Anfang genommen hat, als (aus unklaren Gründen) die Datenverbindung gestorben ist:
Code:
# RIL sagt Bescheid, dass sich an den Datenverbindungen etwas geändert hat (wahrscheinlich active: 1 -> 0
06-13 12:34:24.960 D/RILJ    (2416): [UNSL]< UNSOL_DATA_CALL_LIST_CHANGED [DataCallState: { cid: 1, active: 0, type: IP, apn: internet, address: 10.65.115.16 }]
# Framework fragt sicherheitshalber nochmal zur Bestätigung nach
06-13 12:34:24.960 D/RILJ    (2416): [6923]> DATA_CALL_LIST
# RIL antwortet mit: Ja, es sind keine Datenverbindungen da
06-13 12:34:24.967 D/RILJ    (2416): [6923]< DATA_CALL_LIST []
# Framework sagt: Ok, ich melde mal meine alte Verbindung ab
06-13 12:34:24.967 D/RILJ    (2416): [6924]> DEACTIVATE_DATA_CALL 1
# Antwort: 'Irgendein Fehler'
06-13 12:34:24.975 D/RILJ    (2416): [6924]< DEACTIVATE_DATA_CALL error: com.android.internal.telephony.CommandException: GENERIC_FAILURE
Leider gibt der RIL-Stack keine Debug-Ausgaben, was genau kaputt ist; und zu versuchen, bei solchen Fehlern in die Binary-Blobs reinzudebuggen, halte ich für praktisch aussichtslos.

EDIT: Du kannst ja spaßenshalber mal 'ro.sys.atvc_allow_gki_log=1' in build.prop setzen und bei Wiederauftreten ein neues Logcat posten. Dieser Wert aktiviert zusätzliche Debug-Ausgaben im RIL-Stack. Wenn das nix offensichtliches ergibt, sehe ich wirklich schwarz.

EDIT2: Ich lade nachher mal noch ein Build hoch, was das oben gezeigte Szenario abfängt. Ich bin mir nicht sicher, ob das was hilft (ich kenne ja das eigentliche Problem nicht), probier's aber bitte trotzdem mal ;) Setze aber trotzdem mal die erwähnte Property, und wenn wieder etwas auftritt, wieder Logcat posten.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: bitboy0 und wieselmuff
bitboy0 schrieb:
Also das geht, aber nicht über Android , sondern mit einem SIM-Kartenleser und einem entsprechenden Tool!

Damit kann man auf der SIM Netze in "verboten"-Listen eintragen bzw. aus den "bevorzugten" Netzen entfernen ... ganz zu Anfang der GSM-Telefonie mussten wir das im Telefonladen oft für unsere Kunden machen... damals musste man vor einem Urlaub auch erst mal die Netze dort eintragen damit man im Ausland telefonieren konnte!

Ich bräuchte das allerdings schaltbar, das schließt eine SIM-Kartenprogrammierung wohl aus.

PS: Natürlich kann man das auch im Handy einbauen ... also früher gab es in den ersten guten Telefonen oft entsprechende Menüpunkte zur Verwaltung solcher Netzkennzahlen auf der SIM ... aber ob der Bedarf dafür groß genug ist um das einbauen zu wollen ... ?
Den Bedarf versuche ich doch gerade zu wecken...:D oder den Programmiertrieb unsere Dev´s...

Gruß

Christoph
 
maniac103 schrieb:
Code:
# RIL antwortet mit: Ja, es sind keine Datenverbindungen da
06-13 12:34:24.967 D/RILJ    (2416): [6923]< DATA_CALL_LIST []
# Framework sagt: Ok, ich melde mal meine alte Verbindung ab
06-13 12:34:24.967 D/RILJ    (2416): [6924]> DEACTIVATE_DATA_CALL 1
Ich bin zwar in der Materie null drin, aber wenn der Prozess sich bei dem Request aufhängt, bzw. nicht mehr funktioniert, könnte man den dann nicht unterbinden, denn was soll schließlich dabei rauskommen, wenn man eine Verbindung deaktivieren will, die nicht existiert?
 
Krasskat schrieb:
Ich bin zwar in der Materie null drin, aber wenn der Prozess sich bei dem Request aufhängt, bzw. nicht mehr funktioniert, könnte man den dann nicht unterbinden, denn was soll schließlich dabei rauskommen, wenn man eine Verbindung deaktivieren will, die nicht existiert?

maniac103 schrieb:
EDIT2: Ich lade nachher mal noch ein Build hoch, was das oben gezeigte Szenario abfängt. Ich bin mir nicht sicher, ob das was hilft (ich kenne ja das eigentliche Problem nicht), probier's aber bitte trotzdem mal ;) Setze aber trotzdem mal die erwähnte Property, und wenn wieder etwas auftritt, wieder Logcat posten.

Siehe oben ;)
 
  • Danke
Reaktionen: phynix5800
maniac103 schrieb:
EDIT: Du kannst ja spaßenshalber mal 'ro.sys.atvc_allow_gki_log=1' in build.prop setzen und bei Wiederauftreten ein neues Logcat posten. Dieser Wert aktiviert zusätzliche Debug-Ausgaben im RIL-Stack. Wenn das nix offensichtliches ergibt, sehe ich wirklich schwarz.
Done! Jetzt heißt es warten, bis der Fehler wieder auftaucht (schade dass der sich nicht triggern lässt). Wenn sich der Bug nicht beheben lässt, sehe ich für mich fast keine andere Möglichkeit mehr, als zu ner anderen ROM wie ms2ginger zu wechseln, so ungerne ich das auch machen würde. Walter hat schon bestätigt, dass dort solche Probleme nicht auftauchen. :(
EDIT2: Ich lade nachher mal noch ein Build hoch, was das oben gezeigte Szenario abfängt. Ich bin mir nicht sicher, ob das was hilft (ich kenne ja das eigentliche Problem nicht), probier's aber bitte trotzdem mal ;) Setze aber trotzdem mal die erwähnte Property, und wenn wieder etwas auftritt, wieder Logcat posten.
Werde natürlich sofort den Build installieren (aber nicht während des Fußballspiels) und sobald ich was neues hab, berichte ich auf jeden Fall.
Scheiß O2 (ich denke die sind irgendwie schuld daran).
Vielen Dank für die Mühe! Ich würde so gerne mehr beitragen.

Der ursprüngliche Beitrag von 17:19 Uhr wurde um 17:26 Uhr ergänzt:

Mein Feedback zum battery drop Problem:

Die alte battd hat nix gebracht!
 
wieselmuff schrieb:
Scheiß O2 (ich denke die sind irgendwie schuld daran).
Ja, das vermute ich auch! DAS hab ich BISHER auch nur von Leuten gehört die O2 haben! Wenn es andere auch betrifft BITTE MAL MELDEN!

gruß
 
Also ich hatte es defintiv auch schon aber ganz selten (also Empfangsbalken da aber grau, war nicht erreichbar & konnte nicht telefonieren), bin bei blau/eplus.
 
erzu schrieb:
morgen!

ich hab das problem auch, aber sagen wir mal unregelmäßig und nicht wirklich reproduzierbar. bei mir hängts nicht ausschließlicht mit wlan zusammen auch beim normalen mobilfunk tritt das auf.
ich weiß nur dass ich das problem mit der stock rom nicht hatte und dass es erst beim umstieg auf CM7 (stable und nix nightly) aufgetreten ist!

es ist zwar zweitweise nervig -weil nach ca 20min online sein kommen die anderen kontakte dann ohnehin online-, aber ich löse das problem dann indem ich den kontakten irgendeine msg schicke, dann werden sie sofort als online angezeigt.

Hast du evtl einen alternativen Lockscreen aktiviert? Ich habe bis gestern Widgetlocker genutzt, diesen aber nun mal testweise runtergeworfen... anscheinend hat sich damit die Situation bei mir gebessert.
Bin beim googlen darüber gestolpert, dass irgendwo anders mal der GoLocker für ein solches Problem verantwortlich gemacht wurde.

Allerdings verstehe ich den Zusammenhang zwischen Lockscreen und Talk nicht.
 
Nein, hab keinen alternativen locker, nachdem maniac nach einigem hin u her den eingebauten zum laufen gebracht hat! :)
Das einzige was ich in der richtung hab is "screen off".
 
Hallo Maniac103
seit der letzten nightly vom13.06. gibt es bei mit probleme mit der Cam.
Sie geht von Hoch auf quer und bleibt auf quer.Der Bildschirn läßt sich nicht meht auf hoch umstellen nur ausstellen und neu hochfahren hilft.
Habe die nightlyvom 12.06. draufgemacht da ist das nicht mehr.
Vielleicht ist in der neuen nightly ein fehler? Wollte Dich nur Informieren.
Gruß Armin
 

Ähnliche Themen

R
Antworten
110
Aufrufe
44.073
Julsen
J
P
Antworten
2
Aufrufe
4.089
pseudodeed
P
Android94
Antworten
745
Aufrufe
163.261
armalyte
A
Zurück
Oben Unten