Die vierte Betaversion von Android 17

Android 17 hat die Beta 4 erreicht, die letzte geplante Betaversion dieses Release-Zyklus. Das ist ein wichtiger Meilenstein für die App-Kompatibilität und die Plattformstabilität. Ob Sie die Nutzerfreundlichkeit Ihrer App optimieren, für ein reibungsloses Rendering von Edge zu Edge sorgen oder die neuesten APIs nutzen – Beta 4 bietet die nahezu finale Umgebung, die Sie für Tests benötigen. 

Apps, Bibliotheken, Tools und Spiel-Engines vorbereiten

Wenn Sie ein Android SDK, eine Android-Bibliothek, ein Android-Tool oder eine Android-Spiel-Engine entwickeln, müssen Sie jetzt alle erforderlichen Updates vorbereiten, damit Ihre nachgelagerten App- und Spieleentwickler nicht durch Kompatibilitätsprobleme blockiert werden und die neuesten SDK-Funktionen nutzen können. Informieren Sie Ihre nachgelagerten 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. Arbeiten 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 fokussieren. Dazu gehören die folgenden Änderungen:

• Größenänderung auf großen Displays: Wenn Sie auf Android 17 ausgerichtet sind, 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 in Android 14 eingeführte sicherere Schutz für das dynamische Laden von Code (Dynamic Code Loading, DCL) 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 markiert sein. Andernfalls gibt 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 aktiviertwerden.)
• Schutz für lokale Netzwerke:Bei Apps, die auf Android 17 oder höher ausgerichtet sind, wird der Zugriff auf lokale Netzwerke standardmäßig blockiert. Verwenden Sie nach Möglichkeit datenschutzfreundliche Auswahltools und verwenden Sie die neue ACCESS_LOCAL_NETWORK Berechtigung 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, von Audiofokus-Anfragen und von APIs zur Lautstärkeänderung. Wir haben Ihr Feedback berücksichtigt und seit Beta 2 einige Änderungen vorgenommen, darunter die targetSDK-Gating-Erzwingung für FGS während der Nutzung und die Ausnahme von Alarm-Audio. Ausführliche Informationen finden Sie in der aktualisierten Anleitung.

App-Arbeitsspeicherlimits

Android führt App-Arbeitsspeicherlimits ein, die auf dem gesamten RAM des Geräts basieren, um eine stabilere und deterministischere Umgebung für Ihre Anwendungen und Android-Nutzer zu schaffen. In Android 17 werden die Limits konservativ festgelegt, um System-Baselines zu erstellen und extreme Speicherlecks und andere Ausreißer zu erkennen, bevor sie zu systemweiter Instabilität führen, die sich in UI-Rucklern, schneller Akkuentladung und dem Beenden von Apps äußert. 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 die triggerbasierte Profilerstellung mit TRIGGER_TYPE_ANOMALY verwenden, um Heap-Dumps zu erhalten, die erfasst werden, wenn das Arbeitsspeicherlimit erreicht wird.

Um Ihnen bei der Suche nach Speicherlecks zu helfen, bietet Android Studio Panda die LeakCanary-Integration direkt im Android Studio Profiler als eigene Aufgabe, die in die IDE eingebettet und vollständig in Ihren Quellcode integriert ist.

Ein geringerer Arbeitsspeicherbedarf führt direkt zu einer reibungsloseren Leistung, einer längeren Akkulaufzeit und einer erstklassigen Nutzererfahrung auf allen Formfaktoren. Gemeinsam können wir eine schnellere und zuverlässigere Zukunft für das Android-Ökosystem schaffen.

Profilerstellungstrigger für App-Anomalien

Android führt einen On-Device-Dienst zur Erkennung von Anomalien ein, der ressourcenintensive Verhaltensweisen und potenzielle Kompatibilitätsregressionen überwacht. Dieser Dienst ist in ProfilingManager integriert und ermöglicht es Ihrer App, Profilerstellungsartefakte zu empfangen, die durch bestimmte vom System erkannte Ereignisse ausgelöst werden.

Verwenden Sie den TRIGGER_TYPE_ANOMALY Trigger, um Probleme mit der Systemleistung zu erkennen, z. B. übermäßige Binder-Aufrufe und übermäßige Arbeitsspeichernutzung. Wenn eine App die vom Betriebssystem definierten Arbeitsspeicherlimits überschreitet, können Entwickler mit dem Anomalie-Trigger app-spezifische Heap-Dumps erhalten, um Arbeitsspeicherprobleme zu identifizieren und zu beheben. Außerdem bietet der Anomalie-Trigger bei übermäßigem Binder-Spam ein Stack-Sampling-Profil für Binder-Transaktionen.

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

    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 (Post-Quantum Cryptography, PQC) im Android Keystore

Android Keystore unterstützt jetzt den von 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, und zwar vollständig in der sicheren Hardware des Geräts. Android Keystore stellt die Algorithmusvarianten ML-DSA-65 und ML-DSA-87 über die Standard-Java Cryptographic Architecture-APIs zur Verfügung: 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 kabellos 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, wird Ihnen ein kabelloses Update auf Beta 4 angeboten.

Sie können weiterhin Probleme melden und Funktionswünsche einreichen , und zwar 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 Issue 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 für die Vorschauversion/Betaversion und das SDK während des gesamten Release-Zyklus von Android 17 regelmäßig. Nachdem Sie einen Beta-Build installiert haben, erhalten Sie zukünftige Updates für alle späteren Vorschauversionen und Betaversionen automatisch kabellos.

Ausführliche Informationen finden Sie auf der Android 17-Entwicklerwebsite.

Mitreden

Ihr Feedback ist nach wie vor unser wertvollstes Gut. Ob Sie ein Early Adopter im Canary-Channel oder ein App-Entwickler sind, der mit Beta 4 testet, sollten Sie unseren Communities beitreten und Feedback geben. Wir sind gespannt auf Ihre Meinung.