Heute veröffentlichen wir die erste Betaversion von Android 17. Damit setzen wir unsere Bemühungen fort, eine Plattform zu entwickeln, bei der Datenschutz, Sicherheit und optimierte Leistung im Vordergrund stehen. Mit diesem Build setzen wir unsere Bemühungen fort, Android-Apps anpassungsfähiger zu machen. Außerdem führen wir wichtige Verbesserungen bei Kamera- und Medienfunktionen, neue Tools zur Optimierung der Konnektivität und erweiterte Profile für Begleitgeräte ein. Diese Version markiert auch eine grundlegende Änderung in der Art und Weise, wie wir neue Versionen für die Entwickler-Community bereitstellen, vom traditionellen Entwicklervorschau-Modell zum Android Canary-Programm.
Über die Entwicklervorschau hinaus
Unter Android wurde die traditionelle „Entwicklervorschau“ durch einen kontinuierlichen Canary-Channel ersetzt. Dieses neue „Always-on“-Modell bietet drei Hauptvorteile:
- Schnellerer Zugriff:Funktionen und APIs werden in Canary eingeführt, sobald sie interne Tests bestehen, anstatt auf eine vierteljährliche Version zu warten.
- Höhere Stabilität:Durch die frühe „Praxisprüfung“ in Canary wird die Beta-Version optimiert. Neue APIs und Verhaltensänderungen sind dann fast fertig.
- Einfacheres Testen:Canary unterstützt OTA-Updates (kein manuelles Flashen mehr). Als separater Update-Channel lässt es sich einfacher in CI-Workflows einbinden und bietet Ihnen die Möglichkeit, sofort Feedback zu anstehenden potenziellen Änderungen zu geben.
Zeitplan für Android 17
Wir werden diese Beta-Phase schnell durchlaufen und im März den Meilenstein „Plattformstabilität“ erreichen. Bei diesem Meilenstein stellen wir die endgültigen SDK-/NDK-APIs und die weitgehend endgültigen app-bezogenen Verhaltensweisen bereit. Ab diesem Zeitpunkt haben Sie mehrere Monate Zeit, um Ihre Tests vor dem endgültigen Release abzuschließen.
Ein Jahr voller Releases
Wir planen, Android 17 in einer Reihe von vierteljährlichen Releases weiter zu aktualisieren. Das bevorstehende Release im 2. Quartal ist das einzige, in dem wir geplante funktionsgefährdende Änderungen an Apps einführen. Wir planen, im vierten Quartal ein untergeordnetes SDK mit zusätzlichen APIs und Funktionen zu veröffentlichen.
Einschränkungen bei Ausrichtung und Größe
Mit der Veröffentlichung der Betaversion von Android 17 gehen wir in die nächste Phase unseres adaptiven Fahrplans über: In Android 17 (API-Ebene 37) wird die Möglichkeit für Entwickler entfernt, die Einschränkungen für die Ausrichtung und Größenänderung auf Geräten mit großen Displays (sw > 600 dp) zu deaktivieren.
Wenn Ihre App auf SDK 37 ausgerichtet ist, muss sie sich anpassen können. Nutzer erwarten, dass ihre Apps überall funktionieren – egal, ob sie auf einem Tablet Multitasking betreiben, ein Gerät aufklappen oder eine Desktop-Freiform-Fensterumgebung verwenden. Außerdem erwarten sie, dass die Benutzeroberfläche den verfügbaren Platz ausnutzt und die Geräteausrichtung berücksichtigt.
Wichtige Änderungen für SDK 37
Apps, die auf Android 17 ausgerichtet sind, müssen mit der Einstellung von Manifestattributen und Laufzeit-APIs kompatibel sein, die in Android 16 eingeführt wurden. Wenn die App auf einem großen Bildschirm (kleinere Dimension ≥ 600 dp) ausgeführt wird, werden die folgenden Attribute und APIs ignoriert:
| Manifestattribute/API | Ignorierte Werte |
| screenOrientation | portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape |
| setRequestedOrientation() | portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape |
| resizeableActivity | alle |
| minAspectRatio | alle |
| maxAspectRatio | alle |
Ausnahmen und Nutzerkontrolle
Diese Änderungen gelten nur für große Bildschirme und nicht für Bildschirme mit einer Breite von weniger als 600 dp (einschließlich Smartphones im herkömmlichen Slate-Formfaktor). Apps, die anhand des Flags android:appCategory als Spiele kategorisiert sind, sind von diesen Einschränkungen ausgenommen.
Es ist auch wichtig zu beachten, dass die Nutzer die Kontrolle behalten. Nutzer können die Standardeinstellungen einer App explizit über die Einstellungen für das Seitenverhältnis des Systems aktivieren oder deaktivieren.
Aktualisierungen bei Konfigurationsänderungen
Um die App-Kompatibilität zu verbessern und Unterbrechungen bei der Videowiedergabe, verlorene Eingaben und andere Arten von störenden Zustandsverlusten zu minimieren, aktualisieren wir das Standardverhalten für die Neuerstellung von Aktivitäten. Ab Android 17 werden Aktivitäten bei bestimmten Konfigurationsänderungen, die in der Regel keine Neuerstellung der Benutzeroberfläche erfordern, nicht mehr standardmäßig neu gestartet. Dazu gehören CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_UI_MODE (wenn nur UI_MODE_TYPE_DESK geändert wird), CONFIG_TOUCHSCREEN und CONFIG_COLOR_MODE. Stattdessen werden Laufaktivitäten einfach über onConfigurationChanged aktualisiert. Wenn Ihre Anwendung auf einen vollständigen Neustart angewiesen ist, um Ressourcen für diese Änderungen neu zu laden, müssen Sie jetzt explizit das neue Manifestattribut android:recreateOnConfigChanges verwenden. Damit können Sie angeben, welche Konfigurationsänderungen einen vollständigen Aktivitätslebenszyklus (von „stop“ über „destroy“ bis hin zur erneuten Erstellung) auslösen sollen. Dazu gehören die zugehörigen Konstanten mcc, mnc und die neuen Konstanten keyboard, keyboardHidden, navigation, touchscreen und colorMode.
App vorbereiten
Wir haben Tools und Dokumentationen veröffentlicht, um Ihnen die Arbeit zu erleichtern. In unserem Blogpost finden Sie weitere Informationen und Strategien zur Behebung häufiger Probleme. Apps müssen Layouts im Quer- und Hochformat für Fenstergrößen über den gesamten Bereich von Seitenverhältnissen hinweg unterstützen, da die Einschränkung der Ausrichtung oder des Seitenverhältnisses nicht mehr möglich ist. Wir empfehlen, Ihre App mit der Android 17 Beta 1 mit Pixel Tablet- oder Pixel Fold-Emulatoren (konfiguriert für targetSdkPreview = "CinnamonBun") oder mit dem App-Kompatibilitäts-Framework zu testen, um UNIVERSAL_RESIZABLE_BY_DEFAULT auf Android 16-Geräten zu aktivieren.
Leistung
Sperrfreie MessageQueue
In Android 17 erhalten Apps, die auf SDK 37 oder höher ausgerichtet sind, eine neue Implementierung von android.os.MessageQueue, die ohne Sperren auskommt. Die neue Implementierung verbessert die Leistung und reduziert fehlende Frames, kann aber Clients, die private Felder und Methoden von MessageQueue verwenden, beeinträchtigen.
Generational Garbage Collection
Mit Android 17 wird die generationenbasierte automatische Speicherbereinigung für den Concurrent Mark-Compact-Collector von ART eingeführt. Bei dieser Optimierung werden neben vollständigen Heap-Sammlungen häufigere, weniger ressourcenintensive automatische Speicherbereinigungen der jungen Generation eingeführt. Ziel ist es, die CPU-Kosten und die Zeitdauer der automatischen Speicherbereinigung insgesamt zu senken. ART-Verbesserungen sind auch für über eine Milliarde Geräte mit Android 12 (API‑Level 31) und höher über Google Play-Systemupdates verfügbar.
Statische „final“-Felder sind jetzt wirklich „final“
Ab Android 17 können Apps, die auf Android 17 oder höher ausgerichtet sind, keine „static final“-Felder mehr ändern. Dadurch kann die Laufzeit Leistungsoptimierungen aggressiver anwenden. Ein entsprechender Versuch über Reflection (und Deep Reflection) führt immer dazu, dass „IllegalAccessException“ ausgelöst wird. Wenn Sie sie über die SetStatic<Type>Field-Methoden von JNI ändern, stürzt die Anwendung sofort ab.
Einschränkungen bei der benutzerdefinierten Benachrichtigungsansicht
Um die Arbeitsspeichernutzung zu reduzieren, beschränken wir die Größe von benutzerdefinierten Benachrichtigungsansichten. Mit diesem Update wird eine Sicherheitslücke geschlossen, durch die Apps vorhandene Limits mithilfe von URIs umgehen konnten. Dieses Verhalten ist von der Ziel-SDK-Version abhängig und gilt für Apps, die auf API 37 und höher ausgerichtet sind.
Neue ProfilingManager-Trigger für das Debugging der Leistung
Wir haben mehrere neue System-Trigger für ProfilingManager eingeführt, damit Sie detaillierte Daten zur Behebung von Leistungsproblemen erfassen können. Diese Trigger sind TRIGGER_TYPE_COLD_START, TRIGGER_TYPE_OOM und TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE.
Informationen zum Einrichten der neuen System-Trigger finden Sie in der Dokumentation zu triggerbasiertem Profiling und Abrufen und Analysieren von Profiling-Daten.
Medien und Kamera
Android 17 bietet professionelle Tools für Media- und Kamera-Apps, darunter Funktionen wie nahtlose Übergänge und standardisierte Lautstärke.
Dynamische Updates für Kamerasitzungen
Wir haben updateOutputConfigurations() in CameraCaptureSession eingeführt. So können Sie Ausgabeflächen dynamisch anhängen und trennen, ohne die gesamte Kameraaufnahmesitzung neu konfigurieren zu müssen. Diese Änderung ermöglicht nahtlose Übergänge zwischen verschiedenen Anwendungsfällen und Modi der Kamera (z. B. zwischen dem Aufnehmen von Fotos und Videos), ohne dass der Speicherbedarf und die Codekomplexität für die Konfiguration und Aufbewahrung aller Kameraausgabeoberflächen anfallen, die Ihre App beim Starten der Kamera möglicherweise benötigt. So werden für Nutzer sichtbare Fehler oder Einfrierungen während des Betriebs vermieden.
fun updateCameraSession(session: CameraCaptureSession, newOutputConfigs: List<OutputConfiguration>)) {
// Dynamically update the session without closing and reopening
try {
// Update the output configurations
session.updateOutputConfigurations(newOutputConfigs)
} catch (e: CameraAccessException) {
// Handle error
}
}
Metadaten für logische Geräte mit mehreren Kameras
Wenn Sie mit logischen Kameras arbeiten, die mehrere physische Kamerasensoren kombinieren, können Sie jetzt zusätzliche Metadaten von allen aktiven physischen Kameras anfordern, die an einer Aufnahme beteiligt sind, nicht nur von der primären. Bisher mussten Sie Workarounds implementieren und manchmal unnötige physische Streams zuweisen, um Metadaten von sekundären aktiven Kameras zu erhalten, z.B. bei einem Objektivwechsel für den Zoom, wenn eine Follower-Kamera aktiv ist. Mit dieser Funktion wird ein neuer Schlüssel, LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS, in CaptureRequest und CaptureResult eingeführt. Wenn Sie diesen Schlüssel in Ihrem CaptureRequest auf ON setzen, enthält das TotalCaptureResult Metadaten von diesen zusätzlichen aktiven physischen Kameras. Sie können mit TotalCaptureResult.getPhysicalCameraTotalResults() auf diese umfassenden Metadaten zugreifen, um detailliertere Informationen zu erhalten, mit denen Sie die Ressourcennutzung in Ihren Kameraanwendungen optimieren können.
Unterstützung von Versatile Video Coding (VVC)
Android 17 bietet Unterstützung für den Standard Versatile Video Coding (VVC). Dazu gehört das Definieren des MIME-Typs video/vvc in MediaFormat, das Hinzufügen neuer VVC-Profile in MediaCodecInfo und die Integration der Unterstützung in MediaExtractor. Diese Funktion wird auf Geräten mit Hardware-Decodierungsunterstützung und kompatiblen Treibern verfügbar sein.
Konstante Qualität für Videoaufzeichnungen
Wir haben setVideoEncodingQuality() zu MediaRecorder hinzugefügt. So können Sie einen Modus mit konstanter Qualität (Constant Quality, CQ) für Video-Encoder konfigurieren und haben so mehr Kontrolle über die Videoqualität als mit einfachen Bitrateneinstellungen.
Härten von Hintergrundaudio
Ab Android 17 werden im Audio-Framework Einschränkungen für Audiointeraktionen im Hintergrund erzwungen, darunter Audiowiedergabe, Audiofokus-Anfragen und Lautstärkeänderungs-APIs. So soll sichergestellt werden, dass diese Änderungen vom Nutzer initiiert werden.
Wenn die App versucht, Audio-APIs aufzurufen, während sich die Anwendung nicht in einem gültigen Lebenszyklus befindet, schlagen die APIs für die Audiowiedergabe und die Lautstärkeänderung ohne Ausnahme oder Fehlermeldung fehl. Die Audiofokus-API schlägt mit dem Ergebniscode AUDIOFOCUS_REQUEST_FAILED fehl.
Datenschutz und Sicherheit
Einstellung des Attributs „Cleartext Traffic“
Das Attribut android:usesCleartextTraffic wird nicht mehr unterstützt. Wenn Ihre App auf Android 17 oder höher ausgerichtet ist und auf „usesCleartextTraffic='true'“ ohne entsprechende Netzwerksicherheitskonfiguration angewiesen ist, wird standardmäßig kein Klartextverkehr zugelassen. Wir empfehlen, für eine detaillierte Steuerung zu Network Security Configuration-Dateien zu migrieren.
HPKE-Hybridkryptografie
Wir führen eine öffentliche Service Provider Interface (SPI) für eine Implementierung der HPKE-Hybridkryptografie ein, die eine sichere Kommunikation durch eine Kombination aus Public-Key- und symmetrischer Verschlüsselung (AEAD) ermöglicht.
Konnektivität und Telekommunikation
Erweiterte VoIP-Anrufliste
Wir führen die Verwaltung von Nutzereinstellungen für die Integration des VoIP-Anrufverlaufs von Apps ein. Dazu gehört die Unterstützung von Anrufer- und Teilnehmer-Avatar-URIs im System-Dialer, die eine detaillierte Nutzerkontrolle über den Datenschutz von Anruflisten ermöglichen und die visuelle Darstellung integrierter VoIP-Anruflisten verbessern.
WLAN-Entfernungsmessung und ‑Nähe
Wi‑Fi Ranging wurde um neue Funktionen zur Erkennung der Nähe erweitert, die kontinuierliches Ranging und die sichere Peer‑to‑Peer-Erkennung unterstützen. Zu den Updates für Wi-Fi Aware gehören neue APIs für Peer-Handles und PMKID-Caching für sichere 11az-Entfernungsmessungen.
Produktivität und Tools für Entwickler
Updates für Companion-Geräte-Apps
Wir haben zwei neue Profile im CompanionDeviceManager eingeführt, um die Unterscheidung von Geräten und die Berechtigungsverwaltung zu verbessern:
- Medizinische Geräte:Mit diesem Profil können mobile Apps für medizinische Geräte alle erforderlichen Berechtigungen mit einem einzigen Tippen anfordern, was die Einrichtung vereinfacht.
- Fitness-Tracker:Mit dem Profil DEVICE_PROFILE_FITNESS_TRACKER können Companion-Apps explizit angeben, dass sie einen Fitness-Tracker verwalten. So wird eine genaue Nutzererfahrung mit eindeutigen Symbolen gewährleistet, während vorhandene Berechtigungen für die Uhrenrolle wiederverwendet werden.
Außerdem bietet der CompanionDeviceManager jetzt einen einheitlichen Dialog für die Gerätezuordnung und Berechtigungsanfragen für Geräte in der Nähe. Mit der neuen Methode setExtraPermissions in AssociationRequest.Builder können Sie Aufforderungen für Berechtigungen in der Nähe in den vorhandenen Verknüpfungsablauf einbinden und so die Anzahl der Dialogfelder reduzieren, die dem Nutzer angezeigt werden.
Erste Schritte mit Android 17
Sie können jedes unterstützte Pixel-Gerät registrieren, um dieses und zukünftige Android-Beta-Updates Over-the-Air zu erhalten. Wenn Sie kein Pixel-Gerät haben, können Sie die 64‑Bit-System-Images mit dem Android Emulator in Android Studio verwenden.
Wenn Sie derzeit am Android-Betaprogramm teilnehmen, erhalten Sie ein Over-the-Air-Update auf Beta 1.
Wenn Sie Android 26Q1 Beta verwenden und die endgültige stabile Version von 26Q1 nutzen und die Betaphase beenden möchten, müssen Sie das Over-the-Air-Update auf 26Q2 Beta 1 ignorieren und auf die Veröffentlichung von 26Q1 warten.
Wir freuen uns über Ihr Feedback. Melden Sie Probleme und reichen Sie Feature Requests auf der Feedbackseite ein. Je früher wir Ihr Feedback erhalten, desto mehr können wir in unsere Arbeit an der endgültigen Version einbeziehen.
Für die beste Entwicklungsumgebung mit Android 17 empfehlen wir die Verwendung der neuesten Vorabversion von Android Studio (Panda). Nach der Einrichtung sollten Sie Folgendes tun:
- Kompilieren Sie mit dem neuen SDK, testen Sie in CI-Umgebungen und melden Sie alle Probleme in unserem Tracker auf der Feedbackseite.
- Testen Sie Ihre aktuelle App auf Kompatibilität, prüfen Sie, ob Ihre App von Änderungen in Android 17 betroffen ist, installieren Sie Ihre App auf einem Gerät oder Emulator mit Android 17 und testen Sie sie gründlich.
Wir aktualisieren die Vorabversionen von Systemimages und das SDK während des gesamten Android 17-Releasezyklus regelmäßig. Nachdem Sie einen Beta-Build installiert haben, erhalten Sie künftige Updates für alle späteren Vorabversionen und Betas automatisch over-the-air.
Mitreden
Auf dem Weg zur Plattformstabilität und zur endgültigen stabilen Version von Android 17 im Laufe des Jahres ist Ihr Feedback weiterhin von unschätzbarem Wert. Egal, ob Sie Early Adopter im Canary-Channel oder App-Entwickler sind, der Beta 1 testet: Treten Sie unseren Communities bei und geben Sie Feedback. Wir hören zu.
Verfasst von:
Weiterlesen
-
Produktneuheiten
Heute stellen wir Gemma 4 vor, unser neuestes hochmodernes offenes Modell, das für komplexes Reasoning und autonomes Tool-Calling entwickelt wurde.
Matthew McCullough • Lesezeit: 2 Minuten
-
Produktneuheiten
Mit Beta 3 hat Android 17 heute offiziell die Plattformstabilität erreicht. Das bedeutet, dass die API-Oberfläche gesperrt ist. Sie können die letzten Kompatibilitätstests durchführen und Ihre für Android 17 entwickelten Apps im Google Play Store veröffentlichen.
Matthew McCullough • Lesezeit: 5 Minuten
-
Produktneuheiten
Wir möchten Ihnen die Entwicklung hochwertiger Android-Apps erleichtern und beschleunigen. Dazu stellen wir Ihnen KI-Funktionen zur Verfügung, die Ihre Produktivität steigern.
Matthew McCullough • Lesezeit: 2 Minuten
Auf dem Laufenden bleiben
Lassen Sie sich Woche für Woche die neuesten Informationen zur Android-Entwicklung zusenden.
