I have battery-powered backpackable LTE network which uses an Intel-based computing platform running Linux. Currently, the unit is normally configured using a command line interface accessed from a desktop or laptop computer running a SSH-based terminal application while physically connected to the unit's Ethernet interface.
The unit is most often used in rapid-deployment situations and operated by first responders. The first responders are not expected to be IT-savvy, and do not normally carry a portable computer. The handsets used in the field are ruggedized Android devices.
There is a hardware UI on the unit itself composed of a three-position switch, and two LEDs, but it is not sufficient to be able to manage the various operational modes of the network.
I am looking at developing an out-of-band management solution for the first responders to use, where they can use an application on one of the Android devices to configure the unit's LTE and IP network parameters though a simple UI. The UI would present a number of pre-engineered configurations (such as high-power / hotspot mode, WiFi or VSAT backhaul, etc.), and also allow them to enter a limited number of parameters, such as a SSID and passphrase when using WiFi backhaul.
I don't want the communications channel between the unit and the Android device to based on any of the interfaces which may be changed between configurations (LTE, Ethernet, WiFi), and I don't want to have a dependency on any other external equipment (plain old cables are okay). This leaves Bluetooth and USB.
Bluetooth is fine for many types of deployments. but there are times when the unit must go in to complete radio-silence mode and disable all transmitting functions - including Bluetooth.
Now for my question ...
I am looking for any suggestions on how to establish a communications channel between the internal Linux-based platform and an Android handset using a USB connection. It shouldn't require root access on the Android device nor need the handset to have debug mode enabled. Options on the Linux side are wide-open.
If those Android devices are capable of acting as USB hosts or USB-OTG master, then use the USB APIs. These are userland APIs, so they don't require any USB device driver on the device. The LTE unit can have a corresponding userland application that responds, perhaps using libusb.
If the android devices are not capable of USB hosting, then they have to act as USB slaves by conforming to the android accessory specs (not sure if this is outdated stuff now).
Now for a much more exotic idea: If the android device and linux device have audio jacks, perhaps you can exchange data over the audio cable. Think telephone DTMF tones or even what those old telephone modems did. There's probably some deep DSP coding required here. SO threw up some existing solutions but you'll have to evaluate feasibility of deploying them on your custom devices.
The Android devices are capable of acting as a USB host, but the computing platform which they would connect to is not capable of being a USB slave. Ideally, I would like the handset to appear to Linux as serial device. I'm sure it is possible to add this to the Android device, but it most likely would mean making changes which require root-level privileges on the handset (I need to understand this better).
Interesting idea with the audio jack - I didn't think of it as a possible interface to build a communications channel on, but unfortunately the audio ports for the computing platform are not accessible to the outside.
That did get me thinking though that since the handset can appear as a Mass Storage device to Linux, that I could probably create a couple of directories in the handset to used as message queues (one for each direction), and then drop message files on one side and then read (and delete) the message files on the other side. That would provide a two-way asynchronous channel. Not sure what the performance would be like (depends on if the applications on both side can watch the directories or they would need to periodically poll), but I will give this a try and see if it is a practical solution.