From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Help with ADB (Android Debug Bridge) start-server
Solved!
I'm afraid that is a dead end. The Pharlap OS only supports a subset of the Win32 API as it was present in Windows 2000 or so. As such almost all software developed nowadays for Windows simply won't run on it as they make use of Active X, .Net and several dozen other Microsoft frameworks, libraries and APIs.
The typical Samsung ADB driver download is anyhow a monster in what it all includes. Googles own solution isn't much better. And the whole ADB bridge is complicated enough that it is unlikely that someone made an alternative driver for it, rather than relying on the Google provided solution.
ADB on the host site consiste of two things, the adb command line tool and the adb server. The adb server is the one responsible to talk to the actual device through USB interface. Now porting that server to Pharlap OS would be a very serious undertaking since it would require a full Pharlap development license, porting of the USB stack and the adb specific drivers and all. The chances that someone is going to do that unless you can throw a massive amount of money into it yourself, is about 0%. With massive I'm talking about 5 to 6 digits numbers of hard dollars. Requesting it from NI without a business case that gives them revenues of even higher numbers is simply a lost battle.
Now the ADB server could be run on a Windows system and then you only would have to port the ADB command line tool to Pharlap. This should be fairly easy to do, since the ADB command line tool connects over TCP/IP with the server and that could be even implemented in pure LabVIEW if you only require a few commands to work.
I would start with downloading the sources and see if everything is present or if Google maybe withheld something like the actual USB driver sources. Then I would read up a few books about embedded programming in general and Pharlap ETS development especially. Then buy the Pharlap ETS development SDK from Interval Zero. Also don't forget to buy a Visual Studio license for VS2003 or I believe VS2008 or 2010 since that are the two compiler NI has ported the Microsoft C runtime library for.
Last but not least spending countless hours developing by porting the ADB code to Pharlap. The server itself is probably going to be fairly straigtforward as it is supposedly running in the user context of Windows, albeit maybe as Windows Service. If it runs as Windows Service you would have to port that part since Pharlap ETS doesn't have a Service Manager like Windows. That could be quite some work. The really hard nutcracker will be the USB driver. That may end up killing the whole project anyways, as porting that even if Google provides the total source code may be in fact a complete rewrite to match the Pharlap ETS device driver model.
In short, if your company isn't willing to spend a LOT (and I mean amounts where a full PXI system is really peanuts in comparison) of money into this, it is totally unfeasable.
It may be a lot cheaper to buy a NI Linux Realtime cRIO, get the ADB sources for Linux and recompile them for the new target (might be not a straight forward recompile but might require a few modifications to the code and make scripts), then connect that to the network and talk to the ADB server over TCP/IP from your PXI system.
