Security in Android 12

Im ersten Teil dieser Blogserie wurden die neuen Features im Kontext von Design sowie Benutzererlebnis evaluiert und bewertet, die zum Großteil sehr gelungen umgesetzt worden sind und die sowohl für den Endnutzer als auch für den Entwickler deutliche Mehrwerte schaffen.

In diesem Teil geht es um wichtige Änderungen und Innovationen in den Bereichen Performance, Security und Privacy sowie um die Themen Nachvollziehbarkeit und das performante Durchführen von Multimediaanwendungen, die in den Vordergrund gestellt werden und mit denen vor allem Endnutzer angesprochen werden sollen.

Aufgrund der fortgeschrittenen Beta-Phase lohnt es sich, einige der neuen Funktionalitäten und APIs, die in diesem Blogbeitrag sowohl aus Entwickler- als auch aus Nutzersicht erörtert werden, genauer zu betrachten.

Beginnend mit Android 12 wurde die Performance Class eingeführt, mit der Entwickler die Leistungsfähigkeit eines Endgeräts klassifizieren können. Über die Performance Class kann bestimmt werden, ob das jeweilige Endgerät die Mindestanforderungen für die Nutzung bestimmter zusätzlicher Gerätefunktionen in der entsprechenden Android-Version erfüllt.

Mit jeder nachfolgenden erscheinenden Android-Version wird die Performance Class entsprechend inkrementiert, sodass abhängig von der Geräteleistung das bestmögliche Benutzererlebnis für den Nutzer zur Verfügung gestellt werden kann.

Ein Update auf eine höhere Android-Version muss somit nicht automatisch mit dem Erreichen der höheren Performance Class korrelieren. Die Anforderungen werden an die Videowiedergabefunktionen, Aufnahmefunktionalitäten und Bildschirmauflösung sowie Arbeitsspeicher und Lese-/Schreibgeschwindigkeit gestellt.
Eine Anfrage bezüglich der Erreichung einer Performance Class kann simpel abgefragt werden.

Das Privacy Dashboard listet dem Nutzer einen Verlauf auf, welche Apps zu welchem Zeitpunkt und wie oft bestimmte Funktionalitäten, beispielsweise Kamera oder Mikrofon, genutzt wurden. Über diese Screens kann der Nutzer dann auch bestimmte Rechte für eine App verwehren.

Das Privacy Dashboard ist ein sehr gutes Feature für den Endnutzer, um nachvollziehen zu können, wann welche Funktionalitäten tatsächlich verwendet wurden. Weiterhin wird dem Nutzer oben rechts in der Statusbar ein entsprechendes Icon angezeigt, falls eine App die Kamera oder das Mikrophon verwendet. Zudem kann über das Quick Settings-Menü der Zugriff auf die Kamera- und Mikrophonsensoren für das gesamte System deaktiviert werden.

Um die Privatsphäre von Nutzern zu stärken, können Apps mit targedSDK=S kompiliert werden, wodurch die App die Lokalisierung nur über eine ungefähre statt einer präzisen Standortermittlung vornehmen kann.

Viele Apps, wie beispielsweise Wetter-Apps, benötigen keinen exakten Standort des Nutzers, um eine Wettervorhersage zur Verfügung zu stellen.

Während Anfragen auf den ungefähren Standort (ACCESS_COARSE_LOCATION) einzeln möglich sind, müssen Entwickler ab sofort, sobald sie eine präzise Standortermittlung (ACCESS_FINE_LOCATION) anfragen möchten, gleichzeitig immer die Anfrage für eine ungefähre Standortermittlung mitsenden – andernfalls erhalten sie folgende Fehlermeldung beim Kompilieren im Logcat: ACCESS_FINE_LOCATION must be requested with ACCESS_COARSE_LOCATION.

Aus Nutzersicht ist diese Restriktion hervorragend, weil in den allermeisten Fällen lediglich der ungefähre Standort benötigt wird.

Ab Android 12 wurden drei neue Bluetooth-Rechte zum Interagieren mit anderen Bluetooth-Geräten in der Nähe hinzugefügt. Hierdurch muss keine Anfrage mehr zur Standortbestimmung durchgeführt werden.

Anhand folgender Anwendungsfälle können die Rechte angefragt werden:

Die granulare Aufteilung der Bluetooth-Rechte verbessert die Nachvollziehbarkeit der Zugriffsrechte nach dem Motto: so wenig wie möglich und so viel wie nötig.