CP210x (USB to TTL adapter) for Android devices

Few days ago, while searching for something interesting I can do with my Android phone I found out that Sony is publishing kernel source of all their (and old SE ones too) ROMs. Beside hacking the kernel itself I was wondering if it is possible to compile additional kernel modules (stock ROM provides only internal WiFi module’s drivers). Well.. it was. The first one I tried was driver of my cheap, Chinese USB to serial adapter based on CP2102 chip.


  • kernel source – it is important to be the same kernel as the one working on your device. Otherwise it would probably be necessary to boot your system with kernel compiled with source you have and it will not be described in this tutorial. The reason it is important is that between kernel version compatibility is not guaranteed. Different configuration could mess with functionality too (but not tried myself). I have Sony Ericsson device so I downloaded from its official repository.
  • cross-compiler – while compiling programs for Android you definitely should get special version of a compiler because Android is different than usual Linux box so compiler options are different too. The easiest way is to download official NDK which has built-in compilers and easy-to-use script to make standalone toolchain out of them. Same toolchain should also work as compiler for kernel but I haven’t tested it myself. In case it didn’t there is very powerful tool for making your own toolchain for any platform supported by GCC so in practice any you can imagine called crosstool-ng (on Arch available on AUR).
  • uucp source code

Kernel module

We will start with a kernel module. First of all we will unpack our kernel. In case of SE kernel need to be uncompressed and then unpacked so I did:

bzcat 4_1_B_0_431_tar.bz2 | tar -xv
cd kernel

And changed dir to kernel. Next thing I had to do was patching Makefile, because it complained about unused variables. If you are using Sony or SE kernel you probably need to do it too. If so create file named Makefile.patch with your favorite editor, i.e.

vim Makefile.patch

and paste following content:

--- Makefile	2012-05-25 12:07:05.000000000 +0200
+++ Makefile.new	2014-08-20 21:16:50.642703198 +0200
@@ -342,7 +342,6 @@
 KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-		   -Werror \
 		   -fno-strict-aliasing -fno-common \
 		   -Werror-implicit-function-declaration \
 		   -Wno-format-security \

Now you can patch it with:

patch Makefile < Makefile.patch

Then we can start the compilation process which should end in a second. I assume you have working toolchain in your $PATH and it is prefixed with arm-unknown-eabi- (arm-unknown-eabi-gcc, etc.). If its name is different change all occurrences of arm-unknown-eabi- below.

make mrproper
ARCH=arm CROSS_COMPILE=arm-unknown-eabi- make semc_iyokan_defconfig
ARCH=arm CROSS_COMPILE=arm-unknown-eabi- make prepare
ARCH=arm CROSS_COMPILE=arm-unknown-eabi- make modules_prepare
ARCH=arm CROSS_COMPILE=arm-unknown-eabi- make modules SUBDIRS=drivers/usb/serial CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_CP210X=m

If everything worked you should have your module compiled in drivers/usb/serial directory. It is worth to note you could compile any other module the same way. It is only important to change SUBDIRS to your module location and ensure it is configured to be built by issuing make menuconfig or setting appropriate CONFIG-* variable to ‘m’.

Now you can copy modules to your devices. With adb it will be:

adb push drivers/usb/serial/usbserial.ko /mnt/sdcard/others
adb push drivers/usb/serial/cp210x.ko /mnt/sdcard/others

We have two modules to copy here since cp210x (and any other serial device driver) depends on usbserial and without it being already in kernel it would be impossible to insert cp210x and furthermore it will give you strange error message (tested :). So now, again with help of ADB, we can insert our modules.

adb shell
cd /mnt/sdcard/others
insmod ./usbserial.ko
insmod ./cp210x.ko

After that you can connect your device and device you compiled module for and test if it works. Serial adapters should create new device file in /dev and, at least with CP210x, it uses ttyUSB* name so you can list it with:

ls -l /dev/ttyUSB*

You can also read from your port as simply as by typing

cat /dev/ttyUSB0

Now after you connect some device talking UART you should see its output.

Program to easily control our port – cu and the rest of uucp package

Warning: in the following steps I assume that you have directories like /data/local/bin and /data/local/etc already on your device. As far as I remember there is only /data/local by default.

At first we need to unpack our source and create some useful directories. Then we will configure our script in build-uucp so we won’t get garbage in source directory and could easily clean things when something goes wrong.

tar -zxvf uucp-1.07.tar.gz
mkdir build-uucp
mkdir install-uucp
cd build-uucp/

Then we will patch our program so it will work on Android out of the box. If we omitted following patch it would be necessary to create configuration file, configure program to read it before work and whole bunch of similar fun. So it is easier to let him know where he could store his files now. You can obviously use the one you want to. If you stay with my config you won’t be able to start cu as normal user which is no problem because by default you won’t have permission to use serial terminal.

Now the procedure is the same as with previous patch. I assume you used policy.h.patch name and the content is:

--- policy.h	2003-05-29 08:08:45.000000000 +0200
+++ policy.h.new	2014-08-20 12:03:45.595405893 +0200
@@ -297,7 +297,7 @@
    systems the lock files are placed in /etc/locks.  On some they are
    placed in /usr/spool/locks.  On the NeXT they are placed in
    /usr/spool/uucp/LCK.  */
-/* #define LOCKDIR "/usr/spool/uucp" */
+#define LOCKDIR "/data/local/etc/spool/uucp"
 /* #define LOCKDIR "/etc/locks" */
 /* #define LOCKDIR "/usr/spool/locks" */
 /* #define LOCKDIR "/usr/spool/uucp/LCK" */
@@ -572,7 +572,7 @@
 /* The name of the default spool directory.  If HAVE_TAYLOR_CONFIG is
    set to 1, this may be overridden by the ``spool'' command in the
    configuration file.  */
-#define SPOOLDIR "/usr/spool/uucp"
+#define SPOOLDIR "/data/local/etc/spool/uucp"
 /* #define SPOOLDIR "/var/spool/uucp" */
 /* The name of the default public directory.  If HAVE_TAYLOR_CONFIG is
@@ -580,7 +580,7 @@
    configuration file.  Also, a particular system may be given a
    specific public directory by using the ``pubdir'' command in the
    system file.  */
-#define PUBDIR "/usr/spool/uucppublic"
+#define PUBDIR "/data/local/etc/spool/uucppublic"
 /* #define PUBDIR "/var/spool/uucppublic" */
 /* The default command path.  This is a space separated list of
@@ -644,21 +644,21 @@
 /* The default log file when using HAVE_TAYLOR_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``logfile''
    command in the configuration file.  */
-#define LOGFILE "/usr/spool/uucp/Log"
+#define LOGFILE "/data/local/etc/spool/uucp/Log"
 /* #define LOGFILE "/var/spool/uucp/Log" */
 /* #define LOGFILE "/var/log/uucp/Log" */
 /* The default statistics file when using HAVE_TAYLOR_LOGGING.  When
    using HAVE_TAYLOR_CONFIG, this may be overridden by the
    ``statfile'' command in the configuration file.  */
-#define STATFILE "/usr/spool/uucp/Stats"
+#define STATFILE "/data/local/etc/spool/uucp/Stats"
 /* #define STATFILE "/var/spool/uucp/Stats" */
 /* #define STATFILE "/var/log/uucp/Stats" */
 /* The default debugging file when using HAVE_TAYLOR_LOGGING.  When
    using HAVE_TAYLOR_CONFIG, this may be overridden by the
    ``debugfile'' command in the configuration file.  */
-#define DEBUGFILE "/usr/spool/uucp/Debug"
+#define DEBUGFILE "/data/local/etc/spool/uucp/Debug"
 /* #define DEBUGFILE "/var/spool/uucp/Debug" */
 /* #define DEBUGFILE "/var/log/uucp/Debug" */
@@ -669,17 +669,17 @@
 /* The default log file when using HAVE_V2_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``logfile''
    command in the configuration file.  */
-#define LOGFILE "/usr/spool/uucp/LOGFILE"
+#define LOGFILE "/data/local/etc/spool/uucp/LOGFILE"
 /* The default statistics file when using HAVE_V2_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``statfile''
    command in the configuration file.  */
-#define STATFILE "/usr/spool/uucp/SYSLOG"
+#define STATFILE "/data/local/etc/spool/uucp/SYSLOG"
 /* The default debugging file when using HAVE_V2_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``debugfile''
    command in the configuration file.  */
-#define DEBUGFILE "/usr/spool/uucp/DEBUG"
+#define DEBUGFILE "/data/local/etc/spool/uucp/DEBUG"
 #endif /* HAVE_V2_LOGGING */
@@ -692,16 +692,16 @@
    be replaced by the system name (if there is no appropriate system,
    "ANY" will be used).  No other '%' character may appear in the
    string.  */
-#define LOGFILE "/usr/spool/uucp/.Log/%s/%s"
+#define LOGFILE "/data/local/etc/spool/uucp/.Log/%s/%s"
 /* The default statistics file when using HAVE_HDB_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``statfile''
    command in the configuration file.  */
-#define STATFILE "/usr/spool/uucp/.Admin/xferstats"
+#define STATFILE "/data/local/etc/spool/uucp/.Admin/xferstats"
 /* The default debugging file when using HAVE_HDB_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``debugfile''
    command in the configuration file.  */
-#define DEBUGFILE "/usr/spool/uucp/.Admin/audit.local"
+#define DEBUGFILE "/data/local/etc/spool/uucp/.Admin/audit.local"
 #endif /* HAVE_HDB_LOGGING */

If you prefer I have it on my gist so you can just issue one command and get it. Then we are patching as usually:

patch ../uucp-1.07/policy.h < policy.h.patch

As mentioned above you can change path of uucp’s files by issuing the following (remember to escape every occurrence of slash with backslash, otherwise it will fail):

sed -i "s/\/data\/local\/etc/[your-path]/" ../uucp-1.07/policy.h

Now you are ready to compile. It can be done with following commands. Your compiler should have same name (at least if you use NDK’s compiler). It is important to note that I had to switch off HAVE_SYSCONF flag since it was causing ugly errors. In my case makescript couldn’t also find a rule to make ftw.o so I had to make it myself. If you have no trouble here, just omit the line after make.

CC=arm-linux-androideabi-gcc AR=arm-linux-androideabi-ar RANLIB=arm-linux-androideabi-ranlib \
../uucp-1.07/configure --prefix=`pwd`/../install-uucp/ --host=arm-linux-androideabi
sed -i "s/#define HAVE_SYSCONF 1/#define HAVE_SYSCONF 0/" config.h
cd unix; make ftw.o; cd ..; make
make install
adb push ../install-uucp/bin/cu /mnt/sdcard/others
adb shell
cp /mnt/sdcard/others/cu /data/local/bin/

Finally you can test the program with the following and you should be able to talk RS232 with just a phone/tablet!

cu -lttyUSB0 -s115200

where 115200 is the speed the device you connect to transmits.

BTW: uucp have few other tools and by following this tutorial you compiled them all so you can explore them on your own.

Posted in Tutorials | Tagged , , , , | Leave a comment

[Android] Odblokowywanie kanałów 12, 13, 14

Jak wspomniałem w swoim pierwszym wpisie dotyczącym Androida na tym systemie niemożliwe jest połączenie się z siecią działającą na kanale wyższym niż 11 (a więc takim, który jest zabroniony w USA). Ja jednak nie mieszkam w Stanach i chciałbym, aby mój telefon miał dostęp przynajmniej do tego co nie jest w Polsce nielegalne. Na szczęście udało mi się znaleźć rozwiązanie tego problemu.

Użycie tej metody wymaga dostępu do roota, więc jeśli twój telefon nie został jeszcze zrootowany odsyłam do strony Zeely’ego. Kolejnym wymaganiem będzie zainstalowanie do folderu bin sqlite’a (nie wiedzieć czemu ten, który można używać prze adb przestaje działać gdy wpiszemy w konsoli su). Potrzebne też będzie SDK Adroida (będę używał go, aby przeklejać komendy do konsoli, nada się też każdy emulator terminala np. Terminal IDE, ale tu trzeba będzie wszystko pisać ręcznie). Radzę też żeby koniecznie wykonać backup systemu z użyciem CWM (mnie przy pierwszej próbie coś poszło nie tak i musiałem przywracać kopię z poprzedniego dnia).

  1. Podłączamy telefon do komputera w trybie debugowania USB. Wchodzimy w Ustawienia=>Aplikacje i zaznaczamy Debugowanie USB.
  2. Potem należy uruchomić konsolę Windowsa (lub terminal gdy używamy Linuksa) i przejść do folderu, w którym zainstalowaliśmy SDK. Wpisujemy adb shell. Gdy wszystko pójdzie dobrze powinniśmy być już w konsoli naszego telefonu (pojawi się znak $). Można teraz wpisać su, aby uzyskać uprawnienia roota (# oznacza sukces).
  3. Aby móc zmodyfikować folder /system należy zamontować go do zapisu. Używamy komendy mount, aby odnaleźć odpowiednie urządzenie:
    $ mount
    rootfs / rootfs ro,relatime 0 0
    tmpfs /dev tmpfs rw,relatime,mode=755 0 0
    devpts /dev/pts devpts rw,relatime,mode=600 0 0
    proc /proc proc rw,relatime 0 0
    sysfs /sys sysfs rw,relatime 0 0
    tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
    tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
    /dev/block/mtdblock0 /system yaffs2 ro,relatime 0 0
    /dev/block/mtdblock3 /data yaffs2 rw,nosuid,nodev,relatime 0 0
    /dev/block/mtdblock2 /cache yaffs2 rw,nosuid,nodev,relatime 0 0
    /dev/block/mtdblock1 /data/idd yaffs2 rw,nosuid,nodev,relatime 0 0

    Właściwa linia została pogrubiona. Wpisujemy więc mount -o remount,rw -t rfs /dev/block/mtdblock0 /system (uwaga! Wartość po /dev/block/ może być inna).

  4. Teraz przenosimy plik sqlite3 (dostępny do pobrania na końcu wpisu) do folderu, w którym zainstalowane jest adb. Otwieramy w tym samym folderze drugie okno konsoli i wpisujemy w nie adb push sqlite3 /sdcard/ czym kopiujemy sqlite3 na kartę pamięci (tutaj ważne jest, żeby karta pamięci NIE była zamontowana w komputerze tj. w trybie MSC).
  5. Wracamy do poprzedniego okna, w którym wpisujemy cp /sdcard/sqlite3 /system/bin oraz chmod 4755 /system/bin/sqlite3.
  6. Na koniec montujemy system znów do odczytu: mount -o remount,ro -t rfs /dev/block/mtdblock0 /system.
  7. Teraz możemy wpisać sqlite3 i sprawdzić czy wszystko poszło pomyślnie. Jeśli tak przechodzimy do modyfikacji właściwego pliku.
  8. Zostajemy w tej samej konsoli (tą drugą można już zamknąć). Wpisujemy: sqlite3 /data/data/com.android.providers.settings/databases/settings.db “INSERT INTO secure (name, value) VALUES (‘wifi_country_code’, ‘JP’);”. Gdybyś nie chciał odblokowywać bądź co bądź zakazanego w Polsce kanału 14 możesz zmienić JP na EU w powyższej linii.
  9. Restartujemy telefon. Gdy system włączy się kanały 12,13 i 14 powinny już zostać odblokowane i powinno być już możliwe połączenie się z siecią na tych kanałach.

Nie jestem w stanie tego teraz sprawdzić, bo już zainstalowałem sqlite3 powyższą metodą, ale najpewniej, aby dokonać jego instalacji wystarczyłoby użyć jakiegokolwiek menadżera umożliwiającego modyfikację folderu /system. Potem wystarczyłoby tym samym programem zmienić chmody tak, aby możliwe byłoby wykonywanie pliku. Tym samym możnaby wtedy pominąć punkty 3-6.

Posted in Tutorials | Tagged , , , , , , , | Leave a comment

Android – pierwsze wrażenia z przesiadki na nowoczesny smartfon

Niedawno minął miesiąc odkąd stałem się użytkownikiem smartfona z tym systemem. Platforma ta ma oczywiście mnóstwo zalet i stanowi znaczny postęp w stosunku do używanego przeze mnie do tej pory Symbiana. Zalety te są niewątpliwe i nie będę się na ich temat rozpisywał. Zamiast tego zajmę się tym co nie działa tak jak powinno lub w Symbianie było rozwiązane lepiej niż tu.

Jeżeli chodzi o sam telefon to nie miałem zbyt dużego wyboru, bo jako warunek konieczny uznałem klawiaturę QWERTY, która nie jest zbyt popularna więc i ilość modeli była dość ograniczona. Ostatecznie padło na SE Xperia Pro co już teraz mogę powiedzieć było strzałem w dziesiątkę bo jak się okazało jedyne środowisko umożliwaiające pisanie programów dla Androida bezpośrednio na Androidzie nie ma wirtualnej klawiatury a dzięki temu, że mam fizyczną to nie jest dla mnie problemem więc będę mógł pisać apki bez testowania ich najpierw na emulatorze. Zacznę jednak od początku.


Pierwsze niemiłe zaskoczenie spotkało mnie już dosłownie po paru sekundach po włączeniu telefonu. Każdy nowoczesny telefon byłby bezużyteczny gdyby nie posiadał dostępu do Internetu. Pierwszą rzeczą bylo więc połączenie się z domowym routerem. I tu właśnie spotkało mnie owo niemiłe zaskoczenie. Odnalezienie ustawień sieci nie było problemem mimo, że jest według mnie bardziej skomplikowane niż w wypadku starej dobrej Nokii. Potem jednak okazało się, że telefon nie widzi mojego routera mimo, że znajdował się w odległości metra od niego. Jak się później okazało model ten (nie wiem czy to ogólny problem wszystkich zielonych robotów) jest przystosowany do przepisów chyba wszystkich krajów w jakich jest oferowany czego konsekwencją jest to, że moduł wifi (albo jego soft) obsługuje tylko te kanały, które są dozwolone wszędzie,czyli te z numerami od 1 do 11. Oczywiście mój router, aby nie zakłócały go routery sąsiadów działał na mało popularnym kanale 13 co było powodem braku jego widoczności.

Menadźer plików

Kolejny problem popjawił się niewiele później. Jak na kogoś kto wie co nieco o bezpieczeństwie router mam zabezpieczony hasłem o maksymalnej długości(63 znaki, w tym znaki specjalne). Nie chcąc przepisywać tego czegoś ręcznie przeniosłem plik z hasłem na kartę pamięci. Następnie zacząłem przeglądać menu w poszukiwaniu jakiegoś menadżera, który byłby w stanie odczytać plik z karty. Co się okazało nic tego typu nie jest preinstalowane na urządzeniu!!! Już w starym Symbianie taka funkcja była dostępna na czystym systemie. Jak się później okazało część funkcjonalności eksploratora przejął program o nazwie OfficeSuite. Sprytne. Ciekawe tylko kto na to wpadnie nie włączając wszystkich programów po kolei albo nie czytając instrukcji, której tak naprawdę nie ma (w pudełku jest tylko standardowy QuickStart Guide i info, że instrukcja jest dostępna na stronie producenta). Ostatecznie więc musiałem przepisać hasło ręcznie (OfficeSuite’a znalazłem potem) za co system dostałby ode mnie kolejnego minusa.

Google Play

Właściwie powinienem o tym czymś napisać dopiero później bo najwięcej problemów zaczął robić dopiero po rootowaniu systemu, ale napiszę już teraz jako, że póki co piszę o czynnościach dla mniej technicznych użytkowników. Oczywiście nie spodziewałem się po Google nic więcej. Program ten do działania wymaga zalogowania się na konto Google a więc de facto to jakie mamy zainstalowane apki dołącza do ogromnej bazy danych jakie ten gigant przechowuje na nasz temat. W moim wypadku są to jedynie maile na konto na które loguję się tylko przez Tora i to raz na miesiąc albo i rzadziej więc dla mnie to żaden problem. W normalnej sytuacji ograniczenie pobierania aplikacji wyłącznie do urządzeń z Androidem z powiązanym kontem Google nie stanowiłoby problemu jednak po zrootowaniu znów pilnie potrzebowałem Menadżera plików, aby odczytać hasło do wifi z pliku na karcie. Oczywiście było to niemożliwe! Tym razem udało mi się dojść czym jest ten cały OfficeSuite.


Jako użytkownik potrzebujący z każdej platformy nieco więcej niż jest w stanie dać producent po paru dniach zabawy i zapoznawania się z systemem przyszedł czas na rootowanie systemu. Znalezienie dobrego poradnika jak tego dokonać nie stanowiło większego problemu. Użyłem tego napisanego przez Zeely’ego jako że był po polsku czym dawał gwarancję, że po całej operacji będę nadal miał systemu w tym języku. I tu znowu kolejne bezsensowne utrudnienie ze strony producenta. Aby dokonać całej operacji należy zainstalować starszy firmware, bo w najnowszym luka pozwalająca rootowanie została załatana. Szkoda tylko, że aktualizacja do ICS nie przebiega w równie szybkim tempie jak ta blokująca uwalnianie systemu. Oczywiście downgrade spowodował, że wszystkie ustawienia, zainstalowane programy itp. przepadły “dzięki” czemu musiałem od nowa ustanawiać połączenie internetowe. Google Play zapamiętał wszystkie programy, które miałem zainstalowane za co tu muszę go pochwalić. Nie usprawiedliwia to i tak trzymania tego typu danych na czyimś (tu: Google’a) serwerze. Po pomyślnym zrootowaniu urządzenia przyszedł czas na ClockworkMod Recovery. Tu też użyłem poradnika od Zeely’ego, bo był akurat pod ręką. Ta część nie sprawiała żadnych problemów, zapewne dlatego, że Google nie mogło maczać w tym swoich palców. Po instalacji przyszedł czas na backup (bo do tego ten program zainstalowałem).


Następnym krokiem ku używalności nowej zabawki było znalezienie programu do skanowania sieci wifi. Ponieważ jak każdy współczesny telefon tak i ten ma wbudowany moduł GPS skanowanie takie powinno oczywiście odbywać się wraz z logowaniem współrzędnych sieci. I tu oczywiście pojawia się kolejna Googlowa niespodzianka. Jak większość bzdur wprowadzonych przez tą firmę ma oczywiście wpływ na prywatność użytkowników. Mianowicie po zaznaczeniu opcji używania GPSa do lokalizacji pojawia się informacja o konieczności zgody na anonimowe wysyłanie danych (WTF?). Ale dobra wifi poza zasięgiem, karty SIM nie ma więc zgadzam się, niech stracę.


Tu Android wypada jednym słowem żałośnie. Po systemie opartym na linuksie można się spodziewać, że aplikacji do wyszukiwania i przede wszystkim zapisywania sieci z okolicy będzie mnóstwo. Okazuje się jednak, że tego typu narzędzia można policzyć na palcach jednej ręki (no chyba, że nie umiem szukać tak jak przy Symbianie gdzie znalezienie barbelo zajęło mi parę tygodni). Jedyny program, który wydawał mi się do przyjęcia (chociaż na pewno nie dobry) to G-mon powiązany z jakimś niemieckim forum wardriverów. Cóż, nie mając innego wyboru zainstalowałem to coś. Niestety po paru skanach zaczął o sobie przypominać ten nieszczęsny GPS. Nie wiem czy to normalne aby do odnalezienia pozycji potrzebe było aż 12 satelit?


Element niezbędny tym bardziej, że coraz częściej słyszy się o szpiegujących aplikacjach a nawet potencjalnym wykorzystaniu nowoczesnych telefonów jako pluskiew. Swoją drogą takie CIA czy NSA pewnie nawet nie marzyła kiedyś o tym, że nastaną takie czasy, że praktycznie każdy będzie nosił w kieszeni podsłuch możliwy do aktywowania w każdym momencie (a nie wierzę żeby amerykańskie służby nie były w stanie zmusić amerykańskiej firmy do wbudowania jakiegoś backdoora, niby to OpenSource ale przecież są w Androidzie też dodatki od producentów, które OpenSource już nie są). W każdym razie początkowo jako Firewalla używałem Avasta, do którego jakoś przyzwyczaiłem się przez parę dobrych lat korzystania z niego na desktopie. Później jednak zauważyłem, że po ustawieniu trybu białej listy nie mogę pobrać nic z marketu więc zdezaktywowałem zaporę w Avaście i zainstalowałem DroidWall, w którym udało mi się znaleźć program, który był odpowiedzialny za pobieranie programów (oczywiście pomogła mi funkcja wyświetlania logów, tak jak w poprzednim wpisie, co potwierdza wniosek z jego końca).


Na koniec praktycznie parę dni temu zainstalowałem GoLauncher EX zastępujący domyślny pupit dostarczany przez SonyEricssona. Ciągle jednak nie pasuje mi sposób uruchamiania latarki, która czasami się przydaje a teraz żeby ją włączyć muszę odblokować ekran co wydaje mi się zbędne. Jako, że zdążyłem się już nauczyć co nieco programowania pewnie jeszcze spróbuję sobie poradzić z tym problemem, ale to już będzie temat na osobny wpis.

Posted in Uncategorized | Tagged , , , , , , , , , , , | Leave a comment