EXAMENSARBETE INOM TEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2019
Undersökning av alternativ för virtualisering av Android på SailfishOS
AMANDA NEE
KTH SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP Abstract
This report documents the result of an attempt to port the virtual android environment Anbox to the smart phone operating system SailfishOS. The purpose of the project is to see if such a solution can make SailfishOS and similar operating systems useful in a society that indirectly requires you to be able to run Android or iOS applications on your phone. The result of the project makes a number of short comings clear in the SailfishOs platform which hindered an actual attempt to evaluate the compatibility between Anbox and SailfishOS. 2 Sammanfattning
Denna rapport redovisar resultatet från ett försök att portera den virtuella androidmiljön Anbox till det telefoninriktade operativsystemet SailfishOS. Detta görs för att uppskatta om en sådan lösning kan få SailfishOS och liknande operativsystem användbara i dagligt bruk i dagens samhälle som har ett indirekt krav på att man ska kunna köra Android eller iOS appar. Resultatet visar på begränsningar som SailfishOS-plattformen har idag vilket hindrade en ordentligt granskning av kompatibiliteten mellan Anbox och SailfishOS att genomföras. 2 Innehåll
1 Introduktion 5 1.1 Bakgrund ...... 5 1.2 Problem ...... 6 1.3 Syfte ...... 6 1.4 Mål ...... 6 1.5 Fördelar, Etik och Hållbarhet ...... 6 1.6 Metod ...... 7 1.7 Avgränsningar ...... 7 1.8 Översikt ...... 7
2 Teori 9 2.1 informationsinhämtning ...... 9 2.2 Kernelmoduler i Linux ...... 9 2.3 Programvaran - Anbox ...... 9 2.4 Platformen - SailfishOS ...... 10 2.5 ARM-plattformen ...... 10 2.6 Versionshanteringssystem - Repo ...... 10 2.7 Hardware Adaption Developers Kit ...... 10
3 Metod 11 3.1 Mjukvaruval ...... 11 3.2 Prototypen ...... 11 3.3 Utvecklarmiljön ...... 12 3.4 Arbetsmetod ...... 12
4 Genomförande 13 4.1 Prototyp 0 - Försök med ren linuxkernel ...... 13 4.2 Prototyp 1 - Fungerande bassystem ...... 14 4.3 Prototyp 2 - Fungerande anboxkompatibel kernel ...... 19
5 Avslut 23 5.1 Resultat ...... 23 5.2 Diskussion ...... 23 5.3 Sammanfattning ...... 24 5.4 Framtida arbete ...... 24
Referenser 24
3 4 INNEHÅLL Kapitel 1 Introduktion
1.1 Bakgrund
Idag finns det två plattformar för smarta mobiltelefoner, Android och iOS. Båda har effektivt sett stängd källkod, båda ägs av stora amerikanska företag och båda används för att samla in så mycket information om sina användare som det går, direkt eller indirekt. Dessa två plattformar har tillsammans oligopol på världsmarknaden. Googles Android har delar med öppen källkod då det är baserat på Android Open Source Project vanligen kallat AOSP men har även licensbelagda kärnkomponenter likt Play Store och Google Services baserade på stängd källkod. Då dessa applikationer har en central del i plattformen är androidplattformen i realitet stängd. Android till skillnad från iOS är tillgängligt för tillverkare andra än Google att utveckla enheter till, vilket är varför Android idag är den största plattformen i världen.[1] Företagen bakom dessa två plattformar är baserade i USA vilket kan göra att tillverkare i omvärlden effektivt bli förbjudna att använda någon de två plattformar som har världsomfattande oligopol om regeringen i USA bestämmer sig för att svartlista tillverkaren. Detta gör att Android på grund av sin stängda källkod inte bara är världens största plattform men även ett kraftfullt politiskt och ekonomiskt vapen.[2] Efter Snowden läckorna[3], Cambridge Analyticas[4] och att anställda på Amazon använder inspelade ljudklipp från Alexa som skämt på deras interna forum[5] har fler och fler blivit intresse- rade att byta ifrån plattformar där användaren betalar genom att ge all sin personliga information till plattformsägaren. Problemet är att det just nu inte finns en mobilplattform som respekterar sina användare. Vi har även historiskt sett att monopol eller oligopol inte leder till innovation eller i vissa fall inte äns en kvalitativ produkt. Där ett relevant exempel är hur linuxkerneln tillsammans med GNUs verktyg blev ett operativsystem som tävlade med de på den tiden stora unixbaserade opera- tivsystemen för att sedan konkurrera ut dem och bli standard i servervärlden. Ett operativsystem som från början utvecklats av hobbyister på sin fritid för att komma bort från mjukvarujättarnas restriktioner konkurrerade ut en mångmiljonindustri[6].
Behovet av appar I dagens samhälle är det svårare och svårare att leva utan en Android eller iOS baserad mobiltelefon. Om du ska åka med kommunala färdmedel i Stockholm behöver du ha ett accesskort och veta att du har reskassa på detta eller använda en mobil app till Android eller iOS. Om du ska försöka parkera i Stockholm behöver du en mobil app då antalet p-automater minskat till en sådan grad att det är väldigt svårt att hitta en. Dagens gym håller sakta att gå från gym kort och använder istället en app för inträde och bokning av pass. Om du är student måste du nu specifikt beställa ett studentkort eller använda en mobil app. Om du vill logga in på din banks hemsida gör du det lättast med en mobil app eller så loggar du in i bankens egna app och uträttar ditt ärende. Beställning av taxi håller också på att gå över till appar. Det görs även försök att byta ut kredit och betalkort mot applikationer så som Swish, Samsung pay och Google pay. Som regel håller all gammal funktionalitet som tidigare krävt personal i form av kassörer sakta på att gå över till appar och då fokus skiftar försämras kvalitén och användarvänligheten av de gamla systemen då pengar läggs på de nya tjänsterna istället.
5 6 KAPITEL 1. INTRODUKTION
Majoriteten av dagens kommunikation sker också via appar. Appar som i vissa fall inte har något sätt att användas från en vanlig dator. Medan vanlig telefoni och sms fortfarande existerar väljs dessa i många fall bort på grund av sin avsaknad av funktionalitet de nya apparna har. Detta förstärker också behovet av en enhet som kan köra android eller iOS.
En alternativ plattform SailfishOS är ett operativsystem för mobiltelefoner som varken är baserat på Android eller iOS. Detta gör att det måste hitta ett annat sätt att köra applikationer från någon av de nämnda för att kunna användas i dagligt bruk. Detta görs idag med hjälp av virtualiseringslösningen som kallas Alien Dalvik[7] vilket gör att operativsystemet kan köra androidapplikationer. Men implementa- tionen har begränsningar vilket gör att användaren måste köpa en ny telefon om de vill ha stöd för en nyare version av Android. Detta krävs inte för SailfishOS då alla SailfishOS-enhet har rullande uppdateringar vilket betyder att alla enheter får den senaste versionen av operativsystemet.
1.2 Problem
Behovet av androidappar gör det svårt att utveckla en alternativ plattform för mobilmarknaden. SailfishOS har i detta fall en lösning men då androidstödet är låst vid en viss version av android per enhet och mjukvaran är licensbelagd skapas samma behov av att köpa en ny enhet som i androidvärlden, där applikationer sakta inkluderar ny funktionalitet vilket gör att versionskravet för android ökar. Faktumet att huruvida tillverkaren utvecklar en ny SailfishOS enhet eller ej är en osäkerhet som förstorar problemet. För att frångå behovet av att köpa en ny enhet och behovet av att en ny enhet existerar krävs en fungerande lösning för androidstöd som är baserad på öppen och fri källkod. En sådan lösning finns inte idag.
1.3 Syfte
Syftet med projektet var att undersöka alternativ till nuvarande implementation av virtualisering av android för att se om det finns ett realistiskt alternativ som kan implementera ett rullande stöd för android på plattformen SailfishOS.
Syftet med rapporten var att dokumentera utmaningen, tillvägagångssättet och resultatet, så att detta kan användas för att hjälpa och informera framtida arbete inom området.
1.4 Mål
Arbetets mål var att se om Anbox som tillåter användaren att köra androidappar på desktop linux gick att få att fungera på SailfishOS och i så fall vad som krävdes.
Uppsatsens effektmål är att presentera resultatet från porteringsförsöket, dokumentera detta, re- flektera över det och föreslå ett nästa steg i arbetet.
1.5 Fördelar, Etik och Hållbarhet
Detta projekt försöker få programvara med öppen och fri källkod att fungera på en annan plattform med öppen och fri källkod1. Då öppen och fri källkod ger alla oavsett ställning vare sig i samhället eller ekonomiskt samma rätt samt möjlighet att ta del av, lära sig om och modifiera koden är det ett hållbart sätt att utveckla mjukvara ur ett samhällsperspektiv. Projektets indirekta mål är att försöka göra denna öppna plattform mer gångbar och ta bort behovet av att med jämna mellanrum behöva ny hårdvara. Detta har i sin tur den indirekta påver- kan att försöka motverka dagens oligopol på mobiltelefonmarknaden, minska mängden elektroniskt
1Det grafiska gränssnittet och några av applikationerna i SailfishOS är fortfarande inte öppet även om Jolla lovat att göra detta. Dock går dessa att byta ut mot helt öppna alternativ. 1.6. METOD 7 avfall och behovet av sällsynta metaller till tillverkningen av nya enheter. Dessa konsekvenser är också positiva för samhället ur både ett hållbarhetsperspektiv och ett etiskt perspektiv. Dock måste nämnas att den faktiska skillnaden detta projekt gör i isolation är försumbar. Men författaren hoppas på att det kan inspirera och hjälpa andra att fortsätta arbetet.
1.6 Metod
Då projektet försöker lösa ett problem genom att få programvara att fungera på en ny plattform används en applicerad forskningsmetod med utgångspunkt i realismen då datorer och mjukvara kan anses vara deterministiska inom omfattningen av projektet. En fallstudie i form av en prototyp är utgångspunkten för projektet och resultat där rapporten ska kunna användas som grund till reproducerbarhet av resultatet vilket ger möjlighet till att bekräfta det. Prototypen kommer tas fram genom en iterativ metod.
1.7 Avgränsningar
SailfishOS valdes som plattform att portera mot då det är den som är störst av de alternativa platt- formarna baserat på åratal av följande av nyhetsflöden och den författaren hade mest erfarenhet av. Anbox valdes då det var det projekt som verkade mest aktivt och hade kommit längst i utveck- lingen av de alternativ som fanns. Detta baserat på aktiviteten på respektive projekts githubsida. Plattformen som porterades till var Xperia X vilken valdes då det fanns en enhet tillgänglig och det är lättare att upptäcka problem om man porterar mot en fysisk enhet istället för en virtuell maskin. Det säger även mer att få en fungerande fysisk prototyp än en virtuell prototyp.
1.8 Översikt
I följande kandidatuppsats finns totalt sju kapitel:
Kapitel ett är en introduktion till uppsatsen som berättar bakgrunden till studien och vilket pro- blem som undersökts. Kortfattat beskrivs målet med arbetet, metoden som använts och arbetets koppling till etik och hållbarhet.
Kapitel två är en fördjupad teoretisk bakgrund till den plattform, de programvaror och bestånds- delar som ingår i projektet.
Kapitel tre diskuterar och analyserar val av valda metod för att genomföra projektet, samt desig- nen av utförandet.
Kapitel fyra handlar om det utförda arbetet och återger hur detta skulle kunna reproduceras till den mån som går.
Kapitel fem presenterar resultatet som framkom från arbetet.
Kapitel sex analyserar och diskuterar resultatet.
Kapitel sju presenterar en sammanfattning samt förslag på framtida arbete. 8 KAPITEL 1. INTRODUKTION Kapitel 2 Teori
Denna sektion går genom informationsinhämtning inom ämnet och en kort sammanfattning av de förkunskaper som krävs för att förstå projektet.
2.1 informationsinhämtning
På grund av ämnets natur kan ingen ordentlig litteraturstudie genomföras då det inte finns något relevant tidigare arbete dokumenterat inom detta område. Istället har en generell sökning av infor- mation skett via sökmotorer som duckduckgo.com och startpage.com en anonymiserande proxy till google.com. Även källor som IRC-kanalen sailfish-porters på freenode och dess loggar, och Riot.im kanalen Sailfish OS Fan Club har tagits till hjälp för att hitta relevant information inom ämnet. Utav den information som hittats användes Jolla Oys egna guide om hur man portar operativ- systemet till nya enheter; Hardware Adaption Developers Kit[8], samt en guide specifik till enheten Sailfish X Build and Flash[9] som användes för framtagning av prototypen. Som hjälp i att förstå systemets uppbyggnad användes även guider på Sonys hemsida om hur man kompilerar kernel och Android till Xperia X från Sonys egna versioner av kodbaserna.
2.2 Kernelmoduler i Linux
Kernelmoduler är ytterligare funktionalitet som går att aktivera eller inaktivera genom att inklu- dera modulens kod antingen vid kompilering som en intern modul eller som en extern modul efter kompilering. I fallet som extern modul krävs det att kerneln har stöd för externa moduler vilket i sig är en modul vilken endast går att lägga till vid kompileringstillfället. Om stöd för externa moduler finns sköts modifierandet av kernelns externa moduler via en samling av program som kallas kmod.I kmod finns bland annat insmod som installerar moduler och rmmod som tar bort moduler från kerneln[10].
2.3 Programvaran - Anbox
Anbox är en virtualisering av Android utvecklad för linuxdistributioner för persondatorer. Imple- mentationen använder sig av Qemu[11] som virtualiseringsmotor och isolerar processen med en implementation baserad på Canonicals Snaps[12]. Båda dessa programvaror kräver stöd i opera- tivsystemets kernel. Qemu kräver virtualiseringsstöd och Snaps kräver att modulen AppArmor[13] är aktiv. Anbox har två egna kernelmoduler vilka möjliggör dess implementation av kontainerisering. Dessa finns inte i linuxkernelns egna kodträd i skrivande stund utan måste kompileras in via externa eller interna moduler. Programmet är skrivet i c++ men då det använder sig av Snaps behöver det inte kompileras utan går i teorin med hjälp av Snaps att ladda ner och installera Anbox automatiskt på plattformen via terminalemulator.[14]
9 10 KAPITEL 2. TEORI
Figur 2.1: A simple overview of SailfishOS
2.4 Platformen - SailfishOS
SailfishOS är en plattform som använder sig av Androids modifierade linuxkernel, ett översätt- ningslager, libhybris, och på den grunden ligger en normal linuxbas vilket illustreras i Figur 2.1. Detta innebär att kerneln som behöver modifieras för användning av Anbox är linuxkerneln och att kompilatorn som kommer användas är GNU C Compiler; GCC. Då SailfishOS inte är baserad på någon av de stora linuxdistributionerna så är antalet färdig- kompilerade program i programarkiven som går att hämta från via terminalemulatorn begränsat vilket gör att nya program behöver portas över eller hämtas från annat håll. SailfishOS kommer i ursprung med en kernel utan stöd för externa moduler vilket gör att kerneln måste kompileras om med den nya modulen inkluderad eller med stöd för externa moduler inkluderat.[15]
2.5 ARM-plattformen
ARM-plattformen är en löst definierad plattform konstruerad kring instruktionskitet som företaget ARM[16] licensierar ut till företag för användning i sina processorer. På grund av sin i jämförelse med x86-plattformen lösa definition behövs det ett annat sätt för mjukvara att veta vilken enhet som är inkopplad var. Linuxkernelns lösning heter Device Tree Reference[17] vilket är en fil med en lista över vilken enhet som sitter var och vilken drivare denna kräver. Detta underlättar ut- vecklingen av nya enheter då information som denna inte längre behöver hårdkodas vilket tillåter varierande konfigurationer. Detta gör också denna fil viktig när linuxkerneln ska kompileras för en ny enhet då kerneln inte kommer kunna hitta var till exempel skärmen på enheten sitter om filen saknas.[18]
2.6 Versionshanteringssystem - Repo
Repo är ett versionshanteringssystem framtaget av Google byggt ovanpå git. Repo är det huvud- sakliga verktyget för att ladda ner, arbeta med och bidra till Android Open Source Project. Verktyget har använts för att ladda ner, uppdatera och sköta kodbasen i projektet då SailfishOS använder sig av lågnivådelar från android.[19]
2.7 Hardware Adaption Developers Kit
Hardware Adaption Developers Kit eller HADK som det oftast kallas är ett dokument som är till för att hjälpa till vid porterandet av SailfishOS till ny hårdvara. Detta gör det även bra vid modifiering av operativsystemet då det går igenom hur man hämtar ner dess delar och bygger dem. HADK är ett dokument som uppdateras av utvecklarna Jolla Oy, som är företaget bakom SailfishOS, med hjälp av återkoppling från externa utvecklare.[8] Kapitel 3 Metod
Då projektets fokus är ett försök till framtagande av en prototyp med Anbox körandes på SailfishOS finns det inte många olika metoder som är realistiska för projektet. Ett helt teoretiskt projekt är svårt att genomföra då kompatibilitet mellan mjukvaror av denna storlek är svår att avgöra utan att testa. I teorin bör det vara möjligt att modellera det hela matematiskt men då detta skulle bli ett projekt i sig valdes en mer praktisk väg. En virtuell prototyp i form av en implementation i en virtuell miljö är ett annat möjligt val. Detta skulle dock inte bli en praktiskt användbar implementation vilket är ett indirekt mål med projektet och valdes därför inte som metod. Det som valdes var att försöka implementera en fungerande mjukvaruprototyp på en fysisk en- het. Detta underlättar bland annat eventuell testning av den färdiga prototypen. En fysisk prototyp kan svara på frågan huruvida lösningen lever upp till en användbar standard eller om oförutsedda problem som en virtuell miljö inte skulle kunna visa existerar, så som abnorm energiförbrukning eller prestandabrister i användning parallellt med annan programvara.
3.1 Mjukvaruval
Mjukvarumässigt fanns det fler alternativ till både SailfishOS och Anbox. Som alternativ till Sa- ilfishOS finns Ubuntu Touch, Mer, PureOS och även ARM versionen av flertal desktop OS där bland Arch Linux och Debian. Men då SailfishOS var det enda alternativet som aktivt utvecklas till telefoner, i ett användbart skick, med finansiering från ett företag som inte lär upphöra med sin support och utveckling inom snar framtid, fanns det egentligen inte något annat alternativ. Till Anbox finns det egentligen bara ett annat alternativ utöver att skriva en egen implementation vilket är långt förbi omfånget av projektet och kunskaperna hos genomföraren. Alternativet heter Sfdroid men då det inte är tydligt vad som hänt med det projektet utöver att det inte varit aktivt på länge fastslogs att Anbox som är ett aktivt projekt var det bättre alternativet.
3.2 Prototypen
Figur 3.1: Serien av prototyper som kommer itereras mellan.
Prototypen kommer köras på en Sony Xperia X som kommer flashas med verktyget Fastboot från Androidprojektet. Prototypen kommer utvecklas iterativt vilket visas i Figur 3.1. Där den
11 12 KAPITEL 3. METOD första versionen kommer vara en omodifierad version av SailfishOS för att säkerställa att hela utvecklingskedjan fungerar. Därefter kommer kerneln modifieras med de modifieringar som krävs vilket kommer resultera i en ny version av prototypen som kommer säkerställa att operativsystemet fungerar med den modifierade kerneln. Därefter följer att sammanställa alla mjukvaror som Anbox kräver, lägga till dem i prototypen, testa så allt fortfarande fungerar och att mjukvaran ligger där den ska i den nya versionen av prototypen. Sist blir att få in Anbox i prototypen vilket kan göras på några olika sätt som får testas på prototypen från tidigare steg.
• Prototyp 0 - Försök med ren linuxkernel • Prototyp 1 - Fungerande bassystem
• Prototyp 2 - Fungerande anboxkompatibel kernel • Prototyp 3 - Fungerande mjukvaruberoenden till Anbox (Genomfördes inte) • Prototyp 4 - Fungerande installation med Anbox (Genomfördes inte)
3.3 Utvecklarmiljön
Hela arbetet har genomförts på en dator med Linux Mint och medföljande terminalemulator men projektet bör vara reproducerbart på majoriteten av linuxdistributioner då verktygen som används inte skiljer sig på väsentliga punkter mellan linuxdistributioner. För de små kodingrepp som behöv- de göras användes Neovim och Gedit. För tillhandahållande av kodbaserna användes som nämnt Git och Repo. Androids byggmiljö kräver Bash vilket gjorde att majoriteten av det direkta arbetet med bygg- skripten och den medföljande byggmiljön skedde via Bash. SailfishOS har i sig en egen utvecklingsmiljö vilken består av en SDK och ett Ubuntu root system. Hur dessa installeras går igenom i nästa kapitel.
3.4 Arbetsmetod
Då projektet genomfördes individuellt ansågs inte någon större organiserande metod så som Vat- tenfallsmodellen eller Agile vara behövd. Istället användes de olika prototypversionerna som orga- niserande delmål inom projektet. Kapitel 4 Genomförande
Här gås igenom den del av portningsprocessen som kunde genomföras. Då de fel som påträffades beskrivs enklare i sammanhang med resten av portningsprocessen har hela processen dokumente- rats. Felsökningsprocesserna summeras och fokus ligger på att presentera lösningar och de problem som inte kunde lösas.
Prototyp noll är ett misslyckat försök att få en ren linuxkernel att fungera med enheten i syf- te att undvika den extra komplexitet Android introducerar.
Prototyp ett går ut på att få en fungerande egenkompilerad version av SailfishOS på enheten. Genom att göra detta fastställs att utvecklingskedjan från kernel till prototyp fungerar. Detta görs genom att följa Sailfish X byggsida och HADK version 3.0.1.
Prototyp två går igenom vad som gjordes för att försöka få prototypen att fungera och vad som gick mindre bra.
4.1 Prototyp 0 - Försök med ren linuxkernel
Följande genomförs i en terminal för att möta beroendena för korskompilering av linuxkerneln.
Listing 4.1: Paketberoenden och miljövariabler sudo apt install gcc gcc-aarch64-linux-gnu gcc-arm-linux - gnueabi export ARCH=arm64 export CROSS_COMPILER=/usr/bin/aarch64-linux-gnu- Paketkraven från ovan är samma för båda kernelversionerna och miljövariablerna sätts en gång per terminal.
Listing 4.2: Mainline linuxkernel git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux git checkout v4.9 git remote add linux-next git://git.kernel.org/pub/scm/ linux/kernel/git/next/ linux-next.git git fetch linux-next make qcom_defconfig make menuconfig make Om allt fungerat ska nu arch/arm64/boot/dts innehålla en dts-fil med enhetens namn vilken används för att skapa filen boot.img som kan flashas till enheten. Enhetens namn är loire suzu. Efter en del efterforskning konstaterades att enheten saknade support i mainline-kerneln baserat på avsaknaden av dts fil under arch/arm64. Detta ledde till att Sonys kopia av linuxkerneln provades istället.
Listing 4.3: Sonys linuxkernel git clone https://github.com/sonyxperiadev/kernel-copyleft cd kernel-copyleft
13 14 KAPITEL 4. GENOMFÖRANDE
git branch -r git checkout Nästa steg är att identifiera konfigurationsfilen för att använda den som bas till att kompilera kerneln. Ingen sådan fil hittades och efter ytterligare testande, sökande och läsande konstaterades att även Sony verkade sakna tillgänglig källkod till en kernel för enheten.
Summering Försöket att få en androidfri linuxkernel att fungera på enheten övergavs baserat på bristen på instruktioner och information. Det faktum att det även fanns väldokumenterade instruktioner för hur man kompilerar och får androidkerneln att fungera på enheten och att fokus ligger vid att försöka få Anbox att fungera på systemet inverkade också på beslutet. Att få androidfri Linux att fungera på enheten är inte ett krav utifrån projektet.
4.2 Prototyp 1 - Fungerande bassystem
Denna sektion är en sammanslagning av HADK, Sailfish X Build and Flash guiden och egna lös- ningar på buggar och problem som hittades.
Minst 80 GB ledigt hårddiskutrymme och 16 GB RAM krävs för följande metod.
Installation av repo Repo är verktyget som kommer användas för att ladda ner all källkod. Det installerades på följande sätt.
Listing 4.4: Installation av repo mkdir ~/ bin curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo För att verkställa ändringen stängs terminalen och en ny öppnas för fortsatt arbete.
Konfiguration av utvecklingsmiljön SailfishOS utvecklingsmiljö består av tre filer en ubuntu chroot och en SDK. SDKn laddas ner när resterande delar är på plats. De tre filerna .hadk.env, .mersdkubu.profile och .mersdk.profile ska skapas i användarens hemkatalog. Dessa filer konfigureras med information om enhet, plattform med mera likt följande.
Listing 4.5: ∼/.hadk.env export PLATFORM_SDK_ROOT="/srv/mer" export ANDROID_ROOT="$HOME/android" export VENDOR=sony export DEVICE=f5121 export HABUILD_DEVICE=suzu export DEVICE_GROUP=f512x export BRANCH=6.0.1_r80 export HAVERSION="sony-aosp-"$BRANCH"-20170902" export PORT_ARCH="armv7hl" export PATH=~/bin:$PATH
Listing 4.6: ∼/.mersdkubu.profile function hadk() { source $HOME/.hadk.env; echo "Env␣setup ␣for␣$DEVICE"; } export PS1="HABUILD_SDK␣[\${DEVICE}]␣$PS1" hadk
Listing 4.7: ∼/.mersdk.profile function hadk() { source $HOME/.hadk.env; echo "Env␣setup ␣for␣$DEVICE"; } hadk PS1="PlatformSDK␣$PS1" if [ -d /etc/bash_completion.d ]; then for i in /etc/bash_completion.d/*; 4.2. PROTOTYP 1 - FUNGERANDE BASSYSTEM 15
do . $i done fi
alias hadksdk=’ubu-chroot -r $PLATFORM_SDK_ROOT/sdks/ubuntu ’ Efter att de tre filerna är skapade läggs två rader till i .bashrc för att underlätta användningen av utvecklingsmiljön.
Listing 4.8: ∼/.bashrc export PLATFORM_SDK_ROOT=/srv/mer alias sfossdk=$PLATFORM_SDK_ROOT/sdks/sfossdk/mer-sdk - chroot Med alla filer klara laddas SDKn ner.
Listing 4.9: Installation av SDK export PLATFORM_SDK_ROOT=/srv/mer curl -k -O http://releases.sailfishos.org/sdk/installers/latest/Jolla-latest- SailfishOS_Platform_SDK_Chroot -i486.tar.bz2 sudo mkdir -p $PLATFORM_SDK_ROOT/sdks/sfossdk sudo tar --numeric-owner -p -xjf Jolla-latest-SailfishOS_Platform_SDK_Chroot -i486 .tar.bz2 -C $PLATFORM_SDK_ROOT/sdks/sfossdk SailfishOS SDK kan nu i en ny terminal startas genom att använda kommandot sfossdk.
Källkoden Kommandona sfossdk följt av hadksdk exekveras i ett nytt terminalfönster. Detta placerar ter- minalen i HABUILD_SDK $ vilket är en del av byggmiljön. Härifrån kan filsystemet modifieras och nerladdningen startas.
Listing 4.10: Nerladdning källkod HABUILD_SDK $
sudo mkdir -p $ANDROID_ROOT sudo chown -R $USER $ANDROID_ROOT cd $ANDROID_ROOT repo init -u git://github.com/mer-hybris/android.git -b hybris-$HAVERSION -m tagged-manifest.xml --no-repo-verify repo sync -j6 --fetch-submodules En make-fil kräver modifiering för att kompilera på system med ANSI-2011 som standard.
Listing 4.11: ANSI-2011 fix vim rpm/dhd/helpers/mkbootimg.mk # efter andra flaggor CPPGLAGS= -std=c99
Listing 4.12: Kompilation av hybris-hal . build/envsetup.sh export USE_CCACHE=1 lunch aosp_$DEVICE-userdebug make -j$(nproc --all) hybris-hal HABUILD_SDK $ respektive PLATFORM_SDK $ visar vilken miljö kommandona behöver och kan exe- kveras i.
Efter att hybris-hal är klar ska två filer ha skapats; hybris-boot.img och hybris-recovery.img.
Scratchbox installeras då detta krävs senare i processen.
Listing 4.13: Installation av Scratchbox PLATFORM_SDK $
sdk-assistant create SailfishOS-3.0.2.8 http://releases.sailfishos.org/sdk/ targets/Sailfish_OS-latest-Sailfish_SDK_Tooling-i486 . tar .7z sdk-assistant create $VENDOR-$DEVICE-$PORT_ARCH http://releases.sailfishos.org/ sdk/targets/Sailfish_OS-latest-Sailfish_SDK_Target- armv7hl.tar.7z 16 KAPITEL 4. GENOMFÖRANDE
När Scratchbox installerats konfigureras systemlagret.
Listing 4.14: Systemlager PLATFORM_SDK $
cd $ANDROID_ROOT rpm/dhd/helpers/build_packages.sh --droid-hal git clone --recursive https://github.com/mer-hybris/droid-config-$DEVICE hybris/ droid-configs -b master
if [ -z "$(grep␣community_adaptation␣$ANDROID_ROOT/hybris/droid-configs/rpm/droid -config-$DEVICE.spec)" ]; then sed -i ’/%include droid-configs-device/i%define community_adaptation 1\n’ $ANDROID_ROOT/hybris/droid-configs/rpm/droid-config -$DEVICE.spec fi
if [ -z "$(grep␣patterns-sailfish-consumer-generic␣$ANDROID_ROOT/hybris/droid- configs/patterns/jolla-configuration-$DEVICE.yaml)" ]; then sed -i "/Summary:␣Jolla␣Configuration␣$DEVICE/i-␣patterns-sailfish-consumer- generic\n-␣pattern:sailfish-porter-tools\n" $ANDROID_ROOT/hybris/droid- configs/patterns/jolla-configuration-$DEVICE.yaml fi
if [ -z "$(grep␣jolla-devicelock-daemon-encsfa␣$ANDROID_ROOT/hybris/droid-configs /patterns/jolla-hw-adaptation-$DEVICE_GROUP.yaml)" ]; then sed -i "s/sailfish-devicelock-fpd/jolla-devicelock-daemon-encsfa/" $ANDROID_ROOT/ hybris/droid-configs/patterns/jolla-hw-adaptation-$DEVICE_GROUP.yaml fi
rpm/dhd/helpers/build_packages.sh --configs rpm/dhd/helpers/build_packages.sh --mw \# select "all" option when asked Efter systemlagret kompileras stöd för NFC och Bluetooth, följt av droid-system och ljud.
Listing 4.15: NFC and Bluetooth HABUILD_SDK $
sudo apt-get install rsync cd $ANDROID_ROOT/.. mkdir syspart cd syspart repo init -u git://github.com/mer-hybris/android.git -b syspart-$HAVERSION -m tagged-manifest.xml repo sync -j6 --fetch-submodules source build/envsetup.sh export USE_CCACHE=1 lunch aosp_$DEVICE-userdebug make -j$(nproc --all) libnfc-nci bluetooth.default_32 systemtarball
Listing 4.16: droid-system PLATFORM_SDK $
cd $ANDROID_ROOT/../syspart git clone https://github.com/mer-hybris/droid-system- $DEVICE mb2 -t $VENDOR-$DEVICE-$PORT_ARCH -s droid-system-$DEVICE/rpm/droid-system- $DEVICE.spec build rm -f $ANDROID_ROOT/droid-local-repo/$DEVICE/droid-system -*. rpm mv RPMS/droid-system-*-0.1.1-1.armv7hl.rpm $ANDROID_ROOT/droid-local-repo/$DEVICE / createrepo_c "$ANDROID_ROOT/droid-local-repo/$DEVICE " sb2 -t $VENDOR-$DEVICE-$PORT_ARCH -m sdk-install -R zypper ref
Listing 4.17: Audio HABUILD_SDK $
cd $ANDROID_ROOT git clone https://github.com/mer-hybris/audioflingerglue external/ audioflingerglue git clone https://github.com/sailfishos/droidmedia external/droidmedia
source build/envsetup.sh 4.2. PROTOTYP 1 - FUNGERANDE BASSYSTEM 17
export USE_CCACHE=1 lunch aosp_$DEVICE-userdebug make -j$(nproc --all) $(external/droidmedia/detect_build_targets.sh $PORT_ARCH $( gettargetarch)) $(external/audioflingerglue/detect_build_targets.sh $PORT_ARCH $(gettargetarch)) Till sist paketeras allt.
Listing 4.18: Paketering PLATFORM_SDK $
cd $ANDROID_ROOT DROIDMEDIA_VERSION=$(git --git-dir external/droidmedia/.git describe --tags | sed -r "s/\-/\+/g") rpm/dhd/helpers/pack_source_droidmedia-localbuild.sh $DROIDMEDIA_VERSION mkdir -p hybris/mw/droidmedia-localbuild/rpm cp rpm/dhd/helpers/droidmedia-localbuild.spec hybris/mw/droidmedia-localbuild/rpm /droidmedia.spec sed -ie "s/0.0.0/$DROIDMEDIA_VERSION/" hybris/mw/droidmedia-localbuild/rpm/ droidmedia.spec mv hybris/mw/droidmedia-$DROIDMEDIA_VERSION.tgz hybris/mw/droidmedia-localbuild rpm/dhd/helpers/build_packages.sh --build=hybris/mw/ droidmedia-localbuild rpm/dhd/helpers/build_packages.sh --mw=https://github.com/sailfishos/gst-droid. git
AUDIOFLINGERGLUE_VERSION=$(git --git-dir external/audioflingerglue/.git describe --tags | sed -r "s/\-/\+/g") rpm/dhd/helpers/pack_source_audioflingerglue-localbuild .sh $AUDIOFLINGERGLUE_VERSION mkdir -p hybris/mw/audioflingerglue-localbuild/rpm cp rpm/dhd/helpers/audioflingerglue-localbuild.spec hybris/mw/audioflingerglue- localbuild/rpm/audioflingerglue.spec sed -ie "s/0.0.0/$AUDIOFLINGERGLUE_VERSION/" hybris/mw/audioflingerglue- localbuild/rpm/audioflingerglue.spec mv hybris/mw/audioflingerglue-$AUDIOFLINGERGLUE_VERSION.tgz hybris/mw/ audioflingerglue-localbuild rpm/dhd/helpers/build_packages.sh --build=hybris/mw/ audioflingerglue-localbuild rpm/dhd/helpers/build_packages.sh --mw=https://github.com/mer-hybris/pulseaudio- modules-droid-glue.git
rpm/dhd/helpers/build_bootimg_packages.sh sb2 -t $VENDOR-$DEVICE-$PORT_ARCH -m sdk-install -R zypper in --force-resolution droid-hal-$DEVICE-kernel-modules git clone --recursive https://github.com/mer-hybris/droid-hal-img-boot-$DEVICE hybris/mw/droid-hal-img-boot-$DEVICE rpm/dhd/helpers/build_packages.sh --mw=https://github.com/mer-hybris/droid-hal- img-boot-$DEVICE rpm/dhd/helpers/build_packages.sh --mw=https://github.com/mer-hybris/bluetooth- rfkill-event --spec=rpm/bluetooth-rfkill-event-hciattach . spec
git clone --recursive https://github.com/mer-hybris/droid-hal-version-$DEVICE hybris/droid-hal-version-$DEVICE rpm/dhd/helpers/build_packages.sh --version Med allt kompilerat och paketerat konfigurerar vi kickstarter-filen vilken ligger som grund för systemavbilden.
Listing 4.19: Konfigurering av Kickstarter-fil PLATFORM_SDK $ cd $ANDROID_ROOT HA_REPO="repo␣--name=adaptation-community-common-$DEVICE-@RELEASE@" HA_DEV="repo␣--name=adaptation-community-$DEVICE-@RELEASE@" KS="Jolla-@RELEASE@-$DEVICE-@[email protected]" sed \ "/$HA_REPO/i$HA_DEV␣--baseurl=file:\/\/$ANDROID_ROOT\/droid-local-repo\/$DEVICE" \ $ANDROID_ROOT/hybris/droid-configs/installroot/usr/ share/kickstarts/$KS \ > $KS Systemet paketeras till en systemavbild.
Listing 4.20: Paketering av system PLATFORM_SDK $ 18 KAPITEL 4. GENOMFÖRANDE
RELEASE=3.0.2.8 hybris/droid-configs/droid-configs-device/helpers/process_patterns.sh sudo zypper in lvm2 atruncate pigz sudo ssu ar unbreakmic http://repo.merproject.org/obs/home:/sledge:/branches:/mer -tools:/devel/latest_i486/ sudo zypper ref unbreakmic sudo zypper rm droid-tools \# it’s ok if you hadn’t any sudo zypper in android-tools cd $ANDROID_ROOT sudo mic create loop --arch=$PORT_ARCH \ --tokenmap=ARCH:$PORT_ARCH,RELEASE:$RELEASE,EXTRA_NAME:$EXTRA_NAME \ --record-pkgs=name,url --outdir=sfe-$DEVICE-$RELEASE$EXTRA_NAME \ $KS Hela processen tar i ungefärlig tid upp till åtta timmar från grunden men kan kortas ner till två timmar efter första nerladdningen och fullständiga kompileringen av systemet.
Fastboot och udev Udev måste ges en regel för hur enheten som ska flashas ska hanteras. Detta så den kan hittas och användas av fastboot. Först hittas enhetens id. Detta görs genom att exekvera lsusb först utan enheten inkopplad i datorn och sedan med enheten inkopplad för att sedan jämföra utskrifterna. Detta kan se ut som följer: Listing 4.21: Exempel på lsusb utskrift utan enheten inkopplad. Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ...
Listing 4.22: Exempel på lsubs utskrift med enheten inkopplad. Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ... Bus 005 Device 004: ID 0fce:0dde Sony Ericsson Mobile Communications AB Xperia Mini Pro Bootloader ... IDt är i detta fall 0fce:0dde. Med IDt känt skapas en udevregel. Listing 4.23: Udevregel SUBSYSTEM=="usb", ATTR{idVendor}==0fce, MODE="0666", GROUP="plugdev" Udevregeln sparas till filen 51-android.rules i mappen /etc/udev/rules.d/. Listing 4.24: Kommando för att spara udevregel till fil. sudo echo ’SUBSYSTEM=="usb", ATTR{idVendor}==0fce, MODE ="0666", GROUP="plugdev"’ >> /etc/udev/rules.d/51-android.rules Användaren ges de korrekta rättigheterna över filen och udev startas om. Listing 4.25: Ändra accessrättigheter och starta om servicen sudo chmod a+r /etc/udev/rules.d/51-android.rules sudo service restart udev
Flashning ev enheten Metoden kräver att enheten har uppdaterats till Sonys senaste officiella Android-release för enheten vid något tillfälle innan den flashas. Listing 4.26: Förberedelser inför flashning PLATFORM_SDK $
RELEASE=3.0.2.8 cd $ANDROID_ROOT mkdir flashing cd flashing unzip $ANDROID_ROOT/sfe-$DEVICE-$RELEASE/SailfishOS-*. zip cd SailfishOS-*/ 4.3. PROTOTYP 2 - FUNGERANDE ANBOXKOMPATIBEL KERNEL 19
SW\_binaries\_for\_Xperia\_AOSP\_M\_MR1\_3.10\_v13\_loire.zip laddas ner från https: //developer.sonymobile.com/downloads/software-binaries/software-binaries-for-aosp- marshmallow-android-6-0-1-kernel-3-10-loire/ och placeras i flashing. Från mappen flashing packas filen upp och enheten flashas. Enheten kopplas in i datorn medan volym-upp trycks ner för att initiera fastboot-läge.
Listing 4.27: Flashning BLOBS=$(ls -1 *_loire.zip | tail -n1) unzip $BLOBS bash ./flash.sh När flashningen är klar kan enheten kopplas bort från datorn och startas om. Utvecklarversionen av SailfishOS version 3.0.2.8 är nu flashat och klar att användas.
4.3 Prototyp 2 - Fungerande anboxkompatibel kernel
Prototyp 2 färdigställdes aldrig på grund av problem under processen.
Anbox kräver två egna kernel moduler som även finns som patchar och att AppArmor är aktiverat i kerneln. Efter försök att kompilera in modulsupport i kerneln för SailfishOS valdes kernelpatcharna framför modulerna.
Kernelpatch Kerneln patchas med patchar för Anbox hittade på projektets sida på Github[20]. Patcharna appliceras på kerneln med verktyget patch och kompletteras med några manuella justeringar av koden som inte inkluderats i patcharna. Patcharna återfinns inte i huvudgrenen av kodträdet så vilken gren och version av koden man tittar på måste justeras för att få åtkomst till patcharna.
Listing 4.28: Nerladdning av patchar cd ~/downloads git clone https://github.com/anbox/anbox.git cd anbox git checkout 0f80db1
Listing 4.29: Patchande av kernelkoden cd $ANDROID_ROOT/kernel/sony/msm/ patch -p1 < ~/downloads/anbox/kernel/patches/0001-ipc- namespace-a-generic-per-ipc -pointer-and-peripc_o.patch patch -p1 < ~/downloads/anbox/kernel/patches/0002-binder-implement-namepsace- support-for-Android-binde.patch Andra patchen misslyckas med två kodingrepp. Dessa läggs till manuellt i filen, drivers/android/binder.c, genom att jämföra koden och de delar av patchen som misslyckades och lägga in kodstyckena där det är logiskt. Även ett annat kodstycke som inte är del av patchen behöver ändras då referenser till gammal kod är kvar vilket hindrar kerneln från att bli byggd.
Listing 4.30: Patchad driver/android/binder.c rad 3783 static int binder_proc_show(struct seq_file *m, void *unused ) { struct binder_proc *itr; struct binder_proc *proc = m->private; int do_lock = !binder_debug_no_lock; bool valid_proc = false; struct binder_namespace *binder_ns = current_binder_ns();
if (binder_ns == NULL) return 0
if (do_lock) binder_lock(__func__); hlist_for_each_entry(itr, &binder_ns->procs, proc_node ) { if (itr == proc) { valid_proc = true; 20 KAPITEL 4. GENOMFÖRANDE
break ; } } if (valid_proc) { seq_puts(m, "binder␣proc␣state:\n"); print_binder_proc(m, proc, 1); } if (do_lock) binder_unlock(__func__); return 0; }
Problem med Repo Hittills har en omsynkronisering av kodträdet eller en ominitiering och sedan synkronisering med Repo varit allt som krävts för att systemet skulle kompilera utan problem. Dock inte denna gång. Listing 4.31: Kompileringsfel vid kernelkompilering system/core/init/property_service.cpp:351:10: error: use of undeclared identifier ’PROP_MSG_GETPROP’ case PROP_MSG_GETPROP: ^ system/core/init/property_service.cpp:371:10: error: use of undeclared identifier ’PROP_MSG_LISTPROP’ case PROP_MSG_LISTPROP: ^ 2 errors generated. make: *** [out/target/product/suzu/obj/EXECUTABLES/init_intermediates/ property_service.o] Error 1
#### make failed to build some targets (30 seconds) #### För att lösa problemet provades att omsynkronisera, reinitiera och omsynkronisera och sist att radera och ladda ner kodbasen på nytt. Inget av detta löste problemet. Efter en del grävande i koden med vim och kommandot grep -rnw
rm -rf build/ .repo/projects/build.git .repo/project-objects/platform/build.git repo sync build --force-sync 4.3. PROTOTYP 2 - FUNGERANDE ANBOXKOMPATIBEL KERNEL 21
Platserna och namnen för alla kodträd hittas i tagged-manifest.xml1. Enkeltrådad synkronisering av kodträdet görs efter varje åtgärdat fel tills alla fel är åtgärdade.
Kernelkonfiguration De första konfigurationerna gjordes genom att kopiera konfigurationsfilen arch/arm64/config/aosp_loire_suzu_defconfig till filen .config i rooten till kernelkoden. Starta menuconfig genom att exekvera make menuconfig, ladda in .config i menuconfig, mo- difiera konfigurationen för att sedan spara konfigurationen ner till fil igen. Därefter kopieras filen tillbaks till sin mapp där originalet döpts om och make mrpropper exekveras i kernelrooten för att undvika kompileringsfel vid kompilering av hybris hal. Denna metod byttes ut. Den nya metoden modifierar konfigurationsfilen direkt med en editor och lägger till de inställ- ningar som krävs. En konfigurationsfil hittades på internet som enligt sitt namn använts i ett tidigare försök att få Anbox att fungera. Denna version fick kompileringsfel där kompilatorn sa sig ej kunna jämföra en undigned int med en annan undigned int. Felet visade sig vara svårt att felsöka och kan bero på inkompatibilitet med kompilatorversionen. Denna konfigurationsfil övergavs. En konfigurationsfil med minimala modifikationer från originalfilen skapades. Denna fil inklu- derar AppArmor då Anbox har AppArmor som beroende och inget annat. AppArmor aktiveras genom att lägga till tre rader i konfigurationsfilen.
Listing 4.34: Inställningar för aktivering av AppArmor # AppArmor CONFIG_SECURITY_APPARMOR=y CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1 CONFIG_DEFAULT_SECURITY="apparmor" Denna konfiguration kompilerade utan fel och ett fullständigt OS kunde byggas. Efter flashning av den nya versionen lyckas enheten inte starta.
Epilog Då enheten inte startar med Prototyp 2 reverterades kodbasen tillbaks till Prototyp 1 och en ny Prototyp 1 kompileras. Denna version startar inte heller på enheten trots att den fungerat tidi- gare. repo sync --force_sync --fetch-submodules exekveras och en ny Prototyp 1 påbörjas kompileras. Ett fel uppträder nu under en ny del av byggprocessen.
1https://github.com/mer-hybris/android 22 KAPITEL 4. GENOMFÖRANDE Kapitel 5 Avslut
5.1 Resultat
Efter projektets slutförande har Anbox inte fåtts att köra på SailfishOS på Xperia X. SailfishOS utvecklingsplattform kom i vägen för faktiskt testande av Anbox. Baserat på detta är det svårt att avgöra huruvida Anbox skulle vara ett bra alternativ till nuvarande lösning på SailfishOS. Vad som blivit tydligt är dock att SailfishOS inte är en plattform som gör det lätt för utvecklare att använda. Det som varit problemet som förhindrat större framsteg inom projektet har varit oberäkneligt beteende från verktyget Repo. Då metoden förutsätter att det finns ett sätt att gå tillbaks till ett rent kodträd görs detta omöjligt när detta inte lyckas. Anbox anses därför inte vara ett bra alternativ till SailfishOS i dess nuvarande skick då tiden det kommer ta att portera över programmet med stor sannolikhet kommer ta nära på lika lång tid som att programmera en dedikerad lösning till SailfishOS men ge sämre integration med plattformen.
5.2 Diskussion
Metoden för projektet fungerade inte i realiteten då det centrala grundantagandet för programme- ring och empiriska studier, det vill säga att om du gör samma sak med samma förhållanden och förutsättningar så ska du få samma resultat, helt enkelt inte fungerade. Repo, programmet som användes för nerladdning och versionshantering av kod hade problem med att gå tillbaks till tidigare versioner av kodbasen. Det hade även en förmåga att korrumpera kodbasen vilket gjorde så ytterligare tid spilldes på att bara få saker att än en gång kunna kom- pilera. Detta gjorde så eventuella fel som dök upp under projektets gång inte alltid kunde avgöras om det var Repos fel eller om det var konfigurationens fel. Repo har en checkout-funktion men i detta projekt gav den endast ett felmeddelande vilket gjorde att ominitiering av projektet och omsynkning med flaggan --force-sync användes i stället, med varierande framgång. Innan en fungerande lösning hittades på första kompileringsfelet, och det klargjorda felet i kodbasen, gjordes några försök att radera hela källkoden och ladda ner den på nytt. Detta lyckades Repo korrumpera vilket gjorde så felen från den tidigare kodbasen var kvar. Hur den lyckades med detta är okänt. Ett alternativ till Repo skulle kunna vara att flytta över den rena kodbasen till ett eget git-träd, där varje version av prototypen får en egen gren. På så sätt kan man vara säker på att de olika versionerna är vad de bör vara. Detta användes inte och tänktes inte på under projektets gång eftersom Repo är ett lager ovanpå Git och borde då enligt en naiv person fungera lika bra. Nu i efterhand låter det självklart. Baserat på detta kan konstateras att resultatet inte visar hur lätt eller svårt det skulle vara för någon som är väldigt familjär med plattformen att portera Anbox eller Anbox faktiska kompatibi- litet med plattformen.
Plattformen Att SailfishOS är byggt ovanpå Androidkerneln skapar problem. Inte minst i det att man behöver använda AOSP egna verktyg för att modifiera och utveckla plattformen. Att de valt att göra på
23 24 KAPITEL 5. AVSLUT detta sätt är inte konstigt eftersom majoriteten av dagens mobiltillverkare endast släpper enhets- drivare till androidkernelns Hardware Adaption Layer (HAL). Detta gör det omöjligt att använda något annat än androidkerneln om du vill att ditt operativsystem ska kunna köra på enheten. Dock är det fortfarande plattformens största hinder då det introducerar konstiga lösningar och stora mängder arbete för att modifiera eller förbättra plattformen. Detta är tyvärr inte ett problem Jolla kan lösa då ODMerna1 i China och chiptillverkaren som gör hårdvaran som används i enheterna i många fall inte är intresserade att lägga in sin drivare i linuxkerneln. Att plattformen även är beroende av ett projekt ägt av Google är inte ett problem nu men kan bli det i framtiden då eventuella ändringar Google gör för att underlätta för Android kommer tvinga Jolla och SailfishOS behöver anpassa sig. Ett projekt som i nuläget har en teoretiskt perfekt plattform är Purism projekt Librem 5 vilket är en smartphone som ska köra deras egna version av Debian Linux direkt på hårdvaran. Hur detta kommer gå i praktiken återstår att se[21].
Summering Att virtualisera Android på en ren alternativ Linux plattform är en lösning som är teoretiskt bra. SailfishOS har redan en liknande lösning. Men för att få en sådan lösning att fungera kommer det krävas mycket tid och då arbetet i nuläget endast görs av studenter och hobbyister kommer vi troligen inte få se en ordentlig lösning förän ett företag ställer sig bakom utvecklingen.
5.3 Sammanfattning
Efter avslutat projekt har inte Anbox fåtts att köra på SailfishOS. Baserat på utvecklingshastighe- ten från detta försök ses detta inte som en realistisk lösning. Problemen ligger vid hur plattformen valt att implementera utvecklingsmiljön där Repo är en av det största problemet.
5.4 Framtida arbete
Portning av Anbox kommer försökas mot plattformen Librem 5 i framtiden om det fås tag på en enhet, finns tid och ingen annan hinner före.
1Original Device Manufacturer Referenser
[1] L. Sui, Strategy Analytics: Android Captures Record 88 Percent Share of Global Smartp- hone Shipments in Q3 2016, en, nov. 2016. URL: https : / / www . strategyanalytics . com / strategy - analytics / news / strategy - analytics - press - releases / strategy - analytics - press - release / 2016 / 11 / 02 / strategy - analytics - android - captures - record-88-percent-share-of-global-smartphone-shipments-in-q3-2016 (hämtad 2019-05-27). [2] B. Ekblom, Prylar är politik – och oskyldiga drabbas när supermakterna ryker ihop, sv, maj 2019. URL: https : / / pcforalla . idg . se / 2 . 1054 / 1 . 719194 / huawei - usa - google - supermakterna-ryker-ihop (hämtad 2019-05-27). [3] E. MacAskill, G. Dance, F. Cage, G. Chen och N. Popovich, NSA files decoded: Edward Snow- den’s surveillance revelations explained, en, nov. 2013. URL: http://www.theguardian.com/ world/interactive/2013/nov/01/snowden- nsa- files- surveillance- revelations- decoded (hämtad 2019-05-27). [4] C. Cadwalladr, ”Cambridge Analytica a year on: ‘a lesson in institutional failure’”, en-GB, The Guardian, mars 2019, issn: 0261-3077. URL: https://www.theguardian.com/uk-news/ 2019/mar/17/cambridge- analytica- year- on- lesson- in- institutional- failure- christopher-wylie (hämtad 2019-05-27). [5] ”Amazon Workers Are Listening to What You Tell Alexa”, en, april 2019. URL: https: //www.bloomberg.com/news/articles/2019-04-10/is-anyone-listening-to-you-on- alexa-a-global-team-reviews-audio (hämtad 2019-05-27). [6] Security space, Web Server Survey - SecuritySpace, maj 2019. URL: https://secure1. securityspace.com/s_survey/data/201904/index.html (hämtad 2019-05-27). [7] Myriad Group, Myriad Alien Dalvik, nov. 2013. URL: https://web.archive.org/web/ 20131113193859 / http : / / www . myriadgroup . com / Myriad / Device - Manufacturers / Android-solutions/~/media/D42B513FB5114FF2B4CA13A2D8CE313E.ashx (hämtad 2019-06-16). [8] Hardware Adaptation Development Kit, en-US. URL: https://sailfishos.org/develop/ hadk/ (hämtad 2019-03-05). [9] Sailfish X Build and Flash - SailfishOS Documentation. URL: https://sailfishos.org/ wiki/Sailfish_X_Build_and_Flash (hämtad 2019-05-27). [10] Kernel modules — The Linux Kernel documentation. URL: https://linux-kernel-labs. github.io/master/labs/kernel_modules.html (hämtad 2019-05-27). [11] QEMU version 3.1.50 User Documentation. URL: https://qemu.weilnetz.de/doc/qemu- doc.html#Introduction (hämtad 2019-06-16). [12] Snap confinement - Snap documentation. URL: https : / / docs . snapcraft . io / snap - confinement (hämtad 2019-06-16). [13] AppArmor / apparmor, en. URL: https : / / gitlab . com / apparmor / apparmor (hämtad 2019-06-16). [14] Anbox is a container-based approach to boot a full Android system on a regular GNU/Li- nux system : anbox/anbox, original-date: 2017-02-22T05:59:40Z, mars 2019. URL: https: //github.com/anbox/anbox (hämtad 2019-03-05). [15] Architecture - SailfishOS Documentation. URL: https://sailfishos.org/wiki/Architecture (hämtad 2019-05-27).
25 26 REFERENSER
[16] A. Ltd, Architecting a Smarter World – Arm, en. URL: https://www.arm.com/ (hämtad 2019-06-16). [17] DeviceTree, en. URL: https://www.devicetree.org/ (hämtad 2019-06-16). [18] Power_ePAPR_APPROVED_v1.1.pdf. URL: https://elinux.org/images/c/cf/Power_ ePAPR_APPROVED_v1.1.pdf (hämtad 2019-05-27). [19] Downloading the Source, en. URL: https://source.android.com/setup/build/downloading (hämtad 2019-05-23). [20] Anbox is a container-based approach to boot a full Android system on a regular GNU/Li- nux system : anbox/anbox, original-date: 2017-02-22T05:59:40Z, juni 2019. URL: https : //github.com/anbox/anbox (hämtad 2019-06-16). [21] Librem 5, en-US. URL: https://puri.sm/products/librem-5/ (hämtad 2019-03-05). TRITA TRITA-EECS-EX-2019:167
www.kth.se