Heute veröffentlichen wir die zweite Betaversion von Android 17. Wir arbeiten weiter daran, eine Plattform zu entwickeln, bei der Datenschutz, Sicherheit und eine verbesserte Leistung im Vordergrund stehen. Dieses Update bietet eine Reihe neuer Funktionen, darunter die EyeDropper API und eine datenschutzfreundliche Kontaktauswahl. Außerdem fügen wir erweiterte APIs für die Entfernungsbestimmung und die geräteübergreifende Übergabe hinzu.

Mit dieser Version setzen wir die Änderung unseres Release-Rhythmus fort. Auf dieses jährliche große SDK-Release im zweiten Quartal folgt ein kleineres SDK-Update.

Nutzererfahrung und System-UI

Bubbles

Bubbles ist eine Funktion für den Fenstermodus, die eine neue schwebende UI-Erfahrung bietet, die von der Messaging Bubbles API getrennt ist. Nutzer können auf ihrem Smartphone, Faltgerät oder Tablet eine App-Bubble erstellen, indem sie lange auf ein App-Symbol im Launcher drücken. Auf großen Bildschirmen gibt es eine Bubble-Leiste als Teil der Taskleiste, in der Nutzer Bubbles organisieren, zwischen ihnen wechseln und sie zu und von verankerten Punkten auf dem Bildschirm verschieben können.

Sie sollten die Richtlinien für die Unterstützung des Multi-Window-Modus befolgen, damit Ihre Apps als Bubbles korrekt funktionieren.

Bubbles sind in der zweiten Betaversion 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 jedem Pixel auf dem Display anfordern, ohne dass dafür 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 READ_CONTACTS-Berechtigungen reduziert. Außerdem können Nutzer Kontakte aus den privaten oder geschäftlichen Profilen 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 der Zeigererfassung mit Touchpads

Bisher haben Touchpads Ereignisse ganz anders als Mäuse gemeldet, wenn eine App den Zeiger erfasst hat. Sie haben die Positionen der Finger auf dem Touchpad gemeldet, nicht die relativen Bewegungen, die von einer Maus gemeldet würden. Dadurch war es ziemlich schwierig, Touchpads in Ego-Shootern richtig zu unterstützen. Jetzt erkennt das System standardmäßig Zeigerbewegungen und Scrollgesten, wenn das Touchpad erfasst wird, und meldet sie wie Mausereignisse. Sie können weiterhin die alten, detaillierten Daten zur Fingerposition anfordern, indem Sie die Erfassung explizit im neuen „absoluten“ Modus 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 der Animationen und des Ladens der Daten einnimmt. So lassen sich die UI-Anpassungen verbessern.

Konnektivität und geräteübergreifende Funktionen

Übergabe von Apps zwischen Geräten

Mit einer neuen Handoff API können Sie den Anwendungsstatus angeben, der auf einem anderen Gerät, z. B. einem Android-Tablet, fortgesetzt werden soll. Wenn diese 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 Aufgabenfortsetzung ermöglichen, sodass Nutzer genau dort weitermachen können, wo sie in ihrem Android-Ökosystem aufgehört haben. Wichtig ist, dass Handoff sowohl Übergänge von App zu App als auch App-zu-Web-Fallback unterstützt. So wird maximale Flexibilität geboten und eine vollständige Nutzererfahrung gewährleistet, auch wenn die native App nicht auf dem empfangenden Gerät installiert ist.

Erweiterte APIs für die Entfernungsbestimmung

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

1. UWB DL-TDOA , mit der Apps UWB für die Navigation in Innenräumen verwenden können. Diese API-Oberfläche entspricht der FIRA-Spezifikation (Fine Ranging Consortium) 4.0 DL-TDOA und ermöglicht eine datenschutzfreundliche Navigation in Innenräumen, da das Gerät nicht vom Anker getrackt wird.
2. Näherungserkennung , mit der Apps die neue Spezifikation zur Entfernungsbestimmung verwenden können, die von der WFA (WiFi Alliance) eingeführt wird. Diese Technologie bietet im Vergleich zur bestehenden auf Wi-Fi Aware basierenden Spezifikation zur Entfernungsbestimmung eine verbesserte Zuverlässigkeit und Genauigkeit.

Verbesserungen bei Datentarifen

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

Kernfunktionen, Datenschutz und Leistung

Zugriff auf lokales Netzwerk

In Android 17 wird die ACCESS_LOCAL_NETWORK Laufzeitberechtigung eingeführt, um Nutzer vor unbefugtem Zugriff auf das lokale Netzwerk zu schützen. Da diese Berechtigung zur vorhandenen Berechtigungsgruppe NEARBY_DEVICES gehört, 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) erkennen und sich mit ihnen verbinden, z. B. Smart-Home-Geräte oder Streamingempfänger. So wird verhindert, dass schädliche Apps den uneingeschränkten Zugriff auf das lokale Netzwerk für verdecktes Nutzertracking und Fingerprinting ausnutzen. 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 explizit zur Laufzeit anfordern, um die Kommunikation im lokalen Netzwerk aufrechtzuerhalten.

Broadcast für Ä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. Dieser Intent 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 zu verhindern, dass der Zugriff auf die NPU blockiert wird. Dazu gehören Apps, die den LiteRT NPU-Delegaten, anbieterspezifische SDKs sowie die veraltete NNAPI verwenden.

Unterstützung für 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 Zeitobjekten ermöglicht.

SMS-OTP-Schutz

Android erweitert den SMS-OTP-Schutz, indem der Zugriff auf SMS-Nachrichten mit OTP 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. Bestimmte Apps wie die Standard-SMS-App und die App, die dem Hash entspricht, sind jedoch von dieser Verzögerung ausgenommen. Mit diesem Update wird der Schutz auf alle SMS-Nachrichten mit OTP ausgeweitet. Bei den meisten Apps sind SMS-Nachrichten mit einem OTP erst nach einer Verzögerung von drei Stunden zugänglich, um das Abfangen von OTPs zu verhindern. Der Broadcast SMS_RECEIVED_ACTION wird zurückgehalten und Datenbankabfragen des SMS-Anbieters werden gefiltert. Die SMS-Nachricht ist für diese Apps nach der Verzögerung verfügbar. 

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

Wenn die App die Berechtigung zum Lesen von SMS-Nachrichten hat, aber nicht der beabsichtigte Empfänger des OTP ist (wie durch die Domainbestätigung ermittelt), ist die SMS-Nachricht 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 genannten Domain verknüpft sind, den Bestätigungscode programmatisch lesen können. Diese Änderung gilt für alle Apps, unabhängig von ihrem Ziel-API-Level.

Verzögerter Zugriff auf Standard-SMS-Nachrichten mit OTP

Bei SMS-Nachrichten mit einem OTP, die nicht das WebOTP- oder SMS Retriever-Format verwenden, ist die OTP-SMS für die meisten Apps erst nach drei Stunden zugänglich. 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 Assistant-App sowie Companion-Apps für verbundene Geräte usw. sind von dieser Verzögerung ausgenommen.

Alle Apps, die zum Extrahieren von OTPs auf das Lesen von SMS-Nachrichten angewiesen sind, sollten auf die Verwendung der SMS Retriever oder SMS User Consent APIs umgestellt werden, um die Funktionalität aufrechtzuerhalten.

Zeitplan für Android 17

Wir werden schnell von dieser Betaversion zum Meilenstein der Plattformstabilität übergehen, der für März geplant ist. Bei diesem Meilenstein stellen wir die endgültigen 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 in den Monaten vor der allgemeinen Verfügbarkeit von Android 17 Tests durchführen und Nutzerfeedback einholen.

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 Änderungen am Verhalten von Apps einführen, die zu Inkompatibilitäten führen können. Wir planen ein kleineres SDK-Release im vierten Quartal mit zusätzlichen APIs und Funktionen.

Erste Schritte mit Android 17

Sie können jedes unterstützte Pixel-Gerät registrieren, um dieses und zukünftige Android-Beta-Updates kabellos zu erhalten. Wenn Sie kein Pixel-Gerät haben, können Sie die 64-Bit-System-Images mit dem Android Emulator verwenden in Android Studio.

Wenn Sie derzeit am Android-Betaprogramm teilnehmen, wird Ihnen ein kabelloses Update auf die zweite Betaversion angeboten.

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

Wir freuen uns auf Ihr Feedback. Melden Sie Probleme und senden Sie Feature Requests 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 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 ausführlich.

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

kabellos für alle späteren Vorschau- und Betaversionen.

Weitere Informationen finden Sie auf der Website für Android-Entwickler.

Mitreden

Auf dem Weg zur Plattformstabilität und zur allgemeinen Verfügbarkeit von Android 17 im Laufe dieses Jahres ist Ihr Feedback weiterhin unser wertvollstes Gut. Egal, ob Sie ein Early Adopter im Canary-Channel oder ein App-Entwickler sind, der die zweite Betaversion testet: Treten Sie unseren Communities bei und geben Sie uns Feedback. Wir sind gespannt auf Ihre Meinung.