No-Name-i.onik-Android-Tablet wird von ADB nicht erkannt – ADB-Geräte leer

Ich habe verschiedene Anweisungen befolgt und konnte schließlich mein ZTE Blade zum USB-Debugging an meinen Ubuntu-Laptop anschließen. Das gleiche Setup funktioniert nicht, wenn ich das Telefon durch mein "no-name" i.onik TP10.1-1500DC Tablet tausche.

Ich habe verschiedene Kabel und verschiedene USB-Anschlüsse ausprobiert. Benötige ich ein spezielles Kabel, um ein Tablet für das USB-Debugging anzuschließen?

Das bekomme ich von einer Root-Shell:

~# adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached 

~#

(Ich weiß, dass es möglich sein sollte, adbals Nicht-Root ausgeführt zu werden, aber dieser Test sollte Berechtigungsfehler ausschließen.)

Die lsusbAusgabe ist speziell für dieses Gerät, es wird keine Textbeschreibung angezeigt. Der erste Eintrag unten stammt von einem anderen Gerät, der zweite Eintrag vom Tablet. Ich habe dies überprüft, indem ich lsusbmit und ohne angeschlossenes Tablet ausgeführt habe:

Bus 002 Device 005: ID 10d5:5000 Uni Class Technology Co., Ltd 
Bus 002 Device 009: ID 2207:0010  

Natürlich ist USB-Debugging in den Einstellungen des Tablets aktiviert, und ich habe es bereits neu gestartet.

Irgendwelche weiteren Hinweise?

Vielleicht möchten Sie ADB für Nexus 4 unter Ubuntu 11.10 konfigurieren überprüfen . Vielleicht hast du den Schritt ausgelassen, dein Gerät bekannt zu machen :)
@Izzy: Das Hinzufügen der Hersteller-ID zur adb_usb.iniDatei löste das Problem sofort. Danke vielmals! Möchten Sie eine Antwort schreiben, damit ich sie akzeptieren kann?
Klar, habs gerade gemacht. Da wir die Details bereits in der verknüpften Frage haben, habe ich sie allgemeiner gehalten. Ich bin froh, dass es so einfach gelöst wurde - aber andererseits war das genau das, was ich erwartet hatte :) Viel Spaß! // Übrigens, damit andere Maschinen einfach eingerichtet werden können, interessiert Sie vielleicht auch Gibt es eine minimale Installation von ADB? -- was mich letztendlich davon überzeugt hat: Einfach ein paar Dateien kopieren, fertig. Sie brauchen nicht das gesamte SDK, wenn Sie kein Entwickler sind :)
@Izzy: In Ubuntu kann ich adbmit apt-get install android-tools-adb. Sie müssen niemals Dateien kopieren oder PATHEinstellungen anpassen. Das Paket selbst ist winzig und enthält nur adbein paar notwendige Dateien.
Ich weiß davon (da ich auch Ubuntu verwende). Aber ich habe auch gehört, dass es eine Reihe von Abhängigkeiten mit sich bringt - weshalb ich auf die "Kopiervariante" zurückgegriffen habe. Hier werden die ausführbaren Dateien statisch kompiliert, so dass es unabhängig von der Distribution immer funktioniert.
@Izzy: Richtig, die Abhängigkeit von zlib1g wird libxml2 und texlive-binaries beschädigen. Hm... Schwer.
Sehen? Da geht es los. Anstatt mit kniffligen Abhängigkeiten herumzuspielen, um eine "einfache apt-get-Installation" zu beheben, erweist es sich am Ende als viel einfacher, eine Datei manuell herunterzuladen und zu entpacken :)
@Izzy: Warte, ich habe mich geirrt. Es würde nur libxml2 oder texlive-binaries beschädigen, wenn diese Pakete sehr alt sind. In der Praxis würde ich immer aptdiesen Ansatz wählen, es sei denn, eine Installation versucht, die Hälfte meines Systems zu deinstallieren, aber das ist hier nicht der Fall. Wie auch immer, beide Methoden zum Abrufen der Dateien sind gültig und funktionieren meistens :-)

Antworten (3)

Izzys Antwort ist irreführend. Zwei nicht zusammenhängende Dinge wurden verwechselt (die Hersteller-ID-Liste in adb auf der einen Seite und die Berechtigungseinstellung in Linux auf der anderen Seite).

1) von adb berücksichtigte Geräte:

Adb hat eine hartcodierte Liste von USB-Anbieter-IDs, die es versucht. Beispielsweise verwenden HTC-Mobiltelefone 0xbb4, das aufgelistet ist ( Quelldatei usb_vendors.c ), während 0x2207 nicht aufgeführt ist.

Die einzige Möglichkeit, diese Liste zu erweitern (ohne die Quelle zu patchen), besteht darin, Hersteller-IDs $HOME/.android/adb_usb.iniZeile für Zeile in die Datei einzufügen. (HOME ist richtig eingerichtet?)

Es wird kein spezielles Kabel benötigt.

2) Berechtigungseinstellung für Nicht-Root-Zugriff:

Die udev-Fummelei soll dem Benutzer Zugriff auf zB /dev/bus/usb/002/009 geben (Busnummer/Gerätenummer ändern; siehe lsusbfür aktuelle Werte).

Die Details dazu sind für die Frage des ursprünglichen Posters nicht relevant, da er adb als root ausführte.

Wie in Konfigurieren von ADB für Nexus 4 unter Ubuntu 11.10 beschrieben , ist es unter Linux wichtig, entweder in ~/.android/adb_usb.ini(benutzerbasiert) oder aufgeführt zu sein /etc/udev/rules.d/51-android.rules. Die Syntax für beide Dateien ist unterschiedlich: Während es im ersten Fall ausreicht, einfach die Vendor-ID ( echo 0x18d1 >> ~/.android/adb_usb.inifür ein Nexus 4) hinzuzufügen, ist der Eintrag für die UDEV-Regel etwas komplexer. Details finden sich in der verlinkten Frage (bzw. deren Antworten).

Im Fall von krlmlr war es kein "entweder-oder", aber anscheinend wurden beide Teile benötigt (das hatte ich noch nie und ich habe das noch nie benutzt adb_usb.ini- aber das bedeutet nicht, dass es keine solchen Ausnahmen gibt). Durch das Hinzufügen des Geräts an beiden Stellen (was sowieso nicht schaden kann) tauchte das Gerät schließlich auf.

Zwei zusätzliche Anmerkungen: Nach dem Ändern der UDEV-Regeln muss der UDEV-Dienst neu gestartet werden, um die Änderungen zu übernehmen. Unter Ubuntu kann dies über erfolgen sudo service udev restart(alternativ können Sie UDEV einfach mit zwingen, seine Regeln neu zu laden udevadm control --reload-rules). Wenn Ihr Gerät immer noch nicht erkannt wird, war es höchstwahrscheinlich angeschlossen, während Sie die Änderungen vorgenommen haben. Sie müssen dann das USB-Kabel trennen und wieder anschließen. Natürlich muss USB-Debugging in Ihrem Gerät aktiviert sein :)

Beispiel

von krlmlr

Basierend auf der folgenden Ausgabe von lsusbfür das betreffende Android-Gerät:

Bus 002 Device 009: ID 2207:0010  

/etc/udev/rules.d/51-android.rulesEs war notwendig, wie rootmit den folgenden Inhalten zu erstellen :

SUBSYSTEM=="usb", ATTR{idVendor}=="2207", ATTR{idProduct}=="0010", MODE="0660", GROUP="plugdev"

und~/.android/adb_usb.ini mit folgenden Inhalten zu erstellen :

0x2207

Die erste ist erforderlich, um normalen Benutzern (die zur Gruppe gehören plugdev) den Zugriff auf das Gerät zu ermöglichen. Beachten Sie die aus Sicherheitsgründen schwächere Berechtigungsmaske 0660anstelle der häufig gesehenen 0666(letztere erlaubt "Welt" -Zugriff, während erstere nur "Benutzer- und Gruppen" -Zugriff erlaubt). Der zweite wird benötigt, damit überhaupt adbversucht wird, mit dem Gerät zu sprechen. Nachdem:

sudo chmod a+r /etc/udev/rules.d/51-android.rules
sudo udevadm control --reload-rules
adb kill-server

und trennen Sie Ihr Android-Gerät. Dann,

adb devices

schließlich zeigte das Android-Gerät.

Anmerkung von Izzy:

Bei meinem LG Optimus 4X HD reichte es aus, eine Zeile hinzuzufügen zu /etc/udev/rules.d/51-android.rules:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1004", ATTRS{idProduct}=="61a6", MODE="0666" GROUP="androiddev", SYMLINK+="android%n"

Vielleicht SYMLINKmacht die Option den Unterschied, dass ich den extra Eintrag in nicht benötigt habe ~/.android/adb_usb.ini.

Beachten Sie, dass ich mein Tablet bereits zu einer Datei in rules.d. Nach meinem Verständnis musste ich beides tun: Die Einstellung in der .iniDatei ist für "No-Name"-Geräte erforderlich, von denen adbnicht bekannt ist, dass sie Android ausführen, während die rules.dEinstellung erforderlich ist, um ohne rootBerechtigungen auf das Gerät zuzugreifen.
Ich habe dieser INI-Datei nie ein Gerät hinzugefügt, immer nur der UDEV-Regeldatei. Vielleicht hast du dabei etwas übersehen? Meines Wissens ist eine der beiden Varianten ausreichend. In meinem Fall funktioniert der UDEV-Teil gut, und ich habe viele Berichte gelesen, wo die Ini-Datei-Variante ohne spezielle UDEV-Anpassungen auskam.
Nein, nach Ihrem Kommentar war das einzige, was ich getan habe, die .iniDatei zu patchen, und es funktionierte, ohne dass ich udevals normaler Benutzer neu starten musste. (Ich musste den adbServer jedoch neu starten.) Ich hatte das Gerät bereits erfolglos zu den Regeln hinzugefügt. Diese spezielle Information über die .iniDatei ist sehr schwer zu finden, lassen Sie uns ein Q&A erstellen, das die Dinge endlich klärt :-)
Versuchen Sie, die Änderungen an UDEV zu entfernen (oder auszukommentieren), starten Sie den UDEV-Dienst neu und Sie werden feststellen, dass er immer noch funktioniert. Und ich stimme Ihnen zu: Ich war überrascht, auch von der Ini-Dateilösung zu lesen. Was Ihren Q&A-Vorschlag betrifft: Schauen Sie einfach im ADB-Tag-Wiki nach :)
Nein, tut es nicht. Ich brauche sowohl die Regeln als auch die .ini. Wirklich. Ich habe gerade alle Kombinationen überprüft. Darüber hinaus, wie Sie richtig gesagt haben, .inimuss sich das im Home des entsprechenden Benutzers befinden -- wenn Sie also beabsichtigen, es adbals auszuführen root, müssen Sie es dem rootVerzeichnis .androidvon hinzufügen.
Vielleicht ein subtiles Detail: Damit geänderte udev-Regeln wirksam werden, müssen Sie neu starten udev(oder ausführen udevadm control --reload-rules) und Ihr USB-Gerät trennen und anschließen.
OK -- wieder etwas Neues gelernt: Es gibt Fälle, wo beides benötigt wird. Hatte das noch nie. Und ja, guter Tipp mit "restart and unplug/plug", das kann ich bestätigen.
Die Regeln werden nicht benötigt, wenn Sie adbals ausführen rootund (falls erforderlich) das adb_usb.iniin im rootVerzeichnis .androidhaben. Hab das auch gerade gecheckt.
Also ist diese Antwort für Sie nicht mehr akzeptabel? Soll ich einige der Kommentare integrieren? :)
Ihr Hinweis war entscheidend und hat mir geholfen, mein Problem zu lösen. Aber bisher ist die Antwort ungenau, und es wäre großartig, wenn sie die Essenz unserer Erkenntnisse für spätere Referenzen enthalten würde, insbesondere hinsichtlich des Unterschieds zwischen ini und Regeln.
Sie haben Ihren Standpunkt klar gemacht - und ich habe meine Bearbeitung vorgenommen :) Volle Anerkennung, um wichtige Informationen aus Kommentaren zusammenzustellen und sie in die Antwort selbst aufzunehmen - das ist es, was ich auch oft ermutige, da niemand alle Kommentare durchgeht (besonders wenn es so viele sind).
Ich habe ein Beispiel mit tatsächlichen Dateiinhalten hinzugefügt, das zeigt, wie ich das zum Fliegen gebracht habe.
Nein, die SYMLINKOption hat nicht geholfen, ich brauche die .iniDatei noch.

Versuchen Sie, adb_usb.ini zu bearbeiten und fügen Sie Ihre Geräte-ID hinzu. Sie finden sie, indem Sie zum Geräte-Manager gehen, die „Android ADB-Schnittstelle“ doppelt anklicken, zur Registerkarte „Details“ gehen und im Dropdown-Menü „Eigenschaften“ „Hardware“ auswählen Ids" auf dem Feld darunter mit der Bezeichnung "Werte". Sie sollten so etwas wie "USB\VID_2207&PID_0010&MI_01" sehen. Die Zahlen können je nach Hersteller-ID Ihres Geräts unterschiedlich sein, zum Beispiel ist meine Hersteller-ID "2207". Öffnen Sie nicht die adb_usb.ini, die sich auf der befindet Ordner unten und fügen Sie Ihre Geräte-ID im Hexadezimalformat hinzu

Zum Beispiel ist meine Geräte-ID "2207". Ich gebe sie dort als "0x2207" ein.

Es befindet sich normalerweise in

  1. XP: \Dokumente und Einstellungen.android\
  2. Windows 7: \Benutzer.android\
  3. Windows 7: \Benutzer.android\

Aber wenn der Ordner nicht existiert, versuchen Sie ihn mit cmd zu erstellen. Und wenn die Datei adb_usb.ini auch nicht existiert, können Sie sie mit Notepad erstellen und nur Ihre Geräte-ID einfügen und im .android-Ordner speichern.