Heute veröffentlichen wir Android 17, das auf den meisten unterstützten Pixel-Geräten verfügbar sein wird. In den kommenden Monaten werden neue Geräte mit Android 17 auf den Markt kommen.

Mit Android 17 beginnt die Umstellung auf ein intelligentes System, bei dem Ihre Apps im Mittelpunkt stehen. Android wird auf adaptive Entwicklungsstandards umgestellt, indem die Größenanpassung für große Bildschirme obligatorisch wird. Gleichzeitig werden Datenschutz, Sicherheit, Media, Kamera und Leistung der nächsten Generation eingeführt. In diesem Beitrag erfahren Sie alles dazu sowie dazu, wie wir Tools, Bibliotheken und Agent-Skills der nächsten Generation zusammenführen, damit Ihre Apps diese Möglichkeit nutzen können.

Im vergangenen Jahr haben wir von unserem Canary-Channel bis hin zu unseren Beta-Releases mit vielen von euch in der Entwickler-Community zusammengearbeitet, um eine Plattform zu entwickeln, der ihr und eure Nutzer vertrauen können. Daher ist der Quellcode ab sofort im Open-Source-Projekt für Android (AOSP) verfügbar. So könnt ihr den Quellcode untersuchen, um besser zu verstehen, wie Android funktioniert.

Sehen wir uns Android 17 genauer an.

Ein intelligentes System

Durch die enge Integration von Hardware, Software und KI wandeln wir Android von einem Betriebssystem in ein intelligentes System um. Es geht darum, neue nützliche Funktionen bereitzustellen, die den Bedürfnissen der Nutzer entsprechen, und mehr Möglichkeiten für die Nutzerinteraktion und ‑bindung mit Ihren Apps zu schaffen. Dazu werden in Android 17 die Funktionen von AppFunctions erweitert, einer Plattform-API mit einer entsprechenden Jetpack-Bibliothek. So können Sie die einzigartigen Funktionen Ihrer App als orchestrierbare „Tools“ für Android MCP bereitstellen, das dem Model Context Protocol auf dem Gerät entspricht. KI-Agents und ‑Assistenten wie Google Gemini können AppFunctions erkennen und ausführen, um Workflows im Namen des Nutzers mit direktem Zugriff auf den lokalen Status der App auszuführen.

Mit der Jetpack-Bibliothek, die sich derzeit in der Alphaphase befindet, können Sie AppFunctions ganz einfach hinzufügen, indem Sie eine Klasse mit Anmerkungen versehen und KDoc-Kommentare hinzufügen. 

/**
 *   A note app's [AppFunction]s.
 */
class NoteFunctions(
    private val noteRepository: NoteRepository
) {
    /**
     *   Adds a new note to the app.
     *
     *   @param appFunctionContext The execution context.
     *   @param title The title of the note.
     *   @param content The note's content.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createNote(
        appFunctionContext: AppFunctionContext,
        title: String,
        content: String
    ): Note {
        return noteRepository.createNote(title, content)
    }
}

Wir haben außerdem den AppFunctions-Agent-Skill eingeführt, der die wichtigsten Workflows Ihrer App analysiert, automatisch den erforderlichen Kotlin-Code generiert, Ihre KDocs für LLM-Tool-Aufrufe optimiert und ADB-Befehle zum Testen und Debuggen bereitstellt.

Die Gemini-Integration befindet sich derzeit in einer privaten Vorschau mit vertrauenswürdigen Testern. Sie können aber schon jetzt mit der Vorbereitung Ihrer Apps beginnen. Zusätzlich zu den ADB-Befehlen zum Ausführen Ihrer AppFunctions haben wir eine Test-Agent-App bereitgestellt, die eine Benutzeroberfläche zum Erkennen und Ausführen Ihrer AppFunctions sowie zum Simulieren einer KI-Agent-Integration enthält. Nehmen Sie an unserem Early-Access-Programm für die Integration unter goo.gle/eap-af teil, um die Chance zu erhalten, zu den ersten Apps zu gehören, die AppFunctions in der Produktionsumgebung bereitstellen.

Adaptive-First-Ansatz

Ihre Nutzer verwenden nicht mehr nur einen einzigen Formfaktor, sondern wechseln zwischen Smartphones, Foldables, Tablets, Laptops, Displays in Fahrzeugen und immersiven XR-Umgebungen. Mit über 580 Millionen Geräten mit großem Display, die Nutzer verwenden, und der bevorstehenden Einführung von Google Books ist die nächste Generation von ChromeOS, die auf dem Android-Stack basiert, nicht mehr nur ein technisches Ziel. Sie bietet eine enorme Chance, Nutzer mit hoher Interaktionsbereitschaft zu erreichen. Das ist einer der Gründe, warum wir auf einen adaptiven Entwicklungsstandard umstellen.

Keine Einschränkungen für die Größenänderung/Ausrichtung auf großen Displays

Damit Apps auf allen Formfaktoren, einschließlich Mobilgeräten, die im Desktopmodus auf angeschlossenen Displays ausgeführt werden, eine optimale Nutzererfahrung bieten, wird mit Android 17 (API-Level 37) die Möglichkeit für Entwickler entfernt, Einschränkungen für die Ausrichtung und Größenänderung auf Geräten mit großen Displays (sw > 600 dp) für Apps, die auf API-Level 37 ausgerichtet sind, zu deaktivieren. Das System ignoriert alte Manifestattribute und Laufzeit-APIs, einschließlich screenOrientation, setRequestedOrientation(), resizeableActivity=false und der Seitenverhältnisbeschränkungen (minAspectRatio/maxAspectRatio). Spiele (basierend auf der App-Kategorie bei Google Play) sind weiterhin ausgenommen. Ihre App muss sich an jede Fenstergröße anpassen, die bevorzugte Geräteausrichtung des Nutzers berücksichtigen und das Freeform-Fensterformat nativ unterstützen.

Multitasking der nächsten Generation: App-Bubbles, Bubble-Leiste und interaktiver PiP-Modus für den Desktop

Mit Android 17 werden leistungsstarke neue Fensterfunktionen eingeführt, die die Art und Weise, wie Nutzer Multitasking betreiben, neu definieren. Das erfordert noch mehr Layoutflexibilität von Ihren Apps:

• App-Bubbles : Über die Messaging-Bubbles API hinaus können Nutzer jetzt jede App in eine schwebende Bubble verwandeln, indem sie lange auf das Symbol im Launcher drücken. Diese Funktion ist auf Smartphones, Falt-Smartphones und Tablets verfügbar und ermöglicht leichtes Multitasking für jeden Workflow.
• Bubble-Leiste:Auf großen Bildschirmen (Tablets und Falt-Smartphones) enthält die System-Taskleiste jetzt eine spezielle Bubble-Leiste, um diese schwebenden App-Bubbles zu organisieren, zwischen ihnen zu wechseln und sie anzudocken.
• Interaktive BiB-Funktion für Desktop: In Desktopumgebungen wird mit Android 17 die interaktive Bild-im-Bild-Funktion (BiB) eingeführt. Im Gegensatz zu herkömmlichen BiB-Fenstern, die schreibgeschützt sind, bleiben diese angepinnten Fenster voll interaktiv und werden immer über anderen Anwendungsfenstern angezeigt.

Aktualisierungen zur Erstellung von Aktivitäten

Um störende Zustandsverluste und Ruckeln zu vermeiden, wird in Android 17 das Standardverhalten für die Neuerstellung von Aktivitäten aktualisiert. Das System startet Aktivitäten nicht mehr standardmäßig neu, wenn typische Konfigurationsänderungen auftreten, die kein vollständiges Neuzeichnen der Benutzeroberfläche erfordern (einschließlich CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN und CONFIG_COLOR_MODE).

Stattdessen erhalten laufende Aktivitäten diese Updates über onConfigurationChanged(), was für reibungslose Übergänge sorgt. Wenn Ihre Anwendung explizit auf einen vollständigen Neustart angewiesen ist, um Ressourcen für diese Änderungen neu zu laden, müssen Sie jetzt das neue Manifestattribut android:recreateOnConfigChanges explizit aktivieren.

Continue On

Mit „Continue On“ in Android 17 können Nutzer eine Aufgabe nahtlos zwischen Android-Geräten übertragen. In der Taskleiste des Tablets wird eine Empfehlung für die zuletzt auf dem Mobilgerät geöffnete App angezeigt. So können Nutzer die App mit nur einem Tippen starten und direkt dort fortfahren, wo sie aufgehört haben. „Continue On“ unterstützt Übergänge von Apps zu Webseiten und kann auch auf das Web zurückgreifen, wenn die App nicht installiert ist.

class MyHandoffActivity : Activity() {

    ...

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // Do stuff
    ...
    // Enable handoff
    setHandoffEnabled(true, null)
  }

  // Override and implement onHandoffActivityDataRequested
  override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData {
    // Create and return handoff data
  }
}

Adaptive Apps mit Jetpack Compose erstellen

Damit Sie Ihre Apps an die neuen Anforderungen von Android 17 anpassen können, haben wir den adaptiven Jetpack Compose-Skill eingeführt. Dieser KI-basierte Entwickler-Workflow hilft Ihnen, die besten adaptiven Praktiken zu implementieren:

• Adaptive Navigation:Mit NavigationSuiteScaffold aus der Material 3-Bibliothek für adaptive Navigation können Sie automatisch zwischen Navigationsleisten am unteren Rand auf Mobilgeräten und am Rand verankerten Navigationsleisten auf großen Bildschirmen wechseln.
• Layouts mit mehreren Bereichen:Implementieren Sie Listen-Detailansicht- und unterstützende Bereichslayouts nativ mit Navigation 3-Szenen (ListDetailSceneStrategy und SupportingPaneSceneStrategy) anstelle von anfälligen Fragmenttransaktionen.
• FlexBox- und Grid-APIs:Mit den dynamischen Layoutkomponenten von Compose 1.11 lassen sich Zeilen- und Spaltenüberspannungen ganz einfach anpassen, damit Ihre Inhalte immer optimal dargestellt werden.
• Erweiterte Eingabe ohne Touch-Funktion:Nutzen Sie die verbesserte Unterstützung für Trackpad und Maus in Compose 1.11, einschließlich nativer Fokusringe und neuer APIs (wie TrackpadInjectionScope und performTrackpadInput), um eine echte „Laptop-Erfahrung“ in Google Books und im Desktopmodus zu testen und bereitzustellen.
• Dynamische Fensterstatus:Nutzen Sie das reaktive Statusmodell von Compose, um die Benutzeroberfläche nahtlos anzupassen, wenn die App vom Vollbildmodus zu einer schwebenden App-Blase oder einem interaktiven Desktop-BiB-Fenster wechselt. So wird auch bei minimalen Abmessungen eine optimale Nutzerfreundlichkeit gewährleistet.

Android ist Compose-first

Compose ist die einfachste Möglichkeit, adaptive Apps zu entwickeln. Das ist nur einer der vielen Gründe, warum wir der Meinung sind, dass alle Android-Benutzeroberflächen mit Compose erstellt werden sollten. Aus diesem Grund ist die Android-Entwicklung jetzt Compose-first. Alle neuen Android-APIs, ‑Bibliotheken, ‑Tools und Entwickleranleitungen werden ausschließlich für Jetpack Compose entwickelt. Legacy-View-Komponenten (im Paket android.widget) und View-basierte Jetpack-Bibliotheken (wie Fragments, RecyclerView und ViewPager) befinden sich jetzt im Wartungsmodus. Sie erhalten nur kritische Fehlerkorrekturen und keine neuen Funktionen.

TIPP: Sie möchten migrieren? Mit unserem KI-basierten XML to Compose Migration Skill können Sie Ihre alten View-Layouts automatisch analysieren und in hochgradig adaptiven Compose-Code umwandeln.

Leistung und Effizienz

App-Leistung bedeutet eine flüssige Benutzeroberfläche, schnelle App-Startzeiten und effizientes Multitasking. Android 17 bietet in all diesen Bereichen wichtige Verbesserungen. 

App-Arbeitsspeicherlimits

Die Arbeitsspeichernutzung ist einer der stillen Grundpfeiler der Gesamtleistung. Wenn eine App im Vordergrund oder ein Vordergrunddienst ungehindert wächst, steigen die CPU- und Akkunutzung durch die Speicherverwaltung sprunghaft an. Dies führt schließlich zum Beenden anderer gut funktionierender Apps im Cache und Hintergrundjobs, was letztendlich langsamere Kaltstarts und beeinträchtigtes Multitasking zur Folge hat. 

Ab Android 17 erzwingt das System strenge App-Arbeitsspeicherlimits, die auf dem gesamten RAM eines Geräts basieren. Prozesse, die diese Limits überschreiten, werden abrupt beendet. Neues, das Ihnen helfen soll, die strengeren Anforderungen zu erfüllen:

• R8-Optimierer:  Der R8-Optimierer reduziert den Bytecode-Speicherbedarf Ihrer App erheblich, indem er Klassen, Methoden und Felder in kürzere Namen umbenennt und nicht verwendeten Code und nicht verwendete Ressourcen entfernt. Verwenden Sie R8 im vollständigen Modus zusammen mit dem neuen R8-Konfigurationsanalysetool, um sicherzustellen, dass Ihre App R8 optimal nutzt.

• LeakCanary in Android Studio Panda : Der Profiler bietet jetzt eine native LeakCanary-Integration als spezielle Aufgabe, die vollständig in Ihre IDE und Ihren Quellcode integriert ist.
• ApplicationExitInfo:Wenn Ihre App aufgrund dieser Grenzwerte beendet wird, gibt getDescription() aus ApplicationExitInfo „MemoryLimiter:AnonSwap“ zurück.
• On-Device Anomaly Detection (Anomalieerkennung auf dem Gerät): Als Teil von ProfilingManager können Sie die triggerbasierte Profilerstellung mit TRIGGER_TYPE_ANOMALY nutzen, um automatisch Heap-Dumps zu erfassen, wenn das Speicherlimit erreicht wird.

val profilingManager = applicationContext
   .getSystemService(ProfilingManager::class.java)

val triggers = ArrayList<ProfilingTrigger>().apply {
  add(ProfilingTrigger.Builder(
    ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build())
}
profilingManager.addProfilingTriggers(triggers)

Außerdem arbeiten wir daran, Ihnen in der Google Play Console weitere Messwerte zum In-Field-Speicherplatz zur Verfügung zu stellen.

KI-basierte automatische Speicherbereinigung

Android 17 führt häufigere, weniger ressourcenintensive Sammlungen der jungen Generation für den Concurrent Mark-Compact-Garbage Collector (GC) von ART ein. Durch die Trennung kurzlebiger Objekte von stabilen, langlebigen Objekten führt das System häufige, einfache „Young-Generation“-Scans anstelle von teuren Full-Heap-Scans durch, wodurch die CPU-Auslastung, der Stromverbrauch und das Ruckeln der Benutzeroberfläche drastisch reduziert werden. Unsere Tests haben gezeigt, dass die GC-Interferenz mit Anwendungs-Threads deutlich verbessert wurde und die maximale RSS (Resident Set Size) reduziert wurde. 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.

Sperrfreie MessageQueue

Für Apps, die auf SDK 37 oder höher ausgerichtet sind, implementiert die Core-Klasse android.os.MessageQueue jetzt eine sperrenfreie Architektur. Dadurch werden deutlich weniger Frames ausgelassen, die Startzeit von Apps wird verkürzt und die Leistung von stark ausgelasteten Warteschlangen in Multithread-Szenarien wird erheblich verbessert. Hinweis: Dies kann zu Problemen bei Apps führen, die Reflection für private MessageQueue-Felder und ‑Methoden verwenden. Die APIs peekWhen und poll wurden TestLooperManager für Instrumentationstests hinzugefügt, ohne dass auf interne MessageQueue-Elemente zurückgegriffen werden muss. 

Statische „final“-Felder sind jetzt wirklich „final“

Ab Android 17 können Apps, die auf SDK 37 oder höher ausgerichtet sind, „static final“-Felder nicht mehr ändern. Dadurch kann die Laufzeit Leistung optimieren. Ein entsprechender Versuch über Reflection (oder Deep Reflection) führt dazu, dass eine IllegalAccessException ausgelöst wird. 

Wenn Sie sie über die SetStatic<Type>Field-Methodenfamilie von JNI ändern, stürzt die Anwendung sofort ab.

Einschränkungen für benutzerdefinierte Benachrichtigungsansichten

Um die Speichernutzung zu reduzieren, schränken wir die Größe von benutzerdefinierten Benachrichtigungsansichten weiter ein. Mit diesem Update wird eine Sicherheitslücke geschlossen, die es Apps ermöglicht, vorhandene Limits mithilfe von URIs zu umgehen. Dieses Verhalten ist von der Ziel-SDK-Version abhängig und wird für Apps mit API 37 und höher wirksam.

Datenschutz und Sicherheit

Das Vertrauen der Nutzer ist das Herzstück des Android-Ökosystems. Android 17 bietet leistungsstarke Funktionen, die vertrauliche Daten schützen und gleichzeitig die Nutzerfreundlichkeit verbessern.

Datenschutzfreundliche Optionen

Bisher benötigten Apps umfassende, dauerhafte Berechtigungen für den Zugriff auf Informationen wie Kontakte, genauen Standort und Mediendateien. Mit Android 17 wird die Umstellung auf datenschutzfreundliche Optionen fortgesetzt, die nur temporären, sitzungsbasierten Zugriff auf die Daten gewähren, die der Nutzer explizit auswählt:

• Kontaktauswahl auf Systemebene:Mit ACTION_PICK_CONTACTS können Apps temporären Zugriff nur auf bestimmte Felder (z. B. E‑Mail-Adresse oder Telefonnummer) anfordern, die vom Nutzer ausgewählt werden. So ist die umfassende Berechtigung READ_CONTACTS nicht mehr erforderlich. Außerdem wird die Trennung von Arbeits- und privaten Profilen vollständig unterstützt.
• Anpassbares Seitenverhältnis für die Bildauswahl:Mit „PhotoPickerUiCustomizationParams“ können Sie die System-Bildauswahl so anpassen, dass Miniaturansichten im Hochformat angezeigt werden. Das ist ideal für Apps, in denen Fotos und Videos immer im Hochformat angezeigt werden, z. B. für videobasierte Social-Media-Apps.
• Vom System gerenderter Button „Standort“:Mit einem neuen vom System gerenderten Button „Standort“, den Sie in Ihre App einbetten können, wird der Zugriff auf den genauen Standort nur für die aktuelle Sitzung gewährt.
• EyeDropper API:Mit der neuen API auf Systemebene ACTION_OPEN_EYE_DROPPER kann Ihre App eine vom System unterstützte Pipette erstellen, mit der Nutzer eine Farbe aus einem beliebigen Pixel auf dem Display auswählen können. So wird eine sichere, datenschutzfreundliche Farbauswahl ermöglicht, ohne dass umfassende, sensible Berechtigungen für die Bildschirmaufnahme oder Projektion von Medieninhalten erforderlich sind.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
   if (result.resultCode == Activity.RESULT_OK) {
       val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
       // Use the picked color in your app
   }
}
fun launchColorPicker() {
   val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
   eyeDropperLauncher.launch(intent)
}

Zugriff auf lokales Netzwerk

Apps, die auf Android 17 ausgerichtet sind, benötigen jetzt entweder die Laufzeitberechtigung ACCESS_LOCAL_NETWORK oder die Verwendung von datenschutzfreundlichen Geräteauswahlen, die vom System vermittelt werden, für die lokale Netzwerkkommunikation, z. B. für die Kommunikation mit Smart-Home-Geräten oder Casting-Empfängern. Da ACCESS_LOCAL_NETWORK unter die vorhandene Berechtigungsgruppe NEARBY_DEVICES fällt, werden Nutzer, die bereits andere NEARBY_DEVICES-Berechtigungen erteilt haben, nicht noch einmal aufgefordert. 

Schutz von SMS-OTPs

In Android 17 wird der Schutz von Einmalpasswörtern per SMS erweitert, indem der Zugriff auf SMS-Nachrichten um drei Stunden verzögert wird:

• WebOTP-Format:Verzögert für alle Apps, die nicht der beabsichtigte Empfänger sind (Domain stimmt nicht überein).
• Standard-SMS-OTP:Verzögert für alle Apps, die auf SDK 37 oder höher ausgerichtet sind.

Ausnahmen:Standardmäßige SMS-, Assistant- und verbundene Companion-Apps sind ausgenommen. Wir empfehlen dringend, dass Apps zur SMS Retriever API oder zur SMS User Consent API migriert werden.

Post-Quanten-Kryptografie (PQC)

Android 17 ist bereit für die nächste Generation der kryptografischen Sicherheit:

• Keystore-Integration:Auf unterstützten Geräten können ML-DSA-Schlüssel (Module-Lattice-Based Digital Signature Algorithm) in sicherer Hardware generiert werden, um quantensichere Signaturen zu erstellen, die über standardmäßige JCA-APIs verfügbar gemacht werden.
• Hybrides APK-Signieren:Wir führen das APK-Signaturschema v3.2 ein, das klassische Signaturen mit ML-DSA-Signaturen kombiniert, um die App-Bereitstellung zu sichern.

Sicheres natives dynamisches Laden von Code

Wenn Ihre App auf SDK 37 oder höher ausgerichtet ist, gilt der in Android 14 eingeführte Schutz für sichereres dynamisches Laden von Code (Dynamic Code Loading, DCL) jetzt auch für native Bibliotheken. Alle nativen Dateien, die mit „System.load“ geladen werden, müssen als schreibgeschützt markiert werden. Andernfalls wird UnsatisfiedLinkError ausgegeben.

Intelligenterer Passwortschutz für physische Eingaben

Mit Android 17 wird die Eingabe von Passwörtern, PINs und anderen vertraulichen Informationen über eine physische Tastatur sicherer, da das zuletzt eingegebene Zeichen standardmäßig nicht mehr angezeigt wird.

Nutzer können diese Anzeigeeinstellungen weiterhin ganz einfach an ihre Vorlieben anpassen. Die Verfügbarkeit kann je nach Gerätehersteller variieren.

Diese verbesserten Datenschutzfunktionen werden automatisch von den integrierten SDK-Komponenten von Android unterstützt und werden in Compose 1.12 für SecureTextFields unterstützt. 
 

Media- und Kamerafunktionen, die Creator unterstützen und Nutzer begeistern

Mit Android 17 werden neue Creator-Funktionen eingeführt, die den Zugriff auf professionelle Kameras und Medien ermöglichen und gleichzeitig die Nutzerfreundlichkeit verbessern.

• Eclipsa Video: HDR-Videostandard, der auf der SMPTE ST 2094-50-Spezifikation basiert. Er führt neue Metadaten ein, mit denen Geräte Inhalte an ihren Display-Headroom und die Umgebungslichtbedingungen anpassen und die gleichzeitige Anzeige von Standard- und HDR-Inhalten verbessern können.
• RAW14-Bildformat:Die neue Unterstützung für das RAW14-Bildformat ermöglicht es Ihrer professionellen Kamera-App, die höchste Detail- und Farbtiefe von kompatiblen Kamerasensoren zu erfassen.
• Herstellerdefinierte Kameraerweiterungen:Mit herstellerdefinierten Erweiterungen können Hardwarepartner benutzerdefinierte Kameraerweiterungsmodi definieren und implementieren, um Zugriff auf die besten und neuesten Kamerafunktionen zu erhalten.
• Erweiterter HE-AAC-Software-Encoder: Ein neuer vom System bereitgestellter erweiterter HE-AAC-Software-Encoder unterstützt sowohl niedrige als auch hohe Bitraten mit einheitlicher Sprach- und Audiocodierung. Dadurch wird eine deutlich bessere Audioqualität für Sprachnachrichten bei geringer Bandbreite erreicht. Außerdem werden Lautheitsmetadaten unterstützt.
• Versatile Video Coding (H.266):  Ermöglicht OEMs, Codec-Unterstützung hinzuzufügen, indem sie den MIME-Typ video/vvc in MediaFormat definieren, neue VVC-Profile in MediaCodecInfo hinzufügen und die Unterstützung in MediaExtractor integrieren.
• Kameragerätetyp:Neue APIs, mit denen der zugrunde liegende Gerätetyp abgefragt wird, um zu ermitteln, ob es sich bei einer Kamera um integrierte Hardware, eine externe USB-Webcam oder eine virtuelle Kamera handelt.
• Konstante Qualität für Videoaufzeichnung:setVideoEncodingQuality in MediaRecorder konfiguriert einen Modus mit konstanter Qualität (Constant Quality, CQ) für Video-Encoder, um eine einheitliche visuelle Qualität im gesamten Video zu gewährleisten.

Bessere Unterstützung von Hörgeräten

• Unterstützung für Bluetooth LE Audio-Hörgeräte:Android enthält jetzt eine spezielle Geräteklasse für Bluetooth Low Energy (BLE) Audio-Hörgeräte mit der neuen Konstanten AudioDeviceInfo.TYPE_BLE_HEARING_AID. So kann Ihre App Hörgeräte von normalen Headsets unterscheiden und Nutzern mit Hörhilfen ein maßgeschneidertes Erlebnis bieten.
• Detailliertes Audio-Routing für Hörgeräte:Unter Android 17 können Nutzer unabhängig voneinander festlegen, wo bestimmte Systemtöne wiedergegeben werden. Sie können festlegen, dass Benachrichtigungen, Klingeltöne und Wecker über verbundene Hörgeräte oder den integrierten Lautsprecher des Geräts wiedergegeben werden. So lassen sich unerwünschte Unterbrechungen im Ohr vermeiden, während die Bluetooth-Verbindung für Apps zur Verwaltung von Hörgeräten aufrechterhalten wird.

CameraX und Media3

CameraX und Media3 wurden für Android 17 aktualisiert. Sie sind dazu da, die harte Arbeit zu erledigen,  die rauen Kanten der Medienentwicklung zu glätten und die Entwicklung zuverlässiger Kameraaufnahmen, flüssiger Medienwiedergabe sowie kreativer und komplexer Bearbeitungsfunktionen zu vereinfachen. 

Wir haben einen Agent-Skill veröffentlicht, mit dem sich alte Android-Kameraimplementierungen (Camera1 oder rohe Camera2-APIs) zu CameraX migrieren lassen.  

Hinweis: Sie müssen Ihre CameraX-Version auf 1.5.2 oder 1.6.0+ aktualisieren, um einen Absturz zu vermeiden, der mit einem hinzugefügten Dynamikbereichsmodus auf Android 17-Geräten zusammenhängt.

Bereiten Sie Ihre Apps, Bibliotheken, Tools und Game-Engines vor.

Wenn Sie ein Android-SDK, eine Bibliothek, ein Tool oder eine Game-Engine entwickeln, ist es wichtig, jetzt alle erforderlichen Updates vorzubereiten, damit App- und Spieleentwickler nicht durch Kompatibilitätsprobleme blockiert werden und die neuesten SDK-Funktionen nutzen können. Bitte informieren Sie Ihre Downstream-Entwickler, wenn Updates erforderlich sind, um Android 17 vollständig zu unterstützen.

Beim Testen wird Ihre Produktions-App oder eine Test-App, die Ihre Bibliothek oder Engine verwendet, über Google Play oder auf andere Weise auf einem Gerät oder Emulator mit Android 17 Beta 4 installiert. Gehen Sie alle Abläufe Ihrer App durch und suchen Sie nach funktionalen Problemen oder Problemen mit der Benutzeroberfläche. Jede Android-Version enthält Plattformänderungen, die den Datenschutz, die Sicherheit und die allgemeine Nutzerfreundlichkeit verbessern. Sehen Sie sich die Verhaltensänderungen an, die sich auf Apps auswirken, die unter Android 17 ausgeführt werden und auf Android 17 ausgerichtet sind, um Ihre Tests zu optimieren. Dazu gehören die folgenden Änderungen:

• Größenänderung auf großen Displays : Wenn Sie Android 17 (SDK 37) als Zielversion festlegen, können Sie die Einhaltung von Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis auf großen Displays nicht mehr deaktivieren.
• Dynamisches Laden von Code:Wenn Ihre App auf SDK 37 oder höher ausgerichtet ist, wird der in Android 14 eingeführte Schutz für das dynamische Laden von Code (Dynamic Code Loading, DCL) für DEX- und JAR-Dateien jetzt auf native Bibliotheken ausgeweitet. Alle nativen Dateien, die mit System.load() geladen werden, müssen als schreibgeschützt markiert werden. Andernfalls löst das System UnsatisfiedLinkError aus.
• CT standardmäßig aktivieren:Certificate Transparency (CT) ist standardmäßig aktiviert. Unter Android 16 ist CT verfügbar, aber Apps mussten aktiviert werden.
• Schutz des lokalen Netzwerks : Apps, die auf SDK 37 oder höher ausgerichtet sind, haben standardmäßig keinen Zugriff auf das lokale Netzwerk. Verwenden Sie nach Möglichkeit datenschutzfreundliche Auswahltools und die neue Berechtigung ACCESS_LOCAL_NETWORK für einen umfassenden, dauerhaften Zugriff.
• Härtung von Hintergrundaudio:Ab Android 17 erzwingt das Audio-Framework Einschränkungen für Hintergrundaudio-Interaktionen, einschließlich der Audiowiedergabe, Audiofokus-Anfragen und Lautstärkeänderungs-APIs. Wir haben Ihr Feedback berücksichtigt und seit Beta 2 einige Änderungen vorgenommen. Dazu gehören die targetSDK-Gating-Funktion für die Erzwingung von FGS während der Nutzung und die Ausnahme von Alarm-Audio. Weitere Informationen
• Erklärung zum NPU-Zugriff:Apps, die auf Android 17 ausgerichtet sind und direkt auf die NPU zugreifen müssen, müssen  FEATURE_NEURAL_PROCESSING_UNIT in ihrem Manifest deklarieren, um nicht vom Zugriff auf die NPU ausgeschlossen zu werden. Das gilt auch für Apps, die das LiteRT-NPU-Delegate, anbieterspezifische SDKs sowie die verworfene NNAPI verwenden.

Erste Schritte mit Android 17

Ihr Pixel-Gerät sollte in Kürze Android 17 erhalten, falls Sie nicht bereits an der Android-Beta teilgenommen haben. Wenn Sie kein Pixel-Gerät haben, können Sie 64‑Bit-Systemabbilder mit dem Android-Emulator in Android Studio verwenden. Wenn Sie derzeit Android 17 Beta 4.1 verwenden und noch keine Android 17 QPR1-Betaversion installiert haben, können Sie sich vom Programm abmelden. Ihnen wird dann die Release-Version von Android 17 Over-the-Air angeboten.

Android 17-Beta auf Partnergeräten erhalten

Android 17 ist als Betaversion für Smartphones, Tablets und Foldables von Partnern wie Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo und Xiaomi verfügbar.

Für eine optimale Entwicklung mit Android 17 empfehlen wir die Verwendung des neuesten Canary-Builds von Android Studio Quail. Nach der Einrichtung sollten Sie Folgendes tun:

• 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 Android-Emulator mit Android 17 und testen Sie sie gründlich.

Vielen Dank noch einmal an alle, die an unserem Android-Vorabversions- und Betaprogramm teilgenommen haben. Wir sind gespannt, wie Ihre Apps die Updates in Android 17 nutzen, und planen, Ihnen in Zukunft Updates in einem schnellen Release-Rhythmus zur Verfügung zu stellen.

Weitere Informationen zu Android 17