Neues Jahr, neues Android. Wie gewohnt veröffentlicht Google auch in diesem Jahr ein frisches Update des beliebten mobilen Betriebssystems unter dem Namen Android 14, intern auch „Upside Down Cake“ genannt. Es ist der Nachfolger des im August 2022 veröffentlichten Android 13 und hat mit der im Juni 2023 veröffentlichten dritten Betaversion einen stabilen Stand erreicht. Die finale Version steht kurz vor Veröffentlichung (Stand Mitte August 2023) und wird traditionsgemäß zuerst auf den Pixel-Geräten von Google ausgerollt.
Android 14 ist für Entwickler:innen unter dem SDK- bzw. API-Level 34 verfügbar und bringt über 60 neue und aktualisierte Features mit sich. In diesem Blogbeitrag werden die wichtigsten Änderungen und Neuerungen des Android-Updates vorgestellt.
Die Rolle der targetSdkVersion bei einem Android-Update
Wenn eine neue Android-Version veröffentlicht wird, gibt es verschiedene Konstellationen, die man als App-Entwickler:in berücksichtigen muss. Dabei spielt die im Projekt definierte targetSdkVersion eine entscheidende Rolle. Sie gibt an, für welche Android-Version die App entwickelt und getestet wurde. Das bedeutet nicht, dass eine App, die für Android 13 entwickelt wurde und daher eine targetSdkVersion von 33 hat, nicht auch auf Android 14 funktioniert. Im Allgemeinen können Apps mit einer targetSdkVersion, die niedriger ist als der API-Level des Betriebssystems, auf dem sie installiert sind, ohne Probleme ausgeführt werden. Allerdings können solche Apps die neuen Features oder bestimmte Anpassungen der höheren SDK-Level nicht nutzen. Darüber hinaus kann es auch zu Verhaltensänderungen unter der neuen Android-Version kommen, die sich auf Apps auswirken, die noch eine niedrigere targetSdk-Version definiert haben. In diesem Fall sollten entsprechende Anpassungen vorgenommen werden, um unerwünschtes Verhalten zu vermeiden.
Daher gibt es zwei mögliche Szenarien, die bei einer neuen Android-Version zu berücksichtigen sind:
- Android-Version mit API-Level X und App mit targetSdkVersion < X
- Android-Version mit API-Level X und App mit targetSdkVersion X
Entwicklerinnen und Entwickler sollten sich daher vor jedem neuen Android-Release gut informieren, was in welcher Konstellation zu beachten ist, ihre App entsprechend testen, ob sie noch wie erwartet funktioniert und im besten Fall anpassen.
Änderungen für alle Apps unter Android 14
Im Folgenden werden die Verhaltensänderungen betrachtet, die sich auf alle Apps auswirken, wenn sie auf einem Endgerät mit Android 14 ausgeführt werden.
Kernfunktionalität (AlarmManager)
Der AlarmManager von Android wird in vielen Apps verwendet, um Aktionen zu einem bestimmten Zeitpunkt auszuführen, wie z. B. das Anzeigen von Notifications. Um diese Funktionalität nutzen zu können, muss die App die Berechtigung SCHEDULE_EXACT_ALARM in ihrem Manifest definiert haben. Bisher wurde dieses Recht bei der Installation automatisch vergeben. Unter Android 14 ändert sich dies für neu installierte Apps, die die targetSdkVersion 33 (Android 13) oder höher gesetzt haben. Die Berechtigung ist also standardmäßig verweigert und muss von den Nutzer:innen aktiv eingeholt werden.
Sicherheit (targetSdkVersion kleiner als 23)
Wenn eine App eine targetSdkVersion kleiner als 23 hat, also kleiner als Android 6, kann sie unter Android 14 nicht mehr installiert werden. Befindet sich die App jedoch zum Zeitpunkt des Systemupdates bereits auf dem Gerät, bleibt sie installiert. Hintergrund dieser Maßnahme ist, dass Malware-Apps häufig niedrigere API-Level verwenden, um Sicherheitsmechanismen und Maßnahmen zum Schutz der Privatsphäre zu umgehen, die erst auf einem höheren API-Level eingeführt wurden. Ein Beispiel hierfür ist die Einführung des Laufzeitberechtigungsmodells, das erst mit der Android-Version 6, also SDK-Level 23, ausgerollt wurde.
Benutzererfahrung (Medienzugriff, Fullscreen und Foreground Notifications)
Mit Android 13 wurden die Berechtigungen READ_MEDIA_IMAGES und READ_MEDIA_VIDEO eingeführt, um den Zugriff auf alle auf dem Gerät gespeicherten Fotos und/oder Videos zu beantragen.
Unter Android 14 ist es nun möglich, den Zugriff nur auf eine Teilmenge der Medien zu gewähren. Dazu gibt es im entsprechenden Dialog, mit dem der Zugriff beantragt wird, eine neue Auswahlmöglichkeit. Neben der Möglichkeit, die Anfrage abzulehnen und den Zugriff auf alle Bilder und/oder Videos zu erlauben, können nun auch nur bestimmte Dateien ausgewählt werden, für die eine Erlaubnis erteilt wird.
Für jede App kann die Berechtigung USE_FULL_SCREEN_INTENT verwendet werden, das bisher bei der Installation immer automatisch als erlaubt gesetzt wurde. Damit kann eine App jederzeit direkt sogenannte „Fullscreen Notifications“ anzeigen. Diese haben eine sehr hohe Priorität, können den gesamten Bildschirm einnehmen und auch bei einem gesperrten Gerät im Ruhezustand erscheinen.
Sinnvolle Beispiele hierfür sind Anrufe und Alarme. Ab Android 14 soll dieses Recht daher nur noch diesen Funktionen direkt bei der Installation zur Verfügung stehen. Apps, die diesem Profil nicht entsprechen, wird Ende 2023 die Standardberechtigung im Google Play Store entzogen. Es besteht jedoch weiterhin die Möglichkeit, dieses Feature zu nutzen, wenn die Nutzer:innen es manuell in den App-Einstellungen aktivieren.
Außerdem hat sich das Verhalten von „Foreground Notifications“ verändert, die bisher von den Nutzer:innen nicht entfernt werden konnten. Ein Beispiel dafür ist der Musikplayer, z.B. Spotify, wenn Musik aktiv abgespielt wird.
Unter Android 14 können diese Notifications nun entfernt werden. Es gibt jedoch Ausnahmen beziehungsweise Situationen, in denen das dennoch nicht möglich ist:
- Das Gerät ist gesperrt
- Der Button, welcher alle angezeigten Notifications löscht, wird gedrückt
- Notifications im CallStyle
- Notifications des Device Policy Controllers (DPCs)
Barrierefreiheit (Nichtlineare Schriftskalierung)
Ab Android 14 wird die nichtlineare Skalierung von Schriften bis zu 200 % unterstützt, um Nutzer:innen mit eingeschränktem Sehvermögen zusätzliche Möglichkeiten zur barrierefreien Nutzung von Apps zu bieten. Voraussetzung dafür ist die Verwendung von „scaled pixels“ (sp) für Texte in der App, um die in den Systemeinstellungen eingestellte Größe berücksichtigen zu können. Es wird empfohlen, UI-Tests mit maximaler Schriftgröße durchzuführen, um sicherzustellen, dass dies keinen Einfluss auf die Nutzbarkeit der App hat.
Änderungen für Apps mit Android 14 Support
Setzt man nun die targetSdkVersion auf 34 und führt die App auf einem Gerät mit Android 14 aus, so müssen sich Entwickler:innen auf weitere Verhaltensänderungen einstellen, die in diesem Kapitel beschrieben werden.
Kernfunktionalität (Foreground Services, Bluetooth-Berechtigung, Java 17)
Wenn eine Anwendung „Foreground Services“ verwendet, muss ab sofort mindestens ein Typ pro Service angegeben werden. Dieser Typ soll den Anwendungsfall der App repräsentieren, um die Intention der Services besser einordnen zu können. Beispiele sind connectedDevice, dataSync, location, mediaPlayback, microphone, etc. Features, die Bluetooth verwenden, könnten die Funktion „getProfileConnectionState()“ verwenden, um den Verbindungsstatus zu einem bestimmten Profil abzufragen.
Bisher konnte diese Funktion ohne Probleme aufgerufen werden, wenn nur das BLUETOOTH_CONNECT-Berechtigung im Android-Manifest definiert war. Nun wird aber auch eine aktive Erlaubnis dieser Berechtigung erwartet, um diese Funktion ausführen zu können.
Des Weiteren wurden mit dem neuen Update die Kernbibliotheken von Android auf die neueste OpenJDK LTS (Long-Term Support) Version aktualisiert. Damit unterstützt Android 14 nun auch Java 17. Entwickler:innen müssen vor allem die Kompatibilität ihrer App mit dem neuen Betriebssystem prüfen, wenn sie mit „Regular Expressions“ (java.util.regex.Matcher), UUIDs (java.util.UUID.fromString) oder ProGuard (java.lang.ClassValue) arbeiten.
Sicherheit (Senden von Intents, Broadcast Receiver)
Bei Apps, die implizite Intents an app-interne Komponenten (Activities) senden, wird dieses Verhalten nun durch eine geworfene Exception unterbunden.
Dies ist nur noch mit einem expliziten Intent möglich. Dazu muss im Intent entweder component oder package angegeben werden.
Eine alternative Lösung besteht darin, die App-Komponente als exportiert zu definieren. Diese Maßnahme soll verhindern, dass bösartige Apps implizite Intents abfangen, die nur für interne App-Komponenten bestimmt sind. Broadcast Receiver, die zur Laufzeit oder über den Kontext registriert werden, müssen nun in einem Flag angeben, ob sie zu allen Apps auf dem Gerät exportiert werden sollen oder nicht. Hierfür gibt es die vordefinierten Konstanten RECEIVER_EXPORTED und RECEIVER_NOT_EXPORTED, die dafür verwendet werden können. Eine Ausnahme sind „System Receiver“. Diese Receiver müssen dieses Flag nicht setzen, wenn sie registriert werden. Ein Beispiel für einen solchen Receiver ist das Empfangen, ob der Flugmodus gerade ein- oder ausgeschaltet wurde.
Neue Features für Apps mit Android 14 Support
Eine Anwendung mit targetSdk Version 34 kann jedoch auch auf neue Funktionalitäten zugreifen und diese nutzen. Diese neuen Funktionen werden im Folgenden vorgestellt.
Internationalisierung (Sprache pro App, Grammatical Inflection API, Regionale Einstellungen)
Mit Android 13 wurden die Spracheinstellungen pro App eingeführt. Das bedeutet, dass neben der Gerätesprache auch für jede einzelne App eine eigene Sprache in den Systemeinstellungen eingestellt werden kann (wenn die App mehrere Sprachen anbietet). Wenn also die Systemsprache Englisch ist und eine App in Englisch, Spanisch und Portugiesisch verfügbar ist, kann für diese App eine der beiden anderen Sprachen ausgewählt werden. Android 14 verbessert nun dieses neu eingeführte Feature für Entwickler:innen. Die benötigte LocaleConfig kann nun automatisch aus den Ressourcen erstellt werden und muss nicht mehr manuell hinzugefügt und konfiguriert werden. Auch um Updates der Konfiguration muss sich nicht mehr gekümmert werden.
Im Gegensatz zum Englischen ist Deutsch eine geschlechtsspezifische Sprache. Während es im Englischen den „Developer“ gibt, der sowohl männlich als auch weiblich sein kann, gibt es im Deutschen dafür zwei Wörter: Der Entwickler und die Entwicklerin. Weitere so genannte „Gendered Languages“ sind zum Beispiel Spanisch oder Italienisch. In vielen dieser Sprachen wird standardmäßig die männliche Grammatik verwendet, wenn das Geschlecht unbekannt ist oder von gemischten Gruppen gesprochen wird. Dies benachteiligt Frauen und kann unter Umständen negative Auswirkungen haben. Aus diesem Grund wird in Android 14 eine neue API namens „Grammatical Inflection API“ eingeführt, die es Entwickler:innen erlaubt, die Benutzererfahrung ihrer App ohne großes Refactoring zu verbessern, indem sie die Sprache der App personalisierter, natürlicher und geschlechtergerechter gestalten können. Um dies beispielsweise für die deutsche Sprache zu erreichen, legt man mehrere String-Dateien in verschiedenen Paketen nach einem bestimmten Schema an und stellt dort die verschiedenen Grammatikversionen zur Verfügung:
- res/values-de-feminine/strings.xml (weiblich)
- res/values-de-masculine/strings.xml (männlich)
- res/values-de-neuter/strings.xml (divers)
Die Funktion “setRequestedApplicationGrammaticalGender()“ ermöglicht es, das grammatikalische Geschlecht der Nutzer:innen entsprechend festzulegen.
Außerdem wird es im neuen Android-Release einen Bereich in den Systemeinstellungen geben, wo Nutzer:innen angeben können, welche Einheit sie zum Beispiel bei der Temperatur bevorzugen oder welcher Tag für sie der erste der Woche ist.
Entwickler:innen können diese Angaben dann für ihre Apps über APIs mit Funktionen wie „getTemperatureUnit()“ oder „getFirstDayOfWeek()“ verwenden und sich auch über einen Broadcast Receiver (ACTION_LOCALE_CHANGED) informieren lassen, wenn sich diese Angaben ändern, um ihre App perfekt auf die Benutzer:innen auszurichten.
Eine weitere Neuerung ist, dass die sogenannten Sharesheets, also die Bottomsheets, die beim Teilen von Inhalten zwischen Apps verwendet werden, in Android 14 nun anpassbar sind. So können dem standardmäßigen System-Sharesheet ab sofort eigene Bereiche hinzugefügt werden, in denen den Nutzer:innen zusätzliche Aktionen angeboten oder eine Vorschau angezeigt wird.
Dafür muss beim Intent nur ein weiteres Extra (Intent.EXTRA_CHOOSER_CUSTOM_ACTIONS) gesetzt werden, welches eine Liste an ChooserActions enthält. Eine ChooserAction kann über den ChooserActions.Builder definiert werden.
Was in Android 13 als Option für Entwickler:innen eingeführt wurde, soll im neuen Update jetzt auch für die Allgemeinheit möglich sein – die „Predictive Back Gesture“.
Dabei handelt es sich um eine Animation beim Zurücknavigieren mit der Gestensteuerung, die anzeigt, wohin genau die Nutzer:innen navigieren. Man kann in der App bleiben und eine Seite zurückgehen oder die App verlassen, wenn man die letzte Seite erreicht hat. Vor allem im letzteren Fall ist die Animation sehr hilfreich.
Wenn man die Geste ausführt, aber nicht abschließt, indem man den Finger noch nicht vom Display nimmt, wird durch die Animation verdeutlicht, dass die Geste zum Verlassen der Anwendung führen würde. Im Gegensatz zum Drücken eines Buttons können die Nutzer:innen dann während der Geste anhand der Animation entscheiden, ob sie die Geste abschließen oder die Aktion abbrechen wollen, indem sie die Swipe-Bewegung rückgängig machen.
Neben der Veröffentlichung des neuen Features gibt es unter Android 14 weitere Verbesserungen bei der Rückwärtsnavigation im Vergleich zur Vorgängerversion. Die „Predictive Back Gesture“ kann nun über android:enableOnBackInvokedCallback=true pro Activity aktiviert werden und nicht wie bisher für die gesamte App. Außerdem wurden neue Animationen dafür hinzugefügt und auch Bottomsheets, Sidesheets und Suchen werden unterstützt. Es können aber auch eigene Animationen für die Navigation innerhalb der App erstellt werden. Hierfür stehen nun unter Android 14 neue APIs zur Verfügung. Um Entwickler:innen einen standardisierten Ansatz für die Erkennung von Screenshots anzubieten, wird mit dem neuen Release eine eigene API dafür angeboten. Diese erlaubt es, pro Activity einen Callback zu hinterlegen, um informiert zu werden, ob ein Screenshot gemacht wurde und sich die Activity zu diesem Zeitpunkt in einem sichtbaren Zustand befand. Zu beachten ist, dass der Callback keinen Screenshot liefert, sondern nur die Information, dass ein Screenshot gemacht wurde.
Dazu benötigt man die Berechtigung DETECT_SCREEN_CAPTURE im Manifest, muss den Callback in der onStart-Funktion der Activity registrieren und in der onStop-Methode wieder abmelden.
Fazit
Neben einigen Sicherheitsupdates und dem Java 17-Support können sich Entwickler:innen bei Android 14 vor allem auf neue Features zur Steigerung der Benutzererfahrung wie die Einführung der „Predictive Back Gesture“, eine eigene Gestaltung der Sharesheets und neue Funktionen bezüglich Sprachen, freuen. Auch die Barrierefreiheit des Betriebssystems treibt Google mit der neuen nichtlinearen Schriftgrößenskalierung weiter voran und geht beispielsweise mit den regionalen Einstellungen stärker auf die Bedürfnisse der Nutzer:innen ein. Eine vollständige Übersicht zu allen Änderungen und neuen Features, findet man hier.