USB backend

Sun Jun 12 11:37:27 UTC 2016

Picking this up again!

I had a look again at both your code and the official Android Accessory
SDK. It seems that the Accessory SDK allows you to open a socket to talk
between the two ends. Your implementation using libusb is nice because we
don't need to depend on the Accessory SDK but doesn't provide that simple
socket abstraction. How can we communicate the two devices after connecting
them with your approach? I like the idea of using the USB cable when
possible to reach a device, and if we manage to abstract it to a simpe
socket it should be super easy to implement, but I don't see how to do it.

Albert
On Jul 30, 2015 8:50 AM, "Floris Stoica-Marcu" <floris.sm at gmail.com> wrote:

> Awesome, so here is the link to the repo:
>
> https://github.com/SMFloris/qt-android-accessory
>
> Few mentions:
> 1. The device needs to be in some sort of transfer mode other than the
> install-mode (the one with the drivers for windows); MTP and USB 3.0 mode
> work fine
> 2. After putting the phone in accessory mode, it gets the vID-18d1
> (Google) and a *seemingly random* pID I am unsure what will happen if I
> connect 2 Samsung devices (one of them got drained), for example, because
> they might get the same pID after being in accessory mode. So our Device
> class should also include hardware addresses/ports together with original
> pIDs and vIDs
> 4. The code works for already connected devices as well!
> 5. I tested on the Galaxy S5, S2, an Allview P5 and a Serioux tablet; The
> two Galaxies had the exact same pID in their USB modes (6860 for MTP and
> USB 3.0). It should work with all Android devices with a supported API >=
> 10 (if we also use the support library, otherwise it is >= 12)
> 3. In order for the code to work, make sure you have at least
> libusb>=1.0.16
>
> On 29 July 2015 at 23:36, Albert Vaca <albertvaka at gmail.com> wrote:
>
>> Either post a review board with the code [1] or push it to a github repo
>> and send the link.
>>
>> [1] http://reviewboard.kde.org/
>>
>> On Wed, Jul 29, 2015 at 12:44 PM, Floris Stoica-Marcu <
>> floris.sm at gmail.com> wrote:
>>
>>> No, actually, I managed without! xD
>>>
>>> I made a libusb hotplug thingy that scans every usb device and tries to
>>> connect with it via the Android Accessory API. Every new device is also
>>> handled once it is plugged in (or out). It works, but I ran into problems
>>> integrating it into kdeconnect itself.
>>>
>>> Where can I upload the UsbServer I made so we can discuss how to
>>> integrate it? I tried to follow some guidelines regarding how providers and
>>> devicelinks work. For now, this is all it does (I still need to write the
>>> android part in java), it puts the phone into accessory mode :)
>>>
>>> The transfers are capped for Android at 16384 unsigned chars, but will
>>> have to write the Java part to test properly.
>>> Do you need to have a list of all Android vendor IDs for it to work? :S
>>>
>>> On Mon, Jul 27, 2015 at 12:05 PM, Floris Stoica-Marcu <
>>> floris.sm at gmail.com> wrote:
>>>
>>>> Actually the pairinghandler works great since I use Libusb to pair them
>>>> up. Any advice as to what is the best way to implement the vendor/product
>>>> ids? So far I have only the list of vendor ids (bottom of page):
>>>>
>>>> http://developer.android.com/tools/device.html
>>>>
>>>> I also noticed that the phone has different product ids, depending on
>>>> what usb mode it is set to.
>>>>
>>>> On 27 July 2015 at 20:15, Albert Vaca <albertvaka at gmail.com> wrote:
>>>>
>>>>> Cool!
>>>>>
>>>>> Note that we are refactoring some of the backends code, so we might
>>>>> need to make some changes to what you are implementing before we can merge
>>>>> it. Namely, we have split the pairing code into a "pairing handler" class,
>>>>> so every backend can implement its own way to pair. It would be nice if you
>>>>> could have a look at this branch with the changes [1] and see if they make
>>>>> sense for you and for your new backend.
>>>>>
>>>>> https://github.com/grgvineet/kdeconnect-kde/tree/pairinghandler
>>>>>
>>>>>
>>>>> On Mon, Jul 27, 2015 at 3:34 AM, Floris Stoica-Marcu <
>>>>> floris.sm at gmail.com> wrote:
>>>>>
>>>>>> Yes, a socket implementation is more than possible. I looked over the
>>>>>> current backends so it should function almost the same.
>>>>>>
>>>>>> You are right regarding the USB detection, it would be nice to get
>>>>>> the connected android devices from Dolphin somehow. Currently for the
>>>>>> testing I am doing I am providing the vendor id and pid manually. Weirdly
>>>>>> enough the VendorID changes from time to time ... I have Samsung Galaxy S5
>>>>>> and sometimes the VID is 0x04e8, sometimes its 0x04E8.
>>>>>>
>>>>>> The good news is that the accesory API does not interfere with MTP,
>>>>>> so you can have both at the same time.
>>>>>>
>>>>>> I'll get back with some sample code tomorrow!
>>>>>>
>>>>>> Floris.
>>>>>>
>>>>>>
>>>>>> On 27 July 2015 at 03:47, Albert Vaca <albertvaka at gmail.com> wrote:
>>>>>>
>>>>>>> Users should not have debugging enabled on their phones, so the ADB
>>>>>>> approach doesn't seem a good option. I have no idea about what you can do
>>>>>>> with the Android accessories API, but it sounds better even if old phones
>>>>>>> are not supported. Can you implement whatever protocol you like on top of
>>>>>>> that API? Basically what we need is to open a socket between the PC and the
>>>>>>> device. Do you think it can do that?
>>>>>>>
>>>>>>> And something related: right now when you connect your phone through
>>>>>>> USB, we are not smart enough to know that the phone connected by USB and
>>>>>>> the phone connected by KDE Connect are the same phone, and Dolphin displays
>>>>>>> it twice. That is: you end up with two interfaces to send files, one that
>>>>>>> works through MTP and another through KDE Connect. I think that's a bad
>>>>>>> user experience and we should get to a point where we are able to show the
>>>>>>> phone only once in Dolphin, and when the user wants to send a file we use
>>>>>>> the better communication channel we have available (probably MTP). For me,
>>>>>>> this would be the final goal for USB integration in KDE Connect :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 25, 2015 at 8:36 PM, Floris Stoica-Marcu <
>>>>>>> floris.sm at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> So I've recently been experimenting with some USB connection
>>>>>>>> methods for Android. I would like your opinion on what is best to implement
>>>>>>>> for KDE Connect. I found two ways that could work, each with their own
>>>>>>>> advantages and disadvantages:
>>>>>>>>
>>>>>>>> 1. An USB backend through adb ( would require the user to have it
>>>>>>>> installed, but will work on most Android versions) [0]
>>>>>>>> 2. An USB backend that takes advantage of the whole Android
>>>>>>>> accessory API. Writing the PC stuff in libusb it is possible to essentially
>>>>>>>> turn the whole computer into an Android accessory, that can transfer bytes
>>>>>>>> and whatnot to and from the Android device. ( will work only on newer
>>>>>>>> versions of Android, but the user will not have to install anything extra )
>>>>>>>> [1]
>>>>>>>>
>>>>>>>> Quick note on the method through adb, it also requires to have the
>>>>>>>> device in usb-debugging mode. There is also the method of the custom usb
>>>>>>>> driver, but I determined it to be far too fidgety (especially if you
>>>>>>>> already have some drivers intalled).
>>>>>>>>
>>>>>>>> I will attach some resources on the topics:
>>>>>>>> [0]
>>>>>>>> http://qtcstation.com/2011/03/connecting-android-to-the-pc-over-usb/
>>>>>>>> [1] http://source.android.com/accessories/custom.html
>>>>>>>>
>>>>>>>> What method would be the most convenient for KDE connect?
>>>>>>>>
>>>>>>>> Floris.
>>>>>>>> --
>>>>>>>> Stoica-Marcu "FlowRiser" Floris-Andrei
>>>>>>>> floris.sm at gmail.com
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> KDEConnect mailing list
>>>>>>>> KDEConnect at kde.org
>>>>>>>> https://mail.kde.org/mailman/listinfo/kdeconnect
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Stoica-Marcu "FlowRiser" Floris-Andrei
>>>>>> floris.sm at gmail.com
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Stoica-Marcu "FlowRiser" Floris-Andrei
>>>> floris.sm at gmail.com
>>>>
>>>
>>>
>>
>
>
> --
> Stoica-Marcu "FlowRiser" Floris-Andrei
> floris.sm at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20160612/5401359f/attachment.html>