adb und udev

[fischig]

android-sdk-platform-tools-common

Außerdem werden UDEV-Regeln bereitgestellt, mit denen adb und fastboot ohne Rootzugriff auf den Hostcomputer arbeiten können.

Heißt dann: ohne udev kann man adb nicht nutzen, wenn man keine Root-Rechte auf dem Android-System hat?
adb zeigt keine devices an.
Lässt sich das umgehen, lässt sich in diesem Fall (kein Root-Zugriff) adb ohne udev nutzen?

[DeletedUserReAsG]

„Host“ ist hier der Rechner, von dem aus du auf das Device zugreifen willst.

Ohne die udev-Regel wird das Device eben nur für Root zugänglich sein; für den User wird dann kein Gerät angezeigt. Wenn du kein udev benutzt, wirst du dich selbst darum kümmern müssen, dass das Devicefile mit den richtigen Rechten erstellt wird, oder du musst eben den ADB-Server als Root laufen lassen (auf das Device zugreifen kann man im Anschluss dann auch als User).

[fischig]

Alles klar soweit, damit komme ich erstmal zurecht.

Wie kann ich das „devicefile“ auf dem Debian identifizieren?
Immer noch mit mit udev kriege ich eine Zeichen-/Zahlen-Kombination mit

Code: Alles auswählen

adb devices

. Unter /dev entdecke ich die aber nicht.

[TRex]

Die haben auch keinen direkten Zusammenhang. Das Android-Gerät in /dev findest du am einfachsten, indem du dir dmesg anschaust beim Anstecken. Ich will nicht auf die drölf Variationen von MTP und Konsorten eingehen, die dafür sorgen könnten, dass das Gerät anders heißt als das, was ich annehmen würde.

[fischig]

Ich habe mal versucht, das nachzuvollziehen:
Wenn ich die USB-Verbindung herstelle, meldet # adb devices

Code: Alles auswählen

* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
ZY32262ZJR      unauthorized

Spätestens jetzt muss ich am Android USB-Debugging einschalten, dann wird daraus

Code: Alles auswählen

List of devices attached
ZY32262ZJR      device

(Ich habe auch schon gesehen, dass das Android-Gerät den Hinweis auf's USB-Debugging selbständig nach dem Einstecken bringt, aber konstant zuverlässig tut's das von alleine z.Z. nicht.)


dmesg bringt auf den letzten sieben Zeilen:

Code: Alles auswählen

[   26.465823] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
[   30.758794] RPC: Registered named UNIX socket transport module.
[   30.758804] RPC: Registered udp transport module.
[   30.758810] RPC: Registered tcp transport module.
[   30.758817] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   30.983627] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[  118.225829] usb 4-3: new high-speed USB device number 2 using ehci-pci

Anzufangen weiß ich damit nichts. Mir fällt nur auf, dass vielleicht tcp im Spiel ist.
(udev ist immer noch drauf und aktiv. Der Handrechner hat WLAN-Zugang zum DSL-Router. Auf dem Debian ist kein WLAN aktiviert.)

[TRex]

Na den Stand hattest du ja schonmal - ich erinnere mich an einen Thread, wo man dann über deinen Selbstbaukernel und fehlende Module diskutiert hat. Ich würde das nur ungern wiederholen.

[fischig]

Ich habe versucht meine Eigenbau-Kernel-Threads daraufhin abzuklappern. ich habe keine Zusammenhänge gefunden. Um Missverständnissen vorzubeugen: (Der Eigenbau-Kern und) ich kommen mit niemands Tipp auch ohne udev zurecht. Es geht lediglich noch darum, den adb-Daemon ohne Root-Rechte starten zu können (wofür standardmäßig udev sorgt, vermute ich).

Nebenbei: Geht das „Rooten“ des Android-Gerätes tatsächlich so einfach, ohne jegliche und - soweit mir bekannt - recht komplizierte Vorbereitung des Gerätes selber:

Code: Alles auswählen

adb root

?

Und noch nebenbeier: Ich stoße bei meinen Android-Recherchen immer wieder auf die Abkürzung APK. Was ist das? Zunächst glaubte ich apk-installierte Applikationen seien solche die NICHT über Google-Playstore oder F-Droid gelaufen seien. Wikipedia in Deutsch hat mich nicht schlauer gemacht.

[DeletedUserReAsG]

Nebenbei: Geht das „Rooten“ des Android-Gerätes tatsächlich so einfach […]?

Mit einem Stock-ROM vermutlich nicht:

Code: Alles auswählen

niemand@NUC ~ % adb root
adbd cannot run as root in production builds

APK. Was ist das?
[…]
Wikipedia in Deutsch hat mich nicht schlauer gemacht.

Das Paketformat. Grundsätzlich kommt alles an Apps als *.apk auf das Gerät, egal woher.

Ich muss allerdings gestehen, nicht wirklich zu sehen, was an „.apk steht für: Android Package Kit als Dateinamenserweiterung für Android-Programmpakete, siehe Android (Betriebssystem)“ missverständlich sein sollte

[fischig]

Ich muss allerdings gestehen, nicht wirklich zu sehen, was an „.apk steht für: Android Package Kit als Dateinamenserweiterung für Android-Programmpakete, siehe Android (Betriebssystem)“ missverständlich sein sollte

Im Wikipedia-Artikel hatte ich das „K“ überlesen. Die „Chip“-Seite hatte es unterschlagen und im Fortgang in meiner Vermutung, (nicht reguläre) Programminstallation, also Denkrichtung Fremdpaket, appimage, flatpak, etc., bestärkt.

Das Paketformat. Grundsätzlich kommt alles an Apps als *.apk auf das Gerät, egal woher.

Heißt dann, der Zusatz „apk“ bei „Müll-App“ (im anderen Faden) hat mich eher auf Abwege geführt.

Mittlerweile weiß ich immer noch nicht, welchen Dateimanager ich da via f-droid installiert habe. Tippe inzwischen auf "simple file manager". Interessiert mich aber auch (noch) nicht wirklich. Mir ging's und geht's dabei erstmal nur darum, evtl.vom Dateimanager verursachte „Alternativ-“Darstellungen beim Dateien-Ping-Pong erkennen/auschließen zu können.