I want to support my app on as many devices as possible, including those with stock ROMs.
The problem I face is that there is no easy way to access the Bluetooth HCI API as should be found in the Bluez libbluetooth. IE such APIs as hci_get_route(), hci_open_dev(), hci_send_req(), etc.
I CAN do the above from my app on phones that have the "hcitool" binary (such as CM). I can also access the APIs directly from a daemon that my app communicates with.
But my app can't use the HCI apis directly.
But the much BIGGER problem is that most devices with TI or Broadcom BT chips have stock ROMs that do not contain hcitool, and that can't use a copied hcitool, and that don't support the HCI apis anyway.
AFAICT these devices use proprietary BT stacks. Instead of hciattach, Broadcom BT devices use btld and TI devices use btipsd.
Perhaps those proprietary daemons allow direct HCI access through their APIs. I don't know, but even if they do, I don't like using such undocumented APIs. They may be different and broken in different ways on different devices.
One thought I have is some sort of shim/adapter that goes between the daemon and the HCI UART and can inject packets using whatever SLIP or PPP or whatever the protocol is. Yes this is nasty and requires root.
Does anyone know if D-BUS support raw HCI access ?
Any other ideas ?
Thanks !
Related
any chance that someone will crack to access sockets for RDP etc.?
Take a look at the "Functional Webserver" project by Davux. It uses TCP sockets. The actual socket library is from another developer, and is basically a native ARM wrapper around WinCE's WinSock API which in turn exports that functionality to COM. Throw in some code from Mono and you have a working TCP socket implementation. I'm using it myself, in an as-yet unreleased backup app.
No support for UDP just yet, but TCP works fine. The source to "Functional Webserver" is available (you can also get a slightly tweaked version of the same library in my "IE Search Switcher" app, although I'm not using the socket support there). It's only the C# source and a pre-compiled ARM binary - no C++ source, or I might have already added UDP - but if you look hard enough you can probably find that too (or maybe I should...)
Hello *,
a customer asked me to develop an app for Android tablets that should use an external USB webcam (UVC). The app should target any consumer tablet that has a USB Host interface and MUST NOT require rooting.
According to API level 12 docs or Android 3.1, it is possible to use any external USB device.
Until here is theory. Is it actually possible, in practice, and how hard can it be to write java code that implements a UVC driver in user space? The UVC standard documents are hundreds pages long and I fail to understand how much of that specs need to be implemented on the host side, and how much is eventually already implemented in the Android Linux kernels.
Hi All,
I would like to know if I can use open80211s with the BCM4329 chipset? From the research I've done, the BCM4329 is a FullMAC device, not a SoftMAC device. The open-source linux driver that can work with the BCM4329 chipset is the brcmfmac. Therefore, it does not use the mac80211 framework. The brcmfmac driver is integrated with cfg80211. Since open80211s is based off the mac80211 stack, does this mean open80211s can never be used with brcmfmac? Is it possible to interface the open80211s code directly with cfg80211? Would the cfg80211 api provide all the necessary callbacks in order to acheive
mesh functionality? If this is possible, does anyone have an idea of how much time this effort would require?
Additionally, looking at the documentation on the b43 driver, the
website says that all BCM43xx are supported by the b43 driver. The b43 driver does support
open80211s, so I am confused as to whether I can use this driver for the BCM4329 device, although the device list doesnt have BCM4329? Has anyone used the b43 driver for the BCM4329 chipset?
Are there any other options for getting 802.11s support with the BCM4329 chipset?
Any other options for mesh networking? I have heard of olsrd for android, but wondering if people had experience with that, or if they had any recommendations for anything else.
Thanks in advance,
Kiran
Hi,
I'm currently in the process of building linux-wireless drivers for the Sensation (with a bit of HTC code too!).
They'll support mesh fine - but I think the current drivers already do/can? try Batman, if you haven't already.
Hi,
is there a displayLink Software for the RT?? I have an Dockingstation with an extern SCreen and i really would like to use it, but this will only work with DisplayLink Software. So is there a solution for the RT??
Thanks a lot
HandyBesitzer said:
Hi,
is there a displayLink Software for the RT?? I have an Dockingstation with an extern SCreen and i really would like to use it, but this will only work with DisplayLink Software. So is there a solution for the RT??
Thanks a lot
Click to expand...
Click to collapse
Nope- no DDK for WinRT, so no one can make third-party hardware that doesn't fit the preloaded driver set:
http://www.displaylink.com/support/ticket.php?id=335
Well, no public DDK. There's (quite obviously) an internal one, and it has apparently been shared with certain partners, and a copy of it has leaked onto the Internet and been found (and occasionally used) in various places. That said, even if a commercial outfit were willing to entertain the use of such a thing, they would need to get the resulting driver signed by Microsoft for it to be installable on non-"jailbroken" RT devices.
this signing thing is really terrible. is there a chace to get such a driver in future??
GoodDayToDie said:
Well, no public DDK. There's (quite obviously) an internal one, and it has apparently been shared with certain partners, and a copy of it has leaked onto the Internet and been found (and occasionally used) in various places. That said, even if a commercial outfit were willing to entertain the use of such a thing, they would need to get the resulting driver signed by Microsoft for it to be installable on non-"jailbroken" RT devices.
Click to expand...
Click to collapse
Right, so effectively no DDK for general peripheral manufacturers to use unless MS decides otherwise for that device-- hence the situation with USB Ethernet adapters (and the driver that Plugable released then had to pull).
I'm a bit puzzled by the situation-- if MS' concern is that poor drivers would affect the WinRT user experience, then presumably they could enforce a testing process (as they already have w/ WHQL) and only allow driver delivery through Windows Update.
As it stands, WinRT devices, running full-blown Windows, are ironically far less useful in custom applications than iPads, which have all sorts of accessories available. Why wouldn't MS want WinRT to be usable in, say, medical settings? (even iPhones, let alone iPads, can connect to hardware accessories like medical sensors).
Android's also catching up quickly in the accessories space, and it's only a matter of time before iOS/Android destroy any advantage MS had w/ hardware manufacturers, as happened so dramatically in the software space (there are now so many more devs who've worked with iOS and Android than have with modern MS platforms).
Well, for accessories that just need "traditional" data I/O - things like what you might have done over a serial port in days of yore - you can easily use either BlueTooth or the audio jack (although the latter is a real hack, usually used only for very small dongles powered by the audio signal). The iPad is definitely less extensible with third-party hardware (note, accessorizable != extensible) than RT, but I fully agree with you that Microsoft's stance on RT drivers is just plain weird. Keep the pool smallish and/or WHQL-test the crap out of them, but make them available! Those USB ports can and should be a killer feature.
The audio channels available on many consumer devices are often perfect for bit banging various communications protocols. UART "emulation" has often been done on the headset jack with a level shifter and some trickery, often on android devices much less powerful than the surface RT (seen a demo on an 800MHz single core ARMv6 handset). If your willing to sacrifice audio output from your application on the RT (as it is being used for bit banging the UART) then you essentially have a plug and play serial port without any special drivers needed, your application just needs to be able to generate an audio signal and analyse an input. the peripheral will need an external power supply but this is common on many legacy RS232 applications too.
There is the bluetooth serial port profile. Thats often used as a replacement for RS232 or UART. I dont know if windows RT supports it though (someone would have to check).
Another trick I have seen involves a microcontroller with USB capabilities. I have seen examples of people setting a microcontroller to appear as USB mass storage and having a small file system with 1 plain text file. Writing into this text file from windows or linux etc would then cause the microcontroller to perform a particular operation in response. Sensors can also be read by the microcontroller causing it to update the text file too. You essentially have file based GPIO without.
Its all rather hacky but it works technically.
There is also an i2c bus on the RT keyboard connector.
I'm looking for Android Bluetooth / TCP/IP relay application.
-- Details --
I'm looking for RDP client which would be able to relay / bridge Bluetooth devices / peripherals to the RDP host (Windows server 2008 R2).
If there's no such RDP client, wehave a secondary option. Having separate background service which takes care of the data relaying part in background, and leaves the RDP connection / device display to foreground as completely separate process.
I've been planning developing such application. But if possible, I want to avoid re-inventing the wheel. Even if it sounds really simple, I'm sure there will be (too?) many problems before it works reliably.
I'm very curious to know, if such application already exists and where would I get it. I'm quite sure that someone has already made such an application. I just don't know where to look for it.
Additional bonus would come, if the application is quite easy to configure and if the sessions between RDP and this relay are easy to link and access on Windows server end.
As addition to the bluetooth relay, it would be nice to have a simple TCP/IP tunnel / bridge / relay feature in same packet. Allowing access to devices using TCP/IP without bluetooth using same app.
If it's true that such application doesn't exist. Would there be an market for such application if it's created? I could imagine I'm not the only person looking for such app.
I do have additional documentation & specification for there requirements, but I don't want to share it right here. I've been also discussion about this topic with a few Android Application developer companies, but as you might guess, this project won't be cheap. Therefore I'm looking for reasonably priced existing solution.
Here's simple use case sample. Customer is using industrial data collection solution where there are ten sensors attached to something being monitored which are then connected to tablet over bluetooth or wi-fi (TCP/IP). But the actual data processing / logging / control software is running on Windows server and can be accessed using RDP. Of course one solution would be using a full featured Windows laptop instead of that tablet, but we don't want to do that. So this expains what I'm looking for in more detail.
- Thank you
-- Footer --
KW: business, software development, android, thinclient, tablet, bluetooth, wifi, wlan, mobile
HTag: #android #peripheral #connectivity #remotedesktop #remotedesktopclient #softwaredevelopment #bluetooth #tablet #thinclient