Odys Xelio - Brauche funktionierenden "USB Debugging" Treiber (gelöst)

G

Genjin

Neues Mitglied
6
Hallo ihr Lieben, habe heute mein Odys Xelio erhalten und wollte jetzt den Android SDK zum entwickeln aufsetzen. Leider habe ich da jetzt ein kleines Problem: Mein Windows erkennt das Gerät nicht.

Das ganze passiert wenn USB Debugging aktiviert wird. Ohne USB Debugging wird das Gerät durchaus erkannt, aber mit USB Debugging wird versucht einen anderen Treiber zu installieren, was dann fehlschlägt. Der Android SDK ist auch schon installiert, ich habe auch versucht die Treiber die man über den SDK Manager beziehen kann zu installieren, aber das hat auch nicht geklappt.

Weiß jemand, woher ich funktionierende Treiber bekommen kann? Ich bin auf Windows 7, 64 bit.

Vielen Dank im vorraus!
 
Zuletzt bearbeitet von einem Moderator:
Ok, hat sich erledigt. Ich habe mein Problem nun selbst lösen können.

Update: wusel hat die Änderung in die USB Treiber in seinem ADB Archiv aufgenommen. Einfach runterladen und die dort enthaltenen Treiber manuell installieren - fertig. Keine Android SDK Installation notwendig.

--------------------------------------
Meine Original Lösung
Falls sich jemand in der gleichen Situation befinden sollte, hier ist was ich gemacht habe. Natürlich ohne Gewähr, die Idee war Verzweiflungstat und obwohl sie zu funktionieren scheint, möchte ich keine Garantien geben. Außerdem ist das hier auch wirklich nur für Entwickler / Debug Freunde gedacht.

Für den normalen USB Betrieb zum regulären Dateitransfer als "normaler Benutzer" ist all dies nicht notwendig!


- Android SDK installieren, die optionalen USB Treiber herunterladen.
- Zum SDK Installations Ordner gehen, dort den Treiber Ordner aufrufen (bei mir: C:\Program Files (x86)\Android\android-sdk\extras\google\usb_driver)
- Datei "android_winusb.inf" öffnen.
- Finde die Zeile wo steht [Google.NTx86]
- Direkt unten drunter folgendes einfügen:
; Odys Xelio
%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0003
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_0003&MI_01

- Finde die Zeile wo steht [Google.NTamd64]
- Direkt unten drunter wieder einfügen:
; Odys Xelio
%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0003
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_0003&MI_01

- Datei speichern
- Odys Xelio anschalten und auf USB Debugging aktivieren (falls nicht schon getan).
- Windows versucht jetzt Treiber zu installieren und scheitert
- Öffne den Geräte Manager (sorry, bin seit Jahren auf englischem Windows, dort heißt er Device Manager)
- Finde das Gerät mit dem Warnschild wo einfach nur "Android" steht
- Rechtsklick -> Treiber aktualiasieren.
- Computer manuell nach Treibern durchsuchen
- Zum Android SDK Ordner mit den Treibern gehen (bei mir C:\Program Files (x86)\Android\android-sdk\extras\google\usb_driver)
- Ok klicken und Treiber reibunglos installieren lassen
- Fertig :) Wenn erfolgreich sollte ganz oben im Geräte Manager "Android Phone" auftauchen.

Getestet habe ich die Verbindung erfolgreich mit "logcat", und auch ein Praxistest mit der Spiele-Engine "Unity Engine" samt "Unity Remote" war erfolgreich.


PS: Ich hoffe natürlich das die IDs die wir bei android_winusb.inf eingefügt haben universell sind... wenn nicht, bitte die Eigenschaften beim Gerät aufrufen ([Warnschild] Android), zu "Details" gehen, dort das Feld "Hardware IDs" auswählen (heißt womöglich anders im Deutschen Windows), und die Zahlen die dort aufgeführt sind entsprechend zur android_winusb.inf übertragen, so wie ich das weiter oben gemacht habe.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: Oma7144
Hey Danke, genau was ich gebraucht habe. War in der Frühphase der Recherche und dachte ich müsste Eclipse aufsetzen um den Dalvik Debug Monitor zum laufen zu bringen. Was du verlinkt hast funktioniert aber prima ohne Eclipse und hat mir Zeit gespart :)

Den Firmware Dump würde ich machen, insofern ich eine Anleitung dafür bekomme.
 
Genjin schrieb:
Den Firmware Dump würde ich machen, insofern ich eine Anleitung dafür bekomme.
Hast Du das Teil denn schon gerootet? Wenn nicht probier doch mal ob meine Anleitung fürs Cosmo funzt ...
falls Du es aber nicht rooten willst dann packe ich Dir was zusammen womit Du auch so die Firmware auslesen kannst ...
 
Hallo wusel. Ich würde ohne rooten bevorzugen, wenn's nichts ausmacht.
 
Das Tablet ist von Hause aus gerootet also so ist es bei mir.
 
izit schrieb:
Das Tablet ist von Hause aus gerootet also so ist es bei mir.


D.h. auf dem Tab ist die Superuser-App? Oder meinst du su-Zugang über ADB (bedingt ro.secure=0)?



:thumbup:
 
izit schrieb:
Das Tablet ist von Hause aus gerootet also so ist es bei mir.
um so besser! (ich schätze Du meinst dass man mir ADB root-Access hat).
Dann bitte mal einer eine ADB-Shell aufmachen (oder schöner mit modifiziertem PuTTY) und dann rkdump benutzen um die backup.img zu extrahieren:
Code:
rkdump backup /sdcard/backup.img
diese Datei sollte alles enthalten und sich mit afptool zerlegen lassen ...
(ich hoffe der Befehl ist korrekt - sonst mal ohne Parameter aufrufen - ich sitze gerade nicht am Tablet)
wenn einer von Euch eine backup.img erfolgreich abgezogen hat bitte melden und Euer PC-OS nenen, und ich schicke Euch das afptool zum Testen ...
 
Ich habs nur über Titan Backup gesehen bzw das ich die System apps verändern und die Build.prop ändern kann.

Glaub das kann man bei nicht Root , nicht machen.
 
Zuletzt bearbeitet:
izit schrieb:
Ich habs nur über Titan Backup gesehen bzw das ich die System apps verändern und die Build.prop ändern kann.

Glaub das kann man bei nicht Root , nicht machen.
wir haben schon öfter gehört das Apps scheinbar was ändern was dann nach einem reboot wieder weg ist ...
connecte mal mit ADB ....
 
izit hat Recht, bin bei meinem Xelio tatsächlich auch schon Root gewesen. Na sowas.

Also rkdump habe ich jetzt installiert, aber der Syntax von wusel ist wohl nicht richtig. Was dem ganzen am nächsten kommt habe ich hier gefunden rkutils | androtab.info

Ich weiß aber nicht welche davon ich ausführen sollte / darf (wenn überhaupt).
 
Genjin schrieb:
izit hat Recht, bin bei meinem Xelio tatsächlich auch schon Root gewesen. Na sowas.

Also rkdump habe ich jetzt installiert, aber der Syntax von wusel ist wohl nicht richtig. Was dem ganzen am nächsten kommt habe ich hier gefunden rkutils | androtab.info

Ich weiß aber nicht welche davon ich ausführen sollte / darf (wenn überhaupt).
wenn Du das Archiv von meiner Seite genommen hast dann ist da eine dumpfw.sh dabei die Dir alle Arbeit abnimmt; die wird zwar einen Fehler erzeugen weil rkdump die ext3 system (die das Xelio sehr wahrscheinlich hat) nicht erkennt - macht aber nix denn wie schon gesagt nur die backup.img ist erstmal wichtig ...
schau Dir die dumpfw.sh mal an - ausführen kannst Du die auch direkt von SD-Karte mit:
Code:
sh /sdcard/dumpfw.sh
 
Geht auch nicht. Wenn ich die sh auszuführen versuche sagt er /proc/mtd existiert nicht. Danach wollte ich es manuell versuchen, aber die "/dev/block/mtdblock1", "mtdblock2" etc Dateien existieren auch nicht. Ich habe dann im ES File Explorer mal nachgesehen, und die Dateien sind wirklich nicht auffindbar.

Hat sich vielleicht geändert mit ICS, oder mache ich was falsch?
 
Mach mal ein Terminal auf, gibt dort mount ein und poste das Ergebnis hier.


:thumbup:
 
Hoffe ich habe das richtig gemacht:

root@android:/ # mount
mount
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
/dev/block/nandd /system ext4 rw,nodev,noatime,user_xattr,barrier=0,data=ordered
0 0
/dev/block/nande /data ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal
_checksum,data=ordered,noauto_da_alloc 0 0
/dev/block/nandh /cache ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=0,journa
l_checksum,data=ordered,noauto_da_alloc 0 0
/dev/block/vold/93:64 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,u
id=1000,gid=1015,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset
=ascii,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/93:64 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relat
ime,uid=1000,gid=1015,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,ioch
arset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
/dev/block/vold/179:1 /mnt/extsd vfat rw,dirsync,nosuid,nodev,noexec,relatime,ui
d=1000,gid=1023,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=
ascii,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/dm-1 /mnt/asec/com.forthblue.pool-1 vfat ro,dirsync,nosuid,nodev,rela
time,uid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=as
cii,shortname=mixed,utf8,errors=remount-ro 0 0
 
Wow, schnelles Filesystem (ext4) und gleich beschreibbar (rw).

/dev/block/nandd /system ext4 rw
/dev/block/nande /data ext4 rw
/dev/block/nandh /cache ext4 rw


Also kein mtdblockx sondern nandy ;-)

So: nun selber das script anpacken oder warten bis wusel aufgewacht ist.


:thumbup:
 
Lieber auf den Experten warten ;)

Das Xelio ist schon fein. Bin wirklich froh und glücklich, dass das Xelio mein erstes Android Gerät ist... glaube für den Preis gibts kaum eine bessere Alternative :)
 
Oma7144 schrieb:
So: nun selber das script anpacken oder warten bis wusel aufgewacht ist.
ich suche noch immer ne Stunde die mir verloren ging ..... :tongue:
ok, dann mal ran an das Tab, versuch mal:
Code:
cat /proc/nand
wenn das nicht geht dann mach mal:
Code:
ls /proc
damit wir mal sehen wie es eventuell heissen könnte ...
und mach bitte auch mal ein:
Code:
ls -l /dev/block/nand*
thanks!
(ist ja klar dass ich jetzt hier auch nur raten kann ;) )
 
Genjin schrieb:
Ok, hat sich erledigt. Ich habe mein Problem nun selbst lösen können.

Falls sich jemand in der gleichen Situation befinden sollte, hier ist was ich gemacht habe. Natürlich ohne Gewähr, die Idee war Verzweiflungstat und obwohl sie zu funktionieren scheint, möchte ich keine Garantien geben. Außerdem ist das hier auch wirklich nur für Entwickler / Debug Freunde gedacht.

Für den normalen USB Betrieb zum regulären Dateitransfer als "normaler Benutzer" ist all dies nicht notwendig!


- Android SDK installieren, die optionalen USB Treiber herunterladen.
- Zum SDK Installations Ordner gehen, dort den Treiber Ordner aufrufen (bei mir: C:\Program Files (x86)\Android\android-sdk\extras\google\usb_driver)
- Datei "android_winusb.inf" öffnen.
- Finde die Zeile wo steht [Google.NTx86]
- Direkt unten drunter folgendes einfügen:
; Odys Xelio
%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0003
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_0003&MI_01

- Finde die Zeile wo steht [Google.NTamd64]
- Direkt unten drunter wieder einfügen:
; Odys Xelio
%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0003
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_0003&MI_01

- Datei speichern
- Odys Xelio anschalten und auf USB Debugging aktivieren (falls nicht schon getan).
- Windows versucht jetzt Treiber zu installieren und scheitert
- Öffne den Geräte Manager (sorry, bin seit Jahren auf englischem Windows, dort heißt er Device Manager)
- Finde das Gerät mit dem Warnschild wo einfach nur "Android" steht
- Rechtsklick -> Treiber aktualiasieren.
- Computer manuell nach Treibern durchsuchen
- Zum Android SDK Ordner mit den Treibern gehen (bei mir C:\Program Files (x86)\Android\android-sdk\extras\google\usb_driver)
- Ok klicken und Treiber reibunglos installieren lassen
- Fertig :) Wenn erfolgreich sollte ganz oben im Geräte Manager "Android Phone" auftauchen.

Getestet habe ich die Verbindung erfolgreich mit "logcat", und auch ein Praxistest mit der Spiele-Engine "Unity Engine" samt "Unity Remote" war erfolgreich.
habe mein ADB Archiv upgedatet mit Deinen Änderungen damit andere nicht das komplette Android_SDK downloaden müssen nur für den USB-Treiber zu bekommen ... ;)
ausserdem habe ich da auch das aktuelle rkflashtool sowie 2 weitere kleine Tools dazu gepackt: findrkdev um das Tablet im Flash-Modus zu erkennen, und listdevs was im Prinzip ein lsusb ist (dies ist ein Sample was mit libusb kommt, daher habe ich den Original-Namen beibehalten).
 
Habe meinen Lösungspost auf der ersten Seite mit einem Vermerk zum Archiv abgeändert :)

Zurück zum Dumpen... der erste Befehl ging nicht. Hier die Ergebnisse vom Rest:

Code:
ls /proc
1
10
1007
1008
1009
1010
1048
1092
11
1101
1116
1134
1148
116
1162
1188
12
1200
122
1249
1251
1252
1259
13
14
147
15
16
18
19
2
20
21
214
22
23
261
275
291
3
308
321
352
37
373
38
388
404
419
431
46
47
473
48
486
49
50
51
52
53
54
543
55
56
57
6
62
63
631
69
7
71
72
752
78
786
79
8
80
81
818
82
83
84
85
86
87
88
89
893
9
90
91
92
93
94
asound
buddyinfo
bus
ccmu
cmdline
consoles
cpu
cpuinfo
crypto
devices
diskstats
driver
execdomains
fb
filesystems
fs
interrupts
iomem
ioports
irq
kallsyms
kmsg
kpagecount
kpageflags
loadavg
locks
meminfo
misc
modules
mounts
net
pagetypeinfo
partitions
sched_debug
schedstat
scsi
self
slabinfo
softirqs
stat
swaps
sys
sysrq-trigger
sysvipc
timer_list
timer_stats
tty
uid_stat
uptime
version
vmallocinfo
vmstat
wakelocks
zoneinfo
Code:
ls -l /dev/block/nand*
brw------- root     root      93,   0 2012-03-25 16:48 nanda
brw------- root     root      93,   8 2012-03-25 16:48 nandb
brw------- root     root      93,  16 2012-03-25 16:48 nandc
brw------- root     root      93,  24 2012-03-25 16:48 nandd
brw------- root     root      93,  32 2012-03-25 16:48 nande
brw-rw-rw- system   system    93,  40 2012-03-25 16:48 nandf
brw------- root     root      93,  48 2012-03-25 16:48 nandg
brw------- root     root      93,  56 2012-03-25 16:48 nandh
brw------- root     root      93,  64 2012-03-25 16:48 nandi
 

Ähnliche Themen

C
Antworten
0
Aufrufe
836
Camilo2018
C
Cage_and_Fish
Antworten
0
Aufrufe
1.102
Cage_and_Fish
Cage_and_Fish
D
  • dd1al
Antworten
0
Aufrufe
2.444
dd1al
D
Zurück
Oben Unten