Produktneuheiten

Vierte Betaversion von Android 17

Lesezeit: 4 Minuten
Daniel Galpin
Developer Advocate

Android 17 hat Beta 4 erreicht, die letzte geplante Betaversion dieses Releasezyklus. Das ist ein wichtiger Meilenstein für die App-Kompatibilität und die Stabilität der Plattform. Ob Sie die User Experience Ihrer App optimieren, für ein reibungsloses Edge-to-Edge-Rendering sorgen oder die neuesten APIs nutzen – Beta 4 bietet die nahezu endgültige Umgebung, die Sie für Tests benötigen. 

Apps, Bibliotheken, Tools und Game-Engines vorbereiten

Wenn Sie ein Android-SDK, eine Bibliothek, ein Tool oder eine Game-Engine entwickeln, ist es wichtig, jetzt alle erforderlichen Updates vorzubereiten, damit App- und Spieleentwickler nicht durch Kompatibilitätsprobleme blockiert werden und die neuesten SDK-Funktionen nutzen können. Bitte informieren Sie Ihre Downstream-Entwickler, wenn Updates erforderlich sind, um Android 17 vollständig zu unterstützen.

Android17_Timeline_01_V02.png

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 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 und für Android 17 ausgeführt werden, um Ihre Tests zu optimieren. Dazu gehören die folgenden Änderungen:

  • 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, wird der in Android 14 eingeführte Schutz für das sicherere dynamische Laden von Code (Dynamic Code Loading, DCL) jetzt auch auf native Bibliotheken ausgeweitet. Alle nativen Dateien, die mit „System.load()“ geladen werden, müssen als schreibgeschützt markiert werden. Andernfalls wird vom System „UnsatisfiedLinkError“ ausgegeben.
  • CT standardmäßig aktivierenCertificate Transparency (CT) ist standardmäßig aktiviert. (Unter Android 16 ist CT verfügbar, aber Apps mussten aktiviert werden.)
  • Schutz des lokalen Netzwerks:Apps, die auf Android 17 oder höher ausgerichtet sind, haben standardmäßig keinen Zugriff auf das lokale Netzwerk. Stellen Sie nach Möglichkeit auf datenschutzfreundliche Auswahltools um und verwenden Sie die neue Berechtigung ACCESS_LOCAL_NETWORK für einen umfassenden, dauerhaften Zugriff.
  • Härten von Hintergrundaudio:Ab Android 17 erzwingt das Audio-Framework Einschränkungen für Hintergrundaudio-Interaktionen, einschließlich der Audiowiedergabe, Audiofokus-Anfragen und Lautstärkeänderungs-APIs. Wir haben Ihr Feedback berücksichtigt und seit Beta 2 einige Änderungen vorgenommen. Dazu gehören die Einschränkung von targetSDK, die Erzwingung von FGS während der Nutzung und die Ausnahme von Alarm-Audio. Weitere Informationen

App-Speicherlimits

Unter Android werden App-Arbeitsspeicherlimits eingeführt, die auf dem gesamten RAM des Geräts basieren. So soll eine stabilere und deterministischere Umgebung für Ihre Anwendungen und Android-Nutzer geschaffen werden. In Android 17 werden die Grenzwerte konservativ festgelegt, um Systembaselines zu erstellen. Dabei werden extreme Speicherlecks und andere Ausreißer berücksichtigt, bevor sie zu systemweiter Instabilität führen, die sich in Ruckeln der Benutzeroberfläche, schneller Akkuentladung und dem Beenden von Apps äußert. Wir gehen davon aus, dass die meisten App-Sitzungen nur minimal beeinträchtigt werden. Wir empfehlen jedoch, die folgenden Best Practices für den Arbeitsspeicher zu befolgen, 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 wird.

unnamed (2).png
LeakCanary-Aufgabe im Android Studio Profiler

Um Ihnen die Suche nach Speicherlecks zu erleichtern, bietet Android Studio Panda eine LeakCanary-Integration direkt im Android Studio Profiler als spezielle Aufgabe, die in der IDE kontextualisiert 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 Nutzererfahrung auf allen Formfaktoren. Lassen Sie uns gemeinsam eine schnellere und zuverlässigere Zukunft für das Android-Ökosystem schaffen.

Trigger für App-Anomalien profilieren

Android führt einen On-Device-Dienst zur Anomalieerkennung 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 wie übermäßige Binder-Aufrufe und übermäßige Arbeitsspeichernutzung zu erkennen. Wenn eine App die vom Betriebssystem definierten Speicherlimits überschreitet, können Entwickler durch den Anomalie-Trigger App-spezifische Heap-Dumps erhalten, um Speicherprobleme zu identifizieren und zu beheben. Bei übermäßigem Binder-Spam enthält der Anomalie-Trigger außerdem ein Profil mit Stack-Sampling für Binder-Transaktionen.

Dieser API-Rückruf erfolgt vor allen vom System auferlegten Maßnahmen. So können Entwickler beispielsweise Debugging-Daten erfassen, bevor die App vom System beendet wird, weil die Arbeitsspeicherlimits überschritten wurden. Informationen zur Verwendung des Triggers finden Sie in unserer Dokumentation zur 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 (PQC) im Android-Schlüsselspeicher

Android Keystore bietet jetzt Unterstützung für 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, 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-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 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, wird Ihnen ein OTA-Update auf Beta 4 angeboten.

Melden Sie weiterhin Probleme und reichen Sie Funktionsanfragen einauf 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 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 gründlich.

Wir aktualisieren die Vorabversionen von Systemimages und das SDK während des gesamten Android 17-Releasezyklus regelmäßig. Nachdem Sie einen Beta-Build installiert haben, erhalten Sie zukünftige Updates für alle späteren Previews und Betas automatisch over-the-air.

Weitere Informationen finden Sie auf der Entwicklerwebsite zu Android 17.

Mitreden

Ihr Feedback ist uns weiterhin sehr wichtig. Egal, ob Sie Early Adopter im Canary-Channel oder App-Entwickler sind, der Beta 4 testet: Treten Sie unseren Communities bei und geben Sie Feedback. Wir hören zu.

Verfasst von:

Weiterlesen