Mittlerweile dürfte es sich herumgesprochen haben: Unter dem Namen "Material You" verpasst Google seinem mobilen Betriebssystem derzeit gerade eine optische Generalüberholung. Das ist auffällig und wird in den kommenden Wochen – wie es sich für jede Designänderung gehört – unzweifelhaft noch für angeregte Diskussionen sorgen. Doch darum soll es im Folgenden nicht gehen. Denn Android 12 bringt auch eine Fülle an Verbesserungen bei der Softwarebasis mit sich – von Fortschritten in puncto Privatsphäre und Sicherheit über Schnittstellen bis zu Umbauten, die flottere und längere Updates versprechen.
All das soll in Folge gesondert und in gewohnte Ausführlichkeit unter die Lupe genommen werden – sind das doch auch jene Änderungen, die wirklich alle Android-User betreffen, egal welchen Smartphone-Hersteller sie gewählt haben, während Oberflächliches von vielen Anbietern gerne noch einmal komplett umgestaltet wird. Doch keine Angst: Material You und Co sollen natürlich ebenfalls ausführlich gewürdigt, werden, aber eben erst im eigentlichen Test von Android 12, der zu einem späteren Zeitpunkt folgen wird.
Privatsphäre
Ein Bereich, dem sowohl Google als auch Apple in den vergangenen Jahren besondere Aufmerksamkeit haben zukommen lassen, ist die Privatsphäre. Zahlreiche Verschärfungen haben dazu geführt, dass es für Apps heutzutage erheblich schwerer geworden ist, unbemerkt sensible Daten zu sammeln. Insofern ist es keine große Überraschung, dass auch Android 12 in dieser Hinsicht wieder einiges zu bieten hat.
Transparenz ist essenziell
Mit der neuen Softwareversion führt Google ein "Privacy Dashboard" ein. Dieses kann über die Systemeinstellungen erreicht werden und liefert detaillierte Informationen dazu, welche App in den vergangenen 24 Stunden wann auf welche Berechtigung zugegriffen hat. Bei Standort, Mikrofon und Kamera wird das in einer Timeline verzeichnet; wer will, kann sich aber auch die diesbezüglichen Aktivitäten von Systemdiensten anzeigen lassen. All das versehen mit der Möglichkeit, den Apps dann auch gleich die Berechtigung zu entziehen, wenn einem etwas suspekt ist.
In Fragen Transparenz ist das Privacy Dashboard also ein großer Fortschritt, trotzdem wünscht man sich schnell die eine oder andere Erweiterung für dieses Feature. So ist der Zeitraum von 24 Stunden doch recht kurz gewählt. Und auch bei den Berechtigungen jenseits von Standort, Mikrofon und Kamera könnte es noch mehr Details geben. Bei diesen wird nämlich nur dargestellt, ob ein App innerhalb des letzten Tages Zugriff hatte, aber nicht, wann oder wie oft.
Ein anderes Defizit dürfte sich hingegen mit der Zeit von selbst lösen, nämlich das man bislang zwar sieht, dass eine App den Standort nutzt, aber nicht, warum. Gibt Google doch Apps die Möglichkeit, hier erklärende Informationen anzufügen – das müssen diese aber natürlich erst implementieren. Das wäre aber durchaus im Interesse der App-Entwickler, um zu verhindern, dass Berechtigungsanfragen missverstanden werden.
Warnung und Blockade
Mit den vergangenen Android-Updates gab es bereits einige Beschränkungen für den Zugriff auf Kamera und Mikrofon, mit Android 12 macht man all das noch mal expliziter. So gibt es nun – ähnlich wie bei iOS 14 – Indikatoren, die im Statusbereich anzeigen, wenn auf eine dieser beiden Komponenten zugegriffen wird. Dabei gibt es zunächst ein farblich gekennzeichnetes Icon, das sich nach ein paar Sekunden in einen kleinen Punkt verwandelt. Zudem lässt sich über einen Touch darauf schnell herausfinden, welche App dafür verantwortlich ist, und dieser gegebenenfalls die entsprechende Berechtigung entziehen.
Wem das noch nicht reicht, für den hat Android 12 aber noch eine andere Option im Angebot. Es ist nun nämlich möglich, den Zugriff auf Kamera und Mikrofon systemweit zu blockieren. Entsprechende Optionen finden sich unter anderem in den Schnelleinstellungen. Die Umsetzung ist dabei durchaus clever gewählt, werden Apps in so einem Fall doch schlicht leere Daten weitergeleitet. Braucht eine App tatsächlich einen Zugriff – etwa die Kamera-App –, dann wird ein Systemdialog angezeigt, der den Nutzern die Möglichkeit gibt, diese Sperre aufzuheben.
Nicht alle müssen wissen, wo man wohnt
Auch im Hinblick auf die Standortberechtigung schaut sich Google einen Trick vom Konkurrenzsystem iOS ab: Künftig können die Nutzer nämlich selbst bestimmen, ob eine App Zugriff auf den exakten oder nur den ungefähren Standort erhält. Klingt nach einem Detail, ist aber ein wichtiger Schritt gegen Bewegungsprofile, wie sie leider von manchen Apps erstellt und dann gewinnbringend gehandelt werden. Wenn die App nur ungefähr weiß, wo sich eine Person befindet – also etwa in welchem Stadtviertel –, taugt das nicht für detaillierte Analysen zum Nutzerverhalten.
Gleichzeitig benötigen viele Apps, die die Standortberechtigung einfordern, gar nicht den genauen Standort der User. Für eine Wetter-App, die automatisch anzeigt, wie das Wetter in der Umgebung ist, reicht etwa eine ungefähre Verortung allemal. Bei Fitness- oder Navigations-Apps ist das natürlich anders, aber diese machen eben nur einen Teil jener Programme aus, die die entsprechende Berechtigung anfordern.
Für die Nutzer sieht das so aus, dass sie künftig von Apps im entsprechenden Berechtigungsdialog zusätzlich gefragt werden, welche Standortpräzision sie zur Verfügung stellen wollen. Generell gilt diese Regel zunächst einmal nur für jene Apps, die Android 12 als Zielversion anvisieren – was derzeit natürlich noch sehr wenige tun. Trotzdem sollten App-Entwickler sich besser früher als später auf die neue Situation einstellen. Denn nachträglich entziehen können die User den Zugriff auf den exakten Standort nach dem Update auf Android 12 bei allen Apps. Darauf sollten die Programme vorbereitet sein, um etwaige Probleme zu verhindern. Noch besser ist es natürlich, wenn Apps, die das nicht notwendig haben, gar nicht nach dem exakten Standort fragen, dann entfällt auch dieses Entscheidung für die User.
Eine verwirrende Kombination
Es ist ein Verhalten, das in der Vergangenheit immer wieder für Diskussionen gesorgt hat: Unter Android ist für das Scannen nach und das Verbinden mit Bluetooth-Geräten die Zustimmung zur Standortberechtigung notwendig. Was zu allerlei Spekulationen über vermeintlich böse Absichten geführt hat, entspringt in Wirklichkeit einem Privacy-Gedanken: Da es über solche Scans theoretisch möglich ist, den Standort der Nutzer zu bestimmen – etwa wenn die Position von Bluetooth-Geräten im Umfeld bekannt ist –, hat Google diese Kombination als eine Art Warnung vorgenommen. Dass gut gemeint und gut nicht dieselben Dinge sind, stellte sich dann im Vorjahr heraus, als genau dieser Umstand dazu führte, dass viele Nutzer erschreckt feststellen mussten, dass die Contact-Tracing-Apps unter Android vermeintlich nur mit Zugriff auf den Standort funktionieren.
Auf dieses Missverständnis reagierte Google damals recht flott und machte eine explizite Ausnahme für Contact-Tracing-Apps; mit Android 12 geht man auf dieses Problem nun aber genereller ein. Unter dem Namen "Nearby Devices" wird eine neue Berechtigung eingeführt, die speziell für Suche und Kontaktaufnahme mit externen Geräten gedacht ist. Google betont dabei, dass dies ausschließlich für die erwähnten Zwecke benutzt werden darf – wer auf diesem Weg den Standort bestimmen will, muss also weiterhin auch die entsprechende Berechtigung anfordern.
Eine Anmerkung: Wer sich wundert, dass nach dem Update auf Android 12 eine Fülle von Apps automatisch die "Nearby Devices"-Berechtigung erhalten haben: Dafür gibt es eine gute Erklärung. Da die neue Berechtigung aus einer früheren herausgesplittet wurde, soll durch die automatische Vergabe garantiert werden, dass es keine Probleme mit älteren Apps gibt. Erst wenn App-Entwickler ihre Programme an die neue Android-Generation anpassen, wird diese Liste also schrumpfen.
Aufräumen im Tiefschlaf
Unter dem Namen "App Hibernation" widmet sich Google dem Thema lange nicht mehr verwendeter Apps. Genau genommen handelt es sich dabei um die Weiterführung einer Neuerung von Android 11: Seit damals werden Programmen nach einigen Monaten ohne aktive Nutzung sämtliche Berechtigungen entzogen. Mit Android 12 werden die Möglichkeiten entsprechender Apps noch weiter beschränkt, sie werden quasi in eine Art Tiefschlaf versetzt. Das heißt, dass sie generell auch im Hintergrund nicht mehr aktiv sein dürfen; selbst Benachrichtigungen mit hoher Priorität kommen dann nicht mehr durch. Zudem werden alle Caches automatisch gelöscht, um den Platzverbrauch auf dem lokalen Speicher zu minimieren. Aufgehoben werden all diese Beschränkungen, wenn die Nutzer die App wieder einmal aktiv aufrufen. Zudem ist es möglich, Apps gezielt von diesem Mechanismus auszunehmen.
Eine weitere von der Apple-Welt abgeschaute Verbesserung: Künftig zeigt Android immer an, wenn eine App auf den Zwischenspeicher zugreift, um Daten auszulesen. Eine ähnliche Funktion in iOS 14 hatte hier einiges seltsames Verhalten von Apps ausgewiesen. Betont sei, dass es dabei nur um im Vordergrund befindliche Programme geht. Der Zugriff auf den Zwischenspeicher von gerade nicht aktiv genutzten Apps wird unter Android schon länger generell blockiert. Dass dafür sogenannte "Toast"-Nachrichten zum Einsatz kommen, die kurz über das restliche Geschehen geblendet werden, ergibt sich gut – gibt es doch auch bei diesen eine wichtige Neuerung: Ab sofort wird bei solchen Nachrichten nämlich über das zugehörige Icon klargemacht, von welchem Programm sie stammen.
Wider die Sensorenspionage
Smartphones beinhalten eine Fülle unterschiedlicher Sensoren. Das eröffnet Apps allerlei Möglichkeiten, birgt aber auch – oftmals unterschätzte – Datenschutzprobleme. Denn wie Sicherheitsforscher in der Vergangenheit mehrfach demonstriert haben, lassen sich über den Zugriff auf vermeintlich harmlose Sensorenwerte Rückschlüsse auf ganz andere Informationen ziehen – eine sogenannte Seitenkanalattacke. Mit Android 12 beschränkt Google nun von Haus aus die Frequenz, mit der Daten von Gyroskop, Beschleunigungssensor und Co abgefragt werden können, auf 200 Hz. Apps, die einen umfassenderen Zugriff haben wollen, müssen die neu geschaffene "High_Sampling_Rate_Sensors"-Berechtigung abfragen. Diese wird zwar erteilt, ohne dass die Nutzer zustimmen müssen, trotzdem wird damit ein entsprechender Zugriff transparent und kann im Fall eines Missbrauchs auch leichter geahndet werden.
Eine kleine Anmerkung Googles macht dann auch klar, worum es hier konkret geht: Blockieren die Nutzer – wie oben beschrieben – systemweit den Zugriff auf das Mikrofon, wird die Sensorenabfrage nämlich generell auf die erwähnten 200 Hz beschränkt – also auch für Apps, die etwas anderes anfordern. Ab 400 Hz wäre es nämlich theoretisch möglich, Sprache zu reproduzieren – ganz ohne Zugriff auf das eigentliche Mikrofon.
Ein Hochsicherheitsbereich für sensible Aufgaben
Mag das Privacy Dashboard auch die sichtbarste Privatsphärenverbesserung in Android 12 sein – strukturell ist eine andere Neuerung noch erheblich wichtiger: Unter dem Namen "Private Compute Core" (PCC) schafft Google einen eigenen, vom restlichen Android-System strikt getrennten Hochsicherheitsbereich. Dieser ist für die Abwicklung aus einer Datenschutzsicht besonders sensibler Aufgaben zuständig. Dazu zählt man zuvorderst alles, was mit lokalem Maschinenlernen zu tun hat, von smarten Vorschlägen für die Tastatur über die automatische Erkennung von Musik im Umfeld des Smartphones bis zur Erstellung von Untertiteln für beliebige Inhalte.
Die Idee dahinter: Apps können entsprechende Aufgaben im PCC abwickeln lassen, um damit automatisch gewisse Datenschutzgarantien abgeben zu können. Denn die Möglichkeiten dieses Bereichs sind in vielerlei Hinsicht beschränkt: So hat er etwa keinerlei Zugriff auf das Netzwerk, es können also bei der Verarbeitung auch keine Daten weitergeleitet werden. Die Ergebnisse der dort vorgenommenen Berechnungen werden dann über fixe Schnittstellen an die jeweiligen Apps und Services weitergegeben. Vom Namen sollte man sich dabei übrigens nicht irritieren lassen, es handelt sich hierbei um keine neue Hardwarekomponente, sondern um einen Softwareansatz. Zudem ist der PCC natürlich Open Source, Experten können also den Quellcode prüfen, um zu sehen, dass die abgegebenen Versprechen auch wirklich eingehalten wird.
Virtualisierung am Smartphone
Mindestens so interessant wie das generelle Konzept ist dessen technische Umsetzung, zu der Mishaal Rahman von XDA Developers allerlei Details gefunden hat. Beim Private Compute Core handelt es sich demnach um eine Protected Kernel-based Virtual Machine (PKVM), es läuft hier also tatsächlich eine vollständige virtuelle Maschine, wie man es sonst eher aus dem Desktop- oder Server-Bereich kennt auf dem Smartphone.
In dieser virtuellen Maschine selbst läuft dann wiederum eine stark abgespeckte Version von Android, die sich Microdroid nennt. Zur Verwaltung nutzt man ein von Google selbst entwickelt Tool namens CrosVM, das ursprünglich für Googles anderes große Betriebssystem, Chrome OS, entwickelt wurde und dort für den Linux- sowie Android-Support zum Einsatz. CrosVM wurde von Grund auf mit einem Fokus auf Sicherheit entwickelt, Google hat zu diesem Zweck etwa Mozillas Programmiersprache Rust genutzt – aber zu dieser später noch mehr.
Generell sei betont, dass der PCC intern bei Google für Android 12 noch als eine "Preview" verstanden wird und das oben Erwähnte zumindest bei bestehenden Smartphones derzeit noch nicht komplett umgesetzt ist. Auch soll das System mit Android 13 dann weiter ausgebaut werden. Trotz all dieser Einschränkungen sollte die Relevanz dieser Neuerung nicht unterschätzt werden – hat Google damit doch in Fragen Privacy und vor allem Transparenz einen Punkt gefunden, mit dem man Apple etwas voraus hat. Vor allem aber schafft man damit auch die Grundlage für die Schaffung neuer, an die Nutzer angepasster Dienste, ohne Datenschutzbedenken einfach nur mit "Vertraut uns" wegwischen zu müssen.
Privacy Labels: Kommen
Nur am Rande seien noch zwei weitere Privacy-Themen erwähnt, einfach weil sie genau genommen nicht direkt mit Android 12 zusammenhängen, sondern über Policy-Änderungen vorgenommen werden – und doch allgemeine Relevanz haben. Jene Privacy-Labels, die Apple vor einigen Monaten eingeführt hat und die im App Store Informationen zur Datennutzung einzelner Apps liefern, wird Google weitgehend kopieren. Ein entsprechendes System soll bis Ende des Jahre eingeführt und dann bis April 2022 für alle verpflichtend werden. Google will diesen Ansatz mit Angaben zur Sicherheit der Apps sogar noch weiter ausbauen.
Anti-Tracking: So halb schon mit dabei
Schweigen im Walde herrscht hingegen bei einem anderen, viel diskutierten Thema der vergangenen Monaten: bei jener App Tracking Transparency (ATT), mit der Apple seit Anfang des Jahres App-Hersteller dazu zwingt, von den Nutzern explizit eine Berechtigung einzuholen, wenn sie App-übergreifend tracken wollen. Wann und ob Google hier eine entsprechende Lösung einführen wird, bleibt derzeit also komplett unklar.
Das liegt nicht zuletzt daran, dass sich der Softwarehersteller in einer durchaus vertrackten Situation befindet. Immerhin ist Google nicht nur Android-Hersteller, sondern auch der weltgrößte Anbieter von Online-Werbung. Und zwar einer, der von einer reduzierten Nutzung der Android Advertising ID, um die es hier geht, sogar noch profitieren könnte. Erhält man doch dank der eigenen, viel genutzten Services wie Gmail, Google Maps und Co sehr viele Daten von den Nutzern selbst, ist also von App-übergreifendem Tracking erheblich weniger abhängig als andere Werbeanbieter.
Mit einer Lösung analog zur ATT von Apple würde sich das Unternehmen entsprechend mit hoher Wahrscheinlichkeit in die kartellrechtliche Bredouille bringen. Zumindest wenn diese nicht mit weiteren Begleitmaßnahmen einhergeht. Wer diese Einschätzung für überzogen hält, der sei auf die Situation rund um den Browser Chrome und die Deaktivierung von Third Party Cookies hingewiesen, wo exakt das passiert ist. Die diesbezüglichen Pläne wurden nicht zuletzt nach Klagsdrohungen und öffentlicher Kritik aus mehreren Richtungen um Jahre verschoben.
Damit es hier keine Missverständnisse gibt: Es braucht natürlich niemand Mitleid mit Google zu haben. Das Unternehmen hat sich über seine marktbeherrschende Situation schon ganz alleine in diese Zwickmühle gebracht, und es wird auch irgendwie einen Ausweg finden. Für die Nutzer hingegen ist das wirklich unerfreulich, weil sie so unter Android wohl noch etwas länger auf die Übernahme einer sinnvollen Privacy-Maßnahme aus der iOS-Welt warten müssen.
Echte Deaktivierung
Zumindest gibt es aber einen Ausweg – nämlich einfach die erwähnte Advertising ID komplett zu blockieren, das geht über die Privatsphäreneinstellungen. Die schlechte Nachricht: Bisher war das nur eine Empfehlung für Apps. Die gute: Mit Android 12 auf Pixel-Geräten ist es nun möglich, diese ID komplett zu entfernen. Die Advertising ID wird dabei einfach mit einer Reihe aus Nullen ersetzt, womit sie für individuelles Tracken unbrauchbar wird. Für sämtliche Android-Geräte – auch jene mit früheren Versionen – soll diese Änderung dann bis Anfang 2022 durchgesetzt werden.
Damit einher geht übrigens ein generelles Verbot, eindeutige Hardware-Identifikatoren mit privaten Daten der Nutzer oder zurücksetzbaren Identifikatoren zu verknüpfen. Es soll also verhindert werden, dass die Entwickler einfach andere Wege suchen, um einen eindeutigen digitalen Fingerabdruck der Nutzer zu erstellen. Apps, die sich daran nicht halten, riskieren einen Rauswurf aus dem Play Store.
Google übernimmt die Softwarekontrolle
Zeit, sich einem anderen Thema zu widmen: Unter dem Namen "Project Mainline" oder auch "Google Play System Updates" hat Google seit Android 10 damit begonnen, die Wartung einzelner Systembestandteile selbst zu übernehmen. Mit Android 12 nimmt man den bisher größten Brocken in diese Sammlung auf: die Android Runtime ART, die für die Ausführung so gut wie aller Apps zuständig ist und so eine zentrale Rolle im Android-System einnimmt. Dadurch kann Google künftig auf diesem Weg Fehlerbereinigungen gleichzeitig an sämtliche Android-Smartphones schicken – und zwar eben unabhängig von den Systemaktualisierungen der Hersteller. Noch wichtiger ist das aber für App-Entwickler, die bisher öfters mal mit kleinen Unterschieden – oder nicht geschlossenen Bugs – in der ART-Implementation einzelner Anbieter zu kämpfen haben.
Das Ganze hat aber auch einen Nebeneffekt, der nicht allen gefallen wird. ART-Updates führen nämlich gerne dazu, dass sämtliche Apps neu "optimiert" werden müssen. Die Nutzer werden das je nach Gerät von unterschiedlichen Stellen im Systemaktualisierungsprozess kennen. In Zukunft kann dies also auch nach dem Einspielen von Play System Updates passieren und der nächste Neustart dann etwas länger dauern.
Ansonsten wurden einige andere Mainline-Module erweitert, neu aufgenommen wurde noch ein Modul für das Transkodieren von Medieninhalten, auch Virtualisierungskomponenten wie das zuvor erwähnte crosvm sollen künftig über Play System Updates auf dem laufenden gehalten werden.
Achtung, Achtung: Ein gemeinsamer Linux-Kernel kommt
Doch all das ist eigentlich Kleinkram im Vergleich zu einer weiteren Neuerung: Künftig soll nämlich auch der Linux-Kernel für sämtliche Geräte zentral von Google gepflegt werden. Das Ganze nennt sich "Generic Kernel Image" (GKI) und sieht – vereinfacht gesagt – so aus: Google schnürt einen relativ schlanken Kernel, zusätzliche Funktionalitäten sowie Treiber werden über Module geladen. Solche Module kommen zum Teil von Google selbst, aber auch von den Herstellern, die damit etwa spezifische Hardware oder zusätzliche Funktionalitäten unterstützen können.
Kern des gesamten Systems ist aber ein Versprechen, das Google in diesem Zusammenhang abgibt: nämlich API- und ABI-Stabilität, das heißt, dass sich die Schnittstellen durch Kernel-Updates nicht verändern, womit auch sämtliche Module und Treiber problemlos weiterfunktionieren sollen. Damit lassen sich diese Komponenten aber auch getrennt voneinander aktualisieren. Dies beseitigt einen wichtigen Flaschenhals in der Erstellung von Android-Updates – muss doch so bei Kernel-Fehlerbereinigungen nicht mehr auf die Treiberhersteller gewartet werden. Zudem bereitet dies den Weg für geräteübergreifende Treiber-Updates via Play Store.
Doch es gibt noch einen weiteren entscheidenden Vorteil – steht doch der Name generisch nicht zufällig im Kernel. Ist es bisher so, dass praktisch jedes Android-Gerät mit einem eigenen Kernel läuft, soll es künftig für jede Android-Generation nur mehr ein paar unterschiedliche GKIs geben. Natürlich gibt es aber auch hier Beschränkungen. So garantiert Google die API/ABI-Stabilität nur innerhalb einer Generation des Linux-Kernels, große Versionssprünge wird es also – zumindest vorerst – auch weiterhin nicht geben. Zudem wird es unterschiedliche GKIs für unterschiedliche Android-Generationen geben.
Trotzdem ist das für die Android-Welt in mehrerlei Hinsicht ein großer Schritt. Sowohl die Smartphone- als auch die Chipsatzhersteller profitieren von einem massiv reduzierten Wartungsaufwand, denn sie müssen sich in Kernel-Angelegenheiten nur mehr um ihre Module kümmern. Die Nutzer wiederum dürfen sich über eine bessere Stabilität und Sicherheit in diesem Bereich freuen – sind doch viel Android-OEMs bislang notorisch schlecht im Nachziehen von Linux-Kernel-Updates.
Bleibt die Frage: Wenn all das wirklich einen dermaßen großen Fortschritt darstellt, warum wird das im Artikel nicht prominenter erwähnt? Weil es derzeit noch Zukunftsmusik ist. Der GKI soll nämlich erst bei Geräten, die bereits von Haus aus mit Android 12 ausgeliefert werden, zum Einsatz kommen. Für bestehende Smartphones, die jetzt ein Update erhalten, ändert sich hingegen nichts. Das heißt auch, dass aller Voraussicht nach Googles eigenes Pixel 6 das erste Smartphone mit einem GKI wird, und zwar gleich mit einer ungewohnt aktuellen Kernel-Generation – nämlich Linux 5.10. Ebenfalls noch unklar ist, in welchem Umfang die GKI-Nutzung bereits mit Android 12 verpflichtend wird, in der offiziellen Dokumentation dazu ist nur von "manchen Geräten" die Rede.
Sicherheit
Kommen wir zum Bereich Sicherheit – und auch hier gibt es eine strukturelle Verbesserung zu verkünden: Google forciert nun nämlich die Nutzung von Rust zur Entwicklung von sicherheitsrelevantem Code. Die ursprünglich von Mozilla entwickelte Programmiersprache erfreut sich aktuell stark steigender Beliebtheit, was vor allem einen Grund hat: In ihr geschriebener Code ist ähnliche flott wie in C bzw. C++ verfasste Programme, gleichzeitig ist das Ergebnis aber nicht für Speicherfehler anfällig. Durch ein Umschreiben in Rust kann man also gleich eine gesamte Klasse an Fehlern loswerden, und zwar jene, die aktuell für einen Großteil aller aufgespürten Sicherheitsschwachstellen in Android verantwortlich sind.
Natürlich geht so ein Umschreiben nicht von einem Tag auf den anderen, also nimmt sich Google zunächst einmal jene Komponenten vor, wo der Nutzen am größten ist. Mit Android 12 wurde etwa jener Keystore, in dem Verschlüsselungs-Keys gespeichert werde, komplett in Rust neu verfasst. Auch Teile des Bluetooth-Stacks wurden bereits neu geschrieben, weitere Teile sollen dann für Android 13 folgen. Dabei steht überhaupt alles, was mit Funk zu tun hat, weit oben auf der Prioritätenliste, immerhin eignet sich dies besonders gut für Angriffe von außen.
Vermischtes
Zu den weiteren Sicherheitsverschärfungen gehört ein veränderter Umgang mit Third-Party-Cookies im Android Webview, der unbeabsichtigte Datenweitergabe über Domains hinweg verhindern soll. Dabei geht es um jenes Same-Site-Attribut, das bei Chrome/Chromium schon jetzt zum Einsatz kommt. Eine weitere Beschränkung gibt es im Umgang mit Overlays, also Inhalten, die über das restliche Interface eingeblendet werden. Apps können dies nämlich nun generell blockieren, was sich etwa für Online-Banking-Apps anbietet, die sich bislang immer wieder mit solchen Tricks von Schadsoftware herumschlagen müssen, wenn die Nutzer allzu leichtfertig mächtige Berechtigungen erteilen.
Erweitert wurden die Möglichkeiten von Apps in Hinblick auf die Darstellung von Benachrichtigungen am Lockscreen. So können sie nun etwa verhindern, dass Benachrichtigungen von nicht authentifizierten Nutzern weggewischt werden können. Sicherheitsrelevant ist dies, weil sonst jemand eine wichtige Warnung verstecken könnte. Eine Beschränkung gibt es hingegen in Hinblick auf Systemdialoge: Apps können diese nun nur mehr in wenigen Ausnahmefällen schließen.
Problematische Back-ups
Eine weitere Änderung, wird so manchen Nutzern hingegen weniger gut gefallen: Der "adb backup"-Befehl mit dem bislang über die Kommandozeile vom PC aus ein umfassendes Back-up der Daten erstellt werden konnte, wird massiv beschränkt. Und zwar so, dass die Sicherung von Nutzerdaten nur mehr dann erlaubt ist, wenn die jeweiligen Apps dies explizit zulassen.
Einen offiziellen Grund dafür nennt Google nicht. Allerdings kann man sich den auch selbst zusammenreimen. Einerseits hatten Sicherheitsexperten immer wieder kritisiert, dass "adb backup" zu mächtig ist, falls mal jemand Zugriff auf das Smartphone bekommt. Und dann wäre da noch der Umstand, dass vor einigen Monaten aufgeflogen ist, dass die Spionagefirma Cellebrite nach einem erfolgreichen Einbruch auf Android-Smartphones kurzerhand "adb backup" benutzt, um ein vollständiges Abbild aller Daten für die forensische Auswertung zu erhalten.
Doch auch sonst gibt es Neuerungen in diesem Bereich: Schon bisher können Apps festlegen, ob ihre Daten von Back-ups ausgenommen werden sollen. Mit Android 12 ist es nun möglich, zwischen der Sicherung im Google Drive und dem direkten Überspielen auf ein anderes Gerät zu unterscheiden.
Performance
Zu behaupten, dass die eigene Software mit einer neuen Version schneller geworden ist, gehört irgendwie zum guten Ton von größeren Updates. Das ist auch bei Android 12 nicht anders, zumindest liefert Google dieses Mal aber konkrete Zahlen. Eine Fülle unterschiedlicher Optimierungen sollen dafür sorgen, dass die Kernsystemdienste von Android 22 Prozent weniger CPU-Zeit verbrauchen. Das soll sich ebenso positiv auf die Akkulaufzeit auswirken wie der Umstand, dass der System Server von Android nun im Schnitt um 15 Prozent seltener auf die großen Prozessorkerne zugreift.
Außerdem soll Binder, das bei Android für die Interprozesskommunikation zuständig ist, im Schnitt nun doppelt so flott arbeiten, bei einzelnen Aufgaben – konkret dem Aufheben von Wake Locks – soll die Steigerung sogar Faktor 15 bedeuten. Und auch für Maschinenlernaufgaben gab es viele Performance-Optimierungen. All das soll in Summe dazu führen, dass Smartphones mit Android 12 an vielen Stellen schneller und stromsparender sind, wobei sich die Vorteile vor allem bei schwächeren Geräten zeigen sollen. Ehrlich muss man natürlich auch sagen: Ob man das wirklich merkt, hängt sehr vom eigenen Nutzungsszenario ab.
Manchen Android-Usern wird schon aufgefallen sein, dass es beim Anwählen einer Benachrichtigung manchmal eine kurze Wartezeit gibt, bevor die zugehörige App gestartet wird. Das liegt daran, dass diese mit sogenannten "Trampolines" eine Art Zwischendienst zum Aufruf der App nutzen. Genau das wird nun verboten. Um das zu quantifizieren, betreibt Google quasi firmeninternes Shaming: Google Photos werde nach dieser Änderung von einer Benachrichtigung aus nun um 34 Prozent schneller geladen, heißt es.
Optimierungen für schnelle Geräte
Apropos: Unter dem Namen "Performance Class" gibt es künftig einen neuen Mindeststandard für besonders leistungsfähige Geräte. Die Idee dahinter ist, dass Apps abfragen können, ob Smartphones diesen erfüllen, und dann anspruchsvollere Funktionalitäten verwenden können. Was Teil dieses Standards ist, hat Google gemeinsam mit den Geräteherstellern ausbaldowert. Dazu zählen etwa Anforderungen in Hinblick auf Bildschirmauflösung, Schreib/Lese-Geschwindigkeit oder auch Kameraleistung. Die Liste an Mindestanforderungen sollen dabei für jede Android-Generation wieder gemeinsam neu festgelegt werden.
Dazu passend gibt es neue Schnittstellen für einen sogenannten "Game Mode", in dem die Nutzer selbst festlegen können, ob sie optimale Leistung oder doch lieber lange Akkulaufzeit haben wollen. Auch daran sollen sich Entwickler dann orientieren können. Das Ganze geht einher mit einem Game Dashboard, über das die Nutzer die notwendigen Einstellungen vornehmen können – aber dazu dann mehr im eigentlich Android-12-Test.
Akku schonen
Beim Stromsparen soll hingegen eine Nachbesserung bei "App Standby" helfen. Darüber werden Apps schon jetzt automatisch in verschiedene Kategorien mit unterschiedlichen Möglichkeiten eingeteilt, etwa wenig genutzt Programme immer weiter beschränkt. Nun gibt es hier einen neuen solchen "Bucket" namens "restricted". Wer dort landet, wird massiv beschränkt, die Auswahl erfolgt automatisch durch die Erkennung bestimmter Nutzungsmuster – viel genauer wird man in dieser Hinsicht leider nicht. Es klingt aber so, als wäre das eine Art Strafort für Apps, die über irgendwelche Tricks oder aufgrund von Bugs zu viele Ressourcen verbrauchen.
Apropos Beschränkungen: Apps, die einen exakten Zeitpunkt für das Aufwecken festlegen wollen, müssen dafür nun eine neue Berechtigung einholen. Das Ziel dabei ist, dass weniger Apps exakte Alarme anfragen, weil das schlecht für den Akkuverbrauch ist, da das Smartphone hierfür extra aufgeweckt werden muss. Üblicherweise übernimmt das ein Systemdienst, der alle anstehenden Aufgaben bündelt und so Strom spart. Google empfiehlt die Nutzung dieser Berechtigung also nur für Programme, für die exakte Zeitabläufe wirklich essenziell sind – also etwa Wecker oder Timer.
Eine weitere Maßnahmen zur Verlängerung der Akkulaufzeit: Für Android 12 entwickelte Apps dürfen nur mehr in wenigen Ausnahmefällen Vordergrunddienste starten, wenn sie selbst gerade nur im Hintergrund laufen. Auch hier verweist Google mit WorkManager auf einen Systemdienst, über den solche Anfragen koordiniert – und somit stromsparender – abgewickelt werden können.
Leichteres Leben für alternative App Stores
Wunder geschehen (oder: Kartellklagen wirken, je nachdem wie man es sehen will): Mit Android 12 macht Google alternativen App Stores das Leben in einem entscheidenden Punkt leichter. Künftig können diese nämlich Updates automatisch im Hintergrund einspielen und dabei auch mehrere Apps auf einmal aktualisieren, ohne jedes Mal die Genehmigung der Nutzer einzuholen.
Allerdings knüpft man dies an eine Bedingung: Die betreffenden Apps müssen mindestens API-Version 29 adressieren, was Android 10 entspricht. Damit will man garantieren, dass die Apps gewisse minimale Sicherheitsstandards erfüllen, die mit neuen Android-Generationen einhergehen. Ähnliche Regeln gibt es schon für den Play Store – nun dehnt man das auf gewisse Weise auf andere App Stores aus. Hier wie da soll diese Mindestanforderung natürlich jedes Jahr weiter angehoben werden.
Ein vollständiger Neuzugang in Android 12 nennt sich "App Search": Damit schafft Google die Basis für eine lokale Suchmaschine, die die Inhalte sämtlicher Apps durchforsten kann. Derzeit ist diese noch nicht – oder nur über Tricks – für die Nutzer verfügbar, es geht hier also zunächst um die Bereitstellung der notwendigen Infrastruktur. Natürlich bleibt es den Apps dabei überlassen, ob sie die eigenen Daten mit diesem systemweiten Index oder auch anderen Apps teilen wollen – oder eben nicht.
Bessere Zeiten für Foldables, Tablets und Co
Ein Problembereich bei Android bleibt die mangelhafte Unterstützung vieler Apps für Geräte mit größeren Displays. Mit Android 12 unternimmt man nun mit neuen Programmierschnittstellen und Softwarebibliotheken einen weiteren Anlauf, um den Entwicklern die entsprechenden Anpassungen möglichst einfach zu machen. All das mit dem Blick auf die wachsende Schar an Geräten mit größeren Displays – allen voran Chromebooks und faltbare Smartphones. Und selbst die lange von App-Entwicklern vernachlässigten Android-Tablets könnten davon profitieren.
Neue Schnittstellen aller Art
Die Kameras vieler aktueller Smartphones nutzen mittlerweile sogenannte Quad- oder Nona-Bayer-Sensoren, bei denen vier oder neun Bildpunkte am Sensor für ein Pixel im fertigen Bild kombiniert werden. Mit der neuen Softwaregeneration nimmt Google den Support dafür offiziell in sein Betriebssystem auf; dass ein entsprechender Sensor angeblich im kommenden Pixel 6 zu finden sein soll, ist dabei natürlich kein Zufall. Verbesserungen verspricht Google wiederum für die Unterstützung hochfrequenter Bildschirme. Der Wechsel zwischen verschiedenen Frequenzen soll nun auch innerhalb einzelner Apps nahtlos funktionieren.
Mit Android 12 führt Google neue Schnittstellen für das Einfügen unterschiedlicher Inhalte ein. Damit will man diese Vorgänge vereinheitlichen und so den App-Entwicklern Arbeit abnehmen. So ist es dabei egal, ob es um Text, Bilder oder Videos geht oder welcher Weg zum Kopieren gewählt wurde. Auch diese Änderung erfolgt nicht zuletzt mit dem Blick auf Foldables, wo Drag & Drop eine wichtigere Rolle spielt als bei Smartphones.
Multimedia
Einige Neuerungen gibt es wie gewohnt im Multimediabereich: Zuvorderst sei dabei die Unterstützung für das noch recht junge Bildformat AVIF (ein Abkömmling des Videocodes AV1) genannt. Das verspricht bessere Bildqualität bei kleineren Dateigrößen. Ebenfalls neu ist die Unterstützung für Bluetooth LE Audio sowie einer neuen Funktion namens Rendereffect. Diese gibt Apps einen einfachen Zugriff auf diverse grafische Effekte wie Blur oder auch Farbfilter, die dann auch miteinander kombiniert werden können.
Ebenfalls neu ist eine Systemdienst namens "Compatible Media Transcoding". Dieser führt eine automatische Umwandlung von HEVC-Inhalten – also mit dem H.265-Codec erstellten Videos – für Apps durch, die das nicht selbst unterstützen. Damit will man die Verbreitung von HEVC fördern und nicht zuletzt ermöglichen, dass die Kameras aktueller Smartphones dieses Format endlich von Haus aus nutzen und so platzsparender speichern.
Gerade für Spiele könnte eine andere Neuerung äußerst interessant sein: Es gibt nun nämlich die Möglichkeit, die Audioausgabe direkt mit haptischen Effekten – also dem Vibrationsmotor – zu koppeln. Doch auch andere Einsatzgebiete sind denkbar – etwa Videoanruf-Apps, die individuelle Vibrationsmuster für unterschiedliche Anrufer bieten.
Kleinigkeiten
Offizielle APIs gibt es nun für abgerundete Ecken. Was nach einem schlechten Witz klingt, hat durchaus einen relevanten Hintergrund: Geht es doch darum, dass durch solche grafischen Effekte keine relevanten Inhalte abgeschnitten werden – die Schnittstellen kümmern sich darum, und das natürlich im Einklang mit dem restlichen Smartphone-UI. Neue APIs gibt es zudem für sogenannte Companion Devices, also etwa Smartwatches oder Fitnesstracker. Diese sollen garantieren, dass hier die Verbindung nicht verloren geht, solange das entsprechende Gerät in der Nähe ist.
Geschichte ist dafür das für anspruchsvolle Grafikaufgaben mit Android 3.0 eingeführte Renderscript. Dieses gilt nun als offiziell veraltet, Google empfiehlt App-Entwicklern, für solche Anwendungsgebiete direkt auf die modernen Grafikschnittstellen von Vulkan zuzugreifen. Dieser Rat hat auch durchaus seinen guten Grund: Auf vielen aktuellen Geräten wird Renderscript nur mehr auf der CPU ausgeführt und nicht hardwarebeschleunigt auf der eigentlich dafür gedachten GPU. Anders gesagt: In der Praxis ist Vulkan heutzutage oftmals die erheblich flottere Wahl.
Arbeitsaufgaben
Was bleibt, sind all die aktuellen Neuerungen für den Unternehmensbereich – also Android Work. Dazu zählen Verbesserungen für das Festlegen einer minimalen Passwortkomplexität ebenso wie die Möglichkeit, für Administratoren auf Firmengeräten den USB-Zugriff auf das Laden zu beschränken. Für weitere Details sei in diesem Fall aber auf den entsprechenden Eintrag bei Google verwiesen.
Zeitablauf
Android 12 dürfte aller Voraussicht nach im Oktober erscheinen. Die für den Artikel herangezogene Beta-Version, war aber in Hinblick auf all die im Artikel erwähnten Punkte bereits identisch zur fertigen Version ist. Wie immer werden als erstes Googles eigene Pixel-Geräte – in dem Fall ab dem Pixel 3 – mit der neuen Softwaregeneration bedient, parallel dazu erfolgt dann die Freigabe des Quellcodes von Android 12. Wann andere Hersteller nachziehen, ist wie gewohnt noch unklar. Zumindest ist es ein positives Zeichen, dass sich einige Anbieter heuer mit eigenen Testversionen am Betaprogramm beteiligt haben. (Andreas Proschofsky, 22.8.2021)