MyPhoneExplorer: Reconnect USB Plugin
|Zeile 23:||Zeile 23:|
Installation: Just copy MPE_Reconnect.exe to the MPE installation directory (where MyPhoneExplorer.exe resides). '''The executeable must be in the same directory!''' Call MPE_Reconnect.exe
Installation: Just copy MPE_Reconnect.exe to the MPE installation directory (where MyPhoneExplorer.exe resides). '''The executeable must be in the same directory!''' Call MPE_Reconnect.exe . It will reside in background and use essentially no resources (just a few kB RAM and only wakes up when a device is attached).
== Download ==
== Download ==
Version vom 19. März 2015, 23:01 Uhr
MyPhoneExplorer (MPE) is a great tool for synchronizing and controlling an Android phone over ADB with Windows.
My use case is as follows: I usually have turned on Bluetooth and connect to MPE over Bluetooth. However, in my office I use a dockingstation. Not only for charching the battery but also for providing a high-speed connection for synchronizing my files.
I would like MPE to automatically use USB connection (and drop Bluetooth) when I insert the phone into the dockingstation. This is where "MPE Reconnect" comes into play: It is a very light footprint (13k) exe that just resides in background once called. It waits for an Android ADB device over USB. And once such a device is identified, it makes MPE do a disconnect, followed by a reconnect, effectively dropping Bluetooth connection and using USB connection.
This however requires that the connection type is set to "Automatic" in the settings.
If MPE_Reconnect.exe is started after MPE, it displays a short startup greeting via a balloon over the MPE tray icon.
Whenever an ADB device has been plugged it, it isses a reconnect command and displays a balloon over the MPE tray icon.
The "screenshot" looks as follows:
Installation: Just copy MPE_Reconnect.exe to the MPE installation directory (where MyPhoneExplorer.exe resides). The executeable must be in the same directory! Call MPE_Reconnect.exe manually. It will reside in background and use essentially no resources (just a few kB RAM and only wakes up when a device is attached).
The exe generates a small, invisible window and registers for device notification via RegisterDeviceNotification. It then waits for WM_DEVICECHANGE (it does nothing more). When a device of type DBT_DEVTYP_DEVICEINTERFACE connects, the first part of the device path for the compound device is extracted (the compound device is usually the smartphone device itseld and has modem ports, file access or ADB as children). For example, for my phone:
Using AdbWinApi.dll from the MPE DLL subdirectory, it is checked if there is an active ADB device matching this compound device. For this purpose, AdbEnumInterfaces, together with AdbNextInterface is used to iterative over all available ADB interfaces. The appropriate ADB device in my case looks like:
so the check reduces to a simple substring search. If there is a match, the program uses ShellExecute to execute:
MyPhoneExplorer.exe action=disconnect // sleep for 3 seconds MyPhoneExplorer.exe action=connect
It also displays a balloon over the MPE tray icon. Unfortunately the the HWND which handles the tray icon in MPE is just arbitrary! A window without caption and non-unique WNDCLASS. For this reason I decided to use a not very clean shotgun technique (yeah, I just invented this term): First, any window that starts with "MyPhoneExplorer" is found using EnumWindows. For each of those, all child windows are enumerated using EnumChildWindows and a Shell_NotifyIcon is issued for these HWND. This is not clean at all but it does not harm either.