O
onurbi
Neues Mitglied
- 2
Hi,
nach einer Menge von Versuchen will ich hier mal meine Erfahrungen hier Euch teilen. Aber vorsicht, der Text ist "etwas" länger geworden!
Der aktuelle Stand: Mein ALE-21 ist jetzt gebrickt und schon beim Service (bin gespannt, wieviel es kostet...). Der Weg dahin war zwar auch sehr interessant, aber steinig!
Begonnen hat es mit dem Thema Stromverbrauch. Das P8Lite hat ja nur einen 2200mAh Akku. Gerade dann ist es wichtig, Saft zu sparen. Teilweise war der Akku nach Aufladen von 8:00 Uhr am Abend schon auf 40% unten. Also mußte das Teil da schon wieder an den Charger. Mein Ziel war aber, nur alle 2 Tage oder besser sogar 3 Tage. Mein altes Xperia Mk16i hatte sogar 4 Tage gehalten. Alles ohne Aktivität, zum Testen natürlich.
Das echt superige Tool 3C Toolbox hat immer wieder, aber sehr unregelmäßig, einen Service namens SUPL20SERVICES aufgezeigt, der den Akku um ca 4%/h leersaugte. Es gibt aber kaum Info für was dieser Service zuständig ist. Meine Vermutung geht inzwischen in Richtung GPS und Bluetoth.
Bin dann auf Greenify gestoßen. Gut, dann hatte ich endlich einen Grund zu Rooten. Das war auch kein Problem, nachdem ich von der chinesischen Huaweiseite den Entsperrcode abfragen konnte.
Greenify hat aber nicht den Durchbruch geschafft, da ich eh schon alle Googledienste deaktiviert hatte. Das bischen Hangouts wakeup hat sich nicht als DER Akkuentleerer herausgestellt. Das Xposed Framework wollte ich noch nicht installieren. Bluetooth abhängig vom WLAN-Zustand abschalten hat es dann erst gebracht.
Naja, mit einem gerooteten Handy kann man ja schließlich noch mehr anstellen. Besonders Nandroid Backup macht ja wirklich großen Sinn. Natürlich auf eine externe SD-Karte. Anscheinend ist ja seit Android 4.4 bekannt (mir war das neu): Man braucht besonderen Aufwand, um auf diese Speicherkarte schreiben zu können. Ab Lollipop soll angeblich eine Abfrage beim ersten Zugriff erscheinen, ob der R/W Zugrifff freigeschaltet werden soll. Bei mir kam der aber nicht oder ich habe ihn unterbewußt abgenickt und wieder vergessen, dass er doch da war.
Der Nandroid-online Backup lief ca. 40 Minuten ohne Fehlermeldung. Gut, dachte ich. Zum Verifizieren hätte es den Nandroid Manager gebraucht. Wollte ich erst mal kein Geld ausgeben, ich hatte ja noch keine Risikoanwendung wo ich mit einem Restorebedarf gerechnet hätte. Eigentlich wäre er für das Xposed Framework gedacht gewesen. Da hätte ich mich dann mit dem Backupformat beschäftigt. Wie ich jetzt weiß Ist es ein ganz normales tar.gz File, nur mit win als Extension, das ich dann unter einem Linux probeentpackt hätte.
Nächster Schritt: TWRP kann ja angeblich einen Nandroid Backup restoren. Habe nur gutes darüber gelesen, also mal ausführlich spielen damit. Ein Probelauf (da gibt es einen Simulationshaken, wo nicht wirklich was geschrieben wird) lief auch durch. Bestens gerüstet. Dachte ich...
Titanium Backup als zweites Standbein schadet ja auch nicht. Doch da war kein Weg frei, die externe SD-Karte als Ziel zu konfigurieren, obwohl Nadroid es doch gerade konnte. Der Dialog an der Stelle ist da auch etwas unklar, finde ich. Schließlich habe ich gemerkt, dass auch andere Programme die Speicherkarte plötzlich nicht mehr beschreiben können.
Hier habe ich den esten Fehler gemacht: Mir hätte auffalen müssen, dass Nandroid-Backup vorher es ja auch geschafft hatte. Woher kam dann diese plötzliche Verweigerung? Ich vermute, dass die Speicherkarte entweder einen Hau hat (am PC mit chkdsk /f /r ist aber nichts festzustellen) oder da schon einen Filesystemfehler hatte, den Android gemerkt hat und dann den R/W Zugriff verweigerte.
Beim Googlen bin ich dann vom logischen Kurs abgekommen und darauf gestoßen, dass Android SD-Karten erst mal R/O mounted und das Problem mit einer Zusatzzeile in /system/etc/permissions/platform.xml zu lösen ist. Naja, das ist ja kein Problem, mache ich jeden Tag, also mal los...
Fehler #2: Ich vergaß nach /system RW mounten und dem Editieren die Permissions von platform.xml auf 644 zu setzen. Da der vi auf der adb-shell eher nicht zuverläßig zu gebrauchen ist, habe ich das File unter Windows mit LF als Zeilenende mit der Zusatzzeile versehen und mit abd push wieder zurückkopiert.
Nach dem Booten von Android war dann das Permissionsystem nachaltig gestört:
- Die Interne SD-Karte war nicht mal mehr lesbar,
- es gab bei Titantium Backup die Dauermeldung "Anwendungsdaten werden gelesen" und
- IP-Sockets lieferten "Permission denied".
Na toll, also die Originalversion des Files platform.xml wieder zurück kopieren. Davon hatte ich im selben Directory eine Kopie gemacht.
Zwecklos, der Fehler blieb. Beim Booten scheint Android systemweit die Permissions nach Vorgabe in diesem File an vielen Stellen zu setzen. Wenn das wegen des fehlenden chmod 644 nicht richtig durchgeführt werden kann, ist wohl das Filesystem versaut vermute ich.
Also blieb als next Step nur der Bare Metal Restore. Den Nandroid Backup habe ich ja...
Also rein ins TWRP (vorher USB-Stecker aus nicht vergessen!) und den Restore gestartet. Zu früh gefreut: Er brach ab: "Unable to extract tar archive" bei system.ext4.win. Das File hat sich dann unter linux tatsächlich als kaputt an der selben Stelle erwiesen.
Nächster Schritt: Auch nochmal manuellen Backup der /data-Partition in der adb-Shell per tar auf die SD-Karte. Das sind ca. 2.3GB
Ihr glaubt es nicht: Nach ca. 10 Minuten hat das Handy gebootet und der Backup brach natürlich ab. Das Spielchen habe ich nach dem 4. Mal genervt abgebrochen. Dabei ist da Filesystem der SD-Karte sicher nicht besser geworden... Aber ich habe nicht drangedacht, es mal zu checken. Mit efsk wäre es vermutlich nicht gegangen und dauernd raus aus dem Handy, rein in den PC war wahrscheinlich eine unterbewußte Bremse.
Dann eben Original Huawei Restore von deren Downloadseite auf Stock ROM (B130) unter Verzicht auf die Konfigurations- und sonstigen Daten: Von der Huawei Seite das ZIP gesaugt, entpackt und das UPDATE.APP in das Directory dload auf der SD-Karte kopiert. WIN10 sagte beim Einlegen nicht, dass die Karte repariert werden hätte müssen. Sagt es sehr oft bei Sticks und findet dann doch nichts. Ich kam eben auch nicht auf die Idee es vorsichtshalber trotzdem mal zu probieren.
Karte aber auf jeden Fall sicher aus WIN10 ausgeworfen und zurück ins Handy. Dann Vol+/Vol- und Powertaste gedrückt und die Vol's erst losgelassen, als das EMUI-Logo erschien. Das war schon eine Forschungsarbeit herauszufinden, dass man die beiden Tasten gedrückthalten muß! Beim Bootlaoder und TWRP kann sie schon zusammen mit der Power loslassen. Im PDF von Huawei, das beim Downlaod-zip dabei ist, steht das nämlich nicht. Das USB-Kabel war dabei nicht angesteckt (soll auch nicht). Der Installationsvorgang fing dann auch mit Hochzählen an. Ich lehnte mich schon beruhigt zurück. Bei ca. 10% brach er dann mit einer allgemeinen Fehlermeldung ab. SUPER!
Nächster Schritt: UPDATE.APP mit dem HuaweiUpdateextractor zerlegen und die System-Partition per fastboot schreiben. Vergiss es! Jetzt war der Bootloader nicht mehr aufrufbar! Grrr! Aber TWRP war ja noch drauf. Damit gelang es mir dann, über das im Extractor gebildete 06.boot.zip den Bootloader wiederherzustellen. Der Bootloader war dann wieder aufzurufen. "fastboot flash -S 512M system system.img" lief dann zwar länger ohne Fehler durch, half aber nichts. Bei einem Android Bootversuch, kam jetzt plötzlich eine graphische Fehlermeldung mit einem Androidmännchen und dem Text: Function NO: 18(panic) ELR: 0x00000... Das wird immer toller!
Sogar der Recovermodus von vorhin (Vol+/Vol-, Power) war nicht mehr aufzurufen. Dann viel gelesen und gelesen und mich schließlich entschieden, auch das Recovery TWRP wieder durch das Original zu ersetzen. Mir schwante dann schon, dass das ein Risiko ist. Das was dann tatsächlich das Aus. Die cryptische Fehlermeldung kam nun bei allen Tastenkombinationen. Einzig die Vol-, Power MIT USB-Kabel am PC brachte mir das EMUI-Recovery. Das bekam ich seltsamerweise aber auch vorher zu TWRP-Zeiten schon, wenn der USB-Stecker drin war. Ich dachte dann schon, wo ist jetzt der TWRP hin? Ohne Stecker startete TWRP aber. Das muß also Bestandteil eines echten ROMs sein.
Dieses EMUI-Recovery bietet aber nur den Download über WLAN an. Der aber funktionierte schon vorher nicht (Information not found). Jetzt kam aber noch dazu, dass er kein WLAN mehr fand. Mir kam es so vor, als wäre wirklich alles gelöscht worden, was sich in irgendeinem einer beschreibbaren Partition befand, auch die Konfiguration der internen WLAN-Karte.
Dass das interne Recovery per dload nicht lief, hat vielleicht mit der SD-Karte zu tun, und es hätte vielleicht gereicht, das Filesystem wieder zu reparieren, aber wie konnte der Bootloader nach einer offiziell beschriebenen Huaweiaktion verschwinden oder mit falschen Daten überschrieben worden sein?
Vielleicht hilft mein Bericht ein wenig, bei Androidmanipluationen seeeeehr viel sorgfältiger vorzugehen als ich. Denn es kann dabei viel kaputt gehen, was man nicht unbedingt nachvollziehen kann!
Gruß, Onurbi
nach einer Menge von Versuchen will ich hier mal meine Erfahrungen hier Euch teilen. Aber vorsicht, der Text ist "etwas" länger geworden!
Der aktuelle Stand: Mein ALE-21 ist jetzt gebrickt und schon beim Service (bin gespannt, wieviel es kostet...). Der Weg dahin war zwar auch sehr interessant, aber steinig!
Begonnen hat es mit dem Thema Stromverbrauch. Das P8Lite hat ja nur einen 2200mAh Akku. Gerade dann ist es wichtig, Saft zu sparen. Teilweise war der Akku nach Aufladen von 8:00 Uhr am Abend schon auf 40% unten. Also mußte das Teil da schon wieder an den Charger. Mein Ziel war aber, nur alle 2 Tage oder besser sogar 3 Tage. Mein altes Xperia Mk16i hatte sogar 4 Tage gehalten. Alles ohne Aktivität, zum Testen natürlich.
Das echt superige Tool 3C Toolbox hat immer wieder, aber sehr unregelmäßig, einen Service namens SUPL20SERVICES aufgezeigt, der den Akku um ca 4%/h leersaugte. Es gibt aber kaum Info für was dieser Service zuständig ist. Meine Vermutung geht inzwischen in Richtung GPS und Bluetoth.
Bin dann auf Greenify gestoßen. Gut, dann hatte ich endlich einen Grund zu Rooten. Das war auch kein Problem, nachdem ich von der chinesischen Huaweiseite den Entsperrcode abfragen konnte.
Greenify hat aber nicht den Durchbruch geschafft, da ich eh schon alle Googledienste deaktiviert hatte. Das bischen Hangouts wakeup hat sich nicht als DER Akkuentleerer herausgestellt. Das Xposed Framework wollte ich noch nicht installieren. Bluetooth abhängig vom WLAN-Zustand abschalten hat es dann erst gebracht.
Naja, mit einem gerooteten Handy kann man ja schließlich noch mehr anstellen. Besonders Nandroid Backup macht ja wirklich großen Sinn. Natürlich auf eine externe SD-Karte. Anscheinend ist ja seit Android 4.4 bekannt (mir war das neu): Man braucht besonderen Aufwand, um auf diese Speicherkarte schreiben zu können. Ab Lollipop soll angeblich eine Abfrage beim ersten Zugriff erscheinen, ob der R/W Zugrifff freigeschaltet werden soll. Bei mir kam der aber nicht oder ich habe ihn unterbewußt abgenickt und wieder vergessen, dass er doch da war.
Der Nandroid-online Backup lief ca. 40 Minuten ohne Fehlermeldung. Gut, dachte ich. Zum Verifizieren hätte es den Nandroid Manager gebraucht. Wollte ich erst mal kein Geld ausgeben, ich hatte ja noch keine Risikoanwendung wo ich mit einem Restorebedarf gerechnet hätte. Eigentlich wäre er für das Xposed Framework gedacht gewesen. Da hätte ich mich dann mit dem Backupformat beschäftigt. Wie ich jetzt weiß Ist es ein ganz normales tar.gz File, nur mit win als Extension, das ich dann unter einem Linux probeentpackt hätte.
Nächster Schritt: TWRP kann ja angeblich einen Nandroid Backup restoren. Habe nur gutes darüber gelesen, also mal ausführlich spielen damit. Ein Probelauf (da gibt es einen Simulationshaken, wo nicht wirklich was geschrieben wird) lief auch durch. Bestens gerüstet. Dachte ich...
Titanium Backup als zweites Standbein schadet ja auch nicht. Doch da war kein Weg frei, die externe SD-Karte als Ziel zu konfigurieren, obwohl Nadroid es doch gerade konnte. Der Dialog an der Stelle ist da auch etwas unklar, finde ich. Schließlich habe ich gemerkt, dass auch andere Programme die Speicherkarte plötzlich nicht mehr beschreiben können.
Hier habe ich den esten Fehler gemacht: Mir hätte auffalen müssen, dass Nandroid-Backup vorher es ja auch geschafft hatte. Woher kam dann diese plötzliche Verweigerung? Ich vermute, dass die Speicherkarte entweder einen Hau hat (am PC mit chkdsk /f /r ist aber nichts festzustellen) oder da schon einen Filesystemfehler hatte, den Android gemerkt hat und dann den R/W Zugriff verweigerte.
Beim Googlen bin ich dann vom logischen Kurs abgekommen und darauf gestoßen, dass Android SD-Karten erst mal R/O mounted und das Problem mit einer Zusatzzeile in /system/etc/permissions/platform.xml zu lösen ist. Naja, das ist ja kein Problem, mache ich jeden Tag, also mal los...
Fehler #2: Ich vergaß nach /system RW mounten und dem Editieren die Permissions von platform.xml auf 644 zu setzen. Da der vi auf der adb-shell eher nicht zuverläßig zu gebrauchen ist, habe ich das File unter Windows mit LF als Zeilenende mit der Zusatzzeile versehen und mit abd push wieder zurückkopiert.
Nach dem Booten von Android war dann das Permissionsystem nachaltig gestört:
- Die Interne SD-Karte war nicht mal mehr lesbar,
- es gab bei Titantium Backup die Dauermeldung "Anwendungsdaten werden gelesen" und
- IP-Sockets lieferten "Permission denied".
Na toll, also die Originalversion des Files platform.xml wieder zurück kopieren. Davon hatte ich im selben Directory eine Kopie gemacht.
Zwecklos, der Fehler blieb. Beim Booten scheint Android systemweit die Permissions nach Vorgabe in diesem File an vielen Stellen zu setzen. Wenn das wegen des fehlenden chmod 644 nicht richtig durchgeführt werden kann, ist wohl das Filesystem versaut vermute ich.
Also blieb als next Step nur der Bare Metal Restore. Den Nandroid Backup habe ich ja...
Also rein ins TWRP (vorher USB-Stecker aus nicht vergessen!) und den Restore gestartet. Zu früh gefreut: Er brach ab: "Unable to extract tar archive" bei system.ext4.win. Das File hat sich dann unter linux tatsächlich als kaputt an der selben Stelle erwiesen.
Nächster Schritt: Auch nochmal manuellen Backup der /data-Partition in der adb-Shell per tar auf die SD-Karte. Das sind ca. 2.3GB
Ihr glaubt es nicht: Nach ca. 10 Minuten hat das Handy gebootet und der Backup brach natürlich ab. Das Spielchen habe ich nach dem 4. Mal genervt abgebrochen. Dabei ist da Filesystem der SD-Karte sicher nicht besser geworden... Aber ich habe nicht drangedacht, es mal zu checken. Mit efsk wäre es vermutlich nicht gegangen und dauernd raus aus dem Handy, rein in den PC war wahrscheinlich eine unterbewußte Bremse.
Dann eben Original Huawei Restore von deren Downloadseite auf Stock ROM (B130) unter Verzicht auf die Konfigurations- und sonstigen Daten: Von der Huawei Seite das ZIP gesaugt, entpackt und das UPDATE.APP in das Directory dload auf der SD-Karte kopiert. WIN10 sagte beim Einlegen nicht, dass die Karte repariert werden hätte müssen. Sagt es sehr oft bei Sticks und findet dann doch nichts. Ich kam eben auch nicht auf die Idee es vorsichtshalber trotzdem mal zu probieren.
Karte aber auf jeden Fall sicher aus WIN10 ausgeworfen und zurück ins Handy. Dann Vol+/Vol- und Powertaste gedrückt und die Vol's erst losgelassen, als das EMUI-Logo erschien. Das war schon eine Forschungsarbeit herauszufinden, dass man die beiden Tasten gedrückthalten muß! Beim Bootlaoder und TWRP kann sie schon zusammen mit der Power loslassen. Im PDF von Huawei, das beim Downlaod-zip dabei ist, steht das nämlich nicht. Das USB-Kabel war dabei nicht angesteckt (soll auch nicht). Der Installationsvorgang fing dann auch mit Hochzählen an. Ich lehnte mich schon beruhigt zurück. Bei ca. 10% brach er dann mit einer allgemeinen Fehlermeldung ab. SUPER!
Nächster Schritt: UPDATE.APP mit dem HuaweiUpdateextractor zerlegen und die System-Partition per fastboot schreiben. Vergiss es! Jetzt war der Bootloader nicht mehr aufrufbar! Grrr! Aber TWRP war ja noch drauf. Damit gelang es mir dann, über das im Extractor gebildete 06.boot.zip den Bootloader wiederherzustellen. Der Bootloader war dann wieder aufzurufen. "fastboot flash -S 512M system system.img" lief dann zwar länger ohne Fehler durch, half aber nichts. Bei einem Android Bootversuch, kam jetzt plötzlich eine graphische Fehlermeldung mit einem Androidmännchen und dem Text: Function NO: 18(panic) ELR: 0x00000... Das wird immer toller!
Sogar der Recovermodus von vorhin (Vol+/Vol-, Power) war nicht mehr aufzurufen. Dann viel gelesen und gelesen und mich schließlich entschieden, auch das Recovery TWRP wieder durch das Original zu ersetzen. Mir schwante dann schon, dass das ein Risiko ist. Das was dann tatsächlich das Aus. Die cryptische Fehlermeldung kam nun bei allen Tastenkombinationen. Einzig die Vol-, Power MIT USB-Kabel am PC brachte mir das EMUI-Recovery. Das bekam ich seltsamerweise aber auch vorher zu TWRP-Zeiten schon, wenn der USB-Stecker drin war. Ich dachte dann schon, wo ist jetzt der TWRP hin? Ohne Stecker startete TWRP aber. Das muß also Bestandteil eines echten ROMs sein.
Dieses EMUI-Recovery bietet aber nur den Download über WLAN an. Der aber funktionierte schon vorher nicht (Information not found). Jetzt kam aber noch dazu, dass er kein WLAN mehr fand. Mir kam es so vor, als wäre wirklich alles gelöscht worden, was sich in irgendeinem einer beschreibbaren Partition befand, auch die Konfiguration der internen WLAN-Karte.
Dass das interne Recovery per dload nicht lief, hat vielleicht mit der SD-Karte zu tun, und es hätte vielleicht gereicht, das Filesystem wieder zu reparieren, aber wie konnte der Bootloader nach einer offiziell beschriebenen Huaweiaktion verschwinden oder mit falschen Daten überschrieben worden sein?
Vielleicht hilft mein Bericht ein wenig, bei Androidmanipluationen seeeeehr viel sorgfältiger vorzugehen als ich. Denn es kann dabei viel kaputt gehen, was man nicht unbedingt nachvollziehen kann!
Gruß, Onurbi
Zuletzt bearbeitet:
