(gelöst) Android-Erkennung

[fischig]

Welche Bestandteile benötigt ein Kern 5.10 um einen Wischrechner mit Android-OS zu erkennen?

[towo]

Geht's noch etwas ungenauer? Was genau soll den von dem Smartphone erkannt werden?
Der Kernel hat da nicht viel mit zu tun, außer, dass er das USB-Subsystem bereit stellt.

[fischig]

Geht's noch etwas ungenauer?

Nein.

[DeletedUserReAsG]

Imitierst du jetzt Andy oder Strunz?

[fischig]

Nun denn:
Welche Bestandteile benötigt ein Kern 5.10, um einen via USB angeschlossenen Wischrechner mit Android-OS als solchen zu erkennen?

[DeletedUserReAsG]

Keine – dem ist mal völlig egal, was für ein System auf dem anderen Busteilnehmer läuft.

[fischig]

Der Standardkern 5.10 erkennt das Lenovo Moto G5 5 als solches, mein selbstgebauter nicht.

[MSfree]

Welche Bestandteile benötigt ein Kern 5.10, um einen via USB angeschlossenen Wischrechner mit Android-OS als solchen zu erkennen?

Im Kernel brauchst du das USB Subsystem.

USB-Geräte melden sich am Kernel mit ihrer ID, meine Mouse z.B. mit 046d:c03e, wie man unschwer mit lsusb rausfinden kann. Es gibt auf der Platte auch irgendwo eine USB-ID Datenbank, anhand derer lsusb die Bezeichnung des Geräts herausbekommt. Aber "Android" ist keine Funktionsbezeichnung, kann also nicht vom Kernel erkannt werden. Androide geben sich in der Regel als Mass-Storage-Device oder auch als Modem zu erkennen.

[DeletedUserReAsG]

Der Standardkern 5.10 erkennt das Lenovo Moto G5 5 als solches, mein selbstgebauter nicht.

Nein, der gibt nur stumpf die IDs und den String zurück, die er vom Gerät bekommt.

Androide geben sich in der Regel als Mass-Storage-Device oder auch als Modem zu erkennen.

Storage war bis Android 4 möglich. Das ist schon eine Weile her. Dass es sich OOTB als Modem bzw. serielle Schnittstelle meldet, hab ich eigentlich noch gar nicht gesehen.

[fischig]

Der Standardkern ist noch 4.19. Die ersten Reaktionen haben mich schon geärgert.
dmesg 4.19

Code: Alles auswählen

[   26.764234] Bluetooth: RFCOMM ver 1.11
[   34.345069] usb 1-1.2: new high-speed USB device number 5 using ehci-pci
[   34.455654] usb 1-1.2: New USB device found, idVendor=22b8, idProduct=2e81, bcdDevice= 3.18
[   34.455744] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   34.455811] usb 1-1.2: Product: Moto G (5)
[   34.455852] usb 1-1.2: Manufacturer: motorola
[   34.455894] usb 1-1.2: SerialNumber: ZY32262ZJR

dmesg 5.10:

Code: Alles auswählen

[   24.837522] Bluetooth: RFCOMM ver 1.11
[   48.470953] usb 1-1.2: new high-speed USB device number 4 using ehci-pci

USB „an sich“ funktioniert mit beiden Kernen, sonst hätte ich's von mir aus erwähnt.

[towo]

Du hast laufend Probleme mit deinen komischen Eigenbau-Kernen, warum benutzt Du dann nicht einfach die, von Debian gelieferten Kernel?

[DeletedUserReAsG]

Code: Alles auswählen

[   34.345069] usb 1-1.2: new high-speed USB device number 5 using ehci-pci

Das Modul wird benötigt.

Du hast laufend Probleme mit deinen komischen Eigenbau-Kernen, warum benutzt Du dann nicht einfach die, von Debian gelieferten Kernel?

Die Frage hab ich mir auch schon mehr als zehn Mal gestellt …

[TRex]

Naja, wenn das Ziel ist, mehr über die Bestandteile zu erfahren, ist das schon nicht so verkehrt. Nur ein paar mehr Details bei der Fragestellung wären hilfreich. Es offen zu lassen und quasi alle Antworten zu erlauben, um potentiell mehr zu erfahren, fühlt sich irgendwie n bisschen unfair den Antwortenden gegenüber an.

Mein Gegenvorschlag wäre

1. dmesg/lsusb beim Anschluss eines oder mehreren definierten (!) Androiden (Gerät, Android-Version)
2. selbiges mit dem Selbstbaukernel

und dann kann man sich darüber unterhalten, was in 1 passiert und 2 nicht und wieso das so ist.

[fischig]

ehci-pci ist im Eigenbaukern 5.10 vorhanden und geladen.

Es offen zu lassen und quasi alle Antworten zu erlauben, um potentiell mehr zu erfahren, fühlt sich irgendwie n bisschen unfair den Antwortenden gegenüber an.

Das kommt vielleicht auch auf die jeweiligen Überlegungen vor dem Posten an. Man kann auch mal was weglassen, weil man sich nicht sicher ist, ob mehr Info vielleicht auf Abwege führt. Aber das ist vielleicht nicht jedem erlaubt.

USB hätte ich erwähnen müssen, ohne Frage. Aber USB funktioniert, das hatte ich vorher geprüft.

Zu TRex Vorschlag: Reichen die dmesg-4.19-Angaben nicht? Dann hätte ich ein neues Problem, ich bin mit diesen Winzlingen nicht vertraut und müsste erst in Erfahrung bringen, wie man denen die erforderlichen Angaben entlockt. Durchgeführt habe ich 1. und 2. ja bereits. Über ein weiteres Android-Gerät verfüge ich nicht.

[bluestar]

ehci-pci ist im Eigenbaukern 5.10 vorhanden und geladen.

Dann prüfe mal sämtliche USB Treiber die im Standardkernel enthalten sind, egal ob eingebaut oder als Modul und deine eigene Auswahl an USB Treibern, dann kannst du deinen Kernel anpassen und dich an dein Problem herancompilieren.

Der Sinn nach einem selbstgebauten Kernel erschließt sich mir heutzutage auch nicht mehr.

[smutbert]

Wenn ich ins Blaue schießen müsste, würde ich einmal vermuten, dass so Optionen wie CONFIG_USB_FUNCTIONFS* und CONFIG_USB_CONFIGFS* nötig sein können. Wenn ich die Beschreibungen verstehe, geht es dabei u. a. um Geräte deren Treiber nicht Teil des Kernels sondern des Userspace sind und das trifft hier zu.

Ich habe bei mir gerade gesucht ob beim Anstecken eines Androidgeräts und in weiterer Folge dem Übertragen von Daten mit jmtpfs irgendetwas ausgegeben wird, was auf notwendige Kerneloptionen hindeuten würde, aber außer generell USB ist dabei nichts herausgekommen.

noch eine kleine Ergänzung, weil es mir jetzt erst beim Schreiben einfällt:
Bei jmptfs ist natürlich auch CONFIG_FUSE_FS notwendig, aber das ist ja sozusagen eine Besonderheit von jmtpfs und dürfte z.B. weder bei gnome/gvfs noch den mtp-tools notwendig sein.

[fischig]

so Optionen wie CONFIG_USB_FUNCTIONFS* und CONFIG_USB_CONFIGFS* nötig sein können

Die sind im eigenen Kern nicht drin, aber im 4.19er Standard.

Wir werden sehen, ob sich was ändert.

Was smutberts dritten Absatz angeht: So weit war ich halt noch nicht. Ich wollte erst mal die Eignung des Kerns klären.

[fischig]

Einkompilieren von CONFIG_USB_FUNCTIONFS* und CONFIG_USB_CONFIGFS* hat leider keine Änderung der dmesg-Ausgabe gebracht.

Vielleicht ist's nur 'ne Frage der Gesprächigkeit: ich kann das dafür vorgesehene Verzeichnis des Android-Gerätes auch mit meinem 5.10er Kern via jmtpfs und dank df-wiki einbinden. Das bestätigt dann MSFree. Find' ich aber schon irritierend, die unterschiedlichen dmesg-Ausgaben. Mal schauen, ob's auch ohne die o.a. Module geht. Dafür muss ich aber das vorherige linux-image wieder installieren. Probiere ich morgen.

edit:
5.10 Eigenbau funktioniert auch ohne CONFIG_USB_FUNCTIONFS* und CONFIG_USB_CONFIGFS*. ich kann den Debian-Rechner mit dem Android-System verbinden, heißt, ich kann das auf dem Android-System dafür vorgesehene Verzeichnis im Debian-System einhängen und Dateien austauschen. Nötig ist's ja nun nicht mehr, aber interessieren tät's mich doch, wieso die dmesg-Ausgaben so unterschiedlich sind, obwohl die Funktionalität der Kerne doch zumindest in diesem Teilbereich die gleiche ist.

edit: df-wiki-Artikel verlinkt

[bluestar]

aber interessieren tät's mich doch, wieso die dmesg-Ausgaben so unterschiedlich sind, obwohl die Funktionalität der Kerne doch zumindest in diesem Teilbereich die gleiche ist.

Die Kernel-Option lautet USB_ANNOUNCE_NEW_DEVICES Infos dazu findest du u.a. hier: https://cateee.net/lkddb/web-lkddb/USB_ ... VICES.html

[fischig]

Das war's, danke!

Selbst kompilierter 5.10 gibt jetzt ebenfalls preis, was ich da per USB angeschlossen habe.