[REQUEST] ICS ROMs Hardware ID Standardization

---

I have not experimented with ICS based ROMs much, but I have been reading through the various threads from time to time. The 3.0.x kernel seems to be coming along at a good pace and it looks like ICS will become the new norm sooner than later. Thanks and congratulations to Hashcode and the other contributors to that project.

I was trying out some ICS builds today and found that adb would not recognize gedeROM, so I started to do some digging. Using Windows Device Manager, I saw that it returned a device interface name and hardware IDs different than the stock and CM7 based builds. Here's what the stock and CM7 builds show in Device Manager...

Stock / CM7 / TWRP / CWMR
Other devices -> Kindle
USB\VID_1949&PID_0006&REV_0216&MI_01
USB\VID_1949&PID_0006&MI_01

The line in bold is obviously the name of the build. The next line is the "Class Name -> Interface" shown in the Device Manager list when Windows does not know what drivers to load. The last two are the Hardware IDs in the Properties list.

To my knowledge, these are the only hardware IDs that Kindle Fire users have had to deal with in the past and they are the key to getting the proper drivers to load up in Windows. Now, here's the same information for the ICS builds I've tried out...

Hashcode
Other devices -> Amazon
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006

Reloaded
Other devices -> Kindle
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006

Energy / gedeROM / AOKP / MIUI
Other devices -> GT-P1000
USB\VID_1949&PID_0001&REV_0216&MI_01
USB\VID_1949&PID_0001&MI_01

Hashcode's build and Reloaded have omitted the "&MI_01" from the list of hardware IDs. With that value missing, it prompts Windows to load up "Android ADB Interface" instead of "Android Composite ADB Interface" that we've come to know. I'm not sure if that's a big problem because adb still seems to work with the change.

On the other hand, Energy, gedeROM, AOKP and MIUI hardware IDs have a different PID value. This poses a bigger problem because it will force users of these builds to reinstall Windows drivers if they want to use adb with them. That means KFU's driver installer has to be fixed, which I'm guessing won't be a huge problem, but all the other KF how-to's out there will have to be amended to include these hardware IDs in their instructions... and that's impossible. It just makes me shudder when I think about how many people are going to post on the forum asking why adb won't work after changing to a different ROM.

Device driver issues are a big problem for novice users and it would be great if we could avoid any potential pitfalls. In a perfect world, I'd love to see all these Interface names go back to "Kindle" and the Hardware IDs standardized back to what we had all along with CM7. I'm not sure if there's a good reason why these names and IDs have to be different now, so please school me on the reasons why if they are a necessary change. If there's a reason why these can't go back to the values we've been using, I implore the devs to at least come up with a standard that they can live with for all ICS based ROMs. It would make for a saner, happier Kindle Fire world. Thanks.

i am using gedeROM and my devices is shown as "am" on device manager

Originally Posted by kinfauns

I have not experimented with ICS based ROMs much, but I have been reading through the various threads from time to time. The 3.0.x kernel seems to be coming along at a good pace and it looks like ICS will become the new norm sooner than later. Thanks and congratulations to Hashcode and the other contributors to that project.

I was trying out some ICS builds today and found that adb would not recognize gedeROM, so I started to do some digging. Using Windows Device Manager, I saw that it returned a device interface name and hardware IDs different than the stock and CM7 based builds. Here's what the stock and CM7 builds show in Device Manager...

Stock / CM7 / TWRP / CWMR
Other devices -> Kindle
USB\VID_1949&PID_0006&REV_0216&MI_01
USB\VID_1949&PID_0006&MI_01

The line in bold is obviously the name of the build. The next line is the "Class Name -> Interface" shown in the Device Manager list when Windows does not know what drivers to load. The last two are the Hardware IDs in the Properties list.

To my knowledge, these are the only hardware IDs that Kindle Fire users have had to deal with in the past and they are the key to getting the proper drivers to load up in Windows. Now, here's the same information for the ICS builds I've tried out...

Hashcode
Other devices -> Amazon
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006

Reloaded
Other devices -> Kindle
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006

gedeROM / AOKP / MIUI
Other devices -> GT-P1000
USB\VID_1949&PID_0001&REV_0216&MI_01
USB\VID_1949&PID_0001&MI_01

Hashcode's build and Reloaded have omitted the "&MI_01" from the list of hardware IDs. With that value missing, it prompts Windows to load up "Android ADB Interface" instead of "Android Composite ADB Interface" that we've come to know. I'm not sure if that's a big problem because adb still seems to work with the change.

On the other hand, gedeROM, AOKP and MIUI hardware IDs have a different PID value. This poses a bigger problem because it will force users of these builds to reinstall Windows drivers if they want to use adb with them. That means KFU's driver installer has to be fixed, which I'm guessing won't be a huge problem, but all the other KF how-to's out there will have to be amended to include these hardware IDs in their instructions... and that's impossible. It just makes me shudder when I think about how many people are going to post on the forum asking why adb won't work after changing to a different ROM.

Device driver issues are a big problem for novice users and it would be great if we could avoid any potential pitfalls. In a perfect world, I'd love to see all these Interface names go back to "Kindle" and the Hardware IDs standardized back to what we had all along with CM7. I'm not sure if there's a good reason why these names and IDs have to be different now, so please school me on the reasons why if they are a necessary change. If there's a reason why these can't go back to the values we've been using, I implore the devs to at least come up with a standard that they can live with for all ICS based ROMs. It would make for a saner, happier Kindle Fire world. Thanks.

kinfauns,
As a noob, I agree that with the device and driver changes that occurred, ADB and also fastboot became more challenging to use as the Kindle Fire Utility no longer worked as advertised. The end result was problems with being stuck in TWRP during reboot and or other commands not executing properly. Other procedures (such as installing TWRP 2.1.1 and FIREFIREFIRE 1.3) using ADB and fastboot also were rendered incomplete or incorrect and alot of reading and experimentation was required to get these to install and remain installed.

My comments on device drivers can be found in [WIP][KERNEL] 3.0 Kernel User Discussion Thread [04-28 KERNEL #8 -- 1.2GHZ + BT/USB] posts #426 and 597.

Hashcode has a comment in [WIP][KERNEL][DEV-ONLY] 3.0 Kernel for Kindle Fire [04-28 KERNEL #8 -- 1.2GHZ+BT/USB] Post #607 as to why he made a modification that affects what device is seen.

Note: there is also an issue with the mass storage listing of the device and drivers which may be related. Although, the issue doesn’t prevent the mass storage from working.

Hopefully, in the future, developers will have time to fix this. It may be that there is more than one change needed to the build.

For now, the workaround is to open the command prompt as an administrator and change the directory to the C:\android-sdk-windows\platform-tools folder. Then use the ADB and fastboot found in this folder to execute the commands (bootmode, reboot, ect.) discussed in other forums. Note: to execute files such as FIREFIREFIRE 1.3 and TWRP 2.1.1; they must be first placed in the C:\android-sdk-windows\platform-tools folder.

Originally Posted by vbdss

i am using gedeROM and my devices is shown as "am" on device manager

Same here with Hashcode's build!

Envoyé depuis mon Amazon Kindle Fire avec Tapatalk

Originally Posted by Trojan38

Same here with Hashcode's build!

Envoyé depuis mon Amazon Kindle Fire avec Tapatalk

I got it to work

I saw that the device ID changed and i edited the android_winusb file

mine is like this

;
; Android WinUsb driver installation.
;
[Version]
Signature           = "$Windows NT$"
Class               = AndroidUsbDeviceClass
ClassGuid           = {3F966BD9-FA04-4ec5-991C-D326973B5128}
Provider            = %ProviderName%
DriverVer           = 12/06/2010,4.0.0000.00000
CatalogFile.NTx86   = androidwinusb86.cat
CatalogFile.NTamd64 = androidwinusba64.cat

;
; This section seems to be required for WinUsb driver installation.
; If this section is removed the installer will report an error
; "Required section not found in INF file".
;
[ClassInstall32]
Addreg = AndroidWinUsbClassReg

[AndroidWinUsbClassReg]
HKR,,,0,%ClassName%
HKR,,Icon,,-1

[Manufacturer]
%ProviderName% = Google, NTx86, NTamd64

[Google.NTx86]
; HTC Dream
%SingleAdbInterface%        = USB_Install, USB\VID_0BB4&PID_0C01
%CompositeAdbInterface%     = USB_Install, USB\VID_0BB4&PID_0C02&MI_01
%SingleBootLoaderInterface% = USB_Install, USB\VID_0BB4&PID_0FFF
; HTC Magic
%CompositeAdbInterface%     = USB_Install, USB\VID_0BB4&PID_0C03&MI_01
; Moto Sholes
%SingleAdbInterface%        = USB_Install, USB\VID_22B8&PID_41DB
%CompositeAdbInterface%     = USB_Install, USB\VID_22B8&PID_41DB&MI_01
; Google NexusOne
%SingleAdbInterface%        = USB_Install, USB\VID_18D1&PID_0D02
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_0D02&MI_01
%SingleAdbInterface%        = USB_Install, USB\VID_18D1&PID_4E11
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_4E12&MI_01
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_4E22&MI_01
; Kindle Fire
%SingleAdbInterface%	    = USB_Install, USB\VID_1949&PID_0006
%CompositeAdbInterface%	    = USB_Install, USB\VID_1949&PID_0006&MI_01
%SingleAdbInterface%	    = USB_Install, USB\VID_1949&PID_0001
%CompositeAdbInterface%	    = USB_Install, USB\VID_1949&PID_0001&MI_01




[Google.NTamd64]
; HTC Dream
%SingleAdbInterface%        = USB_Install, USB\VID_0BB4&PID_0C01
%CompositeAdbInterface%     = USB_Install, USB\VID_0BB4&PID_0C02&MI_01
%SingleBootLoaderInterface% = USB_Install, USB\VID_0BB4&PID_0FFF
; HTC Magic
%CompositeAdbInterface%     = USB_Install, USB\VID_0BB4&PID_0C03&MI_01
;
;Moto Sholes
%SingleAdbInterface%        = USB_Install, USB\VID_22B8&PID_41DB
%CompositeAdbInterface%     = USB_Install, USB\VID_22B8&PID_41DB&MI_01
;
;Google NexusOne
%SingleAdbInterface%        = USB_Install, USB\VID_18D1&PID_0D02
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_0D02&MI_01
%SingleAdbInterface%        = USB_Install, USB\VID_18D1&PID_4E11
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_4E12&MI_01
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_4E22&MI_01
;
;Kindle Fire
%SingleAdbInterface%		= USB_Install, USB\VID_1949&PID_0006
%CompositeAdbInterface%		= USB_Install, USB\VID_1949&PID_0006&MI_01
%SingleAdbInterface%		= USB_Install, USB\VID_1949&PID_0001
%CompositeAdbInterface%		= USB_Install, USB\VID_1949&PID_0001&MI_01

[USB_Install]
Include = winusb.inf
Needs   = WINUSB.NT

[USB_Install.Services]
Include     = winusb.inf
AddService  = WinUSB,0x00000002,WinUSB_ServiceInstall

[WinUSB_ServiceInstall]
DisplayName     = %WinUSB_SvcDesc%
ServiceType     = 1
StartType       = 3
ErrorControl    = 1
ServiceBinary   = %12%\WinUSB.sys

[USB_Install.Wdf]
KmdfService = WINUSB, WinUSB_Install

[WinUSB_Install]
KmdfLibraryVersion  = 1.9

[USB_Install.HW]
AddReg  = Dev_AddReg

[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{F72FE0D4-CBCB-407d-8814-9ED673D0DD6B}"

[USB_Install.CoInstallers]
AddReg    = CoInstallers_AddReg
CopyFiles = CoInstallers_CopyFiles

[CoInstallers_AddReg]
HKR,,CoInstallers32,0x00010000,"WdfCoInstaller01009.dll,WdfCoInstaller","WinUSBCoInstaller2.dll"

[CoInstallers_CopyFiles]
WinUSBCoInstaller2.dll
WdfCoInstaller01009.dll

[DestinationDirs]
CoInstallers_CopyFiles=11

[SourceDisksNames]
1 = %DISK_NAME%,,,\i386
2 = %DISK_NAME%,,,\amd64

[SourceDisksFiles.x86]
WinUSBCoInstaller2.dll  = 1
WdfCoInstaller01009.dll = 1

[SourceDisksFiles.amd64]
WinUSBCoInstaller2.dll  = 2
WdfCoInstaller01009.dll = 2

[Strings]
ProviderName                = "Google, Inc."
SingleAdbInterface          = "Android ADB Interface"
CompositeAdbInterface       = "Android Composite ADB Interface"
SingleBootLoaderInterface   = "Android Bootloader Interface"
WinUSB_SvcDesc              = "Android USB Driver"
DISK_NAME                   = "Android WinUsb installation disk"
ClassName                   = "Android Phone"

Try to use like this, i am using the drivers that came with Kindle Fire Utility to make the edits and install

Thank you very much, will try it tomorrow .

Envoyé depuis mon Amazon Kindle Fire avec Tapatalk

Guys, I'm glad you got your device drivers fixed up. You actually don't even have to edit that file. You can right-click on the interface name in the device manager and manually install by telling Windows where the drivers are located. However, I'm trying to start a dialog here so the developers of these ROMS can hopefully make the appropriate changes and avoid the problem altogether. Let's not turn this into the "How to fix your adb drivers for ICS ROMs" thread... please.

rcolddroid: Thanks for the heads-up on those posts, but I'm not sure if that particular model name appearing on Google Play is related to the Interface name in the Windows Device Manager. Someone knowledgeable about the ICS source will have to clarify. It might very well be connected in some way and it's been changed around for compatibility reasons. Again, I really don't know.

My focus is on how this will affect new users who have problems getting the device drivers installed properly. I'm sure it's all very straightforward for most users here, but a great number of users were confused with the process already. I even wrote a section of my guide to help users figure things out...

http://forum.xda-developers.com/show...71&postcount=2

Even with that chart in the middle there with the very limited number of things they might see in the Device Manager, many of them still could not get it right. I don't mind updating my post, but the sheer number of possible variations on this or that thing to possibly appear certainly won't help anybody. Like I said before, the ideal situation would be to have the interface name and hardware IDs changed to the same as the CM7 values, then we could have a totally seamless transition without so much as a hiccup.

I see that Hashcode has clicked the "Thanks" button on the OP, so maybe it's his way of giving me a nod that he too would like to make things simple. It would be great if he would champion this cause and spearhead the effort for standardization. I think it's going to take someone of some influence to get the developers together and come to a consensus. Whatever the case, I'm sure this is not the kind of thing that's on the front burner for Hashcode to deal with right now as he's still smashing the kernel bugs, so I'm not going to bug him about it and press the issue. In the meantime... for all of you who are in agreement with me, I suggest you point out this thread to your favorite ROM's developer because nothing's going to happen if they don't see it as a problem. Thanks again.

The OP has been edited to include the information for the Energy ROM released on 4/29.

More importantly, Hashcode has posted the following in the 3.0 Kernel User Discussion thread...

Originally Posted by Hashcode

I did read through the post outlining in excellent detail the differences between stock USB id's and all of the ics builds. I plan on adjusting the values of the stock devtree soon.

Sent from my Amazon Kindle Fire using Tapatalk 2 Beta-6

Sounds like we're on the right track!

Great find. It seems that editing the build.prop is causing some problems. I will try to make the next gedeROM build have the proper Id.

Thanks![COLOR="Silver"]

---------- Post added at 06:10 PM ---------- Previous post was at 05:24 PM ----------

It is indeed some part of the build.prop that changes the productID. Looking into it.

UPDATE:

I've found an easy way to fix the ProductID. Simply do a chmod in the init.rc after initialization of the usb configuration.

gedeROM is now
Other devices -> Galaxy Nexus
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006

in the next build