[ROM][KK][KOT49E][4.4.1] OmniKang - von finnq & Schubi

Nutzt ihr OpenPDroid?


  • Umfrageteilnehmer
    137
Der_Schubi schrieb:
Nicht direkt, aber laut hellsgod liegt es daran, dass die Kiste nach dem reboot stecken bleibt.
Also bitte FSync mal aus machen, z.B. mit Trickster-Mod im "Specific"-Tab. Dann sollte zumindest der Bootloop geschichte sein.

Über den Hinweis FSYNC bin ich heute morgen auch gestoßen und habe es gleich auf verdacht mal deaktiviert. Seltsamerweise war der Schalter nach einer Kontrolle eben wieder an, aber ich hatte bisher weder ein Freez noch ein Reboot. Ich hab es wieder ausgeschaltet und hoffe mal das es weiterhin geht. *Daumen drück*
 
Der_Schubi schrieb:
Aber jetzt willst du mir erzählen, dass wenn GENAU an dem Tag, wo CM diese C-States auch alle aktiviert, ich mit einmal von etwa 8 Nutzern unseres ROMs unabhängig von Bootloops höre, UND im CM-Thread selbst auch einige darunter leiden, dass das dann nicht daran liegt?
Glaub ich dir nicht! :D :flapper:

HellsCore unterstützt kein Spielen an den Spannugen! :D
Und siehe meine längere Erklärung gerade; da es bei stock CM auch auftritt, glaube ich nicht dass es am HellsCore liegen kann.
Da hast du mich falsch verstanden, natürlich kam das Problem der Reboots mit dem Ändern der C States, aber der Kollege hat AFAIK auch mit einem Build wo du es bereits wieder gefixt hattest Reboots.

Und zu den Spannungen, klar man am Hellscore an den Spannungen rumschrauben, man sollte nur nicht zu weit runter, da ja bereits -100 mv voreingestellt sind. Es soll aber Ansicht auch Telefone geben, denen das unter Umständen bereits zu viel ist - deswegen erhöhen und kucken was passiert.
 
Ich will Schubi und Finnq und auch hellscore nicht zu Nahe treten, aber seit ihr den Kernel integriert habt (wozu eigentlich?!) gab es genug ROMs wo man das Handy komplett wipen konnte..

Ich mag ja nichtmal das letzte Update einspielen, weil über die letzten 3 Seiten irgendwas von Bootloop und C-States schreibt und ich mir kein Tool kaufen möchte, damit die ROM überhaupt funktioniert?!


Also was für einen Grund hatte die nicht Standard CM Kernel Integration eigentlich, außer das die Nightlies instabiler geworden sind? (Weil das flashen des Kernels im Zuge eines Update war ja wohl das geringste Problem)

Und kann man mit ~1GB freien Speicher überhaupt ein Nandroid Backup machen, sodass ich im Notfall wieder zurückgehen könnte?
 
Ich stell das jetzt NOCHMAL klar. Die Probleme treten auch bei stock CM mit stock CM-Kernel auf, also können wir und vor allem hellsgod, da NICHTS dafür.
Im Gegenteil, wir haben den schadhaften Commit im Gegensatz zu CM sofort wieder raus genommen.

Und nebenbei, es ist noch nie vorgekommen, dass ich hier jemanden angepflaumt habe, aber bei Dir wars gerade fast so weit...
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: mj084, thE_29, c@p und 3 andere
Deswegen habe ich ja extra geschrieben, ich will euch nicht zu Nahe treten ^^

Das Kernel wechseln Timing war halt nicht perfekt. Woher sollte ich wissen, dass CM "Blödsinn" commited und die ROM unstable wird und das genau dann, wenn ihr den Kernel wechselt..

Jedenfalls blieb die Frage vom wozu noch immer unbeantwortet. Bietet die ROM mit dem integrierten Hells irgendwelche Speed/Performance Vorteile oder kann man noch immer jeden x-beliebigen Kernel flashen?
 
Ist doch gut, wenn der IMHO beste Kernel bereits integriert ist. Und wenn dir der Hells nicht gefällt, dann flash dir halt einfach nen anderen. Die Probleme kamen und kommen nicht vom Kernel und das letzte "Problem" mit den Presettings scheint ja jetzt auch behoben. Sind halt Nighties und keine Stable, man muss ja nicht immer gleich alles flashen, vor allem wenn man ne Kombi hat die gut läuft.

Außer man macht regelmäßig Backups und geht bei Problemen eben wieder zurück. :D

1 GB frei wird für ein Nandroid eher nicht reichen, außer dein Data wäre recht klein.
 
Ich habe ja noch die Version vom 3.09. oben und die läuft eigentlich recht gut, außer das WhatsApp beim Standort schicken abstürzt.. (wenn man auf OK klickt, geht es aber trotzdem?!)
Fehlermeldung in Logcat:
V/PDroidAlternative(11471): NotificationHandler: Notification for: com.google.android.gms:locationGPS:0
W/ContextImpl( 607): Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1153 android.privacy.PrivacySetting
sManagerService.notification:129 android.privacy.IPrivacySettingsManager$Stub.onTransact:98 android.os.Binder.execTransact:388 dalvik.system.NativeStart.run:-2

E/AndroidRuntime(31212): FATAL EXCEPTION: main
E/AndroidRuntime(31212): java.lang.SecurityException: invalid package name: com.google.android.gms
E/AndroidRuntime(31212): at android.os.Parcel.readException(Parcel.java:1431)
E/AndroidRuntime(31212): at android.os.Parcel.readException(Parcel.java:1385)
E/AndroidRuntime(31212): at android.location.ILocationManager$Stub$Proxy.requestLocationUpdates(ILocationManager.java:540)
E/AndroidRuntime(31212): at android.location.LocationManager.requestLocationUpdates(LocationManager.java:836)
E/AndroidRuntime(31212): at android.location.LocationManager.requestLocationUpdates(LocationManager.java:430)
E/AndroidRuntime(31212): at android.privacy.surrogate.PrivacyLocationManager.requestLocationUpdates(PrivacyLocationManager.java:290)
E/AndroidRuntime(31212): at com.whatsapp.tjb.b(tjb.java:131)
E/AndroidRuntime(31212): at com.whatsapp.tjb.onPreExecute(tjb.java:88)
E/AndroidRuntime(31212): at android.os.AsyncTask.executeOnExecutor(AsyncTask.java:586)
E/AndroidRuntime(31212): at com.whatsapp.ke.a(ke.java:2)
E/AndroidRuntime(31212): at com.whatsapp.App.a(App.java:707)
E/AndroidRuntime(31212): at com.whatsapp.App.a(App.java:1430)
E/AndroidRuntime(31212): at com.whatsapp.q2.onClick(q2.java:6)
E/AndroidRuntime(31212): at android.view.View.performClick(View.java:4247)
E/AndroidRuntime(31212): at android.view.View$PerformClick.run(View.java:17728)
E/AndroidRuntime(31212): at android.os.Handler.handleCallback(Handler.java:730)
E/AndroidRuntime(31212): at android.os.Handler.dispatchMessage(Handler.java:92)
E/AndroidRuntime(31212): at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime(31212): at android.app.ActivityThread.main(ActivityThread.java:5295)
E/AndroidRuntime(31212): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(31212): at java.lang.reflect.Method.invoke(Method.java:525)
E/AndroidRuntime(31212): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:739)
E/AndroidRuntime(31212): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:555)
E/AndroidRuntime(31212): at dalvik.system.NativeStart.main(Native Method)
W/ActivityManager( 607): Force finishing activity com.whatsapp/.LocationPicker2
W/DropBoxManagerService( 607): Dropping: data_app_crash (1629 > 0 bytes)

Habe sogar schon alle PDroid Sachen resetted. Wegen dem würde ich halt gerne updaten, nur da ich kein Nandroid backup machen kann, weil das Teil sowenig Speicher hat, bräuchte ich natürlich ein Nightly was stabil läuft und deswegen auch meine Frage vorher..

Werde aber mal meine Fotos auf den PC archivieren und bisschen mein N4 aufräumen ;)

Da die Changelogs ja größtenteils im ROM nun sind und ich den allg. CM Thread nicht mitverfolge, wusste ich ja nicht, dass diese Probleme nix mit dem integrierten Kernel zum tun hatten. Es war halt eine Schlussfolgerung von mir, da es zeitlich zusammengepasst hätte :D
 
thE_29 schrieb:
Und kann man mit ~1GB freien Speicher überhaupt ein Nandroid Backup machen, sodass ich im Notfall wieder zurückgehen könnte?

Ich habe bei TWRP die Kompression aktiviert, jetzt haben meine Backups anstatt ca. 1 GB "nur" noch ca. 500 MB.
 
Hach, nach all den Jahren, bin ich immer noch blutiger Newbie... (aber ich arbeite dran das zu ändern - Dauer nur noch etwas;-)

Hätte mal ne Frage: Wenn das mit dem 00config init.d Skript nicht so richtig funktioniert hat und ihr jetzt die Änderungen direkt in die ramdisk integriert habt, was hat das dann für Auswirkungen auf Kernel wie z.B. Faux, die per Any-Kernel-Update.zip die Ramdisk des ROMs beibehalten??? Gelten die Seetings, sofern vom Kernel unterstützt, dann dort auch?
Grüße
m
 
Ja

Der ursprüngliche Beitrag von 19:46 Uhr wurde um 19:51 Uhr ergänzt:

Wenn dann müsstest du wieder die ramdisk bearbeiten oder kerne mit boot image verwenden oder selbst packen (z.b. mit der cm ramdisk), sofern an der ramdisk sonst nichts geändert wurde (denke nicht).
 
  • Danke
Reaktionen: millomonk
Ah, verstehe, Danke. Glaube nicht, dass es beim Wechsel von Hells zu Faux Kernel nötigt ist, aber ich glaube ich werde mit dem Thema mal etwas rumexperimentieren
 
Zum entpacken ist unmkbootimg oder unpackbootimg, zum packen mkbootimg nicht schlecht (bzw. kenn glaub ich nix anderes). Einfach mal googlen
 
thE_29 schrieb:
Ich will Schubi und Finnq und auch hellscore nicht zu Nahe treten, aber seit ihr den Kernel integriert habt (wozu eigentlich?!) gab es genug ROMs wo man das Handy komplett wipen konnte..

Ich mag ja nichtmal das letzte Update einspielen, weil über die letzten 3 Seiten irgendwas von Bootloop und C-States schreibt und ich mir kein Tool kaufen möchte, damit die ROM überhaupt funktioniert?!


Also was für einen Grund hatte die nicht Standard CM Kernel Integration eigentlich, außer das die Nightlies instabiler geworden sind? (Weil das flashen des Kernels im Zuge eines Update war ja wohl das geringste Problem)

Und kann man mit ~1GB freien Speicher überhaupt ein Nandroid Backup machen, sodass ich im Notfall wieder zurückgehen könnte?

Mein erster Gedanke beim Wechsel zu Hells Kernel war "Fett! S2W, OTG alles was ich brauch an board! Supi!" Dann die Ernüchterung mit den Reboots und dem Datenverlust und die Frage "Wieso? o.O"
ABER. Seit heute läufts! Seit ich mit Trickster Dynamisches FSYNC ausgeschaltet habe, habe ich kein Reboot mehr und kein Freez.

Der Zeitpunkt war pech, aber der Gewinn für die (oder das) ROM überwiegt!!!:thumbup:
 
Bei mir auch. Der dyn. Fsync hat mir auch übel mitgespielt.
 
thE_29 schrieb:
Jedenfalls blieb die Frage vom wozu noch immer unbeantwortet. Bietet die ROM mit dem integrierten Hells irgendwelche Speed/Performance Vorteile oder kann man noch immer jeden x-beliebigen Kernel flashen?
Bei mir und finnq hat der HellsCore einiges an Bettery-Life gebracht. Bin wirklich echt zufrieden, auch wenn ich eigentlich vor hatte nach einer Testphase wieder auf Faux zu wechseln.
thE_29 schrieb:
Ich habe ja noch die Version vom 3.09. oben und die läuft eigentlich recht gut, außer das WhatsApp beim Standort schicken abstürzt.. (wenn man auf OK klickt, geht es aber trotzdem?!)
Das promblem hat auch mj_84. Er hat auch die PDroid-Version, allerdings auf dem HTC One. Ich habe keine Ahnung worans liegt. Ob das nun PDroid, CM oder an uns liegt... Keine Ahnung!
Kann mal jemand ohne PDroid testen? Meinen Standort bekommen die nicht! :D

millomonk schrieb:
Ah, verstehe, Danke. Glaube nicht, dass es beim Wechsel von Hells zu Faux Kernel nötigt ist, aber ich glaube ich werde mit dem Thema mal etwas rumexperimentieren
Einfach zurück wechseln. Die Werte die wir setzen sind für Faux völlig OK! Und wenn ihr von Hand was in einer Kernel App einstellt, wird das ja trotzdem gesetzt. Halt nur nen tick später beim booten als die RamDisk Einstellungen.
amo66 schrieb:
Bei mir auch. Der dyn. Fsync hat mir auch übel mitgespielt.
Das deaktivieren von FSync sollte des Problem mit den Reboots eigentlich nicht beheben. es verhindert nur dass beim hot reboot Daten hops gehen.
aber wenns hilft, umso besser...

Der ursprüngliche Beitrag von 22:46 Uhr wurde um 23:03 Uhr ergänzt:

Changelog der letzten Tage:
//// new features on 13 - 16. Sept 2013 \\\\

# Re-add link to DeviceParts
# QS tiles background color
# Add option to Restart SystemUI to DevSettings
# HALO Mods
# Attempt to fix disappearing Appbar (seems to work now!)
# Fix FC in LightsOut Mode on devices without NavBar
# Fix appwidgets not updating
# Launch floating notifications from notification panel (long click)
Die HALO Mods kommen mit der heutigen Nightly!
 
  • Danke
Reaktionen: black_bottom, "S", Flextrick und eine weitere Person
Ich benutze die Version ohne PDroid. Bei mir funktioniert der Versand des Standort mit Whatsapp Plus 4.15 ohne Probleme
 
Der_Schubi schrieb:
Das deaktivieren von FSync sollte des Problem mit den Reboots eigentlich nicht beheben. es verhindert nur dass beim hot reboot Daten hops gehen.

Kann ich (leider) bestätigen. Hatte gestern Abend noch zweimal einen Freez mit anschließendem Reboot beim Podcast schauen (DailyMe TV). Aber keine Daten verloren und das System bootet wieder hoch.

Last_kmsg:
http://db.tt/O59G6FTV
 
Zuletzt bearbeitet:
Wo bleibt der Log? Sorry, aber so kann ich nichts anderes machen, als es zur Kenntnis nehmen.

Wer will dass sich daran was ändert, der muss mir den last_kmsg zukommen lassen. Sonst wird das nix.

hells
 
Zuletzt bearbeitet von einem Moderator:
c@p schrieb:
Stell mal den Kernel auf die von Hells vorgeschlagen Werte ein und schau mal ob mpdesision auch aus ist. Chrome hast du hoffentlich nicht installiert, den der macht sowas gerne.

Zur Not könnte man mit der CPU Spannung etwas hoch. Gib doch Hells mal ein LastKMS.

Hast du die Build von gestern geflasht oder wenigstens mal irgendwas von dem nachgeprüft/probiert was ich geschrieben hatte?
 
hellsgod schrieb:
Wo bleibt der Log? Sorry, aber so kann ich nichts anderes machen, als es zur Kenntnis nehmen.

Wer will dass sich daran was ändert, der muss mir den last_kmsg zukommen lassen. Sonst wird das nix.

hells

Sorry, hat etwas gedauert weil nur mit Handy unterwegs und gestern war es schon spät...

Drop Box Link:
http://db.tt/O59G6FTV
 
Zuletzt bearbeitet:

Ähnliche Themen

A
Antworten
36
Aufrufe
14.373
AraldoL
A
A
Antworten
20
Aufrufe
8.759
AraldoL
A
Volle
Antworten
0
Aufrufe
2.377
Volle
Volle
Zurück
Oben Unten