Informatyka

Katedra Sieci Komputerowych

Programowanie Systemowe i Sieciowe

Łukasz Domeradzki

Nr albumu 10464

ArchiDroid - zoptymalizowany systemoperacyjny na urządzenia mobilne

Praca inżynierska

Promotor mgr inż. Michail Mokkas

Warszawa, 25 stycznia 2016

Streszczenie 1

Streszczenie

Celem niniejszej pracy było stworzenie uniwersalnego systemu operacyjnego na ba-

zie Androida, o nazwie ”ArchiDroid”, będącego w stanie stanowić alternatywę dla sys-

temu dostarczonego przez producenta. Za cel wybrano dwa urządzenia różnych marek -

Samsunga Galaxy S3 oraz Sony Xperia M.

W pracy został szczegółowo opisany przebieg implementacji, zawierający także na-

potkane problemy oraz utrudnienia. Z powodu ogromnej złożoności systemu, większość

pracy skupia się na wprowadzonych zmianach w stosunku do Androida, którymi Archi-

Droid wyróżnia się na tle innych podobnych rozwiązań.

Opisano również fazę testów, wraz z opinią wybranej grupy użytkowników na ła-

mach portalu xda-developers.com, a także możliwą przyszłość projektu.

Spis treści

1 Wstęp 3

2 Cel i zakres pracy 6

3 Podobne rozwiązania 73.1 CyanogenMod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 OmniROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Inne systemy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.4 Dlaczego ArchiDroid? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Warstwa niższa 104.1 ArchiKernel - Jądro systemowe Linux . . . . . . . . . . . . . . . . . . . . 124.2 CyanogenMod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 Własny kompilator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Flagi optymalizacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Warstwa wyższa 205.1 AROMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.1 Adblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2.2 Haveged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2.3 Pocket Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3 Aplikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Testy systemu 35

7 Opinie użytkowników 40

8 Przyszłość projektu 41

9 Podsumowanie i wnioski 42

Spis rysunków 43

2

Rozdział 1

Wstęp

W dobie postępującej technologii praktycznie przez cały czas mamy przy sobie urzą-

dzenie zapewniające komunikację ze ”światem zewnętrznym”, telefon komórkowy, który

wyewoluował do dzisiejszej postaci znanej pod nazwą smartphone’a. Telefon ten stał

się przenośnym komputerem, a funkcja komunikacji, która niegdyś była jedynym celem

posiadania przy sobie komórki, stała się tylko jedną z co najmniej tysiąca funkcji, które

dzisiaj są dostępne na wyciągnięcie ręki. Tym samym, wraz z postępującą technologią,

zarówno hardware, jak i software, zaczął stawać się coraz bardziej skomplikowany.

Głównym problemem, który dotyka nieco bardziej zaawansowanych użytkowników

smartphone’ów z systemem operacyjnym Android, jest relatywnie krótkie wsparcie za-

pewniane przez producenta, które wynosi najczęściej około dwóch lat. To z kolei prze-

kłada się na brak aktualizacji systemu operacyjnego, co jest przede wszystkim zabiegiem

marketingowym, aby zmusić użytkownika do zakupu nowszego modelu danego produ-

centa, nawet jeśli hardware użyty w obecnie posiadanym modelu w pełni wystarcza do

wszystkiego, z czego korzystamy, a pomijając wymagające gry, tak najczęściej właśnie

jest. Kupując komputer stacjonarny czy laptopa, mamy dostęp do ogromnej ilości syste-

mów operacyjnych, przede wszystkim Windowsa oraz GNU/Linuxa. Pomimo starzenia

się technologii użytej w używanych podzespołach, nie ma żadnych ograniczeń (poza

sprzętowymi) co do systemu operacyjnego, którego mamy zamiar używać. Nie jest za-

tem problemem zainstalować na dziesięcioletnim komputerze jednej z lekkich dystrybucji

GNU/Linuxa, i korzystać ze wszystkich jego funkcjonalności, włącznie ze wszystkimi ak-

tualizacjami bezpieczeństwa, o ile sprzęt na to oczywiście pozwala.

Z androidowymi smartphone’ami tak już niestety nie jest - jesteśmy uzależnieni od

tego co wyda producent, a zatem można założyć, że telefon bez wsparcia jest całkowicie

uśmiercony, a my nie mamy możliwości korzystać z nowej funkcjonalności wprowadzonej

w kolejnym wydaniu Androida, nawet jeśli hardware nam na to pozwala. To niestety

3

Wstęp 4

stanowi pewien rodzaju paradoks, ponieważ mając czysto teoretycznie otwarto-źródłowy

system operacyjny na telefonie, nie jesteśmy w stanie zaktualizować go do wyższej wersji,

co przekłada się na wykupienie pewnego rodzaju ”usługi” świadczonej na okres X lat,

aniżeli urządzenia, które kupujemy na własność. Oczywiście, telefon nadal będzie działał,

ale bez wsparcia producenta szybko stanie się podatny na wszelkiego rodzaju zagrożenia

bezpieczeństwa, które momentalnie dyskwalifikują urządzenie jako bezpieczne do użytku.

To tak, jakbyśmy nadal korzystali z Windowsa 98 i nazywali go ”bezpiecznym”.

Do tej pory powstało co najmniej kilka rozwiązań tego problemu, przede wszyst-

kim projekt CyanogenMod, który jest otwarto-źródłowym oprogramowaniem na bazie

Android Open Source Project (AOSP), co jest możliwe dzięki temu, iż Android jest

również systemem otwarto-źródłowym, podobnie jak i GNU/Linux. Niestety, wspar-

cie CyanogenModa jeśli mówimy o konkretnym urządzeniu jest ogromnie uzależnione

od jego popularności wśród developerów, podzespołów użytych do jego produkcji, oraz

polityki samej firmy - producenta. Jedynie nieliczna część urządzeń jest wspierana na

”dobrym poziomie”, przez co rozumie się, że system zapewnia pełną zgodność z da-

nym urządzeniem i wszystkimi jego podzespołami oraz ich funkcjami. Na tą chwilę,

najlepiej wspieranymi urządzeniami jest seria Nexus od Google, jest to spowodowane

przede wszystkim dużą popularnością wśród developerów, a także polityką samej firmy,

który udostępnia wszystkie potrzebne komponenty potrzebne do zbudowania systemu

ze źródeł, poza kilkoma własnościowymi implementacjami, np. bootloaderem, firmwa-

rem kamery itp. W przypadku większości urządzeń, niestety tak nie jest. Za przykład

możemy wziąć jednego ze starszych flagowców od Samsunga - Galaxy S3, który będzie

głównym rozpatrywanym urządzeniem w niniejszej pracy. Sytuacja w tym przypadku nie

wygląda już tak różowo. Popularność urządzenia była w pewnym momencie szczytowa

(flagowiec), ale niestety polityka samej firmy w stosunku do developerów jest bliska zeru,

a komponenty użyte do produkcji danego urządzenia (Exynos 4412) zgodnie z polityką

firmy nie należą do zbyt ”otwartych” na developerów. To przekłada się na potrzebę

odwoływania się do reverse-engineeringu i jakichkolwiek skrawków kodów źródłowych

przeznaczonych na daną platformę. Problem potęguje fakt absolutnego braku zaintere-

sowania ze strony firmy, która wydaje Androida z własnościową nakładką Samsunga -

TouchWizem, i nie ma potrzeby udostępniania jakichkolwiek kodów źródłowych użytych

do jego produkcji (Androida), poza jądrem systemowym Linux, które jest używane na

licencji GPL 2.0. To wszystko przekłada się na okropne wsparcie tego urządzenia przez

CyanogenModa oraz malejące zainteresowanie developerów z powodu ”kłód” rzucanych

przez Samsunga pod ich nogi.

ArchiDroid jest systemem operacyjnym, wywodzącym się w prostej linii od Cy-

anogenModa. Jego głównym celem jest przede wszystkim zapewnienie jak najlepszego

Wstęp 5

wsparcia dla danego urządzenia, poprawa działania systemu poprzez jak najlepsze do-

stosowanie go do użytych w danym urządzeniu podzespołów, a przy tym pozostanie

przy najnowszym Androidzie i całej bazie używanej w CyanogenModzie. Głównymi atu-

tami jest jego szybkość i optymalizacja, a także wysoka kompatybilność ze wszystkimi

wspieranymi przez system modelami - na tą chwilę Samsungiem Galaxy S3 oraz Sony

Xperią M. ArchiDroid skupia się także na poprawie działania samego systemu poprzez

implementację ciekawych idei niedostępnych na tą chwilę ani w Androidzie, ani w Cy-

anogenModzie. Dzięki modelowi open-source, ArchiDroida można zbudować na każde ze

wspieranych urządzeń, co przekłada się na rozwiązanie głównego problemu czyli samych

systemowych aktualizacji, stanowiąc jednocześnie alternatywę dla brakującego wsparcia

od producenta. To jak długo ArchiDroid będzie w stanie wspierać dane urządzenie zależy

przede wszystkim od developerów, którzy przyłączą się do projektu, oraz kompatybilno-

ści samych podzespołów, których kodu nie uda się napisać, chociażby bootloadera czy

sterowników GPU. Warto zauważyć, że rozwój ArchiDroida przede wszystkim skupia

się na dużo niższej warstwie niż sam Android (wsparcie konkretnego sprzętu), a wyższa

warstwa, jak np. dodatki do interfejsu, zostaną w pełni odziedziczone po CyanogenMo-

dzie, który to zawiera wszystko to, co czysty Android powinien, a także kilka własnych

implementacji, chociażby menadżer motywów czy kontrolę prywatności.

Podsumowując, ArchiDroida można uznać za alternatywę dla domyślnego (własno-

ściowego) systemu operacyjnego, podobnie jak i CyanogenModa, z którego się wywodzi,

a jego celem jest zapewnienie dobrego wsparcia dla wspieranych urządzeń, wysoki po-

ziom optymalizacji i wydajności, a także kilka unikalnych funkcji ułatwiających życie

użytkownikom.

Rozdział 2

Cel i zakres pracy

Celem niniejszej pracy jest stworzenie uniwersalnego systemu operacyjnego będą-

cego w stanie działać na dwóch przykładowych urządzeniach Samsung Galaxy S3 oraz

Sony Xperia M. Zakres pracy obejmuje następujące zagadnienia:

• Przegląd literatury na temat systemu operacyjnego Android, jego kompilacji, moż-

liwości wprowadzania zmian w kodzie, kompatybilności z niewspieranymi urządze-

niami

• Przegląd literatury na temat systemu operacyjnego CyanogenMod, a przede wszyst-

kim części poświęconej implementacji wsparcia dla danego urządzenia

• Stworzenie pierwszego działającego prototypu

• Próba doprowadzenia jak największej części sprzętu do działania z nowym syste-

mem

• Implementacja własnych unikalnych rozwiązań w systemie

• Testy systemu

• Upublicznienie systemu i zebranie opinii od użytkowników

Tworzenie własnego systemu operacyjnego nie jest rzeczą prostą. Android składa

się z setek jeśli nie z tysięcy projektów, które dopiero połączone w jedną całość spra-

wiają wrażenie spójności. ArchiDroid został zatem podzielony na dwie główne części

implementacyjne - warstwę niższą, oraz warstwę wyższą.

6

Rozdział 3

Podobne rozwiązania

Z powodu otwarto-źródłowej natury Androida, powstało dość dużo projektów o

niego opartych. Niestety żaden z nich nie jest perfekcyjny - każdy posiada swój własny

zbiór wad i zalet, który jest dość ściśle uwarunkowany tym, jakie są główne założenia

danego projektu.

3.1 CyanogenMod

CyanogenMod jest opartym na na Androidzie systemem stworzonym początkowo

przez Steve’a Kondika, a aktualnie rozwijanym przez niezależną społeczność. System ten

jest bez wątpienia najbardziej popularnym systemem operacyjnym na bazie Androida.

Wyróżnia się przede wszystkim wieloma unikalnymi dla systemu funkcjami rozwijanymi

na przestrzeni lat, takimi jak własny autorski system motywów, autorska implementacja

pełnej kontroli prywatności, czy LiveDisplay - tryb w którym barwy ekranu dostosowują

się do pory dnia, w szczególności w nocy. To właśnie on został wybrany jako baza dla

ArchiDroida - zawiera bowiem w sobie wiele ciekawych rozwiązań, z których szkoda by

było rezygnować, oraz znacznie ułatwia implementację wsparcia na nowe, niewspierane

urządzenia. Z dzisiejszego punktu widzenia jest to oczywisty, bezpieczny i zaufany wybór,

który zaowocuje w przyszłości.

3.2 OmniROM

OmniROM powstał w wyniku współpracy kilku najbardziej rozpoznawalnych deve-

loperów na XDA i stanowi bardzo ciekawą alternatywę w porównaniu do CyanogenModa.

Głównym powodem powstania były obawy developerów wobec komercjalizacji systemu

7

Podobne rozwiązania 8

CyanogenMod, po tym jak został on niejako przejęty przez założoną niedawno firmę

Cyanogen. Ciężko powiedzieć co tak naprawdę wyróżnia go na tle CyanogenModa, po-

nieważ założenia obu systemów są dość podobne. Niestety, z powodu dużo mniejszej

popularności zarówno wśród developerów jak i użytkowników, system ten jest dostępny

na o wiele mniejszą liczbę urządzeń. Dodatkowo, stanowi on raczej lekką modyfikację

tego, co zawiera w sobie sam Android, aniżeli modyfikuje go w znacznym stopniu tak

jak CyanogenMod. Jest jednak dobrym przykładem projektu, o nieco innych założe-

niach, wciąż będąc dobrą alternatywą wobec tego co dostarcza producent. OmniROM

ma dużą szansę dorównać CyanogenModowi w ciągu kilku następnych lat, jednak na

dzień dzisiejszy nadal jest sporo w tyle.

3.3 Inne systemy

Istnieje także masa innych systemów, np. SlimPop, AOKP, Resurrection Remix,

LiquidSmooth i wiele więcej. Każdy z tych projektów ma jednak dużo mniejszą społecz-

ność developerów, a znaczna część z nich to najczęściej efekt pracy kilku pojedynczych

developerów. Z racji potrzeby stabilnej, dobrze wspieranej i przyszłościowej bazy, żaden

z nich nie spełnia podstawowych wymogów do oparcia o niego ArchiDroida, toteż zostały

one niejako odrzucone już w przedbiegach. Nie znaczy to jednak, że są one jakkolwiek

gorsze od dwóch wyżej wymienionych - Zawierają w sobie wiele ciekawych rozwiązań, z

których ArchiDroid stara się czerpać pomysły i inspiracje.

3.4 Dlaczego ArchiDroid?

Głównymi założeniami ArchiDroida jest dobre wsparcie wszystkich wspieranych

urządzeń. O ile CyanogenMod jest bardzo elastyczny i wielofunkcyjny jeśli chodzi o

samą strukturę, o tyle wsparcie urządzeń jest mocno uzależnione od maintainerów -

osób, które zajmują się wsparciem urządzeń, których niestety zbyt dużo nie ma. Dodat-

kowo, społeczność CyanogenMod jest dość krytycznie nastawiona do nisko-poziomowych

modyfikacji, tak więc niektóre ArchiDroidowe funkcje takie jak np. Adblock czy Pocket

Debian, o których będzie jeszcze wspomniane, nigdy nie zostałyby zaakceptowane do

CyanogenModa, ponieważ są zbyt specyficzne i na pewno bez sporej dawki kodu nie

zadziałają na wszystkich wspieranych platformach. Z tego powodu, projekt ArchiDroid

jest niezależny, jeśli chodzi o licencję, założenia projektowe i samą implementację, lecz

jednocześnie nie jest oparty o czystego Androida dostarczonego przez Google, jako że nie

warto rezygnować ze wszystkich mocnych stron CyanogenModa. Zamiast ”wynajdywać

koło na nowo”, lepiej skupić się na tym co w CyanogenModzie warto poprawić, i co warto

Podobne rozwiązania 9

do niego dodać, zamiast powielać to, co zostało już przez społeczność zaakceptowane

i wdrożone do projektu. Jest to również ważne z poziomu końcowych użytkowników,

którzy będą bardziej zainteresowani w korzystaniu z systemu, który zawiera już w so-

bie wszystkie funkcjonalności, do których się przyzwyczaili, aniżeli jedynie ich wybraną

część. Po co więc rezygnować z możliwości?

ArchiDroid podobnie jak i sam CyanogenMod oraz Android na którym jest oparty,

jest bardzo złożonym projektem, w którym można wyróżnić co najmniej kilkaset mniej-

szych i większych projektów, które składają się na jedną całość. System zatem został

podzielony na dwie główne warstwy - warstwę niższą, i warstwę wyższą. Obydwie te

warstwy zostały szczegółowo opisane w następnym rozdziale. Z powodu złożoności pro-

jektowej, wyróżnione zostały jedynie najważniejsze modyfikacje, aniżeli wszystko to co

ArchiDroid jako projekt do nich wprowadził.

Rozdział 4

Warstwa niższa

W warstwie niższej znajduje się wszystko to co jest wymagane do skompilowania

systemu i działania. Warstwa ta odpowiada za ”szkielet” systemu, i jest w stanie dzia-

łać bez warstwy wyższej. To na nią właśnie składa się Android oraz CyanogenMod.

W tej warstwie powstaje działający system operacyjny na bazie Androida, który sam

w sobie jest w stanie w pełni poprawnie działać, lecz bez zaimplementowanej warstwy

wyższej jest w pewnym sensie ubogi w funkcjonalność i nie oferuje pełnych możliwo-

ści wynikowego systemu. ArchiDroid zakłada, że nie ma żadnego sensu przepisywać

czegoś, co zostało już stworzone, zatem w tej warstwie, projekt skupia się głównie na

zapewnieniu dobrego wsparcia danemu urządzeniu, przez co rozumie się device tree 1

oraz samo serce czyli jądro systemowe Linux. Dodatkowo, ArchiDroid skupia się na za-

pewnieniu jak najlepszej jakości kompilacji, co jest możliwe poprzez szereg zabiegów

optymalizacyjnych, na które głównie składa się korzystanie z własnego spersonalizowa-

nego kompilatora zoptymalizowanego pod daną architekturę, oraz konkretny zbiór flag

optymalizacyjnych przekazywanych do procesu kompilacji, które pozwalają na wygene-

rowanie szybszego i bardziej zoptymalizowanego kodu maszynowego. ArchiDroid także

zawiera w sobie ArchiKernela - Lekko zmodyfikowanego jądro systemowe Linux, głównie

pod kątem optymalizacyjnym, ale także umożliwiając dodatkowe nisko-poziomowe mo-

dyfikacje działania telefonu, takie jak możliwość zwiększenia taktowania procesora czy

układu graficznego, oraz zmniejszenie napięć potrzebnych do ich utrzymania.

Warto wspomnieć, że warstwa niższa jest w dużej mierze zależna od urządzenia,

ponieważ zarówno jądro systemowe jak i sam system są kompilowane pod konkretny

sprzęt, a system skompilowany na jedno urządzenie nie ma prawa działać na innym.

Każde urządzenie więc, wymaga swojego własnego kodu źródłowego (device tree), który

bezpośrednio przekłada się na to jak kompatybilny będzie system wynikowy.1device tree - wyodrębniona część kodu źródłowego odpowiedzialna za możliwość zbudowania Andro-

ida na konkretne urządzenie.

10

Warstwa niższa 11

Jakość i ilość pracy, którą trzeba poświęcić na tą warstwę jest w dużej mierze

zależna od polityki samego producenta. Android głównie operuje na licencji Apache 2.0,

która zezwala producentowi na tworzenie i implementację modyfikacji bez przymusu

udostępniania kodu źródłowego. Jedynie jądro systemowe Linux jest na licencji GPL 2.

Z tego powodu na rynku możemy wyróżnić firmy, które są przyjacielsko nastawione do

niezależnych developerów (np. Google, Sony), jak i te które są nastawione wrogo (np.

Samsung, Mediatek).

Przyjacielskie nastawienie polega na tym, że firma najczęściej oprócz wydania wy-

maganych przez licencję kodów źródłowych jądra na dane urządzenie, często wydaje

również pełną dokumentację oraz dużą część własnego kodu wymaganego do skompi-

lowania Androida na dane urządzenie, co nawet jeśli nie jest kompletnym kodem (np.

z powodów licencyjnych lub patentowych), nadal jest ogromnym krokiem naprzód po-

zwalającym na implementację sporej liczby podzespołów w systemie wynikowym, co

przekłada się zarówno na jakość kodu (bezpośrednio od samej firmy), jak i na ilość

czasu którą trzeba poświęcić (implementacja już napisanej części). Dzięki takiemu po-

dejściu, w systemie unikamy potrzeby używania tzw. blobów 2, dzięki czemu system jest

zarówno bardziej otwarty i przyjazny, jak i bardziej niezależny, co ma ogromny wpływ

na kompatybilność sprzętu w przyszłości.

Wrogie nastawienie polega najczęściej na braku udostępniania jakichkolwiek kodów

źródłowych, a nawet i samej dokumentacji. Co więcej, niektóre firmy (takie jak np. Me-

diatek) łamią nawet postanowienia licencji Linuxa (GPL 2), poprzez odmowę wydania

kodów źródłowych samego jądra. Tworzenie kodu wymaganego do działania urządzeń

takich firm jest najczęściej istną katorgą z powodu braku jakiegokolwiek wsparcia, po-

trzeby używania ogromnej ilości blobów, wymaganego reverse-engineeringu, nie wspo-

minając nawet o potrzebie ogromnej wiedzy developera, który próbuje na własną rękę

”odgadnąć” jak powinien wyglądać kod, który będzie działał z danym urządzeniem. To

przekłada się bezpośrednio na niską popularność danego urządzenia wśród developerów

oraz bardzo słaby poziom wsparcia danego urządzenia. Nawet jeżeli sporym nakładem

pracy uda się uzyskać całkiem dobre rezultaty, wciąż będą one dużo gorsze niż jakakol-

wiek implementacja udostępniona bezpośrednio przez producenta.

Nie bez powodu wybranymi urządzeniami zostały dwa zupełnie przeciwstawne mo-

dele - Galaxy S3 od Samsunga or Xperia M od Sony. Zabieg ten ma na celu sprawdzenie

jak wielka przepaść istnieje między tymi dwiema markami, co pozwoli stwierdzić czy

wspieranie ”wrogich” producentów ma jakikolwiek sens.

2Blob - biblioteka, kod wykonywalny lub firmware wymagany do działania konkretnego podzespołuw urządzeniu

Warstwa niższa 12

4.1 ArchiKernel - Jądro systemowe Linux

ArchiKernel jest nieco zmodyfikowanym jądrem systemowym Linux, które jest two-

rzone poprzez niewielkie zmiany w kodzie źródłowym zaaplikowane na już udostępniony

kod przez samego producenta. Kody źródłowe jądra są absolutnie wymagane do w pełni

zoptymalizowanej i przystosowanej na dane urządzenie kompilacji. W skrajnym przy-

padku ich braku (MediaTek), można pośredniczyć się już skompilowanym obrazem (zI-

mage), który można wyciągnąć z oryginalnego systemu. Obraz ten ma jednak wiele za-

sadniczych wad, z których najmniejszą z nich będzie brak możliwości optymalizacyjnych

czy overclockingowych, a największą będzie całkowita niekompatybilność z używanym

kodem źródłowym Androida, co może się przełożyć na potrzebę pisania tzw. mostów 3,

które z definicji są obejściem problemu, i nie zawsze jest możliwe ich zaimplementowanie.

Wpływają także bardzo negatywnie na wydajność takiego rozwiązania. Niestety, bardzo

często nie ma innego sposobu i trzeba się uciekać do tego typu rozwiązań w przypadku

braku dokumentacji i kodów źródłowych.

Jeśli jednak kody źródłowe są dostępne, ArchiKernel jest możliwy do stworzenia.

Aktualna łatka zawiera m.in takie zmiany jak:

• Wsparcie dla własnego spersonalizowanego kompilatora GCC

• Wsparcie dla własnych flag optymalizacyjnych GCC

• Wybrane zmiany z oficjalnego źródła jądra Linux, głównie naprawiające błędy

kompilacji w związku z nowszą wersją kompilatora

• Wsparcie dla overclockingu CPU oraz GPU

• Kontrola napięć CPU oraz GPU

• Możliwość zmiany oraz kontroli działania zarządcy CPU oraz I/O

• Dodatkowi zarządcy kontrolujący pracę CPU oraz I/O

• I inne

Kontrola ArchiKernela jest dostępna przez mechanizm Linuxowy zwany sysfs. Aby

użytkownik mógł w prosty i przyjazny sposób się z nim porozumiewać, do warstwy wyż-

szej systemu została dołączona aplikacja Synapse, która umożliwia bardzo szczegółową

personalizację tego jak jądro ma działać. Dzięki temu użytkownik ma pełną kontrolę nad

tym, czy preferuje np. większą moc obliczeniową i szybsze urządzenie, które lepiej radzi

3most - kod odpowiedzialny za tłumaczenie żądań zrozumiałych przez jedną części systemu, na żą-dania zrozumiałe przez inną część systemu, i na odwrót.

Warstwa niższa 13

sobie z najnowszymi grami, czy być może preferuje większą oszczędność baterii kosztem

obniżonego taktowania i wydajności.

4.2 CyanogenMod

ArchiDroid jest bazowany w pełni na CyanogenModzie. Dzięki temu dziedziczy po

nim całą funkcjonalność wraz ze wszystkimi komponentami. Pod względem tego co ofe-

ruje CyanogenMod, ArchiDroid stara się współpracować z jego komponentami, aniżeli

je zmieniać lub usuwać. Jedynym usuniętym komponentem została aplikacja CMUpda-

ter, odpowiedzialna za aktualizację systemu CyanogenMod, z racji że nie ma żadnego

zastosowania będąc włączona do ArchiDroida. Oprócz tego, wszystko jest praktycznie

nienaruszone, a projekt skupia się na poszerzaniu już istniejącej funkcjonalności i włą-

czaniu jej do systemu, ponieważ za komponenty CyanogenModa odpowiedzialna jest

społeczność. Wszystkie zmiany przez nią wprowadzone są śledzone i włączane do Archi-

Droida.

4.3 Własny kompilator

CyanogenMod, podobnie jak i AOSP korzysta z tego samego kompilatora - GCC

(GNU C Compiler), dostarczonego przez Google. Dla wersji 4.4 była to wersja GCC 4.7,

dla wersji 5.0 oraz 5.1 wersja GCC 4.8.

Zasadniczo kompilator spełnia swoje zadanie - dobrze tłumaczy kod źródłowy na

kod wynikowy, ale wersja GCC używana przez Google jest dość przestarzała, a każda

nowa wersja zawiera szereg poprawek zarówno w kwestii błędów jak i optymalizacji. Do-

datkowo, własny kompilator poza samym faktem bycia zbudowanym z nowszych źródeł,

może również zawierać szereg mniej lub bardziej znaczących poprawek, które z jakiegoś

powodu nie zostały jeszcze włączone do projektu GNU GCC. Takimi poprawkami zaj-

muje się m.in społeczność Linaro, która postawiła sobie za cel stworzenie kompilatora

bardziej zoptymalizowanego na architekturę ARM, niż ten udostępniany przez GNU.

Szczegółowe porównanie dwóch przykładowych kompilatorów tych samych wersji -

GCC 4.7 oraz Linaro GCC 4.7, można znaleźć we wpisie XDA MythBusters[6]. Poniżej

został zamieszczony przykładowy benchmark wykonany aplikacją AnTuTu na systemach

skompilowanych dwoma różnymi kompilatorami, oczywiście testowanych na tym samym

urządzeniu.

Warstwa niższa 14

Rysunek 4.1: Benchmark GCC 4.7 Rysunek 4.2: Benchmark Linaro 4.7

Jak można zauważyć, w przypadku systemu skompilowanym Linaro udało się osia-

gnąć o nieco ponad 7% wyższą wydajność w stosunku do systemu skompilowanego przy

użyciu domyślnego kompilatora. Należy jednak pamiętać, że benchmark nie ukazuje

wszystkich zalet używania własnego kompilatora, a w szczególności tego jak płynny wy-

daje się być nowy system w porównaniu do starego. Można zatem jasno stwierdzić, że

własny kompilator odgrywa dość dużą rolę w tym jak płynny i wydajny będzie wynikowy

system, a zatem odpowiedni jego wybór stanowi dość ważną część tworzenia systemu

operacyjnego.

Domyślnie CyanogenMod w wersji, na której bazuje ArchiDroid jest kompilowany

przy użyciu GCC 4.8 dla obydwu części systemu - kernela, or Androida. ArchiDroid jed-

nak poszedł o krok dalej i w jego obecnej wersji jest kompilowany przy użyciu SaberMod

4.9 oraz ArchiToolchain 5.2.

SaberMod 4.9 jest używany do kompilacji części Androidowej. Początkowo został

stworzony przez Paula Beelera, jednego z bardziej rozpoznawalnych developerów XDA.

Jego głównymi założeniami są stabilność oraz kompatybilność z aktualnie używaną wer-

sją Androida, jednocześnie starając się podążać za nowymi wersjami GCC. Kompilator

ten został wybrany dla projektu ArchiDroid głównie z powodu dużo większej stabilności

w porównaniu do Linaro, dając bardzo podobne rezultaty. Część Androidowa jest bardzo

Warstwa niższa 15

złożona, stanowi bowiem około 90% całego systemu, a zatem jest bardzo podatna na

tzw. regresje i zmiany w nowych wersjach GCC. Na tą chwilę stabilnym i bezpiecznym

wyborem jest SaberMod w wersji 4.9, być może w przyszłości będzie możliwe pójść o

krok dalej.

ArchiToolchain 5.2 jest używany do kompilacji części kernelowej. Jak można się

domyslić z nazwy, ArchiToolchain to jeden z podprojektów, podobnie jak i ArchiKernel,

na których bazuje ArchiDroid. Został stworzony głównie z powodu braku dobrego kom-

pilatora przeznaczonego do kompilacji jądra systemowego. Na tą chwilę nie wyróżnia

się niczym specjalnym poza kilkoma ciekawymi zmianami włączonymi do kompilatora

Linaro, oraz najnowszą możliwą wersją kompilatora GCC. Kernel jest centralną częścią

systemu operacyjnego, jako że wpływa na niemal każde jego zachowanie, a zatem jego

optymalizacja odgrywa kluczową rolę w płynności całego systemu. Z racji, że część ker-

nelowa jest dużo mniej skomplikowana od części Androidowej, udało się do niej użyć

najnowszej wersji GCC - na tą chwilę 5.2, która stanowi dość duży krok naprzód w

porównaniu do przestarzałej wersji 4.8, która jest używana domyślnie.

Użycie tych dwóch niestandardowych kompilatorów wpłynęło znacznie na wydaj-

ność oraz płynność wynikowego systemu, o czym będzie można przeczytać więcej w

testach systemu.

4.4 Flagi optymalizacyjne

Flagi optymalizacyjne to temat rzeka. Bez wątpienia kompilator użyty w procesie

kompilacji Androida odgrywa bardzo dużą rolę, w końcu to on jest odpowiedzialny za

to jak będzie wyglądał kod wynikowy. GCC jednak to tylko narzędzie, a to jak będzie

wyglądał i działał sam kod maszynowy w dużej mierze zależy właśnie od flag optyma-

lizacyjnych, które jasno przekazują GCC na jakich aspektach optymalizacyjnych ma się

skupić.

Niestety, domyślne flagi kompilacyjne ustawione przez Google mają niewiele wspól-

nego z optymalizacją. Były one pisane prawdopodobnie w czasie powstawania pierwszych

urządzeń z systemem Android, gdy urządzenie nie miało zbyt dużej mocy obliczeniowej,

ilość pamięci była mocno ograniczona, i kierowano się zupełnie innymi zasadami niż

obecnie. Aktualne domyślne flagi optymalizacyjne przedstawiają się następująco:

TARGET_arm_CFLAGS := -O2 -fomit -frame -pointer -fstrict -aliasing -funswitch -loops

TARGET_thumb_CFLAGS := -mthumb -Os -fomit -frame -pointer -fno -strict -aliasing

Kod 4.1: Domyślne flagi kompilacyjne

Warstwa niższa 16

To co ma największy wpływ na wydajność kodu wynikowego to bez wątpienia flaga -O,

która precyzuje stopień dokonywanych optymalizacji. Jak możemy zauważyć w kodzie

wyżej, proces kompilacji jest rozbity na dwa etapy - na kompilację kodu ARM oraz kodu

Thumb. ARM oraz Thumb to tak naprawdę zestaw instrukcji zrozumiałych dla archi-

tektury ARM, które mogą być przez nią wykonywane. Nie zagłębiając się w szczegóły

architektury ARM, należy zadać sobie pytanie, czy domyślne poziomy optymalizacji,

czyli -O2 oraz -Os są dla nas odpowiednie?

Skupmy się na początku na instrukcjach ARM, które są bardziej oczywiste. Flaga -O2

jest od bardzo dawna używana jako poziom bezpiecznej optymalizacji kodu, dzięki której

zwiększa się zarówno szybkość działania aplikacji, jak i bardzo często również zmniejsza

się ilość wygenerowanego kodu. Istnieje jednak wyższy poziom optymalizacyjny - po-

ziom O3, która charakteryzuje się zasadą ”zwiększa ilość wygenerowanego kodu, i może,

lub też nie, zwiększyć wydajność”. Dawniej, kompilator GCC był w stanie wygenero-

wać błędny kod podczas używania flagi O3, co było spowodowane głównie błędami w

algorytmach optymalizacyjnych kompilatora, dlatego też programiści unikali tej flagi na

rzecz o wiele bardziej bezpiecznej O2. Jednak od dłuższego czasu, flaga O3 jest tak na-

prawdę następnym poziomem optymalizacji - poziomem, na którym kompilator spędza

więcej czasu analizując kod źródłowy i starając się przetłumaczyć go na jak najbardziej

zoptymalizowany kod maszynowy. Dzięki użyciu jednej z najnowszych wersji kompila-

tora GCC, o którym napisano wyżej, algorytmy użyte w procesie optymalizacyjnym są

dostatecznie dobre, aby samemu zdecydować które sztuczki optymalizacyjne opłaci się

zastosować do danej porcji kodu. Dzięki temu, używając flagi O3 i jednej z nowszych wer-

sji kompilatora GCC, jesteśmy w stanie wygenerować jeszcze bardziej zoptymalizowany

kod dla instrukcji ARM, poprzez przekazanie GCC informacji, żeby włączył wszystkie

znane mu sztuczki optymalizacyjne, ale jednocześnie sam zdecydował które z nich opłacą

się do danej porcji kodu.

Instrukcje Thumb stanowią jednak pewnego rodzaju paradoks. O ile wybór w przypadku

O2, a O3 jest w miarę oczywisty, tak długo póki używamy w miarę świeżego kompilatora,

o tyle tutaj Google zdecydowało się na dość odważny krok, a mianowicie sprecyzowanie

flagi -Os. Flaga -Os działa podobnie co flaga O2, ale GCC w tym przypadku stara się

wygenerować jak najmniejszy kod wynikowy, stosując głównie optymalizacje, które nie

zwiększają jego rozmiaru. Flaga ta jest szczególnie użyteczna w przypadku kompilacji

kodu na bardzo ograniczone rozmiarowo nośniki, takie jak niewielkie pamięci ROM czy

mikrokontrolery. Wybór flagi -Os jest dość oczywisty w tym przypadku - początkowe

urządzenia były bardzo ograniczone zarówno pod kątem rozmiaru pamięci jak i wydaj-

ności. Logicznym było więc, że Android musi się skupić na posiadaniu jak najmniejszej

ilości instrukcji, które będą w stanie być obsłużone przez dość mało wydajny procesor.

Jednak czasy się zmieniły, w przykładowym rozpatrywanym urządzeniu Samsung Ga-

laxy S3 mamy procesor Exynos 4412, posiadający 4 rdzenie taktowane na 1.4 GHz. Czy

Warstwa niższa 17

zatem powinniśmy zignorować decyzję podjętą przez Google i zmienić flagę -Os na O3?

Odpowiedź na to pytanie nie jest oczywista. Z jednej strony można zauważyć, że rze-

czywiście - nie mamy już aż tak ścisłych wymogów wobec rozmiaru kodu, mamy dość

potężny procesor będący w stanie obsługiwać wszelkiego rodzaju instrukcje, więc nie

ma żadnych przesłanek do pozostania przy poziomie Os. Z drugiej strony, zwiększenie

rozmiaru kodu wynikowego może również wpłynąć negatywnie na wydajność, głównie z

powodu nadal ograniczonego rozmiaru Cache L1/L2 procesora oraz samej architektury

ARM. Kod który jest w stanie się zmieścić w cache’u będzie działał o wiele wydajniej

od kodu, który się w tym cache’u nie zmieści. Kilkanaście zaoszczędzonych instrukcji, na

które ciężko zapracował nasz GCC z flagą O3 zostanie całkowicie przysłonięte przez kilka

tysięcy zmarnowanych instrukcji, które zostały spowodowane potrzebą odwołania się do

pamięci RAM. Dodatkowo architektura ARM wydaje się działać lepiej gdy instrukcji

jak i kodu jest mniej, aniżeli więcej.

Co więcej, sprawdzenie powyższych teorii na przykładowym kodzie mija się z celem, bo

flagę tą chcemy zastosować globalnie podczas kompilacji systemu, a działanie systemu

operacyjnego nie jest benchmarkiem, który można zmierzyć. Dlatego też, zdecydowano

się na dość odważny krok i sprawdzenie jak sytuacja wygląda ”w boju”. Skompilowane

zostały dwie opierające się na tych samych źródłach i tym samym kompilatorze wer-

sje ArchiDroida - jedna, która została skompilowana z flagą -O3 dla poziomu Thumb,

i druga - standardowa, z flagą -Os. Następnie obydwie te wersje zostały przesłane do

wybranej części użytkowników. Użytkownicy mieli za zadanie korzystać z obydwu syste-

mów przez pewien okres czasu, a następnie wybrać w ankiecie który system z tych dwóch

według nich działa lepiej w czterech różnych kategoriach - wydajności, stabilności, ży-

cia baterii, oraz własnego wyboru. Aby wyniki były jak najbardziej obiektywne, a nie

sugerowane zmianami, użytkownicy nie otrzymali informacji czym dokładnie różnią się

te dwie wersje systemu, tak aby uniknąć efektu placebo. W przypadku gdy użytkownik

nie zauważył żadnej różnicy, był proszony o nie dokonywanie wyboru w danej kategorii.

Wyniki okazały się co najmniej zaskakujące:

Warstwa niższa 18

Rysunek 4.3: Wyniki ankiety

Przeanalizujmy je. W głosowaniu wzięło udział 17 użytkowników. Zaczynając od góry, 9

na 10 użytkowników stwierdziło, że pod względem wydajności szybsza jest wersja, która

używa flagi O3 dla instrukcji Thumb, 7 użytkowników nie zauważyło różnicy. Ta jed-

noznaczność jasno wykazała, że mit o tym jakoby nadal istniała potrzeba optymalizacji

kodu pod jego rozmiar, został obalony. To była najważniejsza część ankiety, lecz inne

kategorie również są warte przeanalizowania. Pod kwestią żywotności baterii, po 7 użyt-

kowników wybrało zarówno wersję O3 jak i Os, 3 użytkowników nie zauważyło różnicy.

Wynik ten jest pozytywny, flaga O3 nie powinna wpłynąć w żaden negatywny sposób

na zużycie baterii, tak więc było to do przewidzenia. Wyniki następnej kategorii są co

najmniej zaskakujące. Według 10 użytkowników, bardziej stabilniejszą wersją okazała

się wersja z O3, aniżeli wersja z Os, na którą zagłosowało tylko 5 użytkowników - 2

nie zauważyło różnicy. Wynik ten jest o tyle dziwny, że to właśnie wersja O3 powinna

spowodować potencjalne problemy w użytkowaniu systemu, jako że Android nigdy nie

był tworzony z myślą o kompilacji innymi niż standardowe poziomami optymalizacji,

tak więc dość ciężko jest ten wynik zinterpretować, być może zwiększona wydajność

również sprawiała wrażenie większej stabilności z powodu płynniejszego w użyciu inter-

fejsu? Ostatnią kategorią był wybór użytkownika, w którym to 6 użytkowników preferuje

wersję O3, 3 użytkowników preferuje wersję Os, a 8 użytkowników nie widzi różnicy. Ka-

tegoria ta jest najbardziej subiektywna ze wszystkich czterech, ale również pokazuje że

duża część użytkowników preferowała wersję O3 od Os.

Warstwa niższa 19

Należy zaznaczyć, że testy te były testami ”na ślepo” - użytkownicy nie zdawali sobie

sprawy z modyfikacji, którą różniły się obydwie testowane wersje - ta została im udostęp-

niona dopiero po zakończeniu ankiety. Tym samym uznano, że wersja O3 definitywnie

wygrała pod kwestią wydajności, stabilności oraz jako wybór użytkowników, a także

zremisowała z wersją Os pod kwestią baterii. Z tego też powodu zdecydowano się na

zmianę domyślnego poziomu optymalizacji instrukcji Thumb z Os na O3, jednocześnie

obalając mit jakoby flaga -Os miała przewagę nad flagą O3 pod kwestią wydajności

systemu.

Dodatkowo, zarówno do flag ARM jak i Thumb zostały dołączone dodatkowe flagi opty-

malizacyjne, które nie są standardowo zawarte w poziomie optymalizacji O3. Dokładne

informacje o każdej z nich można przeczytać w dokumentacji GCC4. Po zaaplikowanych

zmianach, domyślne ustawienia kompilacji ArchiDroid przedstawiają się następująco:

ARCHIDROID_GCC_CFLAGS := -O3 -fgcse -las -fgcse -sm -fipa -pta -fivopts \

-fomit -frame -pointer -frename -registers -fsection -anchors -ftracer \

-ftree -loop -im -ftree -loop -ivcanon -funsafe -loop -optimizations \

-funswitch -loops -fweb -Wno -error=array -bounds -Wno -error=clobbered \

-Wno -error=maybe -uninitialized -Wno -error=strict -overflow

TARGET_arm_CFLAGS := $(ARCHIDROID_GCC_CFLAGS) -fomit -frame -pointer \

-fstrict -aliasing -funswitch -loops

TARGET_thumb_CFLAGS := -mthumb $(ARCHIDROID_GCC_CFLAGS) -fomit -frame -pointer \

-fno -strict -aliasing

Kod 4.2: ArchiDroidowe flagi kompilacyjne

4https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Rozdział 5

Warstwa wyższa

W warstwie wyższej znajduje się wszystko to, co zostaje ”nałożone” na wynikowy system

powstający w warstwie niższej, co de facto przekształca nasz ”ubogi” system operacyjny

w jego pełnoprawną wersję, z całą dostępną funkcjonalnością, czyli dokładnie to, czego

oczekuje użytkownik. To tutaj głównie została zawarta część ”widoczna” przez użytkow-

nika. Warstwa wyższa zawiera w sobie wiele często niezależnych od siebie komponentów,

począwszy od instalatora, przez niewidoczny dla użytkownika backend, poprzez aplikacje

z którymi użytkownik może wchodzić w interakcję, a skończywszy nawet na pełnopraw-

nym systemie GNU/Linux będacego w stanie działać wewnątrz ArchiDroida.

5.1 AROMA

AROMA to skrót od ”Android ROM Manifestation” i jest to pierwszy komponent Ar-

chiDroida, z którym bezpośrednio styka się użytkownik. AROMA jest graficznym insta-

latorem napisanym w C, który może zostać uruchomiony i wykonany przez Recovery1,

w celu instalacji modyfikacji. AROMA jest bardzo potężnym narzędziem, które pozwala

zgodnie z zaprogramowaną przez ArchiDroida logiką, zapewnić użytkownikowi bardzo

przyjazny graficzny interfejs, w którym może dokładnie sprecyzować które komponenty

systemu chciałby zainstalować, a także podjąć ważne systemowe decyzje, chociażby taką

jak wybór jądra systemowego, które zostanie zapisane w bloku startowym urządzenia.

To co wyróżnia ArchiDroida na tle innych systemów to nie tylko fakt, że posiada gra-

ficzny instalator AROMA, ale także to jak bardzo jest on rozbudowany. Wielu użytkow-

ników twierdzi, że ArchiDroid posiada najbardziej rozbudowany instalator AROMA jaki

kiedykolwiek został wydany, i nawet jeśli trudno jest tą tezę jednoznacznie potwierdzić

lub jej zaprzeczyć, trzeba przyznać, że użytkownicy mają dużo racji. ArchiDroidowy

instalator rozpoczyna się od powitania użytkownika i przedstawieniu zasad używania

1Recovery - Specjalnie przygotowany statyczny obraz tylko do odczytu, niezależny od systemu opera-cyjnego urządzenia (lub też jego braku), umożliwiający użytkownikowi wprowadzanie zmian w telefonie,takich jak np. zainstalowanie własnego systemu operacyjnego, czy przywrócenie telefonu do ustawieńfabrycznych

20

Warstwa wyższa 21

systemu. Następnie użytkownik ma możliwość wyboru trybu instalacji - użycia pełnej

personalizacji, załadowanie już wcześniej spersonalizowanych ustawień, zainstalowanie

samego szkieletu systemu, lub aktualizacji Recovery z którego korzysta.

Rysunek 5.1: AROMA - Info Rysunek 5.2: AROMA - ToS

W przypadku wyboru personalizacji, użytkownik staje przed wyborem bardzo wielu

aspektów tego jak będzie działał jego system. Wybór ten zawiera m.in takie rzeczy

jak instalowane jądro systemowe, docelowa głębia ekranu, domyślna aplikacja startowa

jak i klawiatura, aplikacja zarządzająca uprawnieniami administratora (roota), wybrane

aplikacje Google, z których użytkownik ma zamiar korzystać, wybrane aplikacje trze-

cie, z których użytkownik ma korzystać, a także zależne od urządzenia wszelkiej maści

”tweaki”, takie jak np. możliwość włączenia paska nawigacyjnego na urządzeniach z

fizycznymi przyciskami. Warto również wspomnieć o tym, że w zależności od danego

urządzenia, dostępne są także inne ustawienia, np. w przypadku Samsunga Galaxy S3,

jest to wybór sterownika odpowiedzialnego za kartę sieciową, a w przypadku Sony Xpe-

ria M, jest dostępna dodatkowa łatka na warianty dual-sim, dzięki której ArchiDroid

jest w stanie wspierać obydwie karty sim w tym samym czasie.

Warstwa wyższa 22

Rysunek 5.3: AROMA - Tryb insta-lacji

Rysunek 5.4: AROMA - Personaliza-cja

Po dogłębnej personalizacji, następuje faza instalacji, w której instalator zgodnie z do-

konanymi przez użytkownika wyborami, instaluje na urządzenie jądro systemowe oraz

system bazowy. Po zakończonej instalacji, użytkownik ma wybór zrestartowania urzą-

dzenia lub powrotu do recovery, a po restarcie, system operacyjny ArchiDroid zaczyna

już w pełni funkcjonować. Na tym etapie, cel graficznego instalatora AROMA kończy

się.

Warstwa wyższa 23

Rysunek 5.5: AROMA - W trakcie in-stalacji

Rysunek 5.6: AROMA - Ekran koń-cowy

5.2 Init

Init to unikalny mechanizm systemu ArchiDroid, który odpowiada za działanie Archi-

Droidowego backendu. Składa się on z dwóch trybów - trybu pierwszego uruchomienia,

oraz trybu inicjalizacji. Tryb pierwszego uruchomienia działa tylko raz, po zainstalowa-

niu systemu, w trakcie jego uruchamiania. Init jest odpowiedzialny za przygotowanie

systemu do działania poprzez modyfikację niektórych ustawień systemu oraz jego apli-

kacji. Podczas normalnej inicjalizacji, Init odpowiedzialny jest za włączenie wszystkich

ArchiDroidowych backendowych usług, takich jak Adblock, Haveged czy Frandom.

Na init składają się dwa komponenty - hook, napisany w języku C, oraz sam Init, napi-

sany w Bashu (shellu). To jak backend został zrealizowany jest całkiem ciekawą rzeczą,

zważywszy na to jak bezpieczny stał się android w wersji 5.1.X, dzięki implementacji

SELinuxa. Init wymaga praw superużytkownika (root), z kolei te są zarezerwowane wy-

łącznie dla jądra systemowego Linux i kilku początkowych usług, które startując, same

obniżają sobie uprawnienia. Aby uzyskać uprawnienia roota, należy więc ”włączyćśię

Warstwa wyższa 24

gdzieś pomiędzy proces jądra systemowego startującego Androidowe usługi, a samą An-

droidową usługę, która działa już z obniżonymi uprawnieniami. Świetnym procesem do

tego celu jest /system/bin/debuggerd, który jest taką usługą.

Cała sztuczka polega na zmianie nazwy pliku debuggerd na inną, np. debuggerd.real,

a w miejsce oryginalnego pliku debuggerd wrzucenie własnego kodu, który będzie w

stanie z uprawnieniami roota uruchomić ArchiDroidowego Inita, oraz kontynuować uru-

chomienie oryginalnej usługi debuggerd.

Warto spojrzeć jak zostało to zrealizowane w samym kodzie:

#include <stdio.h>

#include <string.h>

#include <unistd.h>

#define BRANCH_PREDICTION

#ifdef BRANCH_PREDICTION

#define likely(x) __builtin_expect ((x) ,1)

#define unlikely(x) __builtin_expect ((x) ,0)

#else

#define likely(x) x

#define unlikely(x) x

#endif

static const char* selinuxContext = "u:r:sudaemon:s0";

static const char* selinuxFilePath = "/proc/self/attr/exec";

int main(int argc , char** argv) {

const int childPID = fork();

if (likely(childPID >= 0)) {

if (childPID != 0) {

char realBinary[strlen(argv [0]) + 5 + 1];

sprintf(realBinary , "%s%s", argv[0], ".real");

execv(realBinary , argv);

} else {

FILE* selinuxFile = fopen(selinuxFilePath , "w");

if (likely(selinuxFile != NULL)) {

fprintf(selinuxFile , "%s", selinuxContext);

fclose(selinuxFile);

}

execv("/system/xbin/ARCHIDROID_INIT", (char* []) { "/system/xbin/

ARCHIDROID_INIT", "--background", "--su -shell", NULL });

}

} else { // If fork failed just execute original debuggerd (debuggerd.real)

char realBinary[strlen(argv [0]) + 5 + 1];

sprintf(realBinary , "%s%s", argv[0], ".real");

execv(realBinary , argv);

}

return 0;

}

Kod 5.1: Init hook

Warstwa wyższa 25

Krótkie objaśnienie: Hook rozpoczyna się od operacji fork, czyli utworzenia kopii sa-

mego siebie jako istniejący proces, następnie proces rodzic tej operacji kontynuuje pro-

ces startowy Androida uruchamiając proces debuggerd.real, który powinien zostać

uruchomiony przez jądro systemowe, a proces dziecko tej operacji, czyli ten powstały

w wyniku operacji fork, najpierw zmienia swój SELinuxowy kontekst na sudaemon, po

czym uruchamia nasz ArchiDroidowy Init.

Dzięki tej operacji nie jesteśmy zmuszeni do modyfikacji procesu startowego systemu

Android, ani modyfikacji procesu jądra systemowego. Dzięki temu zachowujemy bar-

dzo wysoką przenośność (ang. portability) kodu, który jest w stanie działać również na

większej ilości urządzeń, chociażby na tych, gdzie dokonanie takowej modyfikacji jest

niemożliwe.

Warto również zauważyć zastosowanie mechanizmu likely oraz unlikely. Dzięki niemu

kompilator GCC jest w stanie zoptymalizować kod w oparciu o wynik instrukcji wa-

runkowej if, jakiego się spodziewamy. Testy wykazały, że jest to korzystny zabieg w

przypadku gdy oczekiwany wynik stanowi 99.9% lub więcej przypadków. Oczywiście, w

przypadku wyżej zastosowanie tego mechanizmu przynosi raczej mizerne, całkowicie nie-

zauważalne wyniki, ale podobny mechanizm jest używany głównie w jądrze systemowym

Linux, gdzie wszystkie nieoczekiwane sytuacje, do których nigdy nie powinno dojść są

zawarte w branchu unlikely, dzięki czemu GCC mając bardzo dużą ilość kodu jest w

stanie go zoptymalizować pod sytuację, której się spodziewamy, jednocześnie generując

bardziej zoptymalizowany kod. W sytuacji, gdy każda operacja w języku C musi zo-

stać sprawdzona na okoliczność tego czy się powiodła, użycie unlikely może dać spore

korzyści bardzo przyspieszając error checking.

Sam Init pełni również wiele ważniejszych nisko-poziomowych funkcji, będąc pewnego

rodzaju pośrednikiem pomiędzy backendowymi komponentami, co zostanie jeszcze opi-

sane w odpowiednich rozdziałach.

5.2.1 Adblock

ArchiDroidowy adblock to pierwsza, jednocześnie jedna z bardziej skomplikowanych

funkcji ArchiDroida, która pełni dość oczywistą i skuteczną funkcję blokowania reklam.

Jednak sposób, w jaki ArchiDroid podchodzi do blokowania natarczywych reklam jest

jednak nieco unikalny.

Zacznijmy od przeglądu aktualnych możliwości. Z możliwości ”systemowych”, bo własnie

o te nam chodzi, Linux oferuje w zasadzie tylko jedną z nich - standardowy Linuxowy plik

hosts. Plik hosts występuje również w innych systemach operacyjnych, m.in Windows,

i polega na tym, że do każdej domeny jesteśmy w stanie przypisać konkretny adres IP.

Dzięki temu, pytając o adres IP danej domeny nie odwołujemy się do serwera DNS,

tylko zakładamy z góry adres IP, który na sztywno jest ustawiony.

Warstwa wyższa 26

Metoda ta ma jednak ogrom wad. Z każdą kolejną linijką zwiększa nam się rozmiar pliku.

Jak wykazały testy, Android nie posiada żadnego systemu cache na niższym poziomie,

przez co każde pojedyncze zapytanie o adres IP danej domeny wymuszona przeczytanie

oraz zinterpretowanie całego pliku hosts, a następnie w oparciu o wynik tego działania

- zwrócenie adresu IP, który się w pliku zawiera, lub odpytanie zewnętrznego serwera

DNS. W przypadku kilkudziesięciu do nawet kilkuset linijek pliku hosts, nie powoduje to

zbyt dużych skutków ubocznych. Żeby jednak adblock był skuteczny, linijek tych musi

się znaleźć co najmniej kilkaset tysięcy, a rozmiar takowego pliku hosts liczony jest już

w kilkudziesięciu megabajtach.

ArchiDroid stara się ugryźć temat z innej strony, jednocześnie znacznie komplikując

mechanizm aby zwiększyć efektywność. Mechanizm AD dzieli się na 3 komponenty -

dnsmasq, Init oraz pixelserv. Wszystkie 3 w odpowiednim połączeniu są w stanie za-

pewnić w pełni działający mechanizm blokowania reklam na poziomie systemowym.

Zacznijmy od dnsmasq. Dnsmasq może pełnić wiele funkcji, w naszym przypadku jest

to serwer DNS. Serwer ten standardowo działa na porcie 53 oraz nasłuchuje wyłącznie

połączeń pochodzących z naszego urządzenia (127.0.0.1). W ArchiDroidzie dnsmasq zo-

stał odpowiednio skonfigurowany - ogromny plik hosts, który był używany przez system,

jest teraz używany wyłącznie przez dnsmasq, i przechowywany w pamięci programu w

formie cache. Gdy dnsmasq odbierze żądanie przetłumaczenia danej domeny na adres

IP, pierwsze co robi to sprawdza czy nie ma już wyniku tego żądania w cache’u, jeśli

nie, odpytuje zdefiniowane serwery DNS, zapisuje odpowiedź w swoim cache’u na pe-

wien okres czasu, a następnie zwraca odpowiedź aplikacji. Dnsmasq w ArchiDroidowym

rozwiązaniu korzysta z 4 niezależnych serwerów DNS do realizacji zapytań spoza cache -

są ta 2 serwery OpenDNS, oraz 2 serwery Google. Dzięki takiemu rozwiązaniu dnsmasq

jest w stanie bardzo szybko odpowiadać na wszystkie zapytania - jeśli zapytanie dotyczy

domeny reklamowej, która ma być blokowana - odpowiedź nadchodzi natychmiast bez

potrzeby opuszczania urządzenia, bezpośrednio z cache. Jeśli zapytanie dotyczy nieblo-

kowanej domeny, dnsmasq przy pierwszym zapytaniu o daną domenę przekazuje żądanie

do zdefiniowanych serwerów DNS, a w przypadku każdego kolejnego zapytania o tą samą

domenę, ponownie, przekazuje odpowiedź bezpośrednio z cache.

Drugim komponentem wchodzącym w skład ArchiDroidowego adblocka jest Init. Tak,

to ten sam komponent, który został opisany już wyżej - jego głównym zadaniem jest

utrzymywanie konfiguracji serwerów DNS w systemie. Nie jest możliwa modyfikacja ser-

werów DNS bezpośrednio z poziomu systemu - Android zawsze używa serwerów DNS

sprecyzowanych przez AP (z ang. Access Point), z którym się łączy. Init ma za zadanie

upewnienie się, że wszystkie aktywne połączenia korzystają z serwera DNS 127.0.0.1:53,

czyli z dnsmasq opisanego wyżej. Mechanizm ten został rozwiązany w najbardziej opty-

malny, a jednocześnie nieinwazyjny dla Androida sposób, po raz kolejny - podobnie jak

Warstwa wyższa 27

hook opisany wyżej. Aplikacja ArchiDroid jest skonfigurowana na odbieranie od An-

droida wszystkich sygnałów (tzw. eventów) dotyczących zmiany aktualnie dostępnych

połączeń internetowych. Gdy taka zmiana nadejdzie, aplikacja informuje Init o potrzebie

zmiany, jednocześnie przesyłając ID danego połączenia, a Init modyfikuje adresy DNS

dla tego połączenia na 127.0.0.1. Jest to spowodowane faktem, iż Androidowy event

dotyczący zmiany połączenia jest dostępny wyłącznie z poziomu javowej aplikacji, a

modyfikacja DNS wymaga praw superużytkownika, które Init jako jedyny komponent

ArchiDroida posiada.

Ostatnim komponentem adblocka jest pixelserv. Pixelserv to minimalistyczny serwer

web napisany w C, którego jedynym zadaniem jest odpowiadanie na każde zapytanie

stroną typu ”NULL”. Pixelserv nasłuchuje na standardowych portach HTTP (80) oraz

HTTPS (443). Kiedy nadejdzie dane zapytanie, w zależności od tego jakiej odpowiedzi

oczekuje aplikacja - pixelserv odpowiada na żądanie. Jeśli zapytanie dotyczy np. strony

HTML, pixelserv odpowiada pustą stroną HTML. Jeśli zapytanie dotyczy np. pliku .png,

pixelserv odpowiada przezroczystym białym plikiem PNG o rozmiarze 1x1.

Łącząc wszystkie trzy komponenty powyżej uzyskujemy w pełni działający Adblock.

Możemy teraz przeanalizować co się dzieje w systemie, na dwóch przykładach - strony

blokowanej, oraz strony nieblokowanej. W obydwu przypadkach sytuacja rozpoczyna się

w danej aplikacji, np. przeglądarce internetowej, o wyświetlenie danego zasobu, dla przy-

kładu uznajmy, że jest to http://google.pl/ oraz http://xxxxxx.pl/reklama.jpg.

W przypadku http://google.pl/:

• Chrome: Przekazanie zapytania do serwera DNS 127.0.0.1

• OS: Sprawdzenie pliku hosts w poszukiwaniu domeny, brak wyniku

• OS: Przekazanie zapytania do serwera DNS 127.0.0.1

• dnsmasq: Sprawdzenie domeny w cache, brak wyniku

• dnsmasq: Przekazanie zapytania do zdefiniowanego serwera OpenDNS

• dnsmasq: Otrzymanie odpowiedzi, zapisanie w cache, zwrócenie wyniku

• OS: Otrzymanie odpowiedzi, zwrócenie wyniku do aplikacji

• Chrome: Wyświetlenie strony

W przypadku http://xxxxxx.pl/reklama.jpg:

• Chrome: Przekazanie zapytania do serwera DNS 127.0.0.1

• OS: Sprawdzenie pliku hosts w poszukiwaniu domeny, brak wyniku

• OS: Przekazanie zapytania do serwera DNS 127.0.0.1

Warstwa wyższa 28

• dnsmasq: Sprawdzenie domeny w cache, wynik 127.0.0.1, zwrócenie wyniku

• OS: Otrzymanie odpowiedzi, zwrócenie wyniku do aplikacji

• pixelserv: Otrzymanie zapytania o reklama.jpg, zwrócenie białego 1x1 JPG

• Chrome: Wyświetlenie obrazka

Można się zastanawiać jaką rolę w tym wszystkich odgrywa pixelserv, skoro efekt bez

niego jest identyczny jak w przypadku metody hosts. Zgadza się, usuwając trzeci kompo-

nent uzyskujemy dokładnie to samo co w przypadku używania pliku hosts, toteż nie jest

on absolutnie wymagany do blokowania reklam. Pełni on jednak bardzo ciekawą funk-

cję, a mianowicie aplikacja, która sprawdza to czy reklamy są wyświetlane, np. jedna z

darmowych gier, zauważy, że zapytanie o wyświetlenie bannera się nie powiodło i od-

mówi działania wyświetlając np. informację o włączonym blokowaniu reklam. W naszym

przypadku, jest to o wiele trudniejsze ponieważ w rzeczy samej odpowiedź nadeszła, bez

błędów, w odpowiednim oczekiwanym typie i z odpowiednią treścią, a to że aplikacja

wyświetla niewidoczny dla nas 1x1 przezroczysty obraz w formacie PNG, to już pro-

blem aplikacji, bo nam jako użytkownikom to w ogóle nie przeszkadza, a aplikacja jest

”zadowolona”, że reklamę udało się wyświetlić.

ArchiDroidowy adblock jest definitywnie ciekawym i innowacyjnym podejściem do te-

matu natywnego systemowego blokowania niechcianych i natarczywych reklam, ale za-

sadnicze pytanie brzmi - czy rzeczywiście warto tak komplikować cały proces w porówna-

niu do metody hosts? Czy zaimplementowane rozwiązanie rzeczywiście ma aż tak duży

wpływ na system w porównaniu do metody hosts? Sprawdźmy to.

Warstwa wyższa 29

Rysunek 5.7: Metoda ArchiDorid Rysunek 5.8: Metoda hosts

Interpretacja testów dokonanych wyżej wygląda następująco. Przetestowany został czas,

który jest potrzebny na wysłanie pakietu ICMP typu ping na domenę zzzzzz.com, która

w obu testowanych metodach wskazuje na adres 127.0.0.1, więc w żadnym wypadku

request nie opuścił testowanego urządzenia. W przypadku użycia metody ArchiDroid,

zanotowane zostały czasy 0.00s, 0.00s, 0.12s, a w przypadku używania metody hosts,

2.12s, 2.11s, 4.24s. Różnica wynika bezpośrednio z tego, że w przypadku metody hosts,

jak możemy zauważyć na rysunku, system ma do przeczytania i przeanalizowania ponad

milion domen, w porównaniu do wyłącznie 9 w przypadku metody ArchiDroid (do-

myślne wpisy systemu). Oczywiście w wykonywanym teście dnsmasq miał załadowaną

dokładnie tą samą listę domen w swoim cache, tak aby test był miarodajny.

Rozwiązanie niesie za sobą pewien, dość niewielki koszt - pamięć. Dnsmasq musi przez

cały okres działania trzymać przeczytane raz wpisy w swojej pamięci podręcznej, a ta

musi znaleźć swoje odzwierciedlenie w pamięci RAM urządzenia. Nie jest to duży koszt,

bo przykładowy milion linijek wyżej zajął tylko 35 MB, co jest dość dobrym wynikiem,

zważając na to, że ilość rekordów i potrzebna pamięć bezpośrednio zależy od tego z ilu

regułek korzysta użytkownik - do w miarę efektywnego blokowania reklam potrzeba ich

Warstwa wyższa 30

znacznie mniej, bo zaledwie 50 tysięcy, co przekłada się na jedynie 4 MB zużycia pamięci

w przypadku używania metody ArchiDroid.

To co jednak wyróżnia tą metodę na tle metody hosts to nie tylko sama wydajność

rozwiązania, która jest co najmniej kilkaset razy większa. Używając metody ArchiDroid

wydłużamy życie naszej pamięci eMMC ulokowanej w urządzeniu, jako że system nie jest

zmuszony za każdym razem czytać i analizować plik hosts, który jak zostało wspomniane

wyżej - potrafi ważyć nawet kilkadziesiąt megabajtów. Z punktu widzenia potencjalnie

krótkiego życia pamięci flash, metoda ta może przynieść ogromne korzyści nie tylko

znacznie wydłużając życie pamięci eMMC, ale także zwiększając jej wydajność poprzez

unikanie niepotrzebnych żądań I/O w przypadku wykonywania zapytań o domeny.

5.2.2 Haveged

Haveged to skrót od ”HArdware Volatile Entropy Gathering and Expansion Daemon”,

i jest to program wspomagający generowanie entropii do urządzenia losowości w ją-

drze systemowym Linux. Android cierpi na dość ciekawy przypadek wyczerpującej się

entropii podczas działania. Entropia ta jest wymagana do generowania liczb losowych.

Obydwa urządzenia przeznaczone do generowania liczb losowych - /dev/random oraz

/dev/urandom z niej korzystają, a gdy ta się wyczerpie - odczyt z /dev/random blo-

kuje się aż do momentu wystarczającej jej ilości, a odczyt z /dev/urandom, który jest

nieblokujący, korzysta z o wiele mniejszej jej ilości.

Do dziś nie wiadomo dlaczego Android podczas normalnego korzystania cały czas ak-

tywnie korzysta z urządzeń do generowania liczb losowych, ale faktem jest, że poziom

entropii jest bardzo niski. Domyślnie w jądrze systemowym Linux, entropia jest ge-

nerowana w oparciu o m.in takie rzeczy jak ruchy myszki, czy przyciski wciskane na

klawiaturze. W urządzeniach mobilnych jednak, nie używamy ani tego, ani tego, więc

źródła generowanej entropii znacząco się zmniejszają.

Haveged rozwiązuje ten problem poprzez ”seedowanie” czyli uzupełnianie entropii w

ilościach uzależnionych od potrzeb. Dzięki temu zabiegowi, poziomy entropii zawsze są

wysokie, co przekłada się na zarówno szybsze jak i bardziej bezpieczne z punktu wi-

dzenia kryptografii działanie urządzeń losujących, jednak to co zauważa użytkownik to

fakt o wiele bardziej płynnego systemu. Ciężko jest jednoznacznie wyjaśnić skąd ten

efekt, ale tak długo póki jesteśmy w stanie zapewnić, że ciągi bitów, które są uzupeł-

niane są dostatecznie bezpieczne, nie istnieją praktycznie żadne skutki uboczne. Haveged

używa algorytmu Havege, który taką gwarancję może nam zapewnić. Warto zauważyć,

że podobny zabieg stosuje się również w przypadku serwerów i maszyn wirtualnych,

gdzie poziomy entropii także mogą wymagać dodatkowego zewnętrznego programu do

ich uzupełniania, z powodu zbyt małej ilości entropii generowanej ”natywnie”.

Warstwa wyższa 31

5.2.3 Pocket Debian

Pocket Debian to jedna z najbardziej skomplikowanych, a zarazem ciekawych, funkcji

ArchiDroida. Polega ona na możliwości uruchomienia i korzystania z systemu GNU-

/Linux - Debiana, bezpośrednio z poziomu telefonu, w postaci natywnej - bez żadnej

emulacji. Całość sztuczki polega głównie na tym czym jest GNU/Linux - jest to jądro sys-

temowe Linux i zbiór aplikacji, w tym plików binarnych, bibliotek i konfiguracji, które

umożliwiają korzystanie z systemu. Pocket Debian to skompresowane archiwum typu

tar, zawierające pełną strukturę systemu operacyjnego przeznaczonego na architekturę

armhf. Po rozpakowaniu w dowolne miejsce, oraz podmontowaniu wymaganych kernelo-

wych komponentów, jesteśmy w stanie uruchomić natywną powłokę bash, jednocześnie

wchodząc ”wewnątrz” nowego systemu.

Rysunek 5.9: Debian - Shell Rysunek 5.10: Debian - Shell 2

Funkcja ta jest o tyle ciekawa, że pozwala na bardzo łatwą instalację aplikacji normalnie

nieosiągalnych na systemie Android, np. web servera nginx, bazy danych MySQL, czy

PHP-FPM. Wszystko to jest w zasięgu ręki dostępne bezpośrednio z menadżera pakie-

tów apt, który jest dostępny natywnie w debianie. Udało się nawet zaimplementować

w połowie działające GUI, dzięki któremu możliwe jest tymczasowe wyłączenie usługi

Warstwa wyższa 32

surfaceflinger odpowiedzialnej za wyświetlanie obrazu w Androidzie, a w jej miejsce uru-

chomienie debianowego X servera. Rozwiązanie to nie jest jeszcze w 100% perfekcyjne,

lecz pozwala już obecnie na sterowanie Pocket Debianem poprzez ekran dotykowy, pi-

sanie poprzez klawiaturę dotykową, a także korzystanie z udostępnianych przez kernel

urządzeń, takich jak chociażby połączenie Wi-Fi.

Rysunek 5.11: Debian - Zdjęcie

Pocket Debian jest przeznaczony głównie dla bardziej zaawansowanych użytkowników,

którzy wiedzą jak można go wykorzystać. Możliwości tego rozwiązania w rzeczy samej

są ogromne, ale definitywnie nie jest to funkcja dla przeciętnego ani nawet bardziej

zaawansowanego użytkownika. Stanowi ona jednak dobry przykład jak głęboko można

zmodyfikować system Android, umożliwiając nawet działanie ”systemu w systemie”. Jest

to definitywnie pozycja warta uwagi, w szczególności jeśli mamy potrzebę lub ochotę na

uruchomienie niedostępnych z poziomu Androida funkcji, takich jak chociażby serwer

WWW czy SSH.

5.3 Aplikacja

Na system składa się również natywna Androidowa aplikacja ArchiDroid, która służy

zarówno użytkownikowi w konfiguracji i personalizacji systemu, jak i ArchiDroidowemu

Warstwa wyższa 33

backendowi - np. adblockowi, poprzez przekazywanie zdarzeń do właściwych komponen-

tów. Aplikacja ta jest we wczesnym stadium rozwoju, i ma ograniczoną listę możliwości,

lecz spełnia kilka podstawowych funkcji, które są ważne dla użytkownika. Aktualnie apli-

kacja oprócz ekranu głównego i pomocy, oferuje obsługę 3 komponentów - aktualizacji,

backendu oraz pocket debiana.

Na ekranie aktualizacji użytkownik jest w stanie sprawdzić swoją aktualną wersję sys-

temu, a także pobrać nowszą, jeśli oczywiście jest ona dostępna. Całość została prze-

myślana i zintegrowana z serwisem GitHub - aplikacja poprzez GitHubowe API wysyła

zapytanie o aktualną wersję, zaznaczając aktualnie zainstalowany wariant oraz model

urządzenia. Dzięki temu zabiegowi, implementacja aktualizacji jest bardzo uniwersalna

i prosta w implementacji dla developerów, ponieważ jest ona w pełnym sensie ”automa-

tyczna” - developer jedynie wysyła na serwer GitHuba wszystkie swoje commity oraz

skompilowaną wersję binarną, a cała reszta odbywa się automatycznie.

Na ekranie backendu użytkownik ma możliwość konfiguracji tego jak działa Init opisany

wyżej. Na możliwość konfiguracji składają się główne jego komponenty, takie jak Ad-

block, Frandom oraz Haveged. Ekran ten pełni również funkcję informacyjną, czy wszyst-

kie procesy, takie jak dnsmasq czy pixelserv, działają prawidłowo. Aplikacja umożliwia

użytkownikowi w prosty i przyjazny sposób konfigurację backendu, np. wyłączenie lub

włączenie wbudowanego adblocka czy usługi Haveged. W przyszłości ekran ten powinien

zostać rozbudowany o więcej możliwości i opcji personalizacji.

Na ekranie Pocket Debiana użytkownik ma możliwość instalacji/usunięcia pocket de-

biana, zamontowania/odmontowania go oraz uruchomienia powłoki shell, która została

pokazana na rysunku powyżej. W przyszłości na pewno pojawi się również opcja włą-

czenia trybu GUI, w momencie kiedy będzie się on nadawał do używania.

Warstwa wyższa 34

Rysunek 5.12: Aplikacja - update Rysunek 5.13: Aplikacja - backend

Rozdział 6

Testy systemu

Rysunek 6.1: Ekran startowy Rysunek 6.2: Informacje o systemie

ArchiDroid został przetestowany na obu planowanych urządzeniach z całkiem dobrymi

rezultatami.

Wszystkie podstawowe funkcje telefonu działają bez zarzutu. System wydaje się być

stabilny i dopracowany, w pełni nadający się do codziennego użytku. Nie stwierdzono

żadnych regresji w stosunku do wszystkich funkcji oferowanych przez CyanogenModa

35

Testy systemu 36

oraz Androida. Niektóre specyficzne dla danego urządzenia funkcje nie są jeszcze do

końca sprawne (np. wysyłanie i odbieranie MMSów).

ArchiDroidowy backend wydaje się działać bez zarzutu. Najmniej stabilny wydaje się

Pocket Debian, co jest logiczne z powodu tego jak trudna jest jego integracja z działaniem

”wewnątrz” samego Androida.

System jest krokiem milowym naprzód w stosunku do systemu wydanego przez produ-

centa głównie w sferze wydajności i optymalizacji. Dzięki pozbyciu się wszystkich nie-

potrzebnych aplikacji, a także skompilowaniu ArchiDroida najnowszym kompilatorem

z własnym ustawieniem flag optymalizacyjnych, system sprawia wrażenie bardzo szyb-

kiego, a zużycie pamięci jest nawet dwukrotnie niższe niż w przypadku oryginalnego

systemu, co przekłada się bezpośrednio również na zużycie baterii i wielozadaniowość.

Aby zmierzyć różnicę, zostały przeprowadzone testy wydajnościowe (benchmarki). Wy-

niki przedstawiają się następująco:

Rysunek 6.3: AnTuTu ArchiDroid Rysunek 6.4: AnTuTu TouchWiz

Testy systemu 37

Rysunek 6.5: GeekBench ArchiDroid Rysunek 6.6: GeekBench TouchWiz

Testy systemu 38

Rysunek 6.7: Quadrant ArchiDroid Rysunek 6.8: Quadrant TouchWiz

Jak możemy zauważyć, we wszystkich trzech przeprowadzonych benchmarkach, trzema

różnymi aplikacjami, ArchiDroid wypada dużo lepiej na każdym testowanym segmencie.

Począwszy od 13% większej wydajności wg. GeekBencha, poprzez 24% wzrost wg. Qu-

adrant, a kończąc na niemożliwym wręcz do uzyskania wyniku 120% wg. AnTuTu, który

najprawdopodobniej jest spowodowany innymi metodami mierzenia wydajności UX oraz

RAM w obydwu z testowanych systemów. Możemy przyjąć porównanie na bazie CPU,

w którym to wzrost wynosi 13%.

Zgodnie z tymi wynikami, możemy założyć, że połączony efekt zarówno własnego kom-

pilatora, własnych flag optymalizacyjnych, a także bazy CyanogenMod przekłada się na

wzrost od 15 do 25 procent, w zależności od testowanego segmentu. Tak jak zostało

już wielokrotnie wspomniane, należy mieć na uwadze, że benchmark testuje ”surową”

wydajność, a nie to jak wpływa ona bezpośrednio na system operacyjny. System wydaje

się o wiele płynniejszy, o większym potencjalne do wielozadaniowości, ze zmniejszonym

zapotrzebowaniem na pamięć, i wydłużonym czasem pracy na baterii. Właśnie te ce-

chy są celem skupienia się na elementach optymalizacyjnych ArchiDroida, a ”surowa

wydajność” jest miłym dodatkiem, który na pewno zainteresuje osoby oczekujące od

urządzenia maksymalnej mocy obliczeniowej, np. graczy.

Testy systemu 39

Warto również zaznaczyć poprawne działanie pozostałych ArchiDroidowych komponen-

tów, chociażby Adblocka - co możemy zauważyć na porównaniu benchmarków wyko-

nanych aplikacją Quadrant. W przypadku ArchiDroida, nie pojawia się dolny pasek z

reklamą, w przypadku systemu dostarczonego przez producenta - możemy takowy pasek

zauważyć. Aplikacja nie zgłasza żadnych problemów z połączeniem z internetem, i działa

prawidłowo nie wyświetlając żadnych reklam - co jest głównym celem ArchiDroidowego

adblocka, a zatem wszystko działa należycie.

Ogółem można stwierdzić, że testy wypadły pozytywnie. Wykazały one jednak, że Archi-

Droid nadal potrzebuje dużo pracy aby zapewnić bezawaryjne działanie niektórych jego

funkcji, w szczególności tych, które są unikalne. Jest to jednak logiczne biorąc pod uwagę

to jak skomplikowany jest sam system. Należy zauważyć, że już w obecnym stadium,

ArchiDroid wyróżnia się wieloma bardzo ciekawymi cechami na tle systemu wydanego

przez producenta, głównie w zakresie optymalizacji, jako że pozytywnie wpływa ona na

każdą część systemu. Nic bardziej nie denerwuje potencjalnego użytkownika niż ociąga-

jący się system, który nie jest responsywny i nie reaguje dostatecznie szybko na nasze

zadania.

Rozdział 7

Opinie użytkowników

ArchiDroid został skompilowany i opublikowany na łamach portalu xda-developers.com

w finalnej wersji 3.1.5 bazującej na Androidzie 5.1.1 (CyanogenMod 12.1). System jest

dostępny do pobrania z dwóch niezależnych źródeł - GitHuba oraz XDA. Z samego

XDA ArchiDroid na Samsunga Galaxy S3 osiągnął liczbę 56944 pobrań, zaś wersja

na Sony Xperia M osiągnęła liczbę 5955 pobrań (stan na 3 stycznia 2016). Wyniki te

należy pomnożyć przez co najmniej przez 2, jako że pobrania przez serwis GitHub nie

są zliczane.

Użytkownicy bardzo ciepło wypowiadają się na temat ArchiDroida. Głównymi wymie-

nianymi atutami jest bardzo dopracowany i pozwalający na personalizację instalator

AROMA, niskopoziomowe optymalizacje, które zostały również przeportowane na wiele

innych podobnych systemów, stabilność i niskie zużycie baterii, a także ArchiDroidowy

Adblock oraz Pocket Debian.

Wielu użytkowników uważa ArchiDroida za aktualnie najlepszy system operacyjny na

wyżej wymienione modele, co bardzo cieszy z uwagi na to, że jest to dość wczesny

prototyp, któremu wiele jeszcze brakuje do w pełni bezawaryjnej pracy. Użytkownicy

bardzo często pytają jakie jeszcze telefony ArchiDroid ma zamiar wspierać w przyszłości,

nawet warunkując swoje własne decyzje tymi, którymi kieruje się projekt. Sam osobiście

spotkałem się nawet z użytkownikami, którzy gotów są wydać swoje własne pieniądze

tylko po to, żeby developerzy ArchiDroida stworzyli działającą wersję na ich urządzenie.

Na bazie opinii użytkowników można stwierdzić, że ArchiDroid spełnia swoją funkcję

bycia alternatywą dla systemu operacyjnego dostarczonego przez producenta. Oczywi-

ście, jest to wstępny prototyp i dużo jeszcze jest do poprawienia, ale znaczna większość

opinii już teraz jest całkowicie pozytywna.

40

Rozdział 8

Przyszłość projektu

W przyszłości ArchiDroid powinien definitywnie wspierać większą ilość urządzeń. Ak-

tualne wydanie wspiera dwa przykładowe urządzenia - Samsung Galaxy S3 oraz Sony

Xperia M, następnym planowanym urządzeniem jest OnePlus Two, dzięki któremu z po-

wodu swojej natury i firmy, która stara się być przyjazna dla developerów, ArchiDroid ma

szansę rozwinąć skrzydła i stać się bardzo ciekawą alternatywą dla osób wymagających

od swojego systemu nieco więcej niż opcji wyglądu interfejsu czy kontroli prywatności

aplikacji. Już teraz ArchiDroid wyróżnia się dość sporą jak na swój wiek, ilością unikal-

nych funkcji, które spełniają swoje założenia w codziennym użytkowaniu, więc pod tym

względem może być tylko lepiej.

Warto będzie próbować trafić do szerzej ilości potencjalnych odbiorców, w tym również

przeciętnych użytkowników, dla których ArchiDroid może być bardzo dobrą alternatywą

dla stockowego systemu dostarczonego przez producenta. Dzięki otwartemu kodowi źró-

dłowemu, aktualizacjami Androida i dobremu wsparciu, istnieje duża szansa na to, że

ArchiDroid zagości na stałe na wielu starszych niewspieranych już przez producenta

urządzeniach. Przykładowo, najnowszą wersją Androida na zarówno Samsung Galaxy

S3, jak i Sony Xperia M jest wersja 4.3, podczas gdy ArchiDroid już teraz oferuje wersję

5.1.1.

Jeśli zaś chodzi o sam projekt to z natury ogromnej ilości zależności, lista rzeczy, które

można poprawić jest w zasadzie nieskończona. Łatwiej jest powiedzieć co w ArchiDro-

idzie jest skończone, niż to co jest do poprawienia. Aktualny stan można ocenić na ”do-

bry” - priorytetem jest zawsze zapewnienie użytkownikowi większości najważniejszych

funkcji, których oczekuje od urządzenia. Cała reszta jest mniej lub bardziej opcjonalna,

jednocześnie wyróżniając ArchiDroida na tle innych przykładowych rozwiąząń.

41

Rozdział 9

Podsumowanie i wnioski

Głównym celem pracy była próba stworzenia własnego systemu operacyjnego na bazie

Androida będącego w stanie działać na przykładowych dwóch urządzeniach różnych

marek.

Jeśli ktokolwiek sądzi, że tworzenie własnego systemu operacyjnego jest rzeczą prostą -

niestety tak nie jest. ArchiDroid udowodnił jednak, że pomimo przeciwności losu, w tym

braku kodów źródłowych czy dokumentacji, można stworzyć system operacyjny który

zaskakująco dobrze działa na danym urządzeniu, nawet jeśli oficjalnie nie jest ono przez

producenta dłużej wspierane.

Trzeba jednak zauważyć, że wsparcie oraz ogólne nastawienie producenta do developerów

ma bardzo ogromny wpływ na to ile czasu trzeba poświęcić, żeby doprowadzić dane

urządzenie do działania z czystym Androidem czy CyanogenModem. Warto pod tym

względem wybierać odpowiednie urządzenia, takie jak np. rodzinę Nexus od Google,

która ma bardzo szerokie wsparcie. Zaoszczędzi to sporą ilość czasu na integrację już

obecnych rozwiązań z nowym urządzeniem.

Tekst pisany nie jest w pełni w stanie ukazać tego jak rzeczywiście działa system ope-

racyjny ArchiDroid, toteż aby doświadczyć tego z poziomu użytkownika, zalecane jest

obejrzenie jakiejkolwiek dostępnej recenzji systemu np. w serwisie YouTube, chociażby

”Archidroid v3.1.5 Final [Android 5.1.1] For Galaxy S3 (GT-i9300)” 1, do której link

zamieszczono w stopce.

Podsumowując, projekt ArchiDroid ma ogromny potencjał i szerokie zastosowanie jako

alternatywny system operacyjny, a przy odpowiedniej ilości czasu i możliwości jest w

stanie w pełni zastąpić system dostarczony przez producenta, wraz ze wsparciem wszyst-

kich funkcji oferowanych przez sam sprzęt. Użytkownicy bardzo ciepło przyjęli projekt,

a przez wielu z nich już teraz jest uznawany, za najlepszy system operacyjny, jaki kiedy-

kolwiek powstał na dane urządzenie, o czym można usłyszeć m.in w powyższej recenzji.

1https://www.youtube.com/watch?v=xbOURRqELTo

42

Spis rysunków 43

Projekt czeka jednak jeszcze bardzo długa droga, nim ArchiDroid będzie w stanie wspie-

rać szerszą gamę urządzeń i być bardziej uniwersalnym systemem operacyjnym, ale już

obecnie jest w stanie pochwalić się szerokim wachlarzem funkcji i usprawnień, których

nadaremno szukać w innych, podobnych rozwiązaniach.

Spis rysunków

4.1 Benchmark GCC 4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Benchmark Linaro 4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Wyniki ankiety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.1 AROMA - Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 AROMA - ToS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 AROMA - Tryb instalacji . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.4 AROMA - Personalizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.5 AROMA - W trakcie instalacji . . . . . . . . . . . . . . . . . . . . . . . . 235.6 AROMA - Ekran końcowy . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.7 Metoda ArchiDorid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.8 Metoda hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.9 Debian - Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.10 Debian - Shell 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.11 Debian - Zdjęcie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.12 Aplikacja - update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.13 Aplikacja - backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1 Ekran startowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 Informacje o systemie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 AnTuTu ArchiDroid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.4 AnTuTu TouchWiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.5 GeekBench ArchiDroid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.6 GeekBench TouchWiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.7 Quadrant ArchiDroid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.8 Quadrant TouchWiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

44

Bibliografia

[1] Angel Alonso-Parrizas. „Securely deploying Android devices”. W: School of Com-

puting, Dublin City University (wrz. 2011).

[2] Martin Host, Alma Orucević-Alagić. „A Systematic Review of Research on Open

Source Software in Commercial Software Product Development”. W: Department

of Computer Science Lund University (czer. 2011).

[3] Martijn van Zetten, Wilbert Seele. „Assessing Developers’ Interdependency and

Project Governance in the Open-source Cyano-genMod Community”. W: Depart-

ment of Computing and Information Sciences, Utrecht University (2011).

[4] Karim Yaghmour. Embedded Android. Mar. 2013.

[5] Karl-Johan Karlsson, William Bradley Glisson. „Android Anti-forensics: Modify-

ing CyanogenMod”. W: Hawaii International Conference on System Science (sty.

2014).

[6] Tomek Kondrat. XDA Myth Busters: Linaro 4.7.4 vs. GCC 4.7. Kw. 2014. url:

http://www.xda-developers.com/xda-myth-busters-linaro-4-7-4-vs-

gcc-4-7/.

[7] Charan K. V, A. S Manjunath, Sharmila. „Customizing AOSP For Different Em-

bedded Devices And Integration at Application Layer”. W: International Journal

of Advance Foundation and Research in Computer (czer. 2014).

[8] „The Peril of Fragmentation: Security Hazards in Android Device Driver Custo-

mizations”. W: School of Informatics and Computing, Indiana University, Blo-

omington (maj 2014).

[9] CyanogenMod Community. How To Port CyanogenMod Android To Your Own

Device. List. 2015. url: https://wiki.cyanogenmod.org/w/Doc:_porting_

intro.

[10] Roger Ye. Embedded Programming with Android : Bringing Up an Android System

from Scratch. Sierp. 2015.

45