[REQUEST] ICS ROMs Hardware ID Standardization

Search This thread

kinfauns

Retired Senior Moderator and Retired DC Lead
Jan 5, 2012
1,861
3,543
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.
 
Last edited:

rcolddroid

Member
Jul 18, 2011
40
3
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.
 

vbdss

Senior Member
Jul 21, 2011
594
90
33
Niteroi, RJ
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

Code:
;
; 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
 
  • Like
Reactions: sthomas38

sthomas38

Senior Member
Feb 9, 2012
695
524
Thank you very much, will try it tomorrow :).

Envoyé depuis mon Amazon Kindle Fire avec Tapatalk
 

kinfauns

Retired Senior Moderator and Retired DC Lead
Jan 5, 2012
1,861
3,543
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/showpost.php?p=23747671&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.
 
Last edited:

kinfauns

Retired Senior Moderator and Retired DC Lead
Jan 5, 2012
1,861
3,543
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...

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!
 

gedemis

Senior Member
Dec 26, 2010
261
677
Copenhagen
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!

---------- 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.
 
Last edited:
  • Like
Reactions: nursereese

gedemis

Senior Member
Dec 26, 2010
261
677
Copenhagen
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

:)
 

kinfauns

Retired Senior Moderator and Retired DC Lead
Jan 5, 2012
1,861
3,543
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

:)

As I was saying in the OP, it would be best if it could look like this...

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

That way, it's consistent with a stock device and the way CM7 and all its derivatives had it up until this time.

Hashcode has said that he intends on fixing it, but I don't know if it's the same as what you did. Regardless, I've got my fingers crossed for the interface and HW IDs I listed above.
 

gedemis

Senior Member
Dec 26, 2010
261
677
Copenhagen
As I was saying in the OP, it would be best if it could look like this...

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

That way, it's consistent with a stock device and the way CM7 and all its derivatives had it up until this time.

Hashcode has said that he intends on fixing it, but I don't know if it's the same as what you did. Regardless, I've got my fingers crossed for the interface and HW IDs I listed above.

I'll try fixing it tomorrow :)
 

gedemis

Senior Member
Dec 26, 2010
261
677
Copenhagen
UPDATE:

I've created a script that goes in
/system/etc/init.d/

The script will configure any ROM to have the following USB footprint:
Other Devices -> Kindle
USB\VID_1949&PID_0006&REV_0216&MI_01
USB\VID_1949&PID_0006&MI_01

Windows will detect and install the Android Composite ADB Interface driver if no driver exists on the target machine. Thus, you might need to remove your current driver for it to update properly. Any new user will have the correct driver right away :)

Download is here:
http://d-h.st/R7M 452 bytes
 

rcolddroid

Member
Jul 18, 2011
40
3
UPDATE:

I've created a script that goes in
/system/etc/init.d/

The script will configure any ROM to have the following USB footprint:
Other Devices -> Kindle
USB\VID_1949&PID_0006&REV_0216&MI_01
USB\VID_1949&PID_0006&MI_01

Windows will detect and install the Android Composite ADB Interface driver if no driver exists on the target machine. Thus, you might need to remove your current driver for it to update properly. Any new user will have the correct driver right away :)

Download is here:
http://d-h.st/R7M 452 bytes

I installed the script as directed and removed the old driver and rebooted my windows 64 puter. I got the following results:
USB Mass Storage Device with hardware IDs:
USB\VID_1949&PID_0001&REV_0216&MI_00
USB\VID_1949&PID_0001&MI_00

USB Composite Device with hardware IDs:
USB\VID_1949&PID_0001&REV_0216
USB\VID_1949&PID_0001

No Android Composite ADB Interface driver was observed.
 

gedemis

Senior Member
Dec 26, 2010
261
677
Copenhagen
I installed the script as directed and removed the old driver and rebooted my windows 64 puter. I got the following results:
USB Mass Storage Device with hardware IDs:
USB\VID_1949&PID_0001&REV_0216&MI_00
USB\VID_1949&PID_0001&MI_00

USB Composite Device with hardware IDs:
USB\VID_1949&PID_0001&REV_0216
USB\VID_1949&PID_0001

No Android Composite ADB Interface driver was observed.

Did you remove your current driver first?
 

rcolddroid

Member
Jul 18, 2011
40
3
Did you remove your current driver first?
yes. prior to removing the driver only one device (android phone) was listed.

when i first installed the kindle fire drivers, i used the following link:
http://www.jayceooi.com/2011/12/13/how-to-install-kindle-fire-adb-usb-driver/

you will notice there were 5 devices listed and the end result was that the Android Composite ADB Interface Driver was installed for the Kindle.
hardware ids were:
USB\VID_1949&PID_0006&REV_0216&MI_01
USB\VID_1949&PID_0006&MI_01

you will notice the hardware ids are slightly different that the ones listed in post #1.

thanks for looking into this problem. i hope this helps.
 
Last edited:

MarkPopkie

Member
May 13, 2011
28
1
Running gedeROM and having the issues stated earlier...

I placed the script as instructed... uninstalled my drivers, rebooted both KF and PC... then plugged it back in... driver installation still failed.

Did I miss something? Admittedly, I'm a bit out of my league but I really like this rom and would like to keep it. The driver issues could be a dealbreaker if I can't get them running.
 

gedemis

Senior Member
Dec 26, 2010
261
677
Copenhagen
Running gedeROM and having the issues stated earlier...

I placed the script as instructed... uninstalled my drivers, rebooted both KF and PC... then plugged it back in... driver installation still failed.

Did I miss something? Admittedly, I'm a bit out of my league but I really like this rom and would like to keep it. The driver issues could be a dealbreaker if I can't get them running.

Did you install the latest version of gedeROM? If so, you should able to get adb running by following these instructions:

http://www.jayceooi.com/2011/12/13/how-to-install-kindle-fire-adb-usb-driver/

Hope this helps :)
 

MarkPopkie

Member
May 13, 2011
28
1
Did you install the latest version of gedeROM? If so, you should able to get adb running by following these instructions:

http://www.jayceooi.com/2011/12/13/how-to-install-kindle-fire-adb-usb-driver/

Hope this helps :)

I do have the latest version of gedeROM... however, I do not have the android sdk.
I'll install everything then give this method a try...

[UPDATE] Yeah this definitely works. It was easiest solution I've ever seen, but who cares... it fixed the issue.
Thanks for the help!
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 19
    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.
    5
    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/showpost.php?p=23747671&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.
    2
    UPDATE:

    I've created a script that goes in
    /system/etc/init.d/

    The script will configure any ROM to have the following USB footprint:
    Other Devices -> Kindle
    USB\VID_1949&PID_0006&REV_0216&MI_01
    USB\VID_1949&PID_0006&MI_01

    Windows will detect and install the Android Composite ADB Interface driver if no driver exists on the target machine. Thus, you might need to remove your current driver for it to update properly. Any new user will have the correct driver right away :)

    Download is here:
    http://d-h.st/R7M 452 bytes
    1
    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

    Code:
    ;
    ; 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
    1
    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!

    ---------- 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.