I am attempting to connect to a serial device from a Android tablet, via USB-Serial Converter. In order to interface with this particular serial device, a linux library must be used as an interface.
This library takes an integer as an argument, and tries to connect to the device at the following location : /dev/ttySx, where x is the arguement. If 2 is provided to the library, it will look for the device at /dev/ttyS2. Very simple.
When I connect the device to Ubuntu, there's is one simple extra step for this device to work with the USB-Serial convert. The converter is exposed at the location /dev/ttyUSB1. I just need to create a simple soft-link with the serial port pattern (etc "ln -s /dev/ttyUSV1 /dev/ttyS99"). It works perfectly.
Now the problem arises for Android. The converter is seen at /dev/bus/usb/01/01. I never seen this convention in other project. The question is how can I direct the I/O from /dev/ttySX to /dev/bus/usb/01/01
Related
(I would have posted this in the development forums but apparently I don't yet have enough "karma" or something {grin})
I'm on a project to use Android tablets to exchange data via USB with an embedded microcontroller environment. At present I'm using a Nexus 7 (because it supports USB Accessory mode, so it can be powered by the other end) and an Arduino Due (because it has two USB interfaces). I've read countless articles and scoured everything I can find on the topic of programming for USB, but still have some fundamental questions.
The biggest one concerns how the host and device interfaces "identify" each other. Seems like each end needs to expose a USB interface with VID/PID values that the other end knows about and looks for during initialization. This implies that the code on each end would need to control the PID and VID values, as well as other USB descriptor values. Yet none of the code examples I've found ever discuss this.
Example: I've found that the Nexus 7 exposes one PID value (0x4E42) when its USB port is configured in "media device (MTP)" mode, and a different PID value (0x4E44) when its USB port is configured in "camera (PTP)" mode. The protocols for interacting with these two configurations is different, and the code on the other end of the wire needs to know how to handle that. I haven't checked yet but I suspect the values in the usb_interface and usb_interface_descriptor structures also change along with the PID value, since usb.org defines a whole bunch of standardized values for various device types. A connecting device would retrieve these values, potentially from multiple exposed logical interfaces on the same physical USB port, and select a compatible one.
Since I'm writing the code on both ends of the wire, doesn't my code need to somehow convey these values into the USB interface hardware? How is that done, for example, under Android? Do the code examples just omit this because everyone but me knows how to do it?
If I just "ignore" this question, then when the Arduino (acting as USB Host) polls the Nexus 7 it will have to select from whatever interfaces are offered. So... whose code is in charge of those interfaces? How does my code tell the Android OS which of these "default" interfaces it will be handling? My suspicion is that, if a USB interface is being advertised, there is *already* code behind it. That brings me full circle to the question of "How does my code inform Android that it wants to use certain VID/PID values?"
I hope I've explained this clearly. It's a pretty detailed question, so if it's unclear I can try to ask it differently. Thanks in advance for any guidance, tips, RTFM's, etc.!
For interacting arduino with android device, it can be written under eclipse, you can learned it from "Beginning Android ADK with Arduino" which can be downloaded from torrent market. VID/PID mostly used to allow your device to be recognised to your computer.
koklimabc said:
For interacting arduino with android device, it can be written under eclipse, you can learned it from "Beginning Android ADK with Arduino" which can be downloaded from torrent market.
Click to expand...
Click to collapse
Thanks, I'll look for that reference!
VID/PID mostly used to allow your device to be recognised to your computer.
Click to expand...
Click to collapse
Yes, but those parameters (along with a couple of others) are used to 1) confirm that the two devices recognize each other, and 2) in some cases to launch the proper code to handle that interface/protocol. So you must have control over them, and must initialize the USB system with the proper values in some manner. I presumed it would be in the Android API but I can't find any reference to setting the low-level values for USB connections.
Thanks again for the response! Anyone with additional data? It would be greatly appreciated!
Hello,
I am attempting to control HCI commands and events directly from the command line (I have access to a few OS's, so bash/cmd are both an option). My test device specifically is a rooted pixel 2.
I've looked into using hcitool, but its no longer a part of the Android OS.
I've looked into using bluedroid test tool, but its no longer a part of the Android OS.
I've looked into using Android Comm Test Suite, but I am unable to secure root permissions without starting an adb shell, and the scripts run outside of the shell - so that hasn't worked out.
I've looked into using Intents/Activities from the com.android.bluetooth apk, running adb shell am -a (activity) or -n (package./activity) but haven't gotten meaningful results from the available commands.
I want my solution to be as generic and portable as possible (work for as many android devices and versions as possible), but I've only found two 'solutions' to this problem thus far.
Currently my options look like:
1) GUI automation (emulating user input to change parameters via nrfConnect or some similar app that would result in changes to HCI/LL level parameters), but this is device specific to the extreme and might break for even simple updates.
2) Building an application that has many functions controlling different bluetooth parameters and interactions, then creating its AndroidManifest.xml file in such a way as to be able to more or less call these functions from the command line.
If there are simpler ways to control these events and commands (alternatives to the now deprecated hcitool) please let me know.
If there are any problems with the two approaches I've listed above, please let me know.
Thank you in advance for any advice.
While performing a vulnerability scan for open ports of an Android Automotive Infotainment system, I found out that port 5151 is open. Doing a netcat on the open port, reveals a continuous stream of unreadable data.
Code:
kali:~$ nc 192.168.x.x 5151 //IP of infotainment system
7ò”°R YJøOæݽ9^çÆC€E†éúaI™íÐåY—
...
...
Since I had the root access to the Android system, I could find out that this data is related to android.car.cluster.
Code:
console:/ # netstat -ltpu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program Name
tcp6 0 0 :::pcrd :::* LISTEN 4473/android.car.cluster
Now my question is, whether there is a way to read this data that is being pushed to the port 5151. for eg. some client application, that I can install on my Kali Machine to read the data on the port.
Android version used : android-10.0.0_r20.
Kali Machine and Infotainment system are on the same local network.
You have a rooted Android 10 Android Automotive in hands? Can you share with us what OEM it is for?
I guess you are aware that the Cluster app in the Google repo above is only an example implementation and that the OEM will have its own private and proprietary implementation of such app pre-installed on the device. If you have a rooted device, then simply pull the apk from the device and re-engineer it
realzoulou said:
You have a rooted Android 10 Android Automotive in hands? Can you share with us what OEM it is for?
I guess you are aware that the Cluster app in the Google repo above is only an example implementation and that the OEM will have its own private and proprietary implementation of such app pre-installed on the device. If you have a rooted device, then simply pull the apk from the device and re-engineer it
Click to expand...
Click to collapse
The system is under development, hence obtaining a root access was not difficult.
There is currently no cluster app available in the infotainment system.
So seems like this is a dummy implementation as you mentioned. Could any valuable information be retrieved from this at all? Here is a link to the data that is read. The data is completely binary
: https://onedrive.live.com/?authkey=!AMcXrkjcLGnjyuY&cid=35E147C2C403215D&id=35E147C2C403215D!106&parId=root&action=locate
If you are doing a vulnerability scan, why is the data content important and why do you not ask the OEM that (I assume) has contracted you with doing the scan? And ... no, I cannot decode this hex stream.
Hi everyone,
I need to create something (maybe a service) that reads data from a serial port on a custom rooted device (I already have the serial port library) and inject input events in the system as a translation of the serial port input.
The target is to control any app on my device with the serial port input, emulating the mouse / keyboard input.
I've followed the methods described in this guide: https://www.pocketmagic.net/injecting-events-programatically-on-android/ but unfortunately I cannot make INJECT_EVENTS permission work. Anyone wknows how to make it work?
Moreover, I've tried to implement method 3 too, but still not working.
Does anyone can tell me how to inject input events in the system?
I am trying to build a custom ROM for pixel 4a. I was able to build the images successfully. After I flash, the phone boots but gets stuck in Google logo. How can I debug this? Device is not listed in adb at this point of time. Any suggestions/guide to debug the device preferably without rooting in this scenario?
I'm assuming you are hitting a problem with the kernel. Your best, maybe only option is to connect a serial console to the device. Luckily, it seems you don't have to disassemble the phone to reach solder pads anymore, but you do have to create an adapter to get console out of the USB port. I found these links that might be helpful. I did not find anyone selling pre-made adapters.
Serial debugging:Cable schematics - postmarketOS
wiki.postmarketos.org
GitHub - Peter-Easton/android-debug-cable-howto: This is a simple how-to to create your own android kernel debugging cable using commercially available parts.
This is a simple how-to to create your own android kernel debugging cable using commercially available parts. - GitHub - Peter-Easton/android-debug-cable-howto: This is a simple how-to to create y...
github.com
GitHub - google/usb-cereal: USB-Cereal is a debugging and development tool for designs that use USB-C port and bring out serial TX/RX lines into SBU1/2 pins. USB-Cereal is made compatible with both 1.8V and 3.3V signalling.
USB-Cereal is a debugging and development tool for designs that use USB-C port and bring out serial TX/RX lines into SBU1/2 pins. USB-Cereal is made compatible with both 1.8V and 3.3V signalling. -...
github.com
If the kernel finishes booting, and you have an Android problem, you might have other options.
If storage can be mounted, you could dump logs there.
If the network is up you can dump logs remotely. You'd need another device on the network to receive the logs. A USB LAN dongle might be better than WiFi for this...
There was a bootsplash mod that printed console messages. I don't know how easy it is to just write on the screen but if you can leverage an existing project like this it might be manageable.
Are you not using any kind of emulation for testing prior to pushing to the device? Emulation will give you the capability to capture dump/log data for analysis.
Actually I have made few changes in the some xml files that goes into vendor.img. For emulators, we dont need vendor .img right?