Schlagwort: Android

Java APIs in Android: Der Rechtsstreit ist entschieden

ihbrune

Die Auseinandersetzungen zwischen Oracle und Google um Google’s Nutzung von Java APIs in Android sind offenbar vorbei: Das Oberste Gericht der USA hat entschieden, dass diese Nutzung unter den Fair Use fällt. Neben IT und Tech Seiten wie Heise und The Verge haben auch SPIEGEL und FAZ direkt darüber berichtet. Das Urteil ist spannend zu lesen:

Fast 11 Jahre vor Gericht

Zusammenfassungen der verschiedenen Etappen dieser Auseinandersetzung zwischen den beiden IT Giganten lassen sich an verschiedenen Stellen im Netz finden, für mich verbindet sich die Anfangsphase noch mit intensiven Diskussionen darüber beim schon lange eingestellten Google+. Dort haben sich naturgemäß die eher Google-freundlichen Diskutanten eingefunden, aber die Frage ob Google sich unrechtmäßig der kreativen Leistung anderer bedient hat, oder ob Oracle mit seinem Versuch Programmierschnittstellen nachträglich als urheberrechtlich geschützte Werke zu interpretieren die Softwarewelt aus ihren gewohnten Angeln hebt, war heiß umstritten. Ich war da eher auf der Seite, die Oracles Klagen strikt ablehnte. Die folgende Karikatur aus dieser Zeit zu den Organisationsstrukturen verschiedener IT Unternehmen ist mir daher direkt wieder eingefallen:

Humoristische Organisationscharts verschiedenen US IT Unternehmen: Apple, Google, Microsoft, Oracle, Facebook, Amazon
Comic von Manu Cornet

Interessante Auszüge aus dem Urteil

Das Urteil kann man hier als PDF vom Heise Verlag abrufen. Es ist durchaus lesenswert und auch ohne umfangreiche juristische Kenntnis durchaus verständlich. Ein paar Abschnitte habe ich mir rauskopiert:

‚To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”

Das oberste Gericht hat also die für die IT Welt – insbesondere auch die Open Source Community – wesentliche Frage ob eine API überhaupt ganz grundsätzlich ein Urheberrecht haben kann, nicht entschieden. Und da hatte Oracle in früheren Instanzen einen Etappensieg errungen. Auch wenn die Oracles Niederlage nun vielleicht einen abschreckenden Effekt hat, grundsätzlich ist damit zumindest in den USA wohl mit weiteren Verfahren zu rechnen, in denen API-Nutzungen Anlass zu Gerichtsverfahren geben. Und nicht jede Beklagte ist so mächtig und wohlhabend wie Google.

‚Computer programs differ to some extent from many other copyrightable works because computer programs always serve a functional purpose.‘

Das Gericht hat sich aber Gedanken dazu gemacht, in wie weit das Urheberrecht eigentlich auf Software angewendet werden kann.

‚As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task. As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system.‚

Hier macht das Gericht zum ersten, aber nicht zum letzten Mal, einen interessanten Punkt: Eine API – zumindest die, um die es hier konkret geht – gewinnt dadurch an Wert, dass Programmierer*innen sie erlernen und dafür Zeit investieren. Damit wird die Wertgenerierung nicht mehr allein den Erschaffer*innen zugebilligt, sondern jede Java Entwickler*in, die diese APIs gelernt hat, vergrößert durch ihr Investment den Wert der Sprache.

‚Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language.‘

Auch hier wird wieder der Verweis auf das existierende Knowhow von Entwickler*innen gemacht und das es Googles Vorgehensweise diesen ermöglicht habe ihr Wissen nun in einem weiteren Umfeld zu nutzen. Dieses Wissen also wertvoller wurde.

‚Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.‘

Und noch einmal der Verweis auf die Möglichkeit für Entwickler*innen ihr Knowhow in einer neuen Umgebung zu nutzen. Verbunden mit der Entlastung von Google, die eine vergleichsbare API oder gleich eine ganze Programmiersprache auch leicht hätten selbst entwickeln können (was sie in späteren Jahre mit Dart und Go taten).

‚The fourth statutory factor focuses upon the “effect” of the copying in the “market for or value of the copyrighted work.” §107(4). Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE. The record also showed that Java SE’s copyright holder would benefit from the reimplementation of its interface into a different market‚

Mir persönlich gefällt, dass das Gericht den positiven Einfluss von Android auf das ganze Java Ökosystem hier honoriert. Schon bei den ersten Diskussionen gab es diesen Punkt, wenn es Oracle wirklich darum gegangen wäre Java zu pushen, dann hätten sie direkt mit Google zusammenarbeiten können. Und offenbar ist im Laufe der Jahre das Argument von Oracle verloren gegangen, wonach Google mit Android das ‚florierende‘ Ökosystem von Java ME Handys vernichtet habe.

Die Entwickler*innen als eigene Partei

Abgesehen von der eigentlichen Urheberrechtsfrage, die vermutlich in anderen Gerichtsverfahren – vielleicht nicht nur in den USA – entschieden wird, finde ich den Aspekt, das wir als Entwickler*innen eine wesentliche Rolle in solchen Erwägungen spielen, sehr spannend:

Wenn wir uns auf eine Sprache / API / Technologie einlassen kostet uns dies Zeit und vielleicht auch Geld und eine Technologie kann sich kaum durchsetzen ohne eine entsprechende Menge von Menschen, die sich damit gut auskennen. Und unsere Interessen sind dabei durchaus anders als die der potentiellen Urheberrechtsinhaber*innen: Für uns ist es attraktiv die Wahl zu haben, zwischen Werkzeugen und zwischen Implementierungen einer API, und jedes neue Feld, in dem wir unsere Kompetenz einsetzen können, ist zunächst einmal gut für uns und den Wert unseres Wissens.

Man wird sehen, ob dieser Aspekt auch in zukünftigen Gerichtsverfahren eine Rolle spielen wird.

Zwei Jahre Android Security Rewards – Was hat sich verändert?

ihbrune

Vor nun zwei Jahren hat Google mit den Android Security Rewards sein spezielles Bug-Bounty-Programm für Android gestartet. Kurz bevor mit den ersten Stagefright Sicherheitslücken die Kritik an der damaligen, desolaten Sicherheitslage Androids ein Allzeithoch erreichte. Im Android Entwicklerblog hat Google nun ein Fazit dazu gezogen, wie sich die Situation seit damals entwickelt hat. Der Post ist recht kurz, aber trotzdem in seinen Details interessant:

Android Update - Rot

Ein steter Strom von Bugreports

Man kann wohl sagen, dass dieses Bug-Bounty-Programm heute funktioniert: Im letzten Jahr sind mehr als 450 Reports eingegangen. Es vergeht damit wohl kaum ein Tag bei Google, an dem nicht eine Fehlermeldung eintrifft. Das ist zunächst einmal ein echter Erfolg, auch wenn daraus natürlich Schlagzeilen entstehen wie z. B. diese hier: „Android Was 2016’s Most Vulnerable Product„.

Da Google den Android Quellcode im Android Open Source Project (AOSP) veröffentlicht kann sich hier faktisch jedeR an der Fehlersuche beteiligen und damit Geld und Anerkennung verdienen. Und tatsächlich tut dies eine große Zahl von Leuten.

In gewisser Weise bestätigt Android damit das von Open Source Verfechtern gern ins Feld geführte Argument, wonach die Offenheit auch gleichzeitig für eine bessere Sicherheit sorge, weil eben viele Menschen ohne große Hürden nach Fehlern suchen können. Auf der anderen Seite zeigt aber der Erfolg des Bug-Bounty-Programms auch was für ein wichtiger Faktor der finanzielle Anreiz sein kann. Dieser Anreiz fehlt bei vielen Open Source Projekten.

Mehr Geld, mehr Bugreports?

1,1 Millionen Dollar hat Google laut dem Bericht in den letzten 12 Monaten ausgeschüttet, was einer durchschnittlichen Summe von mehr als 10.000$ pro Sicherheitsforscher entspräche. Natürlich gibt es Personen / Gruppen, die durch besonders viele Meldungen herausstechen, Google selbst hebt hier das C0RE Team hervor, welches allein 118 Reports eingereicht und dafür 300.000$ erhalten hat.

Die höchsten Belohungsstufen wurden dabei aber bisher nicht erreicht, Google hebt diese Belohnungen nun auf das 4- bzw. 5-fache der bisherigen Werte. Damit könnte man nun 6-stellige Summen allein für einen einzigen Bugreport erhalten.

Google steht hier – wie heute alle großen IT Unternehmen – in starker Konkurrenz zu staatlichen Stellen aus aller Welt, die für ihre Geheimdienste nach ‚Cyberwaffen‘ Ausschau halten und sich dazu privater Dienstleister bedienen, für die die Suche nach Einbruchsmöglichkeiten in populäre Software zu einem profitablem Geschäft geworden ist. Hier kann man mit einem funktionierenden Exploit in das weltweit meistgenutzte Betriebssystem vermutlich noch weitaus höhere Gewinne erzielen.

Das ein hoher Belohnungspreis ein Bug-Bounty-Programm nicht automatisch erfolgreich machen muss hat der gescheiterte Versuch von Googles Project Zero gezeigt: Dieses wollte mit dem Project Zero Price ein eigenes Programm auf die Beine zu stellen, welches ebenfalls 6-stellige Summen für hochwertige Angriffe auf Android in Aussicht stellte. Es erhielt aber keine einzige relevante Einreichung und wurde wieder eingestellt.

Ein breiter aufgestelltes Programm wie die Android Security Rewards kann da durchaus erfolgreicher sein, auch wenn bzw. gerade weil seine Belohnungsstaffelung bei deutlich kleineren Summen beginnt: Dadurch erhöht sich die Zahl der beitragenden ForscherInnen und der Versuch einzelne Fehler zu horten, bis sie sich zu einem leistungsfähigeren Exploit kombinieren lassen, ist dann mit dem großen Risiko verbunden, dass jemand anderes einen der Fehler findet, die Belohnung erhält und Google die Lücke schließt.

Welche Geräte sind für sicherheitsbewusste Android NutzerInnen kaufbar?

Im Oktober 2015 – gezwungen durch das Stagefright Debakel – entschied sich Google einen lange überfälligen Schritt zu machen: Damals begann das Programm der monatlichen Android Sicherheitsupdates. Bis dahin gab es den absurden Zustand, in dem Google Meldungen über Sicherheitslücken zwar einsammelte, aber faktisch niemand zeitnah davon profitieren konnte. Durch die neuen Updates waren zuerst nur die direkt von Google kontrollierten Android Geräte wieder auf einem akzeptablen Sicherheitslevel, aber allmählich auch die Produkte einiger anderer Hersteller.

Android Upate

Und auch darüber gibt der aktuelle Blogpost Auskunft: Bei welchen Herstellern von Android Geräten ist meine Chance groß, dass diese zeitnah Sicherheitsupdates bekommen? Google sagt dabei zum einen dies:

Over 100 device models have a majority of their deployed devices running a security update from the last 90 days

Die dann gezeigte Tabelle mit konkreten Geräten lässt trotz ihrer etwas anderen Semantik (‚This table shows the models with a majority of deployed devices running a security update from the last two months‘) eigentlich nur einen Schluss zu: Wer keines der wenigen direkt von Google kommenden Gerät kaufen kann oder will, der sollte zu einem Samsung Gerät greifen. Samsung hat mit Abstand die größte Zahl von Geräten in dieser Liste und kann damit wohl als Vorbild bei der Updatepolitik gelten (wobei es hier wohlgemerkt nicht um Updates der Android Version geht, dass ist noch mal ein ganz anderes Thema).

Fazit: Auf dem richtigen Weg (aber der Weg ist noch weit)

Google ist es augenscheinlich gelungen ein lebendiges Umfeld von Sicherheitsforschern zu schaffen, die zur Android Sicherheit beitragen. Die ausgeschütteten Summen – auch wenn es sich dabei inzwischen um einen Millionenbetrag handelt – sind dabei vermutlich immer noch ‚günstig‘. Muss man das Fazit ziehen, dass Android angesichts der weiterhin hohen Zahl von monatlichen Fehlerkorrekturen besonders unsicher ist?

Das finde ich schwer zu beurteilen, auch andere (Betriebs-)Systeme haben durchaus ansehnliche Zahlen an korrigierten Fehlern vorzuweisen und faktisch ist jeder korrigierte Fehler einer weniger, den jemand anderes schon im Geheimen gefunden und ausgenutzt haben könnte. Nur falls auch in den kommenden Jahren die Zahl der in Android gefundenen Fehler so hoch bleibt wäre das ein sicheres Zeichen, dass mit der Codebasis bzw. der Weiterentwicklung etwas grundsätzlich nicht in Ordnung ist.

Weiterhin das größte Problem des Android Ökosystems ist aber das Fehlen von Updates für die Masse der inzwischen mehr als 2 Milliarden Geräte. Auch wenn Google die ‚mehr als 100 Modelle‘ nicht genau benennt, bei denen die Mehrheit der NutzerInnen wenigstens ein maximal 3 Monate altes Sicherheitslevel erreicht hat, kann man auf Grund der Vielzahl von Android Geräten – siehe die immer wieder gern zitierte Auswertung von OpenSignal aus dem Jahr 2015 – davon ausgehen, das dies nur ein Bruchteil der in aktiver Nutzung befindlichen Geräte ist.

Auch hier muss es die Zeit erst zeigen, ob die Seamless Updates, die mit Android N eingeführt wurden, und die in Android O mit dem Project Treble geplante stärkere Separierung von Betriebssystemteilen in der Lage sein werden eine signifikante Verbesserung zu bringen. Angesichts der gewohnt langsamen Ausbreitung neuer Android Versionen kann man von diesen Verbesserungen aber bestenfalls in einigen Jahren einen sichtbaren Effekt erwarten.

Bis dahin wird es wohl insbesondere den im Hintergrund von Google durchgeführten Prüfungen im Play Store und auf den Endgeräten überlassen bleiben Angriffe zu verhindert.

Die Stagefright Bugs: Das Beste, was der Android Sicherheit passieren konnte

ihbrune

Vor wenigen Tagen wurde ‘Stagefright 2.0’ bekannt, also die nächste Iteration der gefährlichen Fehler in Stagefright, der zentralen Mediaplayer Komponente des Android Betriebssystems. Warum soll das gut sein für die Sicherheit des weltweit meistgenutzten Betriebssystems?

Eine kurze Geschichte der Stagefright Bugs

Wir erinnern uns kurz: In den Wochen vor der Blackhat Konferenz Ende Juli begannen Gerüchte über einen schweren Fehler in Android zu kursieren. Der besondere mediale Reiz dieses Bugs war die Möglichkeit ihn über eine zugeschickte MMS auslösen zu können. Kombiniert mit dem damaligen Verhalten der Standard MMS Apps solche Inhalte ohne Zutun des Benutzers auszuführen hatte man ein mögliches Horrorszenario und Schlagzeilen wie ‘Eine Milliarde Android Geräte per MMS hackbar!’ waren die unvermeidliche Folge. Und der Name ‘Stagefright’ der betroffene Komponente lieferte auch gleich einen eingängigen Namen für das Problem.

Android Security

Unter dem hohen öffentlichen Druck zeigte sich—wieder einmal—das größte Problem des gigantisch gewordenen Android Ökosystems: Nur ein Teil der mehr als eine Milliarde aktiver Android Geräte bekommt Updates. In diesem Fall standen selbst die Besitzer der direkt von Google mit Updates versorgten Nexus Geräte genauso dumm da, denn obwohl Google den Fehler seit Monaten kannte war noch kein Patch offiziell verfügbar.

Wie konnte es so weit kommen?

Wie konnte ausgerechnet Google in diese Misere geraten? Hat Google mit dem Chrome Browser die automatischen, ohne Benutzerintervention stattfindenden Updates doch erst zum heutigen Standard gemacht und auch in fast allen späteren Produkten durchgesetzt: ChromeBooks, Android Wear Uhren, Chromecasts, OnHub Router, Android TVs, sie alle bekommen ihre Updates unmodifiziert direkt von Google und sind trotz Nutzerzahlen, die ebenfalls im Millionenbereich liegen, immer auf dem aktuellsten Stand. Selbst auf Android Geräten hat Google mit den Play Services einen Systemteil, der regelmäßig Updates erhält, sich selbst ohne Benutzerinteraktion aktuell hält und heute ein wesentliches Element von Googles Android Sicherheitsmanagement ist.

Das Problem beim Android Betriebssystem ist durch das komplizierte Verhältnis zwischen Google, dem Herrscher über die Android Weiterentwicklung, seinen Partnern wie Samsung, die die eigentlichen Geräte bauen und Android dafür modifizieren, und den Telekomanbietern, die noch einmal eigene Anpassungen von den Geräteherstellern verlangen, entstanden. Vermutlich hatte Google bisher die — berechtigte — Sorge, dass Veröffentlichungen von Fehlerkorrekturen im Android Open Source Projekt (AOSP) schnell von Angreifern untersucht und zum Bau von Angriffscode genutzt werden. Schneller, als die Gerätehersteller in der Lage oder Willens sind ihren Kunden Updates zu liefern.

In der Konsequenz konnten nicht einmal die Nexus Geräte Updates erhalten, da auch hier ein Reverse Engineering möglich wäre. Und so ist die Situation entstanden, die am Ende die ganze Android Welt ohne ein einziges Gerät mit einer wirklich nach aktuellem Wissenstand fehlerfreien Version dastehen lies.

Der Befreiungsschlag

Der durch die ersten Stagefright Fehler aufgebaute Druck hat Google schließlich dazu gebracht seine Strategie komplett zu ändern: Der auf der Blackhat Konferenz vortragende Google Sicherheitsmann Adrian Ludwig kündigte in seinem lesenswerten Vortrag an, dass es ab sofort monatliche Sicherheitsupdates für die Nexus Geräte geben werde, gefolgt von einer raschen Veröffentlichung der Fehlerkorrekturen im AOSP.

Ob Google dabei nun vom Druck getrieben wurde, oder ob man den Druck nutzte um auch bei Android eine Entwicklungsgeschwindigkeit zu erreichen, wie man sie in allen anderen Google Produkten kennt, wird man von außen vermutlich nie abschließend beurteilen können. In jedem Fall gibt Google den Druck damit an seine Partner weiter: Der Angriffsdruck auf alle Android Geräte, die keine aktuellen Patches erhalten, wird durch diese neue Linie mit Sicherheit steigen.

Mindestes den großen Herstellern, die auf Markenbildung, nachhaltige Kundenbeziehungen und den Einsatz ihrer Produkte in Unternehmen und Behörden setzen, kann so ein permanenter Kritikpunkt nicht gefallen.

Den Druck noch weiter erhöhen

Interessanterweise hat Google den Druck in den letzten Wochen noch einmal erhöht. Google selbst hatte mit seinem Project Zero angefangen andere Softwarehersteller mit einer 90 Tage Frist bis zur Veröffentlichung von Fehlern unter Druck zu setzen. Und musste sich prompt in Bezug auf Stagefright den Vorwurf gefallen lassen, bei seinen eigenen Produkten offensichtlich mit zweierlei Maß zu messen.

Nach der Strategieänderung hat das Project Zero nun auch Android Lücken öffentlich aufs Korn genommen und in einem Blogpost demonstriert, wie die zunächst dank Schutzmechanismen wie ASLR eher theoretisch erscheinende Ausnutzbarkeit eines bestimmten Stagefright Fehlers in einer Weise aufgerüstet werden kann, die sie in unmittelbare Nähe eines verlässlichen Exploits bringt.

Die Updates von Google kommen

Inzwischen ist das dritte Sicherheitsupdate an die Nexus Geräte ausgerollt werden, kurz bevor Android 6.0 ausgeliefert wird. Google hat hier also sein Versprechen gehalten. Wenn man sich die Liste der behobenen Fehler samt ihrer Kritikalität ansieht und weis, dass sie bald allgemein bekannt sein werden, kann man sich schon die Frage stellen ob man — trotz der zusätzlichen Schutzmaßnahmen, die Google im Play Store und den Play Services implementiert — jemandem ernsthaft dazu raten kann sich ein Nicht-Nexus-Gerät zuzulegen.

Den ersten Gewinn für die Android Sicherheit aus dem Stagefright Desaster haben wir damit: Es gibt nun mit den Nexus Geräten — die bald zwei schöne Hardwareupdates erhalten — eine Android Linie, bei der man von Google garantiert häufige Updates für alle bekanntgewordenen Sicherheitsprobleme bekommt.

Aber auch Custom ROM Anbieter wie Cyanogen haben nun die Chance über die schnelle Integration der AOSP Korrekturen ihre eigenen Versionen von Android aktuell zu halten. Damit haben wir den zweiten Gewinn: Wer kein Nexus Gerät hat oder haben will, aber ein Gerät, für das ein Custom ROM verfügbar ist, kann nun ebenfalls auf ein schnelles Schließen von Sicherheitslücken hoffen.

Wann kommen die Updates von den Geräteherstellern?

Trotzdem hatte die Masse der Android Nutzer bisher noch keinen unmittelbaren Vorteil von diesen Entwicklungen, auch wenn einige Gerätehersteller nach den ersten Stagefright Lücken schon Updates ausgerollt hatten. Hier kann man aber hoffen, dass das nun durch die Nexus Updates monatlich aufflackernde Sicherheitsthema dafür sorgt, dass der Druck auf die Hersteller und Telekomunternehmen nicht nachlässt. Am Ende kann hier eigentlich nur die Einsicht stehen, dass die Möglichkeit schnell und häufig Updates an die Geräte der Kunden zu geben ein eigenes Qualitätsmerkmal ist, mit dem sich werben lässt.

Wenn dieser Status — wenigstens für die Flaggschiffgeräte der großen Hersteller — erreicht worden ist, dann haben wir den dritten und entscheidenden Gewinn aus den Stagefright Lücken gezogen. Ein Gewinn, der sich im verwickelten Android Ökosystem offenbar erst mit dem enormen Druck, den die Stagefright Probleme ausgelöst haben, realisieren liess.

Und falls dies auch dazu führt, dass die im Zeitalter des Material Design oft klobig und unelegant wirkenden ‘Verbesserungen’ der Gerätehersteller am Android System zurückgefahren werden, so kann man dies nur begrüßen.

Notizen zur Google I/O 2015

ihbrune

Gestern begann die Entwicklerkonferenz von Google und wie in jedem Jahr ist die Keynote der Auftakt und in gewisser Weise auch der Höhepunkt der Veranstaltung, jedenfalls von außen gesehen. Hier präsentiert eines der wichtigsten Technologieunternehmen der Welt seinen Stand, seine Produkte und seine Visionen für die nahe und ferne Zukunft. Das sind meine Notizen, ohne Anspruch jedes Detail abzudecken:

Google I/O 2015

Google als KI Unternehmen

Am Anfang der Keynote sprach Sundar Pichai eine kurze Zeit von den Fortschritten beim maschinellen Lernen, die Google im vergangenen Jahr gemacht hat. Ein Schlüsselkonzept sind dabei tiefgestaffelte, neuronale Netze, bei denen die verschiedenen Ebenen unterschiedliche Aspekte der gestellten Aufgabe lernen. Auch wenn das Thema nur vergleichsweise kurz und zeitlich deutlich getrennt von der heute am besten sichtbaren Anwendung (Google Photos) präsentiert wurde: Das ist das Thema, welches heute — oder immer schon — im Kern von Google steckt und mit dem offenbar schnelle und überraschende Fortschritte möglich sind. Beispiel die Spracheingabe bei der Google Suche, deren Fehlerrate innerhalb des letzten Jahres auf diese Weise deutlich verringert werden konnte.

Android M

Das Rechtemodell geht mehr in Richtung iOS: Rechte werden in größeren Gruppen gebündelt; Rechte werden (zumindest teilweise) erst bei der ersten Verwendung abgefragt; Können später wieder entzogen werden und lassen sich sowohl per App wie auch per Recht betrachten und bearbeiten. Sicher die größte Änderung am Rechtemodell, die es in Android jemals gab. Die Entwickler wurde damit geködert, dass Nutzer Apps dann schneller installieren (da keine vorherige Rechteabfrage mehr erfolgt) und auch bei Updates, in denen mehr Rechte verlangt werden, nicht mehr zögern.

Viel Herumreiten darauf, dass man sich in M auf Qualitätsverbesserung konzentriert habe. Vermutlich ein Eingeständnis, dass Lillipop ziemlicher Müll war, was die Softwarequalität angeht.

Google Now wird immer schlauer (und übergreifender)

Google baut seine bisher ziemlich einzigartige Now Funktion noch stärker aus und zwar nicht nur in der schon bekannten Weise, in der einem Informationen proaktiv angeboten werden. Mit Now on Tap kann man die Funktion in Android M dazu veranlassen, die von der gerade offenen App gezeigten Inhalte zu interpretieren und einem geeignete Funktionen und Informationen anzubieten. Hier legt Google also ein eigenes Layer über potentiell alle Apps. Ob die App Anbieter etwas dazu tun müssen ist nicht ganz klar geworden (vermutlich nicht), dagegen wehren können sich aber bestimmt nicht. Wenn das so funktioniert, wie sich Google das vorstellt, bekommt die Google Suche über Now wieder eine ganz neue Funktion und Wichtigkeit und kann das händische Hin- und Herspringen zwischen Apps weitgehend beenden.

Chrome custom tabs

Google arbeitet weiter an der möglichst nahtlosen Verschmelzung von Apps und Webinhalten. Ein neuer Weg sind die custom tabs, die Apps in Chrome öffnen können. Dabei wird ein Webinhalt zwar außerhalb der aufrufenden App in Chrome geöffnet, aber die App ist in der Lage einen Teil ihres Brandings und auch ihrer Funktionen an Chrome zu übermitteln. Damit entsteht für Entwickler ein dritter Weg neben der einfachen Verlinkung und dem Aufbau eines eigenen, internen Browsers über eine Webview. Frage ist für mich aber, in wie weit das andere Browser wie Firefox ausschließt?

Android Pay

Das Google Wallet wird zu Android Pay und wird sich dann auch in den eigenen Apps verwenden lassen. Zusammen mit der neuen Fingerabdrucksensor API, die Android M bringt, macht dies den Eindruck, dass Google hier stark Apple Pay nacheifert. Aber hier in Europa wird davon wohl auf absehbare Zeit nicht viel ankommen.

Brillo und Weave: Googles Lösung für das Internet der Dinge

IoT ist gerade wieder aktuell und tatsächlich kommen ja auch jede Menge Produkte auf den Markt, die irgendwie ‘intelligent’ sind, die sich aber in jedem Fall vernetzen wollen. Und deren komplexe Funktionen von außen gesteuert werden wollen.

Google bietet mit Brillo nun ein abgespecktes Betriebssystem, welches von Android abgeleitet ist und daher bestimmte Funktionen wie Netzwerkstacks erben kann. Interessanter ist aber vielleicht aus Nutzersicht Weave, welches ein Protokoll ist, über das sich IoT Devices und die sie steuernden Geräte wie Smartphones austauschen können. So soll man offenbar mit einer einzigen Weave App auf seinem Smartphone alle entsprechenden Geräte steuern können, die dort ihre Fähigkeiten darstellen.

Wird Google hier etwas schaffen, was quasi schon jeder große Softwarehersteller in den letzten Jahren irgendwie mal versucht hat, aber bisher noch nie so richtig geklappt hat?

Google Photos

Für mich der interessanteste Punkt dieser Keynote: Die Kernideen, die ich an einem Fotodienst in der Cloud am meisten benötige, werden umgesetzt. Google bietet sich als verlässlicher Speicherdienst für ‘lebenslange’ Fotoarchivierungen an. Nun weis niemand, ob es Google in 20 oder 30 Jahren noch gibt und wenn ja, welche Ziele das Unternehmen dann verfolgt. Trotzdem ist das die Zusage, die man von seinem Cloud Anbieter hören will und sie muss sich glaubwürdig anhören. Ich fand sie glaubwürdig, vor allem, da sie von einer weitgehenden Aufhebung der bisherigen Beschränkungen / Grenzen beim gratis zur Verfügung gestellten Speichervolumen begleitet wurde.

Natürlich will man die Bilder immer auf allen Geräten verfügbar haben. Hier gibt es sowohl in der neuen App wie auch in der Webdarstellung einige coole Interfaceideen und neue Gesten, die einem den Umgang mit seinen Bildmassen deutlich zu vereinfachen scheinen. Und schließlich die Suche und Gruppierung: Hier treten die Verbesserungen in der Bilderkennung durch das maschinelle Lernen klar zutage, Google kann inzwischen ein weites Feld von Begriffen / Dingen in Bildern erkennen und kategorisieren.

Das klappt nicht zu 100%, aber das ist auch nicht entscheidend: Zum einen wird sich dies weiter verbessern, zum anderen reicht es mir wenn die Suche nach ‘Pferd’ mir Bilder von Pferden zeigt, ein paar falsch klassifizierte Hundebilder sind da egal. Auf diese Weise kann man in den Datenhalden, die man in den vergangenen Jahren angehäuft hat, endlich wieder schnell die Bilder finden, die man gerade sucht, und das ohne aufwändige Verschlagwortung oder manuelle Einsortierung in irgendwelche Ordner.

Die neue App kam unmittelbar nach der Keynote an, so dass man gleich damit herumspielen konnte.

Cardboard und Jump

Die Papp-3D-Brille von der letzten Google I/O nahm einen überraschend großen Teil der I/O in Anspruch: Google nimmt die Sache, die zuerst wie ein Gimmick erschien, offenbar weiterhin sehr ernst. So gibt es nun eine Neuauflage, die auch große Smartphones aufnehmen kann und mit dem iPhone zusammenarbeitet, und ein merkwürdiges, ergänzendes Produkt: Jump.

Jump ist ein Weg um mit Hilfe von Google 360 Grad Videos erstellen, verarbeiten und veröffentlichen zu können und damit ein Lieferant für Inhalte, die Cardboard oder andere VR Lösungen erst interessant machen. Jump hat drei Bestandteile: Das erste ist im Grunde nur ein Bauplan, den Google zur Verfügung stellt, und der beschreibt wie man 16 Kameras anzuordnen hat, damit deren gleichzeitige Aufnahmen ein 360 Grad Bild ergeben und die spätere Verarbeitung möglich wird. GoPro wird schon ein fertiges Gerät anbieten, aber offenbar könnte sich im Prinzip jeder so etwas zusammenbauen. Google wird z. B. Steuerungsdateien für 3D Drucker veröffentlichen, die den Halter für die Kameras erzeugen.

Danach kommt die Verarbeitung: Aus den 16 Kamerafeeds muss eine 360 Grad Aufnahme samt Tiefeninformation und allen möglichen Blickpunkten synthetisiert werden. Hier bringt Google seine riesigen Rechenzentren ein, die diese Arbeit übernehmen sollen, und die Algorithmen, die all die komplizierten Transformationen durchführen. Schließlich muss das Endprodukt irgendwo abrufbar werden. Dazu dient natürlich YouTube und die entsprechenden Apps, die man dann in Cardboard nutzen kann.

In der Keynote wurde als denkbares Einsatzszenario der Schulbereich genannt, so könnte eine Klasse auf diese Weise tatsächlich zwischen den Gletschern in Grönland umherwandern, an statt sich nur eine flache Projektion anzusehen (aber wer bezahlt die teuren Smartphones?).

Zahlen, Zahlen, Zahlen

Viele Produkte wurde nur gestreift, dafür dann aber mit Zahlen um sich geworfen: 17 Millionen Chromecasts verkauft, für die 1,5 Milliarden Mal der Cast Button angeworfen wurde; eine Milliarde täglicher Android Nutzer; 1 Million Cardboards; so und so viele Android Wear Watches und Watchfaces; so und so viele Autohersteller, die bei Android Auto mitmachen; 50 Milliarden App Downloads im vergangenen Jahr (aber keine Zahl zu den generierten Umsätzen im Play Store).

Die nächste Milliarde Internetbenutzer

Ein wiederkehrendes Thema war die Frage, wie die Reichweite des Internets erhöht wird. Sei es durch Loom, die Ballone, die nicht verkabelten Regionen ein Funknetz bringen sollen; seien es günstige Android Smartphones, die für viele Menschen der erste (und vielleicht einzige) Computer sein werden, mit dem sie ins Netz gehen.

Hardware

Abgesehen von der neuen Cardboard Version und dem skurilen Kameraarray gab es da nichts. Weder ein Chromecast II noch neue Chromebooks und erst recht keine Nexus Geräte.

Programmierung

Konkrete Themen für die anwesenden EntwicklerInnen wurden hier nur gestreift, die Vertiefung kommt dann später in den Sessions. Da gab es Dinge wie die nächste Version von Android Studio, die nun auch sehr umfangreiche Unterstützung für C/C++ Entwicklung mitbringt; Polymer 1.0 ist da; Android M natürlich.

Fazit

Keine ganz so atemlose, überladene Veranstaltungen wie in früheren Jahren, aber trotzdem schön und anregend.