I'm adapting a Gingerbread kernel for my custom board. I'm trying to replace a resistive touch screen that uses an on-chip ADC controller (S5PV210 processor from Samsung). In my design, I need a capacitive controller supported by eGalaxyTouch driver. It's connected to the USB. The driver can be easily enabled from the "make xconfig" menu. It somewhat works since I added some traces on the serial console and I can see it installing during the kernel boot and I see it install and uninstall itself when connecting/disconnecting the USB cable. But it doesn't do anything in the Android user interface. It is an HID type device. The problem is it does not hook-up to the proper Android touchscreen software layer. I must have miss something. There must be something else to call to force this HID to be connected to another software layer managing the touchscreen.
The touchscreen drivers are located at kernel/drivers/input/touchscreen. There is also some code straight in kernel/drivers/input.
Any clues on how to link that HID device to the Android Touchscreen layer? I look how they did the old resistive one and it is not done through an HID because it's a "custom made" device with ADCs integrated in the CPU and it's not going through USB.
I succeeded to integrate the touchscreen driver. Here is a rough idea of the steps just to give an idea of how it works for the others who would face the same kind of problem.
First remove the original touchscreen driver to prevent conflict (make xconfig)
Originally, I had a driver that doesn't work eventhough it was provided by the touchscreen manufacturer. I decided to try the eGalax touchscreen driver already in the Kernel tree. This is a module driver.
It is not enough to enable "module device drivers" in the make xconfig. Yes, it will allow to compile the .ko files. but it will not tell the building script what to do with the file.ko and they will not end up going with the kernel in the target system. So you have to take action by adding stuff to the build script or manually copy the file.ko in the proper root/modules location and add the loading of the module with the "insmod /modules/file.ko" command in the init.rc file. Don't forget to set the proper privileged to /modules and modules/file.ko with chmod command.
After that it basically worked, except for some minor problems not related to that question (the driver was for a slightly different chip with bits placed differently, easy to fix).
Related
I've bought a tablet recently. It's a SysTrade's Plug 10.1 (Chinese product of local company). It features a reasonable CPU and quite nice GPU, so I thought it would be great to hardware debug my applications. However, this feature seems not to work on my device...
At beginning I lacked the required vendor id so after a few phone calls to SysTrade I received one. But that code didn't work. So I've written a small app and got all 2-byte numbers which I copy-pasted to /etc/udev/rules.d/51-android.rules. The problem is that adb still can't see my device. What's important my HTC Wildfire is successfully recognized so rules are written well.
I know none who owns this tablet so I don't have a possibility to check whether all Plugs or only mine are affected. Any ideas would be highly appreciated...
PS. I'm developing on Linux (Ubuntu 12.10).
PS2. When I connect the device to PC it shows that hardware debugging is turned on, but adb doesn't see my device.
I've managed to successfully resolve the issue without rooting the device. The only needed action is to manually add an entry for the device vendorid in ~/.android/adb_usb.ini.
Normally it should be generated based on /etc/udev/rules.d/51-android.rules by android update adb command but it seems that this application failed. What's important, vendorid must be given in hex number specific format, which is: 0x(2-BYTE HEX) for example 0x2207.
Try running adb on root.
If that doesn't work you can still try to root your device(This may void warranty) and use app like adbWifi. I'm using the latter for debugging and it works: I can run my apps on my M-tech aTAB7t.
If I wanted to implement an app for 2 Android devices so I can connect from one to the other via bluetooth, how can I do that via emulator?
HINT: I don't have an Android phone for simulating.
Thanks.
There are few limitations for the Android Emulator. The functional limitations include:
No support for placing or receiving actual phone calls. You can simulate phone calls (placed and received) through the emulator console, however.
No support for USB connections
No support for device-attached headphones
No support for determining network connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insert/eject
No support for Bluetooth
Source Link
I've found the way to debug bt-enabled application on virtual android with real devices. That is not ADK emulator, and it has some flaws, but it definitely works.
Host computer works under Windows 7 64-bit with standard BT stack. Step by step:
Install VMWare Player. It's free for non-commercial usage
Create virtual machine. Set "Other linux 2.6" guest OS type.
Choose reasonable amount of RAM. Remove SCSI disk and printer. Add IDE disk at least 1 GB, keep USB controller, ensure if bluetooth devices are shared with host computer.
Download android installation from android-x86.org. I recommend Android 4.0 RC2 for EEE PC
Point VM's CD to the ISO file.
Start the VM and install android. Unfortunately, it's impossible to add google account there for now.
Switch to android console(Alt-F1 inside virtual machine) and ask for IP address(use netcfg command, look at eth0 network interface), then switch back to GUI(Alt-F7)
On host machine, run adb.exe connect your-vm-ip
Enjoy!
Here is an illustrated tutorial in Russian
You can't use an emulator to test bluetooth apps. The BluetoothAdapter will remain null in emulator. You would need a bluetooth device.
Reference link of accepted no longer exists and I can't seem to find any other pages the mentioned the exact same details. However, it is mentioned in this docs:
What's not supported
The Android Emulator supports most features of a device, but doesn't include virtual hardware for:
WiFi
Bluetooth
NFC
SD card insert/eject
Device-attached headphones
USB
The watch emulator for Android Wear doesn't support the Overview (Recent Apps) button, D-pad, and fingerprint sensor.
While most end users of phones and tablets tend to use earlier API levels, Android Wear and Android TV users tend to use the latest releases. Using recent releases can give you a better experience using the emulator.
In addition to elmot's method (which I have seen on various places on the net and has been reported to work), you may also consider this utility which seems to do exactly what you would need:
https://github.com/cheng81/Android-Bluetooth-Simulator
I would like to turn my computer into an Android accessory using my application. So instead of a specialized hardware this will be just PC that will switch the phone into accessory mode, thus launching some Java app on the phone associated with the host hardware and create a communication channel.
I've found a sample code (plus some Java Android app) to do this on Linux using libusb. It works by "opening" the phone using the standard VID and PID. Then it sends a command to turn on the accessory mode, along with the metadata like model, version etc.
If the phone supports accessory mode it'll then disconnect and reenumerate with a different PID. The sample code then checks if it did and opens the new device.
However, I'm trying to get this running on Windows. I've found a few USB libraries, like LibUsbDotNet, but they all seem to require the device using a WinUSB/libusb driver. I've used a tool in LibUsbDotNet to generate a libusb driver for my phone, installing it over the old generic removable drive one. But this means I now can't access the phone as a removable drive when I want to, so this is not a solution.
Is there a way (preferably a library) that can open any connected USB device based on VID and PID, and then send a few raw commands to it?
After that the device will reenumerate with a different PID, which I can use to create my own WinUSB driver, so that is not an issue. I just need to inject some commands through/around the default driver to turn the accessory mode on.
(I would prefer .NET solution, but anything Windows is fine and I can write my own interop wrapper)
I am also searching for a similar solution. I tried the Linux version, with libusb, with little hickups, was able to communicate with the device.
While searching for the solutions on windows I tried many hacks.
If need to communicate with device in ADK mode, I need to send several Vendor Commands, now this I need to do while its connected in Mass Storage mode. This is impossible using Mass Storage driver. I tried to get the Node handle of connected USB device to see if could send vendor command, but there I could only file Get Descriptor requests. So I went ugly method, replaced mass storage driver with libusb-win32, to see it could do the same, YES, it worked, but not at all a good solution.
Still searching..
For some reason on Windows you need a different driver for every device to work with ADB. In Linux you just add the ID's to a file. We have been trying to figure out how to make a more universal ADB driver for windows, as we use ADB in a 2 part program that has a desktop component and an android component. We do not want to install 100 different device drivers to make sure our program works for every device, however we have Windows OS as a requirement so we can't just switch to Linux.
Why is it so simple to make ADB work on all kinds of devices on Linux (by simply adding the manu ID to a file), but on Windows we need a different device driver for every single device? What direction can we take to come up with a universal ADB driver that works for every android device on Windows as it already does on Linux?
Thanks very much, please let me know what I can do to clarify if this is unclear.
While I cannot provide a definitive answer I can offer these words that may provide some explanation:
Taken from Linux Device Drivers, 3rd Edition, O'Reilly, Chapter 1 "Classes of Devices and Modules"
The Linux way of looking at devices distinguishes between three fundamental device
types. Each module usually implements one of these types, and thus is classifiable as a
char module, a block module, or a network module. This division of modules into different types, or classes, is not a rigid one; the programmer can choose to build huge
modules implementing different drivers in a single chunk of code.
From a Linux User's point of view what this means is that very often they will find that a Linux system will very often now 'recognise' a given device without need for specific drivers, or (hopefully) at least basic OS support will automatically be provided for these devices enabling applications to use them. I'm no expert on Windows having moved to Linux after the Vista debacle (and have never looked back) but I ALWAYS remember having to load device drivers whenever I got a new device even if it were a memory stick (yet had already used other types of memory stick on the computer!)
I believe it's just the way Windows was designed but why that particular way I do not have any idea. I would assume therefore that under Linux, ADB recognises all Android devices under one device type whereas Windows cannot hence the need for numerous device drivers in Windows.
Is it possible to access the USB port on Android phones? (Droid X for example)
Here is my usage case:
Have a USB device attached to the Android phone. The phone listens for data on this USB device. (The USB device is connected to a USB->RS-232 converter that has I/O attached to it)
This would be slick if possible. Does anyone know if this is possible?
Would be slick, yup. Not possible though. There's a feature request for it: http://code.google.com/p/android/issues/detail?id=738
Actually it is possible on a lot of the phones if you are able to install a new kernel with a USB host driver and rig up a custom cabling scheme to provide usb bus power to the device as the phone won't. A few phones even shipped with this capability already live.
I don't know if the Droid X specifically ships with this already, can have it added (if you are able to flash kernels), could have it added but no one has written the host driver yet, or is missing the hardware capability.
You also would need to enable the appropriate usb serial converter device driver (identified by experimenting with the device on a desktop linux box), but that's probably already in the kernel sources and just needs to be selected in the config. You may also need to create a device file for the /dev/ttyUSB0 or whatever and give it permissions appropriate to the application that wants to access it. (This requires root, but if you can reflash the kernel, you can get root)
If you want to pursue this, search the android kernel google group for posts about USB host mode.
One serious downside to putting the USB into host mode is that you loose the adb interface into the phone, which makes working on your projects hard. You'll probably need to either build an adapter for the low voltage debug serial port if there is one (as on G1, mytouch, etc) so you can get a console shell (or just use that instead of USB to talk to your peripheral) or at a minimum set up an ssh and sftp server on the wifi.
Since you want serial anyway, another option people have used is to get a bluetooth-to-serial module from an outfit such as sparkfun.
A bluetooth to serial adapter might solv your problems.
You can find one at https://www.sparkfun.com/products/582. Boards from other companies are also available for example on ebay.