Heute veröffentlichen wir die erste Betaversion von Android 17. Wir arbeiten weiter daran, eine Plattform zu entwickeln, bei der Datenschutz, Sicherheit und eine verbesserte Leistung im Vordergrund stehen. Mit diesem Build setzen wir unsere Arbeit an anpassungsfähigeren Android-Apps fort. Außerdem führen wir erhebliche Verbesserungen an den Kamera- und Media-Funktionen, 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: Wir wechseln vom traditionellen Modell der Entwicklervorschau zum Android Canary-Programm

Mehr als nur eine Entwicklervorschau

Android hat die traditionelle Entwicklervorschau durch einen kontinuierlichen Canary-Kanal ersetzt. Dieses neue Modell bietet drei Hauptvorteile:

• Schnellerer Zugriff:Funktionen und APIs werden in Canary bereitgestellt, sobald sie interne Tests bestanden haben, und nicht erst mit einer vierteljährlichen Version.
• Bessere Stabilität:Durch die frühen Tests in Canary wird die Betaversion ausgereifter. Neue APIs und Verhaltensänderungen sind fast final.
• Einfachere Tests:Canary unterstützt OTA-Updates (kein manuelles Flashen mehr) und lässt sich als separater Updatekanal einfacher in CI-Workflows einbinden. Außerdem erhalten Sie so die Möglichkeit, sofort Feedback zu potenziellen Änderungen zu geben.

Zeitplan für Android 17

Wir werden schnell von dieser Betaversion zum Meilenstein der Plattformstabilität übergehen, der für März geplant ist. Zu diesem Zeitpunkt stellen wir die endgültigen SDK-/NDK-APIs und weitgehend endgültige Verhaltensweisen für Apps bereit. Ab diesem Zeitpunkt haben Sie mehrere Monate Zeit, um Ihre Tests abzuschließen, bevor die endgültige Version veröffentlicht wird.

Ein Jahr voller Releases

Wir planen, Android 17 in einer Reihe von vierteljährlichen Releases weiter zu aktualisieren. Das kommende Release im zweiten Quartal ist das einzige, bei dem wir geplante Verhaltensänderungen einführen, die sich auf Apps auswirken. Wir planen für das vierte Quartal ein kleineres SDK-Release mit zusätzlichen APIs und Funktionen.

Einschränkungen für Ausrichtung und Größe

Mit der Veröffentlichung der Android 17-Betaversion gehen wir in die nächste Phase unserer adaptiven Roadmap über: Android 17 (API-Level 37) entfernt die Möglichkeit für Entwickler, die Einschränkungen für Ausrichtung und Größe auf Geräten mit großen Bildschirmen (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 Multitasking auf einem Tablet nutzen, ein Gerät aufklappen oder eine Desktop-Fensterumgebung verwenden. Außerdem erwarten sie, dass die Benutzeroberfläche den verfügbaren Platz ausfüllt und die Ausrichtung des Geräts 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 Gerät mit großem Bildschirm ausgeführt wird (kleinere Dimension ≥ 600 dp), werden die folgenden Attribute und APIs ignoriert:

Ausnahmen und Nutzerkontrolle

Diese Änderungen gelten nur für Geräte mit großen Bildschirmen. Sie gelten nicht für Bildschirme mit einer Breite von weniger als 600 dp (einschließlich herkömmlicher Smartphones). Außerdem sind Apps, die als Spiele kategorisiert sind (basierend auf dem android:appCategory Flag), von diesen Einschränkungen ausgenommen.

Nutzer behalten die Kontrolle. Sie können das Standardverhalten einer App explizit über die Einstellungen für das Seitenverhältnis des Systems aktivieren oder deaktivieren.

Änderungen an Konfigurationsänderungen

Um die App-Kompatibilität zu verbessern und Unterbrechungen bei der Videowiedergabe, Eingabeausfälle und andere Arten von störendem Statusverlust zu minimieren, aktualisieren wir das Standardverhalten für die Neuerstellung von Aktivitäten. Ab Android 17 startet das System Aktivitäten nicht mehr standardmäßig neu, wenn bestimmte Konfigurationsänderungen vorgenommen werden, die in der Regel keine Neuerstellung der Benutzeroberfläche erfordern. 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 erhalten laufende Aktivitäten diese Updates einfach über onConfigurationChanged.Wenn Ihre Anwendung einen vollständigen Neustart benötigt, um Ressourcen für diese Änderungen neu zu laden, müssen Sie dies jetzt explizit über das neue android:recreateOnConfigChanges Manifestattribut aktivieren. Damit können Sie angeben, welche Konfigurationsänderungen einen vollständigen Aktivitätslebenszyklus auslösen sollen (von „Beenden“ über „Löschen“ bis hin zur Neuerstellung), zusammen mit den zugehörigen Konstanten mcc, mnc und den neuen Konstanten keyboard, keyboardHidden, navigation, touchscreen und colorMode.

App vorbereiten

Wir haben Tools und Dokumentation veröffentlicht, um Ihnen die Arbeit zu erleichtern. In unserem Blogpost finden Sie weitere Anleitungen und Strategien zur Behebung häufiger Probleme. Apps müssen Layouts im Quer- und Hochformat für Fenstergrößen im gesamten Bereich der Seitenverhältnisse 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 zu testen (konfiguriert auf targetSdkPreview = "CinnamonBun") oder das App-Kompatibilitätsframework zu verwenden, um UNIVERSAL_RESIZABLE_BY_DEFAULT auf Android 16-Geräten zu aktivieren.

Leistung

Lock-free MessageQueue

In Android 17 erhalten Apps, die auf SDK 37 oder höher ausgerichtet sind, eine neue Implementierung von android.os.MessageQueue, bei der keine Sperren verwendet werden. Die neue Implementierung verbessert die Leistung und reduziert die Anzahl der ausgelassenen Frames, kann aber Clients beeinträchtigen, die private Felder und Methoden von MessageQueue verwenden.

Generationsbasierte automatische Speicherbereinigung

In Android 17 wird die generationsbasierte automatische Speicherbereinigung für den Concurrent Mark-Compact-Collector von ART eingeführt. Diese Optimierung führt zu häufigeren, weniger ressourcenintensiven Bereinigungen der jungen Generation neben Bereinigungen des gesamten Heaps. Ziel ist es, die CPU-Kosten und die Dauer der automatischen Speicherbereinigung insgesamt zu reduzieren. 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 finale Felder sind jetzt wirklich final

Ab Android 17 können Apps, die auf Android 17 oder höher ausgerichtet sind, keine statischen finalen Felder mehr ändern. So kann die Laufzeit Leistung optimieren. Ein Versuch, dies über die Reflektion (und die Deep Reflektion) zu tun, führt immer dazu, dass eine IllegalAccessException ausgelöst wird. Wenn Sie sie über die SetStatic<Type>Field-Methoden von JNI ändern, stürzt die Anwendung sofort ab.

Einschränkungen für benutzerdefinierte Benachrichtigungsansichten

Um die Speichernutzung zu reduzieren, beschränken wir die Größe von benutzerdefinierten Benachrichtigungsansichten. Mit diesem Update wird eine Lücke geschlossen, die es Apps ermöglicht, vorhandene Limits mithilfe von URIs zu umgehen. Dieses Verhalten wird durch die Ziel-SDK-Version gesteuert und gilt für Apps, die auf API 37 und höher ausgerichtet sind.

Neue ProfilingManager-Trigger für die Leistungsfehlerbehebung

Wir haben mehrere neue Systemtrigger für ProfilingManager eingeführt, mit denen 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 Systemtrigger finden Sie in der Dokumentation zu triggerbasiertem Profiling und zum Abrufen und Analysieren von Profilingdaten.

Medien und Kamera

Android 17 bietet professionelle Tools für Medien- und Kamera-Apps, darunter Funktionen wie nahtlose Übergänge und standardisierte Lautstärke.

Dynamische Updates für Kamerasitzungen

Wir haben updateOutputConfigurations() zu CameraCaptureSession hinzugefügt. So können Sie Ausgabeflächen dynamisch anhängen und trennen, ohne die gesamte Kamerasitzung 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 Speicherverbrauch und die Codekomplexität der Konfiguration und des Beibehaltens aller Kameraausgabeflächen, die Ihre App beim Starten der Kamera möglicherweise benötigt, anfallen. So lassen sich für Nutzer sichtbare Fehler oder Einfrierungen während des Betriebs vermeiden.

  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 Kamera. Bisher mussten Sie Problemumgehungen implementieren und manchmal unnötige physische Streams zuweisen, um Metadaten von sekundären aktiven Kameras zu erhalten (z.B. beim Wechsel des Objektivs für den Zoom, wenn eine Follower-Kamera aktiv ist). Mit dieser Funktion wird in CaptureRequest und CaptureResult ein neuer Schlüssel eingeführt: LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS. Wenn Sie diesen Schlüssel in Ihrer CaptureRequest auf „ON“ setzen, enthält TotalCaptureResult Metadaten von diesen zusätzlichen aktiven physischen Kameras. Sie können auf diese umfassenden Metadaten mit TotalCaptureResult.getPhysicalCameraTotalResults() zugreifen, um detailliertere Informationen zu erhalten, mit denen Sie die Ressourcennutzung in Ihren Kameraanwendungen optimieren können.

Unterstützung für Versatile Video Coding (VVC)

Android 17 unterstützt den Standard Versatile Video Coding (VVC). Dazu gehört das Definieren des video/vvc MIME-Typs 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 geeigneten Treibern verfügbar sein.

Konstante Qualität für Videoaufzeichnungen

Wir haben MediaRecorder die Funktion setVideoEncodingQuality() hinzugefügt. So können Sie einen Modus mit konstanter Qualität (Constant Quality, CQ) für Videocodierer konfigurieren und die Videoqualität über einfache Bitrate-Einstellungen hinaus genauer steuern.

Härtung von Audio im Hintergrund

Ab Android 17 erzwingt das Audio-Framework Einschränkungen für Audiointeraktionen im Hintergrund, einschließlich Audiowiedergabe, Audiofokus-Anfragen und Lautstärkeänderungs-APIs. So wird sichergestellt, dass diese Änderungen vom Nutzer beabsichtigt sind.

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 für 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 Cleartext-Traffic nicht zugelassen. Wir empfehlen Ihnen, zu Netzwerksicherheitskonfiguration-Dateien zu migrieren, um eine detaillierte Kontrolle zu erhalten.

HPKE-Hybridkryptografie

Wir führen ein öffentliches Service Provider Interface (SPI) für eine Implementierung der HPKE-Hybridkryptografie ein, das eine sichere Kommunikation mit einer Kombination aus Public-Key- und symmetrischer Verschlüsselung (AEAD) ermöglicht.

Konnektivität und Telekommunikation

Verbesserte VoIP-Anrufliste

Wir führen die Verwaltung von Nutzereinstellungen für die Integration der VoIP-Anrufliste von Apps ein. Dazu gehört die Unterstützung für Avatar-URIs für Anrufer und Teilnehmer im System-Dialer, die eine detaillierte Nutzerkontrolle über den Datenschutz der Anrufliste ermöglicht und die visuelle Darstellung integrierter VoIP-Anruflisten verbessert.

WLAN-Entfernungsmessung und -Näherungserkennung

WLAN-Entfernungsmessung wurde um neue Funktionen zur Näherungserkennung erweitert, die eine kontinuierliche Entfernungsmessung und sichere Peer-to-Peer-Erkennung unterstützen. Zu den Updates für die WLAN Aware-Entfernungsmessung gehören neue APIs für Peer-Handles und PMKID-Caching für die sichere Entfernungsmessung mit 11az.

Produktivität und Tools für Entwickler

Updates für Begleitgeräte-Apps

Wir haben CompanionDeviceManager zwei neue Profile hinzugefügt, 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 Begleit-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 Rolle „Uhr“ wiederverwendet werden.

Außerdem bietet CompanionDeviceManager jetzt ein einheitliches Dialogfeld für die Gerätezuordnung und Berechtigungsanfragen für Geräte in der Nähe. Sie können die neue setExtraPermissions-Methode in AssociationRequest.Builder nutzen, um Berechtigungsaufforderungen für Geräte in der Nähe in den vorhandenen Zuordnungsablauf einzubinden und so die Anzahl der Dialogfelder zu 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 drahtlos 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, wird Ihnen ein drahtloses Update auf die Betaversion 1 angeboten.

Wenn Sie die Android 26Q1-Betaversion haben und die endgültige stabile Version von 26Q1 nutzen und das Betaprogramm verlassen möchten, müssen Sie das drahtlose Update auf die 26Q2-Betaversion 1 ignorieren und auf die Veröffentlichung von 26Q1 warten.

Wir freuen uns über Ihr Feedback. Bitte melden Sie Probleme und senden Sie Feature-Anfragen auf der Feedbackseite. 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 Entwicklungserfahrung mit Android 17 empfehlen wir Ihnen, die aktuelle Vorschau von Android Studio (Panda) zu verwenden. Sobald Sie alles eingerichtet haben, sollten Sie Folgendes tun:

• Kompilieren Sie mit dem neuen SDK, testen Sie in CI-Umgebungen und melden Sie alle Probleme in unserem Issue 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 ausführlich.

Wir aktualisieren die System-Images für die Vorschau/Betaversion und das SDK regelmäßig während des gesamten Release-Zyklus von Android 17. Sobald Sie einen Beta-Build installiert haben, erhalten Sie zukünftige Updates für alle späteren Vorschau- und Betaversionen automatisch drahtlos.

Vollständige Informationen finden Sie auf der Android 17-Entwicklerwebsite.

Mitreden

Auf dem Weg zur Plattformstabilität und zur endgültigen stabilen Version von Android 17 später in diesem Jahr ist Ihr Feedback weiterhin unser wertvollstes Gut. Egal, ob Sie ein Early Adopter im Canary-Kanal oder ein App-Entwickler sind, der mit der Betaversion 1 testet, treten Sie unseren Communities bei und geben Sie Feedback. Wir sind gespannt auf Ihre Meinung.