Produktneuheiten

Die erste Betaversion von Android 17

Lesezeit: 7 Minuten
Matthew McCullough
Vice President, Product Management, Android Developer

Heute veröffentlichen wir die erste Betaversion von Android 17. Damit setzen wir unsere Bemühungen fort, eine Plattform zu entwickeln, die Datenschutz, Sicherheit und optimierte Leistung in den Vordergrund stellt. 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. Wir wechseln 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 ist die Beta-Version ausgereifter. Neue APIs und Verhaltensänderungen sind 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 schnell von dieser Beta-Version zum Meilenstein „Plattformstabilität“ übergehen, der für März geplant ist. Zu diesem Meilenstein stellen wir die endgültigen SDK-/NDK-APIs und das weitgehend endgültige Verhalten von Apps bereit. Ab diesem Zeitpunkt haben Sie mehrere Monate Zeit, um Ihre Tests vor dem endgültigen Release abzuschließen.

timeline1.png

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.

timeline2.png

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/APIIgnorierte Werte
screenOrientationportrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape
setRequestedOrientation()portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape
resizeableActivityAlle
minAspectRatioAlle
maxAspectRatioAlle

Ausnahmen und Nutzersteuerung

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 das Standardverhalten 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 Statusverlusten 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 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 sperrenfrei ist. Die neue Implementierung verbessert die Leistung und reduziert die Anzahl der ausgelassenen Frames. Allerdings kann es zu Problemen bei Clients kommen, die private Felder und Methoden von MessageQueue verwenden.

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 letzte 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, die es Apps ermöglicht, vorhandene Beschränkungen mithilfe von URIs zu umgehen. 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 Kamera-Anwendungsfällen und ‑Modi (z. B. zwischen dem Aufnehmen von Fotos und dem Aufnehmen von Videos), ohne dass der Speicheraufwand und die Codekomplexität für die Konfiguration und Aufrechterhaltung aller Kameraausgabeoberflächen, die Ihre App beim Start der Kamera möglicherweise benötigt, anfallen. 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 zum Zoomen, 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, um sicherzustellen, 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 Ihnen, zu Network Security Configuration-Dateien zu migrieren, um eine detaillierte Steuerung zu ermöglichen.

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 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 dem 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 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 Vorschauversion 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 zukünftige Updates für alle späteren Previews und Betas automatisch over-the-air.

Weitere Informationen

Mitreden

Auf dem Weg zur Plattformstabilität und zur endgültigen stabilen Version von Android 17 im weiteren Jahresverlauf ist Ihr Feedback weiterhin von unschätzbarem Wert. Wenn Sie Early Adopter im Canary-Channel oder App-Entwickler sind, der Beta 1 testet, sollten Sie unseren Communities beitreten und Feedback geben. Wir hören zu.

Verfasst von:

Weiterlesen