recovery uses its own product id of D001, for adb/sideload/resuce modes.
Bug: 136716811
Test: Install the (unsigned) driver on Windows 7. `adb devices` shows a
device under recovery mode (adb/sideload/rescue).
Change-Id: Ie7526644825c400c9e2b3a9daa9fb93ae8ed00b1
Bug: http://b/110800681
Lld, unlike the MinGW binutils linker, requires import libraries while
linking. Create one for the prebuilt AdbWinApi.dll.
AdbWinApi.def is a list of Adb* functions in prebuilt/usb/AdbWinApi.dll.
AdbWinApi.lib, which is the one passed to lld when linking, is created
as follows:
// First symlink llvm-ar to llvm-dlltool in Clang prebuilts.
$ prebuilts/clang/host/linux-x86/clang-r353983b/bin/llvm-dlltool \
-D AdbWinApi.dll -k -m i386 \
--input-def development/host/windows/prebuilt/usb/AdbWinApi.def \
--output-lib development/host/windows/prebuilt/usb/AdbWinApi.lib
Import library for AdbWinUsbApi.dll doesn't seem necessary since it's
not directly part of any link command.
Test: The following commands pass (but throw exception without this change):
$ adb.exe devices
$ fastboot.exe devices
Change-Id: I10481d43b59adc5464f60bcff7d49ed206c12a5b
There is a race condition in AdbWinUsbApi.dll where AdbCloseHandle() of an
interface would clobber the WinUsb handles, causing a concurrent
Adb{Read,Write}EndpointSync() to crash.
The fix is to make AdbCloseHandle(endpoint) set a flag to prevent future IOs
from starting up, abort any pending IOs, and wait for the pending IOs to abort.
Adb{Read,Write}EndpointSync() participates in this scheme.
There is still a race condition if the caller calls AdbCloseHandle(interface)
before calling AdbCloseHandle(endpoint). No AOSP code does this and assuming
that this never happens simplifies the fix.
This fix also ignores Adb{Read,Write}EndpointAsync() (the async APIs) since
those APIs are unused by AOSP.
This fix should not affect devices whose vendor supplies Windows USB drivers
that use a 'legacy kernel driver'. This causes AdbWinApi.dll to call a 'legacy
kernel driver' instead of AdbWinUsbApi.dll (which uses WinUsb.dll which uses a
kernel driver included with Windows). The source code for the 'legacy kernel
driver' was deleted from AOSP over 4 years ago, so it is probably deprecated
(I don't know the official status of it). Even so, I wouldn't be surprised if
some modern 3rd party devices were still using the legacy driver or a similar
driver derived from the original source code.
Also in this change:
- Added a test case to adb_winapi_test that reproduces the race condition and
verifies the fix.
- adb_winapi_test misc: more strictly check return values and error codes,
symbolize some dumped data to make things more readable, disable old test
code that looked for specific hardware, test AdbGetInterfaceName() the same
way adb uses it, fix dumping of initial "handshake".
- Increased AdbWinUsbApi.dll file version info from 2.0.0.0 to 2.0.0.1.
- Update AdbWinUsbApi.dll in prebuilt tree.
- Include AdbWinUsbApi.pdb (debugging symbols) so the DLL can be debugged in
the future (or at least so crash addresses can be manually symbolized).
- Update AdbWinApi.dll, AdbWinUsbApi.dll, adb_winapi_test.exe build
environments to WDK 7.1.0, which seems to be the publicly available closest
version to what built the last version of these files.
This entailed modifying SOURCES files to use USE_NATIVE_EH=1 instead of
USER_C_FLAGS=/EHsc, removing /Wp64, manually setting DLL base addresses to
the old address, using DEBUG_CRTS=1 to pickup the debug ATL for checked
builds.
- Update BUILDME.TXT files with up-to-date instructions.
- For source files that are already majority CRLF, make the whole file CRLF.
- Update SOURCES to explicitly set Windows Vista as the target. This means
that future rebuilders don't need to worry as much about their build
environment.
Bug: https://code.google.com/p/android/issues/detail?id=161890
Change-Id: I30a4e2ff3919929001c2319c4bb80354f7bcfda0
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
The file has a mix of unix and DOS-mode end-of-lines.
This CL just fixes the end-of-line to make it a consistent DOS-mode.
There is no change to the actualy content.
Change-Id: I6635ec87907f68e1d34c807f712723804eb0e698
As the result of the split, now we have two DLLs that deal with USB driver
connection on Windows. AdbWinApi.dll deals with legacy driver and LoadLibrary
AdbWinUsbApi.dll on condition that WINUSB.DLL is installed on user's machine.
When both DLLs must be installed in the same location in SDK.
BUG 2033924
Move all WINUSB-dependent functionality into AdbWinUsbApi.dll in order to
enable ADB on condition that WINUSB has not been installed.
In this patch set new file (adb_winusb_api.h) has been added where I moved
typedef that broke the build. Aso, adb_api.cpp and AdbWinApi.cpp were changed
to include that new header file.
BUG 2033924
The primary usage for this code is to provide vendors / customers who for some
reasons are not satisfied with WinUsb, with a sample custom driver code that is
compliant with our AdbWinApi.dll. So vendors / customers can build their own
custom USB driver that can be recognized by AdbWinApi, and can be accessible from
adb.exe
usb_windows.c doesn't build with adb_legacy_api.h included into adb_api.h
Since adb_legacy_api.h is not used anywhere outside AdbWinApi.dll project, the simplest
fix would be to remove its inclusion from adb_api.h
To support both, WinUsb and Legacy driver APIs we need to abstract classes
that depend on driver API details and then implement two sets of the
actual classes: one for WinUsb, and another for the Legacy drivers, so
we can choose in runtime which objects should be instantiated, depending
on what type of driver we have underneath this API.
