Die vierte Betaversion von Android 17

Android 17 hat Beta 4 erreicht, die letzte geplante Betaversion dieses Release-Zyklus. Dies ist ein wichtiger Meilenstein für die App-Kompatibilität und Plattformstabilität. Egal, ob Sie die Nutzerfreundlichkeit Ihrer App optimieren, ein reibungsloses Edge-to-Edge-Rendering sicherstellen oder die neuesten APIs nutzen möchten – Beta 4 bietet die nahezu finale Umgebung, die Sie für Ihre Tests benötigen. 

Apps, Bibliotheken, Tools und Spiel-Engines vorbereiten

Wenn Sie ein Android SDK, eine Bibliothek, ein Tool oder eine Spiel-Engine entwickeln, ist es wichtig, dass Sie jetzt alle erforderlichen Updates vorbereiten. So verhindern Sie, dass Ihre nachgelagerten App- und Spieleentwickler durch Kompatibilitätsprobleme blockiert werden, und ermöglichen ihnen, die neuesten SDK-Funktionen zu nutzen. Bitte informiere deine nachgelagerten Entwickler, falls 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 Funktions- oder UI-Problemen. 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 fokussieren. Dazu gehören:

• Größenänderung auf großen Displays:Wenn Sie Android 17 als Zielversion festlegen, können Sie die 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 Android 17 oder höher ausgerichtet ist, gilt der Schutz durch Safer Dynamic Code Loading (DCL), der in Android 14 eingeführt wurde, für DEX- und JAR-Dateien jetzt auch für native Bibliotheken. Alle nativen Dateien, die mit System.load() geladen werden, müssen als schreibgeschützt gekennzeichnet sein. Andernfalls gibt das System einen 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.)
• Schutzmaßnahmen für lokale Netzwerke:Bei Apps, die auf Android 17 oder höher ausgerichtet sind, ist der Zugriff auf lokale Netzwerke standardmäßig blockiert. Wechseln Sie nach Möglichkeit zu datenschutzfreundlichen Auswahlfunktionen und verwenden Sie die neue Berechtigung ACCESS_LOCAL_NETWORK für umfassenden, dauerhaften Zugriff.
• Härtung von Hintergrundaudio:Ab Android 17 erzwingt das Audio-Framework Einschränkungen für Hintergrundaudio-Interaktionen, einschließlich Audiowiedergabe, Audiofokus-Anfragen und APIs für Lautstärkeänderungen. Auf Grundlage Ihres Feedbacks haben wir seit Beta 2 einige Änderungen vorgenommen, darunter die Einschränkung von targetSDK, die Durchsetzung von Vordergrunddiensten während der Nutzung und die Ausnahme von Weckertönen. Ausführliche Informationen finden Sie in der aktualisierten Anleitung.

App-Arbeitsspeicherlimits

Android führt App-Arbeitsspeicherlimits ein, die auf dem gesamten RAM eines Geräts basieren. So soll eine stabilere und deterministischere Umgebung für Ihre Apps und Android-Nutzer geschaffen werden. In Android 17 werden die Limits konservativ festgelegt, um System-Baselines zu erstellen. So werden extreme Speicherlecks und andere Ausreißer erkannt, bevor sie systemweite Instabilität verursachen, die zu UI-Ruckeln, schneller Akkuentladung und dem Beenden von Apps führt. Wir gehen davon aus, dass die Auswirkungen auf die meisten App-Sitzungen minimal sein werden. Wir empfehlen jedoch die folgenden Best Practices für den Arbeitsspeicher, einschließlich der Festlegung einer Baseline für den Arbeitsspeicher.

In der aktuellen Implementierung enthält getDescription in ApplicationExitInfo den String „MemoryLimiter“, wenn Ihre App betroffen war. Sie können auch triggerbasiertes Profiling mit TRIGGER_TYPE_ANOMALY verwenden, um Heap-Dumps zu erhalten, die erfasst werden, wenn das Speicherlimit erreicht ist.

Damit Sie Speicherlecks leichter finden können, bietet Android Studio Panda eine LeakCanary-Integration direkt im Android Studio Profiler als dedizierte Aufgabe, die in die IDE eingebunden und vollständig in Ihren Quellcode integriert ist.

Ein geringerer Speicherbedarf führt direkt zu einer flüssigeren Leistung, einer längeren Akkulaufzeit und einer erstklassigen Nutzung auf allen Formfaktoren. Lassen Sie uns gemeinsam eine schnellere und zuverlässigere Zukunft für das Android-Ökosystem schaffen.

Profilerstellungstrigger für App-Anomalien

Android führt einen Dienst zur Anomalieerkennung auf dem Gerät ein, der ressourcenintensive Verhaltensweisen und potenzielle Kompatibilitätsregressionen überwacht. Dieser Dienst ist in ProfilingManager integriert und ermöglicht es Ihrer App, Profiling-Artefakte zu empfangen, die durch bestimmte vom System erkannte Ereignisse ausgelöst werden.

Verwenden Sie den Trigger TRIGGER_TYPE_ANOMALY, um Leistungsprobleme des Systems zu erkennen, z. B. übermäßige Binderaufrufe und übermäßige Arbeitsspeichernutzung. Wenn eine App die vom Betriebssystem definierten Arbeitsspeicherlimits überschreitet, können Entwickler über den Anomalie-Trigger App-spezifische Heap-Dumps erhalten, um Arbeitsspeicherprobleme zu identifizieren und zu beheben. Außerdem stellt der Anomalie-Trigger bei übermäßigem Binder-Spam ein Stack-Sampling-Profil für Binder-Transaktionen bereit.

Dieser API-Callback erfolgt vor allen vom System auferlegten Maßnahmen. So können Entwickler beispielsweise Debug-Daten erfassen, bevor die App vom System beendet wird, weil die Speichergrenzen überschritten wurden. Informationen zur Verwendung des Triggers finden Sie in unserer Dokumentation zum triggerbasierten Profiling.

    val profilingManager = applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList<ProfilingTrigger>()  
    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer<ProfilingResult> { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 
    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)
}

Post-Quanten-Kryptografie (PQC) im Android Keystore

Der Android-Keystore unterstützt jetzt den NIST-standardisierten ML-DSA (Module-Lattice-Based Digital Signature Algorithm). Auf unterstützten Geräten können Sie ML-DSA-Schlüssel generieren und damit quantensichere Signaturen erstellen – vollständig in der sicheren Hardware des Geräts. Der Android-Keystore stellt die Algorithmusvarianten ML-DSA-65 und ML-DSA-87 über die Standard-APIs der Java Cryptographic Architecture bereit: KeyPairGenerator, KeyFactory und Signature. Weitere Informationen finden Sie in unserer Entwicklerdokumentation.

KeyPairGenerator generator = KeyPairGenerator.getInstance(
        “ML-DSA-65”, "AndroidKeyStore");
generator.initialize(
        new KeyGenParameterSpec.Builder(
                “my-key-alias”,
                KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY)
        .build());
KeyPair keyPair = generator.generateKeyPair();

Erste Schritte mit Android 17

Sie können jedes unterstützte Pixel-Gerät registrieren, um dieses und zukünftige Android-Beta-Updates per Over-the-Air-Update 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 du derzeit am Android-Betaprogramm teilnimmst, wird dir ein Over-the-Air-Update auf Beta 4 angeboten.

Sie können weiterhin Probleme melden und Feature Requests einreichen. Nutzen Sie dazu die Feedbackseite. Je früher wir Ihr Feedback erhalten, desto mehr können wir davon in die endgültige Version einfließen lassen.

Für die bestmögliche Entwicklung mit Android 17 empfehlen wir, die neueste Vorabversion von Android Studio (Panda) zu verwenden. 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 Feedback-Seite.
• Testen Sie Ihre aktuelle App auf Kompatibilität, finden Sie heraus, ob Ihre App von Änderungen in Android 17 betroffen ist, und installieren Sie Ihre App auf einem Gerät oder Emulator mit Android 17, um sie umfassend zu testen.

Wir aktualisieren die Vorabversionen/Beta-System-Images und das SDK während des gesamten Android 17-Release-Zyklus regelmäßig. Nachdem du einen Beta-Build installiert hast, erhältst du automatisch Over-the-Air-Updates für alle zukünftigen Vorabversionen und Betas.

Weitere Informationen findest du auf der Android 17-Entwicklerwebsite.

Mitdiskutieren

Ihr Feedback ist für uns nach wie vor sehr wertvoll. Egal, ob ihr zu den ersten Nutzern im Canary-Kanal gehört oder App-Entwickler seid, die Beta 4 testen – wir freuen uns, wenn ihr unseren Communities beitretet und Feedback gebt. Wir sind gespannt auf deine Meinung.