Root und ADB

[NoHumanBeing]

Hallo zusammen!

Ich habe mir (hauptsächlich wegen des günstigen Preises für verhältnismäßig ja doch ziemlich gute Hardware) ein BQ Aquaris U als Gerät zum Entwickeln angeschafft. Wenn ich dieses per SuperSU (v2.79-201612051815) roote, wird es jedoch nicht mehr von ADB erkannt. (Fastboot und MTP funktionieren weiterhin, d. h. die USB-Verbindung selbst geht durch das Rooten nicht kaputt.)

Vor dem Rooten:

$ ./adb start-server
* daemon not running. starting it now at tcp:5037 *
* daemon started successfully *
$ ./adb shell
shell@chaozu:/ $ exit
$ ./adb kill-server
$

Nach dem Rooten:

$ ./adb start-server
* daemon not running. starting it now at tcp:5037 *
* daemon started successfully *
$ ./adb shell
error: no devices/emulators found
$ ./adb kill-server
$

Firmware ist aktuell: Android 6.0.1, Kernel 3.18.24, Build 1.5.0_20170217-1219

Android SDK ist ebenfalls vollständig aktualisiert.

Wenn ich das Telefon mit dem PC verbinde, zeigt es an, dass es mit einem Debugger verbunden sei, dieser sieht jedoch kein geeignetes Target. Entwickleroptionen und USB-Debugging sind in Android aktiviert und das Gerät wird am Rechner auch in "lsusb" unter der ID "2a47:901b" angezeigt.

Was ich alles versucht habe:

• USB-Modus ("Nur Laden", "MTP", ...) auf dem Gerät ändern.
• Debugberechtigungen auf dem Gerät zurücksetzen.
• Die USB-ID des Gerätes auf dem Entwicklungsrechner zu "~/.android/adb_usb.ini" hinzufügen.
• "udev"-Regeln auf dem Entwicklungsrechner erstellen.
  
• ADB auf dem Entwicklungsrechner als Root ausführen.

Nichts davon scheint zu irgendeiner Veränderung zu führen.

Ein gerootetes Samsung Galaxy Nexus (i9250) wird derweil problemlos von ADB erkannt, auch ohne diese ganzen Eingriffe, d. h. ADB selbst ist in Ordnung und es liegt tatsächlich am Gerät.

Wenn ich ein OTA einspiele, wird das Gerät "unrooted" und ADB funktioniert wieder. Ich brauche aber als Entwickler ADB mit Rootzugriff. Gibt es eine Möglichkeit, das ganze zum Laufen zu bringen? Wenn nicht, müsste ich das Gerät, obwohl es hardwaremäßig wirklich spitze ist, leider wieder zurückgeben, da dies für mich als Entwickler eine absolut kritische Funktion ist. Custom-Firmware ist ja leider keine Option, da es für das Gerät schlicht noch keine gibt. Das war mir zwar bewusst, bevor ich das Gerät gekauft habe, allerdings würde mir Stock + Root prinzipiell auch reichen, wenn es denn funktionieren würde, was ja aber leider nicht der Fall ist.

 

[copy&paste]

Hallo und Willkommen im Forum
Keine Ahnung ob das überhaupt mit root zusammenhängt, da hast du sicher mehr Ahnung als ich und kannst daher besser abschätzen ob sich das lohnt: mal die aktuellere SuperSu-Version versuchen?

 

[NoHumanBeing]

Hey!

Vielen Dank für Deine Antwort!

Das Problem hängt wohl irgendwie mit Root zusammen, da es exakt nach dem Rooten des Gerätes auftritt. In welcher Weise dieser Zusammenhang besteht, weiß ich leider nicht, da ich keine Idee habe, wie SuperSU intern arbeitet. Es scheint allerdings das Kernel-Image in der Bootpartition des Gerätes zu extrahieren, irgendwie zu patchen und dann zurückzuschreiben. Zumindest geht das aus den Logeinträgen hervor, die SuperSU schreibt. Dabei wird auf dem BQ wohl irgendein Stück Code "beschädigt"/überschrieben, das vom Debugger benötigt wird. Zumindest wäre das meine Vermutung.

Danke für den Link. Ich habe SuperSU v2.79-SR3-20170114223742 ausprobiert. Dieses stellt (laut Logeinträgen) den Original-Kernel wieder her und patcht ihn anschließend neu (was Fehler, die möglicherweise durch die ältere Version von SuperSU eingebaut wurden, beseitigen sollte), allerdings habe ich auch damit keinen ADB-Zugriff mehr auf das Gerät. Daran hat sich also mit der neuen Version grundlegend nichts verändert. Ich werde versuchen, Kontakt mit dem Entwickler von SuperSU aufzunehmen. Vielleicht können wir das Problem ja gemeinsam ausfindig machen.

 

[copy&paste]

Okay, einen hab' ich noch: wäre Magisk ,sprich systemless root, vielleicht noch ein Ansatz? Aber nich hauen wenn es nicht funktioniert

 

[NoHumanBeing]

Magisk scheint zu funktionieren.

Danke!

Einziger Nachteil dieser Methode ...

$ ./adb shell
shell@chaozu:/ $ su
root@chaozu:/ # exit
shell@chaozu:/ $ exit
$

Soweit alles gut, aber ...

$ ./adb root
adbd cannot run as root in production builds
$

Schade. :-(

Inwiefern das eine Einschränkung sein wird, weiß ich noch nicht.

Ich schätze, Filetransfer ("./adb push ...", "./adb pull ...") wird nicht mit Rootrechten möglich sein, wenn "./adb root" nicht funktioniert. Aber es ist natürlich schonmal ein gewaltiger Fortschritt.

 

[copy&paste]

Habe ich erwähnt das ich die Shell noch nie mochte und mir in ca. fünfzehn Jahren peripher Beschäftigung damit nie ernsthaft die Mühe gemacht habe diese zu verstehen Mit anderen Worten: ich nix verstehen
Aber wenns ein Anfang ist und dir hilft, freut es mich

 

[Steaven]

Moin allerseits, bin eigentlich aus dem Moto Bereich. Habe mir nun auch das BQ U gekauft.
Ich habe alles unter Android N gerootet. War etwas schwierig, hinsichtlich des Recovery. Aber es hat alles geklappt. Auch meine SD Karte konnte ich per Befehlszeilen als internen Speicher nutzen.

@ NoHumanBeing,

evtl. hängt Dein Problem mit dem Recovery zusammen.

 

[NoHumanBeing]

Ich bin mir ziemlich sicher, dass es mit einem Flag in der Datei "/system/build.prop" (oder so ähnlich) zusammenhängt. Leider kann ich diese Datei nicht modifizieren, da ich "/system" nicht Read-Write mounten darf. Tue ich es dennoch, wird das System danach bootloopen. Die einzige Möglichkeit, dort wieder herauszukommen liegt darin, ein Factory-Image einzuspielen, und zwar ein komplettes (nur Systempartition reicht nicht), womit alle Daten verloren gehen. Aus diesem Grund habe ich auch wenig Lust, damit noch weiter herumzuspielen.

Das Problem scheint mit dm-verity zusammenzuhängen. Nachdem es sich hier um ein "offizielles" Android (kein LineageOS o. ä.) handelt, verifiziert der Kernel über dieses Modul die Integrität der "/system" Partition. (Diese ist kryptographisch signiert.) Sobald "/system" read-write gemounted wird, wird etwas auf die Partition geschrieben, sodass die Signatur invalidiert wird und der Kernel sich künftig weigern wird, die Partition zu mounten. Die einzige Möglichkeit, dort wieder herauszukommen, besteht darin, ein Factory-Image zu flashen.

Mit "stock" bringt Euch Root also nichts, denn wenn ihr etwas am System verändert, invalidiert ihr die Signatur. Nachdem sich dieses Modul im Kernel befindet, wird es mit dem "stock" Kernel nicht funktionieren. Alternative Android-Distributionen haben dm-verity in der Regel deaktiviert, allerdings ist LineageOS ja für die Aquaris-Reihe leider noch nicht verfügbar.

Indem ihr den Bootloader entsperrt, wird die Signatur des Kernels (also der "boot"-Partition) anschließend nicht mehr validiert, was es Euch erlaubt, alternative Kernel zu flashen. Der "offizielle" Kernel widerum validiert aber weiterhin "/system". Das ist das Problem. Die einzige Möglichkeit, das zu umgehen, und somit "/system" tatsächlich modifizieren zu können, liegt in einem modifizierten Kernel und den gibt es noch nocht.

Kurz: "/system" modifizieren bringt nix, solange "boot" weiterhin offiziell ist. Ein offizielles "boot" (Kernel) Image wird eine modifizierte "/system"-Partition nicht mounten.

 

[TheMinefighter]

Moin allerseits, bin eigentlich aus dem Moto Bereich. Habe mir nun auch das BQ U gekauft.
Ich habe alles unter Android N gerootet. War etwas schwierig, hinsichtlich des Recovery. Aber es hat alles geklappt. Auch meine SD Karte konnte ich per Befehlszeilen als internen Speicher nutzen.

@ NoHumanBeing,

evtl. hängt Dein Problem mit dem Recovery zusammen.

Habe auch ein Aquaris U aber in der Lite Variante, wollte mich erkundigen wie du es gemacht gast, da wenn ich das mit fastboot boot versuche passiert folgendes (TWRP Image)

F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools>fastboot boot recovery.img
downloading 'boot.img'...
OKAY [  0.630s]
booting...

Beim booting bleibt er 2 Stunden stehen und dann hab ichs abgebrochen. Dann hab ichs mit nem Flash versucht:

F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools>fastboot flash recovery recovery.img
target reported max download size of 535822336 bytes
sending 'recovery' (19894 KB)...
OKAY [  0.628s]
writing 'recovery'...
OKAY [  0.502s]
finished. total time: 1.134s

gebootet wird dann aber das BQ Android. Hast du irgendwelche Ideen?

 

[Steaven]

@ TheMinefighter ja die hätte ich.

ändere den Namen vom TWRP im Fastboot Ordner in twrp.img.img um! Dann halt unter Fastboot mit den üblichen Befehlen flashen.

Das war damals bei mir das Problem.

Viel Glück

 

[TheMinefighter]

Getestet:

F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools>fastboot boot twrp.img.img
downloading 'boot.img'...
OKAY [  0.630s]
booting...

weiter ist dann wieder nichts passiert.
mit flashen getestet:

F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools>fastboot flash recovery twrp.img.img
target reported max download size of 535822336 bytes
sending 'recovery' (19894 KB)...
OKAY [  0.631s]
writing 'recovery'...
OKAY [  0.623s]
finished. total time: 1.258s

F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools>fastboot reboot
rebooting...
finished. total time: 0.002s

Bootet in trotzdem Danach in das BQ Android.
Weitere Vorschläge?

 

[Steaven]

@TheMinefighter der Bootloader ist unlocked? USB debugging ist eingeschaltet OEM -Entsperrung ( Bootlaoder - Entsperrung zulassen ) ist aktiviert??? Das richtige TWRP ???

 

[TheMinefighter]

@Steaven Ja es ist USB Debugging an, der OEM Unlocking ist an, es ist auch das richtige TWRP von TWRP.ME für genau das Handy (chaozulite), der Hash Wert stimmt mit dem auf der Website überein. Ansonsten danke für schnelle die Hilfe , aber funktionieren tut es weiterhin nicht.

Spoiler: Screenshots

 

[Steaven]

@TheMinefighter mal alles ganz von vorn

Mit welchem Betbriebssystem arbeitest Du? Window 7 oder höher? Bitte bedenke, bei Win 8 & 10 Treibersignifikation zu deaktibieren.
Probiere bitte mal ein anderes USB - Kabel und anderen USB - Port.

Flashe das TWRP 2 bis 3 x hintereinander, dann per mit " Fastboot reboot " Handy neu starten. Das muss funktioneren

 

[TheMinefighter]

@Steaven Ja ich habe (leider) Windows 10 also: Treibersignaturen deaktiviert:

testsigning             Yes

USB Kabel und Port geändert, ändert nichts auch wenn keine Fehlermeldung angezeigt wird:

Spoiler: Code

C:\WINDOWS\system32>"F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools\fastboot" flash recovery "F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools\twrp.img.img"
target reported max download size of 535822336 bytes
sending 'recovery' (19894 KB)...
OKAY [  0.633s]
writing 'recovery'...
OKAY [  0.476s]
finished. total time: 1.114s

C:\WINDOWS\system32>"F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools\fastboot" flash recovery "F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools\twrp.img.img"
target reported max download size of 535822336 bytes
sending 'recovery' (19894 KB)...
OKAY [  0.630s]
writing 'recovery'...
OKAY [  0.529s]
finished. total time: 1.163s

C:\WINDOWS\system32>"F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools\fastboot" flash recovery "F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools\twrp.img.img"
target reported max download size of 535822336 bytes
sending 'recovery' (19894 KB)...
OKAY [  0.630s]
writing 'recovery'...
OKAY [  0.683s]
finished. total time: 1.317s

C:\WINDOWS\system32>"F:\SSDAllo\C\Program Files (x86)\Android\android-sdk\platform-tools\fastboot" reboot
rebooting...

finished. total time: 0.002s

 

[Steaven]

@TheMinefighter evtl ist auch die Datei des TWRP beschädigt. Vielleicht mal erneut eine herunterladen.

BQ Aquaris U Lite (chaozulite)

Root And Install Official TWRP Recovery For BQ Aquaris U Lite

Wenn das wieder nicht funktioniert, dann habe ich im Moment keine Lösung für Dich. Vielleicht meldet sich noch jemand anderes zu Deinem Problem.

Viel Glück erstmal

 

[TheMinefighter]

@Steaven Ich habe es jetzt geschafft! Handy gerootet! Endlich!
Wie? Glück: Der Trick war es nach dem flashen in die Recovery zu gehen, die dann abschmirt, dann in das Bootmenü gehen und Restart auswählen und NICHT normal booten zu lassen. Dann bootet TWRP, der Rest war kein Problem. SuperSu läuft.

 

[Steaven]

@TheMinefighter mein Glückwunsch

Da kannst mal sehen, man lernt nie aus. Es gibt Dinge, die gibt eigentlich überhaupt nicht Mach noch ein Backup vom System, dann passt das alles

 

[TheMinefighter]

@Steaven
schon gemacht.