Heute veröffentlichen wir die zweite 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. Dieses Update bietet eine Reihe neuer Funktionen, darunter die EyeDropper API und eine datenschutzfreundliche Kontaktauswahl. Außerdem fügen wir APIs für erweiterte Entfernungsmessung, geräteübergreifende Übergabe und mehr hinzu.

Mit dieser Version setzen wir die Änderung unseres Release-Rhythmus fort. Auf diese jährliche Hauptversion des SDK im 2. Quartal folgt ein untergeordnetes SDK-Update.

Nutzererfahrung und System-UI

Bubbles

Blasen sind ein Fenstermodus-Feature, das eine neue schwebende Benutzeroberfläche bietet, die von der Messaging Bubbles API getrennt ist. Nutzer können auf ihrem Smartphone, Falt-Smartphone oder Tablet eine App-Blase erstellen, indem sie lange auf ein App-Symbol im Launcher drücken. Auf großen Bildschirmen ist die Blasenleiste Teil der Taskleiste. Nutzer können Blasen organisieren, zwischen ihnen wechseln und sie zu und von Ankerpunkten auf dem Bildschirm verschieben.

Sie sollten die Richtlinien für die Unterstützung des Mehrfenstermodus befolgen, damit Ihre Apps als Blasen richtig funktionieren.

Bubbles sind in Beta 2 noch nicht vollständig aktiviert. Sie werden in einem zukünftigen Build von Android 17 verfügbar sein.

EyeDropper API

Mit einer neuen EyeDropper API auf Systemebene kann Ihre App eine Farbe von einem beliebigen Pixel auf dem Display anfordern, ohne dass sensible Berechtigungen für die Bildschirmaufnahme 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)
}

Kontaktauswahl

Eine neue Kontaktauswahl auf Systemebene über ACTION_PICK_CONTACTS gewährt nur temporären, sitzungsbasierten Lesezugriff auf die vom Nutzer angeforderten Datenfelder. Dadurch wird die Notwendigkeit der umfassenden Berechtigung READ_CONTACTS reduziert. Außerdem können Sie Elemente aus dem privaten Profil oder dem Arbeitsprofil des Geräts auswählen.

val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) {
    if (it.resultCode == RESULT_OK) {
        val uri = it.data?.data ?: return@rememberLauncherForActivityResult
        // Handle result logic
        processContactPickerResults(uri)
    }
}

val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
val intent = Intent(ACTION_PICK_CONTACTS).apply {
    putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields)
    putExtra(EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
}

contactPicker.launch(intent)

Einfachere Kompatibilität von Touchpads mit der Cursorerfassung

Bisher wurden Ereignisse von Touchpads ganz anders als von Mäusen gemeldet, wenn eine App den Mauszeiger erfasst hatte. Es wurden die Positionen der Finger auf dem Touchpad gemeldet und nicht die relativen Bewegungen, die von einer Maus gemeldet würden. Das machte es ziemlich schwierig, Touchpads in Ego-Shootern richtig zu unterstützen. Standardmäßig erkennt das System jetzt Zeigerbewegungen und Scrollgesten, wenn das Touchpad erfasst wird, und meldet sie wie Mausereignisse. Sie können die alten, detaillierten Finger-Standortdaten weiterhin anfordern, indem Sie die Erfassung im neuen „absoluten“ Modus explizit anfordern. 

// To request the new default relative mode (mouse-like events)
// This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE
view.requestPointerCapture()

// To request the legacy absolute mode (raw touch coordinates)
view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE)

Ruhebereich für interaktive Auswahl

Durch Aufrufen von getInitialRestingBounds in der ChooserSession von Android kann Ihre App die Zielposition ermitteln, die die Auswahl nach Abschluss von Animationen und Datenladevorgängen einnimmt. So lassen sich UI-Anpassungen besser vornehmen.

Konnektivität und geräteübergreifend

App-Übergabe zwischen Geräten

Mit der neuen Handoff API können Sie den Anwendungsstatus angeben, der auf einem anderen Gerät, z. B. einem Android-Tablet, fortgesetzt werden soll. Wenn die Funktion aktiviert ist, synchronisiert das System den Status über CompanionDeviceManager und zeigt im Launcher der Geräte in der Nähe des Nutzers einen Vorschlag für die Übergabe an. Diese Funktion soll eine nahtlose Fortsetzung von Aufgaben ermöglichen, sodass Nutzer in ihrem Android-Ökosystem genau dort weitermachen können, wo sie in ihrem Workflow aufgehört haben. Wichtig ist, dass Handoff sowohl Übergänge von systemeigener App zu systemeigener App als auch App-zu-Web-Fallbacks unterstützt. Das sorgt für maximale Flexibilität und dafür, dass Nutzer die Inhalte auch dann vollständig sehen können, wenn die systemeigene App nicht auf dem empfangenden Gerät installiert ist.

Erweiterte APIs für die Reichweitenermittlung

Wir fügen Unterstützung für zwei neue Technologien zur Entfernungsmessung hinzu: 

1. UWB DL-TDOA: Apps können UWB für die Navigation in Innenräumen verwenden. Diese API-Oberfläche entspricht der FIRA-Spezifikation (Fine Ranging Consortium) 4.0 DL-TDOA und ermöglicht datenschutzfreundliche Indoor-Navigation  (ohne Tracking des Geräts durch den Anker).
2. Erkennung von Geräten in der Nähe: Apps können die neue Spezifikation für die Entfernungsmessung verwenden, die von der WFA (WiFi Alliance) eingeführt wird. Diese Technologie bietet im Vergleich zur bestehenden Wifi Aware-basierten Spezifikation eine höhere Zuverlässigkeit und Genauigkeit.

Verbesserungen bei Datentarifen

Zur Optimierung der Mediaqualität kann Ihre App jetzt mit getStreamingAppMaxDownlinkKbps und getStreamingAppMaxUplinkKbps die vom Mobilfunkanbieter zugewiesenen maximalen Datenraten für Streaminganwendungen abrufen.

Hauptfunktionen, Datenschutz und Leistung

Zugriff auf lokales Netzwerk

In Android 17 wird die Laufzeitberechtigung ACCESS_LOCAL_NETWORK eingeführt, um Nutzer vor unberechtigtem Zugriff auf das lokale Netzwerk zu schützen. Da dies unter die vorhandene Berechtigungsgruppe NEARBY_DEVICES fällt, werden Nutzer, die bereits andere NEARBY_DEVICES-Berechtigungen erteilt haben, nicht noch einmal aufgefordert. Wenn Sie diese Berechtigung deklarieren und anfordern, kann Ihre App Geräte im lokalen Netzwerk (LAN) wie Smart-Home-Geräte oder Streamingempfänger erkennen und eine Verbindung zu ihnen herstellen. So wird verhindert, dass schädliche Apps uneingeschränkten Zugriff auf das lokale Netzwerk nutzen, um Nutzer heimlich zu verfolgen und Fingerprints zu erstellen. Apps, die auf Android 17 oder höher ausgerichtet sind, haben jetzt zwei Möglichkeiten, die Kommunikation mit LAN-Geräten aufrechtzuerhalten: Sie können systemvermittelte, datenschutzfreundliche Geräteauswahlen verwenden, um die Berechtigungsaufforderung zu überspringen, oder diese neue Berechtigung zur Laufzeit explizit anfordern, um die lokale Netzwerkkommunikation aufrechtzuerhalten.

Broadcast zur Änderung des Zeitzonen-Offsets

Android bietet jetzt einen zuverlässigen Broadcast-Intent, ACTION_TIMEZONE_OFFSET_CHANGED, der ausgelöst wird, wenn sich der Zeitzonen-Offset des Systems ändert, z. B. bei der Umstellung auf die Sommerzeit. Dies ergänzt die vorhandenen Broadcast-Intents ACTION_TIME_CHANGED und ACTION_TIMEZONE_CHANGED, die ausgelöst werden, wenn sich der Unix-Zeitstempel bzw. die Zeitzonen-ID ändert.

NPU-Verwaltung und ‑Priorisierung

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 am Zugriff auf die NPU gehindert zu werden. Dazu gehören Apps, die den LiteRT-NPU-Delegate, anbieterspezifische SDKs sowie die eingestellte NNAPI verwenden.

Unterstützung von ICU 78 und Unicode 17

Die wichtigsten Internationalisierungsbibliotheken wurden auf ICU 78 aktualisiert. Dadurch wird die Unterstützung für neue Skripts, Zeichen und Emoji-Blöcke erweitert und die direkte Formatierung von time-Objekten ermöglicht.

SMS-OTP-Schutz

Android erweitert den Schutz von SMS-Einmalpasswörtern, indem der Zugriff auf SMS-Nachrichten mit Einmalpasswörtern automatisch verzögert wird. Bisher konzentrierte sich der Schutz hauptsächlich auf das SMS Retriever-Format, bei dem die Zustellung von Nachrichten mit einem SMS Retriever-Hash für die meisten Apps um drei Stunden verzögert wird. Bei bestimmten Apps wie der Standard-SMS-App usw. und der App, die dem Hash entspricht, tritt diese Verzögerung jedoch nicht auf. Durch dieses Update wird der Schutz auf alle SMS-Nachrichten mit OTP ausgeweitet. Bei den meisten Apps sind SMS-Nachrichten mit einem Einmalpasswort erst nach einer Verzögerung von drei Stunden verfügbar, um das Abfangen von Einmalpasswörtern zu verhindern. Der Broadcast SMS_RECEIVED_ACTION wird zurückgehalten und Datenbankabfragen des SMS-Anbieters werden gefiltert. Die SMS ist nach der Verzögerung für diese Apps verfügbar. 

Verzögerter Zugriff auf SMS-Nachrichten im WebOTP-Format

Wenn die App die Berechtigung zum Lesen von SMS hat, aber nicht der beabsichtigte Empfänger des OTP ist (wie durch die Domainbestätigung ermittelt), ist die SMS im WebOTP-Format erst nach drei Stunden zugänglich. Diese Änderung soll die Nutzersicherheit verbessern, indem sichergestellt wird, dass nur Apps, die mit der in der Nachricht erwähnten Domain verknüpft sind, den Bestätigungscode programmatisch lesen können. Diese Änderung gilt für alle Apps, unabhängig von ihrer Ziel-API-Ebene.

Verzögerter Zugriff auf Standard-SMS mit OTP

Bei SMS-Nachrichten mit einem Einmalpasswort, die nicht das WebOTP- oder SMS Retriever-Format verwenden, ist das Einmalpasswort in den meisten Apps erst nach drei Stunden verfügbar. Diese Änderung gilt nur für Apps, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind.

Bestimmte Apps wie die Standard-SMS-App, die Assistenten-App sowie Companion-Apps für verbundene Geräte usw. sind von dieser Verzögerung ausgenommen.

Alle Apps, die zum Extrahieren von Einmalpasswörtern auf das Lesen von SMS angewiesen sind, sollten auf die APIs SMS Retriever oder SMS User Consent umgestellt werden, um die Funktionalität aufrechtzuerhalten.

Der Zeitplan für Android 17

Wir werden diese Beta-Phase schnell durchlaufen und im März den Meilenstein „Plattformstabilität“ erreichen. Zu diesem Zeitpunkt stellen wir die finalen SDK-/NDK-APIs bereit. Ab diesem Zeitpunkt kann Ihre App auf SDK 37 ausgerichtet und bei Google Play veröffentlicht werden. So können Sie Ihre Tests abschließen und in den Monaten vor der allgemeinen Verfügbarkeit von Android 17 Nutzerfeedback sammeln.

Ein Jahr voller Veröffentlichungen

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.

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 2.

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 2 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 Vorabversions-/Beta-Systemimages und das SDK regelmäßig während des Android 17-Releasezyklus. Nachdem Sie einen Beta-Build installiert haben, erhalten Sie zukünftige Updates automatisch. 

Over-the-Air für alle späteren Vorabversionen und Betas.

Weitere Informationen

Mitreden

Auf dem Weg zur Plattformstabilität und zur allgemeinen Verfügbarkeit von Android 17 im weiteren Jahresverlauf ist Ihr Feedback weiterhin von unschätzbarem Wert. Egal, ob Sie Early Adopter im Canary-Channel oder App-Entwickler sind, der Beta 2 testet: Treten Sie unseren Communities bei und geben Sie Feedback. Wir hören zu.