Zweite Betaversion von Android 17

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 Haupt-SDK-Version im 2. Quartal folgt ein untergeordnetes SDK-Update.

Nutzererfahrung und System-UI

Bubbles

Bubbles ist 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-Bubble erstellen, indem sie lange auf ein App-Symbol im Launcher tippen. 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 Mehrfenstermodus befolgen, damit Ihre Apps als Blasen richtig funktionieren.

Blasen 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 temporären, sitzungsbasierten Lesezugriff nur auf die vom Nutzer angeforderten Datenfelder. Dadurch wird die Notwendigkeit der umfassenden Berechtigung READ_CONTACTS verringert. 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 Zeigererfassung und Touchpads

Bisher wurden Ereignisse auf Touchpads ganz anders als bei 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 Daten zum Fingerort 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 des interaktiven Auswahltools

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übergreifende Funktionen

Geräteübergreifende App-Übergabe

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 der Nutzer die Funktion aktiviert hat, 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 App zu App als auch App-zu-Web-Fallbacks unterstützt. Das bietet maximale Flexibilität und sorgt für eine vollständige Nutzung, auch wenn die systemeigene App nicht auf dem empfangenden Gerät installiert ist.

Erweiterte APIs für die Reichweite

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 vorhandenen Spezifikation für die Entfernungsmessung auf Basis von Wifi Aware eine höhere Zuverlässigkeit und Genauigkeit.

Verbesserungen bei Datentarifen

Zur Optimierung der Media-Qualitä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 unbefugtem 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. Dadurch wird verhindert, dass schädliche Apps den uneingeschränkten Zugriff auf das lokale Netzwerk für das verdeckte Nutzer-Tracking und das 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 zur Laufzeit explizit anfordern, um die Kommunikation im lokalen Netzwerk aufrechtzuerhalten.

Broadcast für Änderung der Zeitzonenverschiebung

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 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 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. Mit diesem Update wird der Schutz auf alle SMS-Nachrichten mit Einmalpasswörtern ausgeweitet. Bei den meisten Apps sind SMS-Nachrichten mit einem Einmalpasswort erst nach einer Verzögerung von drei Stunden zugänglich, 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 Einmalpassworts ist (wie durch die Domainbestätigung ermittelt), ist die SMS im WebOTP-Format erst nach drei Stunden zugänglich. Diese Änderung soll die Sicherheit der Nutzer 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 vom Ziel-API-Level.

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

Bei SMS-Nachrichten mit einem Einmalpasswort, 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 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.

Zeitplan für Android 17

Wir werden schnell von dieser Betaversion zum Meilenstein „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 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. Die bevorstehende Version im 2. Quartal ist die einzige, in der wir geplante funktionsgefährdende Änderungen an Apps einführen. Wir planen, im vierten Quartal eine untergeordnete SDK-Version 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 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 die Android 26Q1-Betaversion haben und die endgültige stabile Version von 26Q1 verwenden und die Betaversion beenden möchten, müssen Sie das Over-the-Air-Update auf die 26Q2-Betaversion 2 ignorieren und auf die Veröffentlichung von 26Q1 warten.

Wir freuen uns über Ihr Feedback. Melden Sie Probleme und senden Sie Feature Requests bitte 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 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 gesamten Release-Zyklus von Android 17. Nachdem Sie eine Betaversion 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 unser wertvollstes Gut. Egal, ob Sie Canary-Nutzer sind oder App-Entwickler, die Beta 2 testen: Treten Sie unseren Communities bei und geben Sie Feedback. Wir sind gespannt auf deine Meinung.