Produktneuheiten

App für Änderungen bei der Größenänderung und Ausrichtung in Android 17 vorbereiten

Lesezeit: 6 Minuten
Miguel Montemayor
Developer Relations Engineer

Mit der Veröffentlichung von Android 16 im Jahr 2025 haben wir unsere Vision für ein Geräte-Ökosystem vorgestellt, in dem sich Apps nahtlos an jeden Bildschirm anpassen – egal ob Smartphone, Faltgerät, Tablet, Desktop, Autodisplay oder XR. Nutzer erwarten, dass ihre Apps überall funktionieren. Egal, ob sie auf einem Tablet Multitasking betreiben, ein Gerät aufklappen, um bequem zu lesen, oder Apps in einer Desktop-Fensterumgebung ausführen – Nutzer erwarten, dass die Benutzeroberfläche den verfügbaren Anzeigebereich ausfüllt und sich an die Geräteausrichtung anpasst.

Wir haben erhebliche Änderungen an den APIs für Ausrichtung und Größenänderung vorgenommen, um adaptives Verhalten zu ermöglichen. Außerdem haben wir eine vorübergehende Deaktivierungsoption eingeführt, um Ihnen die Umstellung zu erleichtern. Viele Entwickler haben sich bereits erfolgreich an diese Umstellung angepasst, wenn sie auf API-Level 36 ausgerichtet waren.

Mit der Veröffentlichung der Betaversion von Android 17 gehen wir nun in die nächste Phase unseres adaptiven Fahrplans: In Android 17 (API-Ebene 37) wird die Möglichkeit für Entwickler entfernt, die Einschränkungen für die Ausrichtung und Größenänderung auf Geräten mit großen Displays (sw > 600 dp) zu deaktivieren. Wenn Sie auf Ziel-API-Level 37 ausgerichtet sind, muss Ihre App an verschiedene Anzeigegrößen angepasst werden können.

Die Verhaltensänderungen sollen sicherstellen, dass das Android-Ökosystem auf allen Geräteformfaktoren eine einheitliche, qualitativ hochwertige Nutzung ermöglicht.

Änderungen in Android 17

Apps, die auf Android 17 ausgerichtet sind, müssen mit der Einstellung von Manifestattributen und Runtime-APIs kompatibel sein, die in Android 16 eingeführt wurden. Wir wissen, dass dies für einige Apps eine große Umstellung sein kann. Daher haben wir in diesem Blogpost Best Practices und Tools aufgenommen, mit denen sich häufige Probleme vermeiden lassen.

Seit Android 16 wurden keine neuen Änderungen eingeführt, die Entwickler können die Funktion aber nicht mehr deaktivieren. Zur Erinnerung: Wenn Ihre App auf einem großen Bildschirm ausgeführt wird (wobei großer Bildschirm bedeutet, dass die kleinere Abmessung des Displays mindestens 600 dp beträgt), werden die folgenden Manifestattribute und APIs ignoriert:

Hinweis : Wie bereits bei Android 16 erwähnt, gelten diese Änderungen nicht für Bildschirme, die kleiner als sw 600 dp sind, oder für Apps, die anhand des Flags android:appCategory als Spiele kategorisiert werden. 

Manifestattribute/APIIgnorierte Werte
screenOrientationportrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape
setRequestedOrientation()portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape
resizeableActivityAlle
minAspectRatioAlle
maxAspectRatioAlle

Außerdem behalten die Nutzer die Kontrolle. In den Einstellungen für das Seitenverhältnis können Nutzer explizit zustimmen, dass die App das angeforderte Verhalten verwendet.

App vorbereiten

Apps müssen sowohl das Quer- als auch das Hochformat für Displaygrößen im gesamten Bereich der Seitenverhältnisse unterstützen, in denen Nutzer Apps verwenden können, einschließlich Fenster mit variabler Größe. Es gibt keine Möglichkeit mehr, das Seitenverhältnis und die Ausrichtung auf das Hoch- oder Querformat zu beschränken.

App testen

Als Erstes sollten Sie Ihre App mit diesen Änderungen testen, um sicherzustellen, dass sie auf allen Displaygrößen gut funktioniert.

Verwenden Sie Android 17 Beta 1 mit den Emulatoren für das Pixel Tablet und das Pixel Fold in Android Studio und legen Sie targetSdkPreview = “CinnamonBun” fest. Alternativ können Sie das App-Kompatibilitäts-Framework verwenden, indem Sie das Flag UNIVERSAL_RESIZABLE_BY_DEFAULT aktivieren, wenn Ihre App noch nicht auf API-Level 36 ausgerichtet ist.

Wir haben zusätzliche Tools, mit denen Sie dafür sorgen können, dass sich Ihre Layouts richtig anpassen. Mit Compose UI Check können Sie Ihre Benutzeroberfläche automatisch prüfen und Vorschläge erhalten, wie Sie sie anpassungsfähiger gestalten können. Mit DeviceConfigurationOverride können Sie in Ihren Tests bestimmte Anzeigeeigenschaften simulieren.

Bei Apps, die in der Vergangenheit die Ausrichtung und das Seitenverhältnis eingeschränkt haben, treten häufig Probleme mit verzerrten oder falsch ausgerichteten Kameravorschaubildern, gestreckten Layouts, nicht zugänglichen Schaltflächen oder dem Verlust des Nutzerstatus bei der Verarbeitung von Konfigurationsänderungen auf. 

Sehen wir uns einige Strategien an, mit denen sich diese häufigen Probleme beheben lassen.

Kamerakompatibilität prüfen

Ein häufiges Problem bei faltbaren Geräten im Querformat oder bei der Berechnung des Seitenverhältnisses in Szenarien wie dem Mehrfenstermodus, dem Desktop-Freiform-Fenster oder bei verbundenen Displays ist, wenn die Kameravorschau gestreckt, gedreht oder zugeschnitten wird.

camera_preview_issue.png

Prüfen Sie, ob die Kameravorschau gestreckt oder gedreht wird.

Dieses Problem tritt häufig auf Geräten mit großem Bildschirm und faltbaren Geräten auf, da Apps von festen Beziehungen zwischen Kamerafunktionen (z. B. Seitenverhältnis und Sensorausrichtung) und Gerätefunktionen (z. B. Geräteausrichtung und natürliche Ausrichtung) ausgehen.

Damit sich die Kameravorschau richtig an jede Fenstergröße oder Ausrichtung anpasst, sollten Sie die folgenden vier Lösungen in Betracht ziehen:

Lösung 1: Jetpack CameraX (bevorzugt) 

Die einfachste und stabilste Lösung ist die Verwendung der Jetpack CameraX-Bibliothek. Das PreviewView-UI-Element ist so konzipiert, dass es alle Komplexitäten der Vorschau automatisch verarbeitet:

  • PreviewView korrigiert die Sensorausrichtung, die Gerätedrehung und die Skalierung korrekt.
  • PreviewView behält das Seitenverhältnis des Kamerabilds bei, in der Regel durch Zentrieren und Zuschneiden (FILL_CENTER).
  • Sie können den Skalierungstyp auf FIT_CENTER einstellen, um die Vorschau bei Bedarf zu letterboxen.

Weitere Informationen finden Sie in der CameraX-Dokumentation unter Vorschau implementieren.

Lösung 2: CameraViewfinder 

Wenn Sie eine vorhandene Camera2-Codebasis verwenden, ist die CameraViewfinder-Bibliothek (abwärtskompatibel bis API-Level 21) eine weitere moderne Lösung. Dadurch wird die Anzeige des Kamerabilds vereinfacht, da ein TextureView- oder SurfaceView-Element verwendet und alle erforderlichen Transformationen (Seitenverhältnis, Skalierung und Drehung) für Sie angewendet werden.

Weitere Informationen finden Sie im Blogpost Introducing Camera Viewfinder und im Entwicklerleitfaden Camera preview.

Lösung 3: Manuelle Camera2-Implementierung 

Wenn Sie CameraX oder CameraViewfinder nicht verwenden können, müssen Sie die Ausrichtung und das Seitenverhältnis manuell berechnen und dafür sorgen, dass die Berechnungen bei jeder Konfigurationsänderung aktualisiert werden:

  • Die Ausrichtung des Kamerasensors (z. B. 0, 90, 180, 270 Grad) erhalten Sie von CameraCharacteristics.
  • Aktuelle Bildschirmdrehung des Geräts abrufen (z. B. 0, 90, 180, 270 Grad)
  • Verwenden Sie die Werte für die Ausrichtung des Kamerasensors und die Displaydrehung, um die erforderlichen Transformationen für Ihr SurfaceView oder TextureView zu bestimmen.
  • Achten Sie darauf, dass das Seitenverhältnis Ihrer Ausgabe Surface dem Seitenverhältnis der Kameravorschau entspricht, um Verzerrungen zu vermeiden.

Wichtig:Die Kamera-App wird möglicherweise in einem Teil des Displays ausgeführt, entweder im Multi-Window- oder Desktop-Fenstermodus oder auf einem verbundenen Display. Daher sollte die Bildschirmgröße nicht verwendet werden, um die Abmessungen des Kamera-Suchers zu bestimmen. Verwenden Sie stattdessen Fenstermesswerte. Andernfalls riskieren Sie eine verzerrte Kameravorschau.

Weitere Informationen finden Sie im Entwicklerleitfaden Kameravorschau und im Video zu Kamera-Apps auf verschiedenen Formfaktoren.

Lösung 4: Grundlegende Kameraaktionen mit einem Intent ausführen 

Wenn Sie nicht viele Kamerafunktionen benötigen, können Sie grundlegende Kameraaktionen wie das Aufnehmen von Fotos oder Videos mit der Standardkamera-App des Geräts ausführen. In diesem Fall können Sie einfach ein Intent verwenden, anstatt eine Kamerabibliothek einzubinden. Das erleichtert die Wartung und Anpassung. 

Weitere Informationen finden Sie unter Kamera-Intents.

Gestreckte Benutzeroberfläche oder nicht zugängliche Schaltflächen vermeiden

Wenn Ihre App von einer bestimmten Geräteausrichtung oder einem bestimmten Seitenverhältnis des Displays ausgeht, kann es zu Problemen kommen, wenn sie jetzt in verschiedenen Ausrichtungen oder Fenstergrößen verwendet wird.

elementsLS.png

Achten Sie darauf, dass Schaltflächen, Textfelder und andere Elemente auf großen Bildschirmen nicht gestreckt werden.

Möglicherweise haben Sie für Schaltflächen, Textfelder und Karten fillMaxWidth oder match_parent festgelegt.  Auf einem Smartphone sieht das gut aus. Auf einem Tablet oder Falt-Smartphone im Querformat werden UI-Elemente jedoch über den gesamten großen Bildschirm gestreckt. In Jetpack Compose können Sie mit dem Modifier „widthIn“ eine maximale Breite für Komponenten festlegen, um gestreckte Inhalte zu vermeiden:

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

Wenn ein Nutzer Ihre App im Querformat auf einem faltbaren Gerät oder Tablet öffnet, werden Aktionsschaltflächen wie Speichern oder Anmelden am unteren Bildschirmrand möglicherweise nicht gerendert. Wenn der Container nicht scrollbar ist, kann der Nutzer nicht fortfahren. In Jetpack Compose können Sie Ihrer Komponente einen verticalScroll-Modifier hinzufügen:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

Wenn Sie max-width-Einschränkungen mit vertikalem Scrollen kombinieren, bleibt Ihre App funktionsfähig und nutzbar, unabhängig davon, wie breit oder kurz das App-Fenster ist.

Weitere Informationen finden Sie in unserem Leitfaden zum Erstellen adaptiver Layouts.

Status bei Konfigurationsänderungen beibehalten

Wenn Sie die Einschränkungen für Ausrichtung und Seitenverhältnis entfernen, ändert sich die Fenstergröße Ihrer App viel häufiger. Nutzer können ihr Gerät drehen, es auf- oder zuklappen oder die Größe Ihrer App dynamisch im Splitscreen- oder Desktop-Fenstermodus ändern.

Standardmäßig werden durch diese Konfigurationsänderungen Ihre Aktivitäten zerstört und neu erstellt. Wenn Ihre App dieses Lifecycle-Event nicht richtig verarbeitet, kann das für Nutzer frustrierend sein: Scrollpositionen werden auf den Anfang zurückgesetzt, halb ausgefüllte Formulare werden gelöscht und der Navigationsverlauf geht verloren. Damit die adaptive Benutzeroberfläche reibungslos funktioniert, muss der Status Ihrer App bei diesen Konfigurationsänderungen beibehalten werden. Mit Jetpack Compose können Sie die Neuerstellung deaktivieren und stattdessen zulassen, dass die UI bei Änderungen der Fenstergröße neu zusammengesetzt wird, um den neuen verfügbaren Platz zu berücksichtigen.

Weitere Informationen finden Sie in unserem Leitfaden zum Speichern des UI-Zustands.

Ziel-API-Level 37 bis August 2027

Wenn Sie diese Änderungen für Ihre App zuvor deaktiviert haben, als sie auf API‑Level 36 ausgerichtet war, wirkt sich die Entfernung der Deaktivierungsoption für Android 17 erst auf Ihre App aus, wenn sie auf API‑Level 37 ausgerichtet ist. Damit Sie im Voraus planen und die erforderlichen Anpassungen an Ihrer App vornehmen können, finden Sie hier den Zeitplan für das Inkrafttreten dieser Änderungen:

  • Android 17: Die oben beschriebenen Änderungen sind die Standardeinstellungen für Geräte mit großen Bildschirmen (kleinste Bildschirmbreite > 600 dp) für Apps, die auf API-Level 37 ausgerichtet sind. Entwickler haben keine Möglichkeit, die Funktion zu deaktivieren.

Die Fristen für die Ausrichtung auf ein bestimmtes API-Level sind je nach App-Store unterschiedlich. Bei Google Play müssen neue Apps und Updates auf das API-Level 37 ausgerichtet sein. Dieses Verhalten ist ab August 2027 für die Verteilung obligatorisch.

Vorbereitung auf Android 17

Alle Änderungen, die sich auf Apps in Android 17 auswirken, finden Sie auf der Seite Änderungen in Android 17. Wenn Sie Ihre App testen möchten, laden Sie Android 17 Beta 1 herunter und aktualisieren Sie auf targetSdkPreview = “CinnamonBun”. Alternativ können Sie das App-Kompatibilitäts-Framework verwenden, um bestimmte Änderungen zu aktivieren.

Die Zukunft von Android ist adaptiv und wir helfen Ihnen gern dabei, diese Zukunft zu gestalten. Zur Vorbereitung auf Android 17 empfehlen wir Ihnen, unsere Anleitungen zum Erstellen adaptiver Layouts und unsere Qualitätsrichtlinien für große Displays zu lesen. Diese Ressourcen sollen Ihnen helfen, mehrere Formfaktoren und Fenstergrößen problemlos zu unterstützen.

Warten Sie nicht. Bereiten Sie sich schon heute auf Android 17 vor.

Verfasst von:

Weiterlesen