Communitygetriebene Android Systemerweiterungen

Marc SeegerComputer Science and Media

Hochschule der Medien Stuttgarte-mail: mail@marc-seeger.de

17. Januar 2010

1. Einleitung

Die Android Plattform hat seit der Veroffentlichungder ersten auf Android basierten Gerate eine großeEntwicklercommunity um sich gebildet. DieseCommunity erstellt nicht nur eine Fulle anAnwendungen, sondern erweitert auch die Plattformund das darunter liegende Betriebssystem selbst.Die Quelloffenheit der Plattform ermoglicht esEntwicklern mit tiefgreifenden Anderungen zuexperimentieren und diese einer breitenOffentlichkeit zur Verfugung zu stellen. Durch denLinux Kern der Android Plattform wird es auchEntwicklern ohne Erfahrungen imEmbedded-System Umfeld ermoglicht, eineneinfachen Einstieg in die Systementwicklung furMobiltelefone zu finden.Die Systemerweiterungen ermoglichenrisikobereiten Endnutzern das Hinzufugen vonFeatures, welche im Auslieferungszustand desMobilgerates nicht vorgesehen sind. Diese Featureserstrecken sich von der Unterstutzung neuerAudioformate bis zur Erhohung des CPU Takts. Dievon den Entwicklern bereitgestellten Modifikationenlassen sich mit unterschiedlichem Aufwand auf dieEndgerate einspielen. Android ermoglicht somit alserste Mobilplattform eine Grundlegende Anderungdes vom Hersteller vorgegebenen Betriebssystems.Eine interessante Fragestellung in diesem Bereichsind auch die rechtlichen Hintergrunde bei derVerbreitung und Nutzung der Modifikationen.Dieses Paper erlautert zuerst die Voraussetzungenfur die Modifikationen. Danach folgt eine Definitionder unterschiedlichen Bereiche in welche dieModifikationen gegliedert werden konnen. JederBereich wird hierbei durch entsprechende Beispieleverdeutlicht. Schlussendlich wird dielizenzrechtliche Situation zur Verbreitung derModifikationen betrachtet.

2. Installation der ModifikationenDas Verandern und Hinzufugen vonSystembestandteilen erfordert sowohl unter Linuxim Desktop-Umfeld, als auch auf der AndroidPlattform entsprechende Privilegien. DiesePrivilegien lassen sich unter Android auf zwei Artenerreichen. Entweder man hat die MoglichkeitProgramme mit Rechten des root-Benutzers zustarten um im laufenden System Modifikationenvornehmen zu konnen, oder man besitzt Zugriff aufden Boot-Prozess und kann somit direkt einentsprechend erweitertes Betriebssystemeinspielen.Im Normalfall unterliegt der Boot-Prozess demHardware-Hersteller und der Zugriff wird durchdiesen entsprechend eingeschrankt. DaAndroid-Endgerate jedoch wahrend ihrer Lebenszeiteinige offizielle Softwareupdates erfahren, besteht inallen Fallen zumindest die Moglichkeitentsprechend kryptografisch signierte Updateseinzuspielen.Am Beispiel des HTC Dream konnen die typischenSicherheitsvorkehrungen von AndroidMobiltelefonen gut beobachtet werden. Dies erlaubtauch die Erlauterung der Schritte, welche von derEntwicklercommunity unternommen wurden, umdiese Vorkehrungen auszuhebeln.

2.1. Root-ZugriffDer Root-Zugriff auf dem Mobiltelefon hat die selbeBedeutung wie auf auf Desktop Rechnern. Erermoglicht die Ausfuhrung von Programmen alsprivilegierter Systemuser. Diese Privilegien erlaubenunter anderem den unbeschrankten Zugriff aufHardware und Dateisystem des Systems.Um die in diesem Paper vorgestellten Erweiterungennutzen zu konnen, ist es großtenteils notwendigZugriff auf diese Systembereiche zu haben. Es

1

existieren heutzutage viele Android Distributionender Community, welche einen Root-Zugriff vonHaus aus bereitstellen. Es ist jedoch nicht moglichdiese auf einem Telefon im Auslieferungszustandeinfach einzuspielen. Die Recovery Partition welchefur den Flashprozess zustandig ist, uberpruft diekryptografische Signatur des zu flashenden Images.Das System weigert sich daher eine Dateieinzuspielen welche nicht von Googlebeziehungsweise dem Netzbetreiber kryptografischsigniert wurde.Glucklicherweise ist es moglich die RecoveryPartition aus dem laufenden System heraus zuersetzen, falls es dem Benutzer gelingt Root-Rechtezu erlangen. Der erste Angriffspunkt ist also daserreichen von Root-Rechten um dadurch entwederdirekt Erweiterungen einzuspielen oder dieRecovery Partition zu ersetzen um ein Flashen mitunsignierten Images zu ermoglichen.Der zweite Angriffspunkt ist der Bootloader desGerates. Der sogenannte ”Engineering Bootloader”,welcher sich auf Entwicklergeraten befindet, erlaubtEntwicklern einen Systemzugriff via USB schonwahrend der Bootloader-Phase des Systemstarts.Mit dem Entwicklertool Fastboot lassen sich so inKombination mit dem Engineering Bootloaderbeliebige Partitionen mit unsignierten Images uberUSB flashen. In Endbenutzer-Geraten ist die USBKommunikation mit dem Bootloader deaktiviert.Gelingt es einem Benutzer im laufenden SystemRoot-Rechte zu erlangen, kann der aktuelleBootloader durch sein Engineering Pendant ersetztwerden und erlaubt somit beliebig erweiterteSystem-Images einzuspielen.Die nachsten 2 Abschnitte erlautern wie dieUmgehung der Signaturmechanismen in der Praxisumgesetzt wurde.

2.1.1 Die erste Losung

Als das HTC Dream als erstes Android-Endgerat aufden Markt kam, besaß die installierte AndroidVersion eine Schwachstelle welche unglaubwurdigernicht sein konnte. Das Gerat interpretierteTexteingaben in jedem beliebigen Teil des Systemsals Kommando. Besonders Kritisch wurde dieserFehler dadurch, dass jegliche Eingabe auch noch mitRoot-Rechten ausgefuhrt wurde.Der Grund fur dieses Verhalten lag in einerKombination vieler Konfigurationseinstellungen.Ein Teil davon ist die init.rc Datei, welche beimSystemstart ausgefuhrt wird und folgende Zeileenthalt:

service console /system/bin/sh

Da der init Prozess als Standard Input (stdin) das/dev/console Device gesetzt hat, wird nach diesemBefehl jegliche Eingabe an /dev/console mitRoot-Privilegien ausfuhrt.Dies ist im Normalfall ungefahrlich, da der Benutzerkeinen direkten Zugriff auf /dev/console besitzt. Zudieser Zeit wurde dem System beim booten jedochein ”console=”-Parameter ubergeben welcher/dev/console auf mehrere Devices lauschen lasst. ImNormalfall sollte /dev/console nur auf den seriellenPort lauschen um ein Debugging (z.B. durch denKundendienst) zu ermoglichen. Im Falle des G1lauschte /dev/console jedoch auch auf das virtuelleKonsolen Device ”tty0”. Die von Linux bekanntenvirtuellen Konsolen sind bei einem System wieAndroid eigentlich nicht notig, da der Benutzer nuruber eine grafische Oberflache (auf FramebufferBasis) mit seinem System interagiert und keineKonsolen als Eingabemoglichkeit benotigt. DerKernel des HTC Dream wurde jedoch mit gesetztem”CONFIG VT” Parameter kompiliert und botdeshalb Unterstutzung fur die virtuellen Konsolen.Alle diese einzelnen Probleme laufen zusammenwenn der Benutzer eine Taste auf derHardwaretastatur des Gerates druckt. DerTastaturtreiber leitet jeglichen Tastendruck aufvorhandene virtuelle Konsolen weiter. Dies bedeutetdass tty0 jegliche Eingabe erhalt. Von dort gelangt esdurch den gesetzten Boot Parameter an/dev/console, welches die eingehendenKommandos mit Root-Rechten ausfuhrt.Um von außen Root-Zugriff auf das Gerat zuerlangen genugt somit schon die Eingabe von”telnetd” und das drucken der Enter Taste. Dadurchwird der im System mitgelieferte Telnet Daemongestartet. Mit laufendem Telnet Daemon kann dannuber das Netzwerk auf das Gerat zugegriffen werden.Dieser Zugriff kann dazu benutzt werden denBootloader zu uberschrieben. Das fuhrt dazu, dassauch unsignierte Systemimages eingespielt werdenkonnen.Da signierte Images mit dieser unglucklichenKombination von Fehlern in Umlauf sind konnenBesitzer des G1 ein Downgrade durchfuhren falls dieSicherheitslucke in spateren Versionen geschlossenwird. In diesem Fall gibt es fur HTC und dieNetzbetreiber keine einfache Losung mehr dieseLucke zu schließen.

2

2.1.2 Die aktuelle Situation

Neuere Handsets als das G1 wurden mit Versionender Android Plattform ausgeliefert auf denen dieserFehler behoben wurde. Da fur diese Telefone keinekompatiblen ”fehlerhaften” Images im Umlauf sind,muss der Root-Zugriff auf eine andere Art hergestelltwerden.Das Tool ”FlashRec”[1] nutzt dazu mehrere Exploitsim Linux Kernel. Durch diese Exploits gelingt eseinen Flashvorgang des Recovery Images mit denerforderlichen Root-Privilegien zu starten.Fur Firmware-Images welche vor August 2009veroffentlicht wurden wird von FlashRec eineSicherheitslucke genutzt welche unter dem NamenADV-2009-2272 in der National VulnerabilityDatabase veroffentlicht[2] wurde. Dieser Exploitnutzt eine Schwachstelle des Kernels bei SocketOperationen um beliebigen Code mitRoot-Privilegien ausfuhren zu konnen. Diegenaueren Interna des Exploits wurden den Umfangdes Papers sprengen, konnen jedoch auf der Seiteder National Vulnerability Database nachgelesenwerden. Das Realisieren des Exploits uber SocketVerbindungen wird auch beim Installieren des Toolserkennbar. Der Benutzer muss dem Tool Zugriff aufdas Bluetooth Subsystem genehmigen. Uber dasBluetooth Subsystem kann vom Programm derSocket erstellt werden welcher den Exploitermoglicht.Fur Firmware-Images die zwischen August 2009 undNovember 2009 veroffentlicht wurden benutzt dasTool die Kernel Sicherheitslucke CVE-2009-3547[3].Diese Lucke erlaubt Angreifern durchrace-conditions im pipe Systemcall die Ausfuhrungvon beliebigem Code mit Root-Privilegien. Inunserem Fall leitet der Code das Flashen desRecovery Images ein.

3. Gruppierung derModifikationen

Die von unabhangigen Entwicklern in die AndroidPlattform integrierten Erweiterungen wurden lassensich grob in drei Bereiche gliedern:• Kernel• System• Applikationen

Der Kernelbereich befasst sich mit Erweiterungendie aus der offiziellen Linux Kernelentwicklungstammen. Zum Zeitpunkt ihrer Veroffentlichungsind diese Erweiterungen im Normalfall jedoch aufkeinem offiziellen Android Endgerat im Einsatz.

Hier ware als Beispiel die Integration des ”BrainfuckScheduler” in den Android Kernel zu nennen.Der Systembereich besteht aus Erweiterungenbestehender Systemkomponenten z.B. durchPlugins zur Wiedergabe von bisher nichtunterstutzten Medienformaten oder derImplementation von Funktionalitat welche dieaktuelle Hardware zwar bieten konnte, jedoch in deroffiziellen Entwicklungsversion von Android sonicht zur Verfugung steht. Ein Beispiel ware dieImplementation des Bluetooth Object ExchangeProtokolls (OBEX) welches den Dateitransferzwischen Endgeraten uber Bluetooth ermoglicht.Der Applikationsbereich konzentriert sich auf dieErweiterung vorhandener Applikationen oder diePortierung von Applikationen neuerer Endgerate aufaltere Android-Versionen. Hier ware z.B. dieIntegration von Multitouch in den AndroidWebbrowser zu nennen.Im Folgenden werden die einzelnen Bereiche uberBeispielprojekte verdeutlicht.

4. Erweiterungen auf Kernel EbeneDie Erweiterungen auf der Kernel Ebene dienen zumGroßteil der Erhohung der Performanz desGesamtsystems. Einige von ihnen legen jedochgleichzeitig auch den Grundstein fur andereModifikationen im System- oderAnwendungsbereich.

4.1. BFS - Der ”Brainfuck Scheduler”In heutigen Betriebssystemen kampfen zu jedemZeitpunkt mehrere Prozesse darum, ihrenProgrammcode auf dem Prozessor ausfuhren zudurfen. Die grundlegende Instanz desBetriebssystems, welche sich mit dieserRessourceneinteilung beschaftigt wird ”Scheduler”genannt. Insbesondere bei den begrenztenRessourcen von Mobilgeraten muss er fur eineBalance aus Hintergrundprozessen (z.B. dieAktualisierung der Location-Daten uber GoogleLatitude) und einem flussigen Ablauf derBenutzeroberflache sorgen.Ursprunglich konnte man im Android Quellcode,wie auch im regularen Linux Kernel den CompletelyFair Scheduler (kurz: CFS) in der Datei sched fair.cvorfinden. Dieser Scheduler ist im Gegensatz zuseinen Vorgangern (z.B. dem O(1)-Scheduler)weitgehend frei von komplexen Heuristiken undStatistiken. Es findet keine Priorisierung von

3

einzelnen Tasks statt, stattdessen werden alleProzesse gleich behandelt. Der Prozess welcherschon am langsten auf CPU Zeit warten musste wirdals nachster aktiviert. Erganzend muss nochangemerkt werden, dass es in neueren KernelVersionen die Moglichkeit gibt Prozesse zu ”TaskGroups” zu bundeln. Die Auswahl erfolgt dannprimar auf Gruppenebene um zu verhindern dasseinzelne Benutzer uber eine große Anzahl anProzessen das gesamte System blockieren.Mitte 2009 entwickelte Con Kolivas jedoch eineAlternative zum CFS Scheduler da dieser, in seinenAugen, fur interaktionsbasierteEndanwendersysteme ungeeignet sei. Ein Zitat ausseiner BFS-FAQ[4] zum ”hakeligen” Verhalten desCFS auf seiner neuen Hardware lautete wie folgt:

It’s not a profound effect in CFS and that’sadmirable. It just doesn’t behave the way Ifeel the scheduler should being forwardlooking only (not calculating sleep) and itdoesn’t really make the most of a relativelylightly loaded machine without many manycpus. So I threw it all out and wrote exactlythe opposite.

Um die Gegenlaufigkeit zur aktuellen Schedulern zuverdeutlichen nannte er seine Kreation BFS, den”Brainfuck Scheduler” und veroffentlichte diebereits erwahnte FAQ Datei[4], welche seineMotivation und die Grundidee verdeutlichte.Er charakterisierte das Verhalten des Schedulersdarin mit folgenden Worten:

It was designed to be forward looking only,make the most of lower spec machines, andnot scale to massive hardware. ie [sic] it is adesktop orientated scheduler, withextremely low latencies for excellentinteractivity by design [...]

Durch die Optimierung auf Interaktion undleistungsschwache Systeme ergibt sich eineinteressante Einsatzmoglichkeit in Mobiltelefonen.Dies erkannte auch Steve Kondik, der Communitybesser als ”Cyanogen” bekannt. Er ist Autor der wohlbeliebtesten Android-Distribution ”Cyanogenmod”.Er war auch der Erste der BFS auf Android portierteund ein lauffahiges Image veroffentlichte, welchesdie Endnutzer mit recht wenig Aufwand auf ihreTelefone einspielen konnten. Das Userfeedbackattestierte dem neuen Scheduler eine subjektivflussigere Bedienbarkeit des Gesamtsystems.Genauere Details des Schedulers wurden denRahmen des Papers sprengen, konnen jedoch bei

Bedarf in Con Kolivas Dokument zum BFS Design[5]nachgelesen werden.Ob es in direktem Zusammenhang steht ist nichtbekannt, jedoch gab es einige Wochen spater einencommit[6] welcher BFS dem offiziellen AndroidSourcecode hinzufugte.

4.2. Das Compcache ModulEines der großten Probleme im taglichen Einsatzvon mobilen Endgeraten ist der begrenzteArbeitsspeicher. Besonders in Systemen (wie z.B.Android) in denen der Endnutzer mehrereProgramme parallel laufen lassen kann wirdArbeitsspeicher schnell zur knappen Ressource.Die normale Herangehensweise auf DesktopSystemen ist, Teile der Festplatte quasi als”Uberlauf” zu nutzen und aktuell nicht genutzteProgrammteile vom RAM auf die Festplatte zuverschieben. Mobile Endgerate besitzen jedochFlashspeicher der in der Anzahl vonSchreibzugriffen begrenzt ist und uber die Zeitdegradiert. Neben diesem ”wear-leveling” Problemverlangsamt eine Auslagerung auf den langsamerenFlashspeicher das gesamte System und solltevermieden werden.Hier ist der Einsatzort des Compcache Moduls[10].Anstatt den ”Uberlauf” des Arbeitsspeichers auf dieFestplatte bzw. den Flashspeicher zu verlagern,nimmt das Modul einen Teil des Arbeitsspeichersdafur. Dieser Teil wird als Blockdevice mit demNamen ”ramzswap” zur Verfugung gestellt. DerVorteil dabei ist, dass die Daten welche auf dasBlockdevice geschrieben werden, transparentkomprimiert werden. Dies vergroßert die Menge anDaten die (gleichzeitig) im schnellen RAM gehaltenwerden konnen und ist zugleich bei Weitemschneller als der Zugriff auf einen entsprechendeninternen Flashspeicher des Mobilgerates.Die Community selber ist sich jedoch nochunschlussig ob der zusatzliche Arbeitsspeicher dasGesamtsystem wirklich beschleunigt oder ob derzusatzliche Overhead sich negativ auf dieGesamtperformance fur ein normalesBenutzungsschema auswirkt.

4.3. Erhohung des CPU TaktesDas Ubertakten von Computern ist in der PCCommunity seit Jahren schon ein beliebtes Mittelum gekaufter Hardware mehr Leistung zu entlocken.Die Geschwindigkeit einer CPU wird durch zweiMerkmale bestimmt:

4

• den Bustakt• den Multiplikator

Multipliziert man diese 2 Angaben erhalt man dieNenngeschwindigkeit des Prozessors(z.B. 12 * 133.33MHz = 1600 MHz).Wahrend in normalen Heimcomputern dieProzessoren immer mit der vom Prozessorherstellervorgegebenen maximalen Geschwindigkeit getaktetwerden, sieht die Situation fur Mobilgerate andersaus. Um potentielle Uberhitzung oder zu großenStromverbrauch zu vermeiden werden Prozessorenkunstlich gedrosselt.Ein Beispiel dafur ist das HTC Dream, auch bekanntals ”Google Dev Phone 1” oder ”T-Mobile G1”. Esbesitzt einen 528 MHz Qualcomm MSM7201AARM11 Prozessor, welcher jedoch imAuslieferungszustand des Gerates auf 384 MHzbegrenzt ist.Die Begrenzung ist jedoch rein softwareseitig undkann, entsprechende root-Rechte vorausgesetzt,aufgehoben werden.Programme wie setcpu[7] erlauben die Auswahl desCPU Governor und die Anpassung der minimalenund maximalen Frequenzen.Durch die erhohte Leistung entsteht auch einerhohter Stromverbrauch, jedoch nur zu denZeitpunkten in denen die CPU wirklich rechnenmuss. Bei normaler Interaktion mit dem Gerat wirdsomit zwar mehr Strom verbraucht, jedoch nur uberkurzere Intervalle. Somit kann das Gerat flussigerbedient werden. Insbesondere Spiele, die imNormalfall eine andauernde Auslastung der CPUgarantieren werden dem ubertakteten System wohlmehr Energie entlocken als einem AquivalentenSystem mit Begrenzung des CPU Takts.

5. Erweiterungen auf SystemEbene

Die Erweiterungen auf Systemebene verschaffendem Enduser neue Features welcheUnzulanglichkeiten der vom Hersteller zurVerfugung gestellten Firmware beheben sollen.

5.1. Integration des OBEX ProtokollsDie Integration des OBEX Protokolls[11] istBeispielhaft fur eine Erweiterung, bei der dieHardware des Endgerates entsprechendeMoglichkeiten bietet, jedoch von Softwareseite eineEinschrankung herrscht. Im Falle von OBEX war dieHardware das im HTC Dream verbaute Bluetooth

Modul. Im Bluetooth Standard sind neben denGrundlegenden Eigenschaften wie z.B. Frequenzenund Sicherheitsmodelle auch sogenannte ”Profile”festgelegt. Diese Profile stehen fur eineentsprechend standardisierte Funktionalitat wie z.B.das Hands-Free Profile (kurz: HFP), welches jeglicheDetails bei der Kommunikation mitAuto-Freisprechanlagen festlegt.Fur den Endanwender ist das OBject EXchangeProtokoll (kurz OBEX) interessant. Es dient alsGrundlage fur viele andere Profile wie z.B. ObjectPush Profile oder Generic Object Exchange Profile.Diese Profile ermoglichen es z.B. Visitenkartenelektronisch zwischen Endgeraten zu ubertragenoder Fotos an ein anderes Bluetooth-Gerat (z.B. deneigenen Laptop) zu senden.Das HTC Dream konnte im Auslieferungszustandzwar Bluetooth-Freisprecheinrichtung benutzen,jedoch existierte keinerlei Unterstutzung fur dasOBEX Protokoll um Dateitransfers uber Bluetoothabzuwickeln.Dies ist insbesondere deswegen verwunderlich, weilbereits einige Open-Source Implementationen desOBEX Protokolls fur Linux existieren. DieseImplementationen bildeten die Grundlage fur einigeerfolgreiche Kommandozeilen Experimente. Diefunktionierenden Tools stehen unter dem Namen”android-obex”[8] als Sourcecode zur Verfugung.Eine entsprechende grafischeEndbenutzer-Applikation stand kurze Zeit spater imAndroid Market zur Verfugung. Die einzigeEinschrankung zur Nutzung dieser Applikationenist, dass man Root-Zugriff auf sein Gerat benotigtum die entsprechenden Kommandos an dasBluetooth Subsystem abgeben zu konnen.Als Beispiel fur eine der ersten grafischeApplikationen welche Dateitransfers uber OBEXvornehmen konnten sei ”Bluex” genannt. Der Preisder Applikation fallt mit 2 USD recht gering aus.

5.2. Unterstutzung von FLACEine weitere Systemerweiterung die sich großerBeliebtheit erfreut ist die Unterstutzung des FLACFormats fur das Multimedia-Subsystem.FLAC ist der de-facto Standard fur verlustfreikomprimierte digitale Audiodateien. Es ist einoffenes Format und findet als Archivformat beiaudiophilen Menschen großen Anklang. Es eignetsich auf Grund seiner geringen CPU Anforderungenbeim Decodieren fur vergleichsweise langsameCPUs wie sie in Smartphones und anderen mobilenSystemen vorkommen.

5

Das Schone an dieser Erweiterung ist, dass sie aufdas OpenCORE Media Framework aufsetzt. DiesesFramework bildet die Grundlage fur die erweiterbareMultimedia-Unterstutzung in Android. Der AndroidQuellcode bindet OpenCORE mit den Formaten aac,gsm amr, mp3 und sbc ein[9]Bereits im Dezember 2008 wurde im offiziellenAndroid Bugtracker unter der Ticketnummer1461[13] der Wunsch nach Unterstutzung des FLACFormates deutlich. Leider hat es ein Jahr spater nochkeine offizielle Anderung des Tickets gegeben. Esexistieren Ende Dezember 2009 jedoch schon uber100 Kommentare die diesen Wunsch bekraftigen.Zum 31. Juli 2009 wurden jedoch von Kenny Root 3Patches eingereicht, welche den FLAC Support inAndroid nachrusten. Um Patches zum offiziellenAndroid Repository hinzuzufugen muss ein ReviewProzess angestoßen werden. Dieser Prozess bestehtaus drei Schritten. Der erste Schritt ist ein Uploadder Patches in das ”Gerrit” genannte Code ReviewSystem unter http://review.source.android.com.Schritt zwei ist eine Zustimmung durch berechtigtenPersonen. Jedes Projekt im Android Source Tree hateine Liste von Leuten die einer Anderungzustimmen konnen. Je nach Projekt mussen ein odermehrere berechtigte Personen der Anderungzustimmen. Sollte dies geschehen sein, sind diePatches bei Schritt drei angekommen und werden inden offiziellen Android Source Tree gemerged.Von den FLAC Patches befinden sich zwei aktuell imZustand ”Review in Progress”, der dritte Patch wurdeschon in das offizielle Repository gemerged.Um dem langsamen offiziellen Prozess zu entgehen,wurde das Addon schon vor langerer Zeit in die”Cyanogen” Android Distribution ubernommen undkann damit schon auf aktuellen Geraten genutztwerden.Die offizielle Webseite [12] des Projektes macht nurauf eine Limitierung aufmerksam: Es wird nur FLACmit einer Sampletiefe von 16 Bit unterstutzt. Diessollte jedoch kein großes Problem darstellen, daFLAC Dateien zum Großteil von Audio CDs erzeugtwerden, welche selber nur 16 Bit Sampletiefebesitzen.

5.3. Apps2SDDie Moglichkeit der Auslagerung von Programmenauf die Speicherkarte (”Apps2SD”) ist ein sehrbeliebtes Thema in der Android Community.Das HTC Dream war das erste Android Smartphonewelches von einem Mobilfunkanbieter verkauftwurde. Dieses von T-Mobile ”G1” getaufte Endgerat

besitzt einen internen Speicher von 256 Megabyte.Um mehr als eine Hand voll Musik, Bilder oderVideos auf dem Gerat vorhalten zu konnen, besitztes wie die meisten Smartphones eine Moglichkeitden internen Speicher durch den Einsatz einerSpeicherkarte (meist im Micro SD Format) zuerweitern. Leider hilft diese Erweiterung demEndkunden nicht, wenn ihm durch großeApplikationen der interne Speicher knapp wird.Gizmodo(.com) berichtete, dass als Grund fur diesePraxis die Angst vor Raubkopien genannt wurde. Eswird laut Aussage von einem Google Mitarbeiterjedoch fur kommende Android Versionen an einerLosung gearbeitet, die Applikationen verschlusseltauf der SD Karte abzulegen.Der aktuelle Stand ist jedoch, dass es offiziell nichtmoglich ist. Da Android ein Linux basiertes Systemist, wird die SD Karte jedoch intern nur als weitererOrdner in das Dateisystem ”gemounted”. Demlaufenden System steht die Karte unter dem Pfad/sdcard zur Verfugung.Da die interne Systempartition mit demDateisystem YAFFS2 formatiert ist, beherrscht siedas erstellen von ”symbolischen Links”. Diese stelleneine Indirektion dar um einen Verweis auf einenanderen Ordner bereitzustellen. Will man nun einProgramm auf die SD Karte auslagern, kann maneinfach den Ordner des Programmes vom internenFlash auf die SD Karte verschieben und einenentsprechenden symbolischen Link zurucklassen.Da Programme nur uber die ublichen DateisystemAPIs auf Dateien zugreifen und diese APIs mitsymbolischen Links umzugehen wissen, andert sichfur die Anwenderprogramme selber nichts.Die erste Vorbereitung welche der Benutzer furdiesen Prozess selbst treffen werden muss ist, aufder SD Karte eine Ext3 bzw Ext2 formatiertePartition einzurichten. Leider unterstutzt dasnormalerweise fur SD Karten vom Systemeingesetzte FAT32/vfat die Posix Access ControlListen zur Rechteverwaltung von Dateien nicht undist damit nicht mit dieser Modifikation kompatibel.Die zweite Voraussetzung ist ein Kernel der mitUnterstutzung fur das Ext Dateisystem kompiliertwurde. Im Auslieferungszustand bietet Android nurUnterstutzung fur das YAFFS und FAT32 (aka vfat)Dateisystem. Da jedoch bei Android ein normalerLinux Kernel zum Einsatz kommt, ist die EXTUnterstutzung nur eine Konfigurationseinstellungvor dem Kompilieren und benotigt keinen weiterenAufwand.Vorteile dieser Erweiterung sind der dadurch quasiunbeschrankte Platz fur Programme und die

6

Moglichkeit nach einer Systemwiederherstellung dievorher installierten Programme mit einemKommando zuruck zu bekommen.Diese Modifikation hat jedoch nicht nur Vorteile. Sienimmt dem Benutzer die Moglichkeit die SD Karteim laufenden Betrieb entfernen zu konnen. Dadurchdass im System ein plotzliches fehlen vonProgrammen nicht vorgesehen ist, konntenunvorhersagbare Probleme auftreten. Des Weiterenist die Setup Prozedur recht komplex und sollte mitVorsicht durchgefuhrt werden. Schlussendlich ist es,je nach SD Karte, auch moglich dass eineVerlangsamung der Programme durch denpermanenten SD Karten Zugriff auftritt. DieAutomatisierung des kompletten Prozesses ist heutejedoch bei vielen Android Distributionen (z.B. der”Cyanogen” Distribution) gegeben bzw. uber einerweitertes Recovery Image realisierbar.Um den USB-Modus des Mobiltelefons weiterhinauch auf Systemen nutzen zu konnen welche keineUnterstutzung fur das EXT Dateisystem bieten ist esratsam eine seperate FAT32 formatierte Partition aufder SD Karte zu erstellen um weiterhin eineneinfachen Zugriff auf Bilder und Musikdateien zuermoglichen.

5.4. Funktionsumfang des ”RecoveryImage”

Die Erhohung des Funktionsumfangs des ”RecoveryImage” ist quasi ein Muss fur den Hobby-Entwickler.Die bisher auf dem Markt befindlichenAndroid-basierten Endgerate haben einenmehrstufigen Systemstart.Zu Beginn der Startsequenz wird uberpruft obgewisse Tastenkombinationen gedruckt sind. Einedieser Kombinationen (beim G1 z.B. Home-Key unddie rote Horertaste) fuhrt dazu, dass dasMobiltelefon nicht das volle Android Betriebssystemstartet sondern das System die ”Recovery” Partitionbootet. Diese Partition beinhaltet ein (Linux)Minimalsystem welches nur zum Update/derWiederherstellung der eigentlichen Systempartitiongedacht ist.Erweiterungen dessen Funktionsumfangesbeginnen beim Einspielen eines neuen Kernels miteiner großeren Dateisystemunterstutzung (z.B.wichtig fur ”Apps2SD”).Eine der attraktivsten Erweiterungen, genannt”Nandroid”, verschafft dem Benutzer dieMoglichkeit, den gesamten NAND Flash des Systemsauf die SD Karte zu sichern und bei Bedarf auchwieder zuruckzuspielen. Dies ermoglicht das

Erstellen von kompletten System Backups, wasinsbesondere fur Entwickler von großer Bedeutungist.Teil der erweiterten Recovery Images sind auchTools welche z.B. die Partitionierung von SD-Kartenermoglichen. Die im vorherigen Kapitelbesprochene ”Apps2SD” Erweiterung kann somitvollstandig uber die neuen Bordmittel durchgefuhrtwerden.Die beliebteste Distribution des Recovery Image istdas sogenannte ”Pimped out recovery image withnew features”[14] welches von Steve ’Cyanogen”Kondik erweitert wurde. Die Installation kann ausdem laufenden System erfolgen und beschrankt sichauf die Eingabe eines simplem Kommandos ineinem Terminal-Emulator:

flash image recovery/sdcard/cm-recovery-1.4.img

5.4.1 APN Listen

Die Konfiguration der Datenverbindung einesMobilgerates ist sicherlich eine der komplexerenAufgaben mit denen sich ein Smartphone-Besitzerkonfrontiert sehen kann.Im Normalfall sind auf Mobilgeraten welche durcheinen Mobilfunkprovider verkauft werden dieseDaten automatisch hinterlegt. Das Hauptaugenmerkliegt hierbei auf dem Access Point Name (kurz: APN).Beim Aufbau einer Datenverbindung wird der imTelefon hinterlegte APN mit an das Netz ubergeben.Das Netz ermittelt daraufhin uber eine DNS Anfragean welchen Gateway die Anfrage weitergeleitetwerden muss. Dieses Gateway leitet die Anfragendes Nutzers aus dem Netz des Mobilfunkprovidersin das Globalen Internet weiter. Sollte ein falscherAPN an das Netz ubergeben werden, findet keineWeiterleitung der Pakete ins Internet statt.Die Mobilgerate verfugen im Auslieferungszustanduber eine Liste der APNs von Vertragspartnern.Kleinere Provider oder lokale Provider beiImportgeraten bleiben in desen Listen jedoch oftaußen vor. Die Zusammenarbeit der Communitybeim Sammeln von entsprechenden Netz und APNKombinationen fuhrt zu umfangreichen APN Listenwelche eine manuelle Einrichtung meist uberflussigmacht.

7

6. Erweiterungen auf ApplikationsEbene

Auf Applikationsebene sind in diesem Umfeld seltenkomplette Neuentwicklungen zu finden. Es sindmeist kleine Patches bzw Konfigurationsanderungenan vorhandenen Anwendungen.

6.1. Better BrowserDer ”Better Browser”[15] ist eine Erweiterung desStandardwebbrowsers um u.a. Multitouch-Gesten.Da der Webkit-basierende Android Browser unterOpen-Source Lizenz steht, konnten zusatzlicheFeatures mit vergleichbar geringem Aufwandimplementiert werden.Die zusatzlichen Features welche im originalenBrowser nicht vorhanden sind erstrecken sich voneinfachen kosmetischen Anderungen bis hin zuneuer Funktionalitat. Einer der großtenUnterschiede ist der Support fur Multitouch. Dievom iPhone ublichen ”pinch” Gesten umAusschnitte von Webseiten zu vergroßern werdendadurch bei entsprechendem Kernel (mitMultitouch Support) unterstutzt. KosmetischeAnderungen wie das Deaktivieren der Zoom Buttonsgehen Hand in Hand mit neuen Gesten wie z.B. dieDouble-tap Geste um die Zoomstufe zu erhohenoder die Triple-tap Geste um die Zoomstufe zuverringern. Beachtlich ist hierbei dass die”Triple-Tap” Geste im Android SDK nichtvorgesehen ist sondern von Hand implementiertwurde.Die letzte großere Erweiterung des Browsers ist das”Mobile Web Settings” Feature. Es ermoglicht dieUbertragung eines beliebigen HTTP User Agents.Dieser von vielen Seiten ausgewertet um zuentscheiden ob eine fur Mobilgerate optimierteVersion der Seite ausgeliefert wird. Durch dengeanderten User Agent wird es dem Android Geratermoglicht eine z.B. auf iPhones spezialisierteAnsicht bestimmter Webseiten zu erhalten falls derWebseitenbetreiber die Android Plattform bishernoch nicht als Mobilgerat erkennt.

6.2. BackportsDie Community hat auch eine Reihe von”Backports” hervorgebracht. Dies sindSoftwarekomponenten welche auf neuerenHandymodellen erschienen sind und vonEntwicklern auf alteren Hardwaremodellen lauffahiggemacht werden.

Da Google dem Android Open-Source Projekt inregelmaßigen Abstanden neue Releases des Systemsbeisteuert bieten die offiziellen Android Sourcen oftzusatzliche Features welche in alteren Gerate nichtexistieren.Dies konnte insbesondere beim Erscheinen derAndroid Releases mit den Codenamen ”Donut” bzw”Eclaire” und deren konsequenter Portierung auf dasHTC Dream beobachtet werden. Hierbei wurden z.B.Features wie PPTP/L2TP VPN und WPA EnterpriseSupport hinzugeugt, welche zu dieser Zeit nur imexperimentellen ”Donut” Release zu finden waren.Ein weiteres Beispiel sind oft einzelne Widgetswelche in spateren Handymodellenbeziehungsweise Systemversionen aufgetaucht sind.Widgets sind kleine Programme welche direkt aufdem Homescreen des Gerate laufen und nichtexplizit gestartet werden.Hierzu sind z.B. das Power Widget (zusammen mitdem ”App Fuel Gauge” Systemfeature) oder das HTCTwitter-Widget zu nennen. Diese Widgets erlaubeneine einfache Aktivierung von Services (Bluetooth,GPS, ...) respektive die Interaktion mit demMicro-Blogging Dienst Twitter.Insbesondere bei den Widgets von HTC stellt sichjedoch oft die Frage nach der Legalitat der weiterenVerbreitung der Widgets, da diese nicht unteroffenen Lizenzen stehen.

7. LizenzfrageBei der Verbreitung von ”flash-fertig” Image Dateienuber Entwicklerforen stellt sich naturlich noch dieFrage der Lizenzen der Einzelkomponenten.Wahrend Großteile des Systems unter einer freienLizenz stehen, sind einige Anwendungen (z.B.Google Maps) proprietar und deren Verbreitungohne Zustimmung des Rechteinhabers istumstritten. Hier ist es interessant zu sehen, welcheSystembestandteile der Android Smartphones unterwelche Lizenz fallen.Die im offiziellen Android Repository(http://android.git.kernel.org/) bereitgestelltenKomponenten befinden sich alle unter der Apachev2 Open Source Lizenz.Einige der Hauptkomponenten (neben den ublichenLinux Systembibliotheken) sind:

• Das OpenCORE Media Framework• Die Tesseract Open Source OCR Engine• Der radio interface layer (”ril”)• Andwendungen wie z.B. Alarm Clock, Browser,

Calendar, Calculator, Camera, Contacts, Email,IM, Music, Voice Dialer, Sound Recorder

8

Wahrend diese Komponenten ausreichen um einLauffahiges System herzustellen, gibt es jedoch nocheinige Bestandteile welche sich auf aktuellenEndgeraten finden, jedoch nicht unter einer freienLizenz verfugbar sind:

• Google Maps• YouTube• Google Voice• Google Talk (ein Instant Messaging Client fur

Googles XMPP basierende Chat Platform)• Google Android Market• Google Search• Gmail (ein spezialisierter eMail client fur

Googles Mailservice)• Der Google Calendar Provider (um eine

synchronisation zu GooglesOnline-Kalenderdienst bereitzustellen)

Diese Software ist Teil der sogenannten ”GoogleExperience” und wird von Google an die Herstellerder Endgerate bzw. an Provider verkauft.Interessant ist hierbei die anfanglicheArgumentation von Steve Kondik (besser bekanntunter seinem Pseudonym”cyanogen”). Er verbreitetedie ”Google Experience” Anwendungen als Teilseiner Images. Darin sah er jedoch kein Problem, dadie Images nur auf ”Google Experience” Geratenlauffahig waren. Der Einsatz der Anwendungenerfolgte also stets von Leuten die durch den Kauf desTelefons dazu berechtigt waren.Wahrend diese Argumentation intuitiv rechtnachvollziehbar ist, hat sich Steve Kondik daraufnicht verlassen und vertreibt seine AndroidDistribution fortan ohne die entsprechendenApplikationen. Dies bedeutet jedoch nicht dass dieBenutzer der Distribution darauf verzichtenmussen. Da die offiziellen Firmware Images vonHTC (dem Telefon-Hersteller) die Anwendungenenthalten, wird die Installation der Distributionquasi als Update uber ein vorher geflashtesoffizielles Image durchgefuhrt.Somit verbreitet er selbst nur unbedenklicheKomponenten auf seinen Images und erhalt die”Google Experience” aus den offiziellen Images.Eindeutig ist die Lage bei Widgets oder andererzusatzlicher Software, welche auf neueren Geratenerscheint und nicht unter einer freien Lizenz steht.Hier wird durch die Verbreitung als Backport oderals Teil eines flashbaren Images klar das Copyrightmissachtet.

8. FazitDie Beliebtheit der einzelnen Modifikationen sprichtfur sich. Es gab in der Geschichte der Mobiltelefonenoch keine anderen Zeitpunkt an dem eine großereAnzahl Endbenutzer tiefgreifenden Anderungen anihrem Mobiltelefon durchgefuhrt haben.Insgesamt kann man sagen dass sich dieBereitschaft von Endbenutzern stark erhoht hat, ihrEndgerat eigenstandig zu modifizieren. Benutzerdes Apple iPhone konnten sich uber einen”Jailbreak” schon lange vor dem offiziellenMarktstart des Appstore zusatzliche Applikationeninstallieren. Benutzer des Palm Pre wird es durch”Preware” ermoglicht ihr Gerat mit zusatzlichenProgrammen und Erweiterungen zu versehen.Durch das Aufkommen von unix- bzwlinuxbasierten Endgeraten wird es nun auchProgrammierern ermoglicht Erweiterungen zuschreiben, welche vorher keinerlei Erfahrung mitEmbedded Systems hatten.Trotz der relativ großen Verbreitung derModifikationen gibt es bisher keine Hersteller dieversucht haben rechtliche Schritte gegen eben jeneSoftwareprojekte zu unternehmen. Palm CEO JoshRubenstein ging auf der Consumer Electronics Show2010 sogar soweit, die Ergebnisse der EntwicklerCommunity lobend in seiner Keynote zu erwahnen.Einzig bei der Verbreitung von bestehendemintellektuellem Eigentum ohne Zustimmung desHerstellers wurde eine Unterlassungsanordnungvon Google gegen den Entwickler der beliebtenCyanogen Distribution ausgesprochen. Jedocherfolgte auch hier die Kommunikation sehrverstandnisvoll und hatte keine finanzielleSchadigung des Entwicklers zur Folge.Fur die Zukunft scheint sich eine weiterePopularisierung der Modifikationen durchEndbenutzer abzuzeichnen. Ob diese Zukunft furHardwarehersteller ahnliche Symptome zeigen wird,wie sie auch schon die Content Anbieter beimWechsel des Web 1.0 zum Web 2.0 mitgemachthaben, wird sich zeigen.

9

Literatur

[1] ”Tool to flash the recovery image on Android phones”:http://zenthought.org/content/project/flashrec

[2] Vulnerability CVE-2009-2692:http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2692

[3] Vulnerability CVE-2009-3547:http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3547

[4] Con Kolias, ”FAQS about BFS”:http://ck.kolivas.org/patches/bfs/bfs-faq.txt

[5] Con Kolias, Design Ubersicht fur BFS:http://ck.kolivas.org/patches/bfs/sched-BFS.txt

[6] Commit des BFS Schedulers in den offiziellen AndroidSourcecode:http://android.git.kernel.org/?p=kernel/experimental.git;a=commit;h=c8fa3555b59a200f9a5b1098f17c0333b9529258

[7] SetCPU: Tool zum Anpassen der Taktfrequenz aufdem HTC Dream: http://www.pokedev.com/setcpu/

[8] android obex - provide obex file sharing in Android:http://gitorious.org/android-obex

[9] Audio Support im Git Repository des OpenCOREFrameworks:http://android.git.kernel.org/?p=platform/external/opencore.git;a=tree;f=codecs_v2/audio

[10] Compcache Module, compressed in-memory swapdevice for Linux:http://code.google.com/p/compcache/

[11] Erin Yueh,”how to have OBEX function in Android?”:http://i-miss-erin.blogspot.com/2009/10/how-to-have-obex-function-in-android.html

[12] Kenny Root, FLAC on Android:http://the-b.org/FLAC_on_Android

[13] Bugtracker-Ticket zur Erweiterung des AndroidSourcecode um FLAC:http://code.google.com/p/android/issues/detail?id=1461

[14] Steve ”Cyanogen” Kondik: Pimped out recoveryimage with new features:http://forum.xda-developers.com/showthread.php?p=3915123

[15] Loccy: Better Browser:http://forum.xda-developers.com/showthread.php?t=551119

10