Przejdź do głównej zawartości

Gdy androidowemu urządzeniu ciężko idzie współpraca z linuksem (czy na odwrót?)...

Problem.

Podłączasz urządzenie z Androidem na pokładzie (przykład jednego ze smartfonów Samsunga) do komputera działającego pod kontrolą Xubuntu 13.10 lub 14.04, a urządzenie daje do wyboru tryb MTP ("urządzenie multimedialne")  lub PTP ("aparat fotograficzny"). Któregokolwiek trybu nie wybierzesz, komunikacja między komputerem a telefonem (przechodzenie przez katalogi, zaznaczanie plików do kopiowania itd.) odbywa się tak wolno, że aż prawie wcale...

W czym więc jest problem (którego nie mają telefony dające do wyboru w miarę szybki, acz niewygodny i nielubiany przeze mnie tryb "USB storage")? 

Otóż kiedyś ktoś namieszał w linuksowych bibliotekach (albo ich ubunciakowych wersjach?) - głównie libmtp, mtpfs i fuse - czyniąc je szalenie wolno działającymi. I tutaj jest pies pogrzebany. Głównie.

Co trzeba zrobić?

Rzucić okiem na artykuł "Connect an Android 4.0+ phone/tablet to Ubuntu, the reliable way" i wykonać wszystkie opisane w nim czynności ;-)
Żeby zaś ułatwić sobie życie - nie każdy bowiem lubi wpisywać polecenia w konsoli - można wygenerować sobie skrypty zawierające komendy montujące:

go-mtpfs ~/MyAndroid &

oraz odmontowujące urządzenie:

fusermount -u ~/MyAndroid

i umieścić je  którymś z katalogów dostępnych "na ścieżce", np. /usr/local/bin.
W następnym kroku tworzymy dla tych skryptów aktywatory na pulpicie i - voila! Komunikacja z naszym androidowym młoteczkiem śmiga jak marzenie (widzimy w Thunarze urządzenie pamięci masowej o nazwie MyAndroid)... pod warunkiem, że jesteśmy rootem... Właśnie - w artykule nie wspomniano o jeszcze jednej rzeczy, niezbędnej żeby montowanie i odmontowywanie mógł przeprowadzać Zwykły Użytkownik. Niniejszym zatem uzupełniam artykuł.
Podwyższamy sobie uprawnienia (np. logujemy się na roota lub używamy sudo) i tworzymy plik:

/etc/udev/rules.d/51-android.rules

W pliku tym umieszczamy następującą linijkę:

SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", MODE="0666", GROUP="plugdev"

gdzie XXXX zastępujemy - że posłużę się pewnym uproszczeniem - identyfikatorem naszego urządzenia działającego w trybie MTP ("urządzenie multimedialne"). Zapisujemy plik, upewniamy się, że należymy do grupy "plugdev" (jeśli nie, to sudo adduser $USER plugdev) i restartujemy komputer.
Po ponownym uruchomieniu możemy się cieszyć z szybkiej współpracy androidofona z naszym ulubionym systemem operacyjnym :-)

Jeszcze tylko krótka informacja, skąd wziąć ów identyfikator urządzenia. Otóż jeśli podłączymy nasz telefon do komputera poprzez USB i wybierzemy telefonie tryb MTP, to identyfikator pozyskamy w prosty sposób, wydając w konsoli polecenie lsusb. Przykładowy wiersz (spośród zwykle kilku) wygenerowany przez to polecenie wygląda np. tak (moja klawiatura ;-)):

Bus 002 Device 002: ID 045e:07b9 Microsoft Corp.

Nasz idVendor w tym przypadku to 045e. Proste?

Powodzenia zatem przy zabawie w transfer plików między telefonem a komputerem :-)

Komentarze

  1. Nie lepiej zainstalować np airdroid. Nie musimy podłanczać USB a wszystko leci przez USB z przyzwoitą prędkością.

    OdpowiedzUsuń
    Odpowiedzi
    1. Nawet jeśli weźmiemy pod uwagę połączenie przez WiFi 802.11n, będzie to szalenie wolno w porównaniu z USB 2.0. Tym bardziej, jeśli transmisja odbywa się za pośrednictwem serwerów w internecie. To już lepiej użyć Bluetooth. Ale zawsze to jakaś koncepcja alternatywna.

      Usuń

Prześlij komentarz

Popularne posty z tego bloga

Niesamowicie prosty czujnik zmierzchowy.

Tym razem zero programowania, będzie natomiast nostalgiczno-wspomnieniowy układzik, lekko zmodyfikowany.
Otóż kilka dni temu rozmawialiśmy w gronie znajomych o różnego rodzaju czujnikach zmierzchowych i czujnikach ruchu. Ponieważ należę do tych wariatów, co to hołdują jeszcze owej przestarzałej i kompletnie odrealnionej dziś zasadzie: "po co kupować, gdy można zrobić", stwierdziłem, że poskładam takie coś (czujnik zmierzchowy; sensor ruchu faktycznie lepiej nabyć, choćby ze względu na rozmiary ;)) i być może podłączę do jakiegoś mikrokontrolera. Przypomniało mi się też przy okazji, że znalazłem ostatnio w elektronicznych śmieciach stary fotorezystor (dla niewtajemniczonych: element zmieniający rezystancję, czyli opór elektryczny, pod wpływem działania strumienia światła) RPP130, jeden z kilku pozostałych po montowanych wieki temu układach tranzystorowych do zdalnego sterowania pracą urządzeń za pomocą latarki... No OK, nie było to specjalnie rozbudowane zdalne sterowanie ;)

Android i zewnętrzny moduł GPS

Od kilku dni jestem w posiadaniu smyrfona z Androidem 4.1.1 na pokładzie. Kwestie związane z wyborem systemu roztrząsałem już na G+, a ten artykuł tutaj ma konkretny temat, więc nie będę wyjaśniał po raz n-ty. Po prostu zwyciężyły popularność i ekosystem oraz przywiązanie do produktów sieciowych Google. Mniejsza.

Zbliża się sezon urlopowy :-) Moi podopieczni już mają wakacje, a ja wyjeżdżam wkrótce. W każdym bądź razie wakacje to podróże - samochodem, rowerem, na piechotę, żaglówką, motorówką, samolotem... Zaawansowane urządzenia mobilne przyzwyczaiły nas już do usług lokalizacyjnych, z których najważniejszą jest GPS (na dalszym planie mamy A-GPS, lokalizacje w oparciu o sieci WiFi itp.). Często korzystamy z programów, które w coraz ciekawszy sposób wiążą naszą lokalizację, pobraną z np. GPS-a, z przeróżnymi danymi, nieraz ocierając się o AR.
Każdy współczesny smartfon, a przynajmniej znakomita ich większość, wyposażona jest we wbudowany odbiornik sygnału lokalizacyjnego (GPS, GLONASS…

Po co mi to całe Arduino?

Oczywiście tytuł ma być jedynie prowokacją. Chociaż nie do końca - artykuł jest właśnie poświęcony pracy w Arduino IDE z mikrokontrolerami, ale bez płytek Arduino.
Czym jest Arduino - wiemy wszyscy, zarówno początkujący fani programowania elektroniki, jak i zaawansowani mikrokontrolerowcy. Jeśli jednak nie do końca wiemy, zachęcam do odwiedzenia strony domowej projektu (link 5 na końcu artykułu) oraz zerknięcia np. w poradnik (link 4).

Jakiś czas temu, przełamując się i zmieniając zdanie ("o 180 stopni" ;-)) nabyłem sobie Arduino Leonardo, głównie w celu jego "obwąchania" i zapoznania się z bogatym zbiorem bibliotek dostępnych dla tej platformy. Zgoda, różne biblioteki są dostępne niezależnie od Arduino, ale i tak się zdecydowałem. Dlaczego Leonardo? Otóż miałem ochotę przyrządzić dwie pieczenie na jednym ogniu - mieć Arduino i przetestować ATmegę 32u4. Dziś doskonale zdaję sobie sprawę, że żeby pobawić się Arduino nie trzeba go w ogóle posiadać... Ale po kolei.

Pi…