android-systemeinstellungen-nach-rom-update

Android: Systemeinstellungen nach ROM-Update

Android, Android, Android… ja, seit geraumer Zeit bin auch ich vom Android-Virus infiziert. Nachdem mein Nokia E65 nach knapp 20 meter Schwimmunterricht den Geist aufgab und nach einer drei wöchigen Wiederbelebungsphase mit einigen Macken wieder das Licht der Welt erblickte, musste ein neues Smartphone her. Meine damaligen Favoriten waren ein Nokia N97 mit Symbian und das Nokia N900 mit Maemo als OS.

Ein iPhone wäre im Bezug auf die verbaute Hardware sicherlich auch sehr interessant, jedoch sträuben sich mir die Nackenhaare vor dem iOS und der Apple’schen Softwarepolitik. Ein Windows Phone vielleicht? NEIN, NEIN und nochmals NEIN, auf keinen Fall … als bekennenden Micr**oft Gegner käme ein Windows Phone nicht einmal als Alternative in die Hosentasche.

Also, zurück zu Nokia und open-Source … ähämm. Warum auch immer, diese zwei Begriffe erzeugen keinesfalls wohligen Klang in meinen Ohren.

Quelloffen, super … Maemo als OS, nun ja. Und zu guter letzt ist das Gerät auf dem Maemo läuft physisch eher mit einem Ziegelstein als mit einem modernen Smartphone, zu vergleichen. Doch eines Tages wurde mein Interesse zufällig auf das Android OS gelenkt, dieses freie Betriebssystem wird von der Open Handset Alliance betreut, namhafte Mitglieder entwickeln und unterstützen die Plattform.

1. Nokia adieu

HTC Desire

Die Ära Nokia und somit die von Symbian ist für mich Geschichte, das neue Zeitalter von HTC und Android hält seitdem Einzug. Der iPhone Pendant nennt sich ganz schlicht Desire

Spitzname: Deh-si-reh (Papa sei Dank).

Nach mehreren Wochen intensivsten Trainings auf dem Touchscreen und dem professionellen Entladen des Akkus war ich fast vollständig überzeugt. Jedoch kristallisierte sich heraus, dass das original HTC-Rom runter und ein neues, besseres rauf muss. Was hab ich geschwitzt … zwischenzeitlich dachte ich sogar, dass ich mein (gerade erst sehr lieb gewonnenes) Deh-si-reh gebrickt habe.

Vieles fand sich im WWW, sehr hilfreich war und ist die Webseite von Tobias Graupner alias BrainMcFlywww.brutzelstube.de. Interessant erschien mir hier das DeFrost-ROM, mittlerweile Ginger-Villain was auch der Anlass für diesen Beitrag ist.

Was bedeutet gebrickt? Ein Gerät gilt meist dann als gebrickt, wenn es nicht mehr funktioniert und man selbst nicht in der Lage ist ihm wieder Leben einzuhauchen. Man gelangt weder in den Recovery Modus noch lässt sich das Phone mit der mitgelieferten Software in den Werkszustand zurücksetzen. Im Begriff gebrickt steck das englische Wort brick, somit hat das betroffene Gerät die Funktionalität eines Backsteins. Oft ist die Herstellergarantie bereits durch den Versuch, das original Rom zu ersetzen, futsch.

2. Die Katastrophe

Während das Update von DeFrost-Rom zu DeFrost-Rom durch das eingebaute Setup sehr unproblematisch und bis zum Schluss ohne Wipe vonstatten lief, war der Wechsel zu Ginger-Villain erstmal eine persönliche Katastrophe. Wo sind denn meine SMS und wo meine WLAN-Zugangspunkte hin?

Zum Glück existieren Backups, so hatte ich mit Titanium-Backup eine Sicherung erstellt, indem die SMS und die WLAN-Zugangspunkte NICHT mitgesichert werden. Ein Nandroid-Backup hatte ich ebenfalls erstellt und auf dem PC gesichert, hier wird im gegensatz ein komplettes Abbild der System Partitionen gezogen. Mit unyaffs lassen sich die Images recht einfach entpacken.

3. Die Wiederherstellung einzelner Bereiche

Ich nutze Ubuntu, somit ist die nachfolgende Anleitung auch nur auf diese Linux-Distribution bezogen.

1. Download und Installation von unyaffs, entweder manuell oder via svn…

tamas@tamas-desktop:~$ svn checkout http://unyaffs.googlecode.com/svn/trunk/ unyaffs
tamas@tamas-desktop:~$ cd unyaffs
tamas@tamas-desktop:~/unyaffs$ gcc -o unyaffs unyaffs.c

2. Entpacken des Images…

tamas@tamas-desktop:~/unyaffs$ cd ~/backup/clockworkmod/backup/2011-02-19.18.18.57
tamas@tamas-desktop:~/backup/clockworkmod/backup/2011-02-19.18.18.57$ mkdir data && cd data
tamas@tamas-desktop:~/backup/clockworkmod/backup/2011-02-19.18.18.57/data$ ~/unyaffs/unyaffs ../data.img

nach einem EOF, als alles entpackt war, konnte ich mich auf die Suche begeben …

4. Wie bekomme ich nun meine Daten zurück auf das Phone?

Hierzu wird das Android-SDK benötigt, nach erfolgreicher Installation musste ich erst einmal herausfinden, welche ID das angestöpselte Gerät hat.

tamas@tamas-desktop:~$ android-sdk-linux_86_/tools/adb devices
List of devices attached
HT07MPL03778    device

tamas@tamas-desktop:~$

4.1. SQLite-Datei, die mein SMS-Archiv enthält

Unterverzeichnis: /data/com.android.providers.telephony/databases
Dateiname: mmssms.db

$ adb -s HT07MPL03778 push mmssms.db /data/data/com.android.providers.telephony/databases

4.2. Meine WLAN-Zugangspunkte

Unterverzeichnis: /misc/wifi/
Dateiname: wpa_supplicant.conf

$ adb -s HT07MPL03778 push wpa_supplicant.conf /data/misc/wifi/

Im Detail stellte sich heraus, dass die Datei mit den WLAN-Zugangspunkten nicht ohne Weiteres lief. Bei der Aktivierung des WLAN kam die Meldung “Fehler“, diese sehr aussagekräftige Meldung veranlasste mich zu drastischen Massnahmen: Ich werde nun die zugriffrechte von der Datei wpa_supplicant.conf ändern, viel kann ja nicht schiefgehen. Owner, group und other: bekommen allesamt Lese- und Schreibrechte.

WLAN angeschaltet, super … kein Fehler mehr. Die Freude wehrt jedoch nicht lange, denn nach einem Reboot werden die Zugriffsrechte wieder zurückgesetzt. Es muss also eine andere Lösung her. Mit den Zugriffsrechten lag ich schon recht nah, jedoch muss der Besitzer und die Gruppe auf system.wifi geändert werden. Nach einem abschließenden Neustart ist das WLAN wieder Funktionsfähig.

$ adb -d shell
# chown system.wifi /data/misc/wifi/wpa_supplicant.conf
# reboot

5. Das Letzte

Ohne geht nicht! Mein Deh-si-reh wird nicht mehr erkannt? Wer kennt es nicht: gestern lief es noch wie am Schnürchen und heute haut die ganze Verbindung nicht mehr hin. Eine Geräteabfrage via adb schlägt fehl, da man als User nicht genügend Rechte besitzt um auf dem USB-Port herumzuschreiben.

$ adb devices
List of devices attached
????????????    no permissions

Ja, geil! Was nun, ich schob die Schuld auf  das Phone. Nützte aber nix, denn der böse UDEV war der schuldige! Ein winziges lsusb, spuckte folgendes aus…

$ lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 046d:c31b Logitech, Inc.
Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 034: ID 0bb4:0c87 High Tech Computer Corp.

Die Zeile mit Bus 001 ist hier von Bedeutung, denn hier verbirgt sich die Hersteller-ID mit der wir eine UDEV-Rules Datei füttern könnnen.

echo 'SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"' sudo > /etc/udev/rules.d/99-android.rules

Die SYSFS{idVendor} Variable 0bb4 ist durch den ersten Teil der ID der lsusb Abfrage zu ersetzen. So, fast fertig, am Phone kann nun das USB-Debugging oder alternativ das Handy neu gestartet werden. Auf der Konsole muss UDEV und der adb server einem restart unterzogen werden.

$ /etc/init.d/udev restart && adb kill-server && adb start-server

Bildquelle: HTC Desire – www.htc.com (Herstellerwebsite)