USB backend

Thu Jul 30 06:50:04 UTC 2015

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/20150730/81856efe/attachment-0001.html>