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, faltbares Gerät, Tablet, Desktop, Autodisplay oder XR. Nutzer erwarten, dass ihre Apps überall funktionieren. Ob Multitasking auf einem Tablet, das Aufklappen eines Geräts zum bequemen Lesen oder das Ausführen von Apps in einer Desktop-Fensterumgebung – Nutzer erwarten, dass die Benutzeroberfläche den verfügbaren Anzeigebereich ausfüllt und sich an die Geräteposition anpasst.

Wir haben erhebliche Änderungen an den APIs für Ausrichtung und Größe vorgenommen, um adaptives Verhalten zu ermöglichen. Gleichzeitig 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 Android 17 Beta gehen wir nun in die nächste Phase unserer adaptiven Roadmap: In Android 17 (API-Level 37) wird die Deaktivierungsoption für Entwickler für Einschränkungen bei Ausrichtung und Größe auf Geräten mit großen Bildschirmen entfernt (sw > 600 dp). Wenn Sie auf API-Level 37 ausgerichtet sind, muss Ihre App an eine Vielzahl von Displaygrößen angepasst werden können.

Die Verhaltensänderungen sorgen dafür, dass das Android-Ökosystem auf allen Geräteformfaktoren eine einheitliche, hochwertige Nutzererfahrung bietet.

Änderungen in Android 17

Apps, die auf Android 17 ausgerichtet sind, müssen mit der Einstellung der Manifestattribute 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. Deshalb haben wir in diesem Blogpost Best Practices und Tools zusammengestellt, mit denen Sie häufige Probleme vermeiden können.

Seit Android 16 wurden keine neuen Änderungen eingeführt, aber die Deaktivierungsoption für Entwickler ist nicht mehr verfügbar. Zur Erinnerung: Wenn Ihre App auf einem großen Bildschirm ausgeführt wird – wobei großer Bildschirm bedeutet, dass die kleinere Dimension 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 basierend auf dem Flag „android:appCategory“ als Spiele kategorisiert sind. 

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

App vorbereiten

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

App testen

Im ersten Schritt müssen 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 der Pixel Tablet- und Pixel Fold-Serie in Android Studio und legen Sie targetSdkPreview = “CinnamonBun” fest. Alternativ können Sie das Framework für die App-Kompatibilität verwenden, indem Sie das UNIVERSAL_RESIZABLE_BY_DEFAULT Flag aktivieren, wenn Ihre App noch nicht auf API-Level 36 ausgerichtet ist.

Wir haben zusätzliche Tools, mit denen Sie sicherstellen 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, um sie anpassungsfähiger zu machen. Mit DeviceConfigurationOverride können Sie in Ihren Tests bestimmte Displaymerkmale simulieren.

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

Sehen wir uns einige Strategien an, um diese häufigen Probleme zu beheben.

Kamerakompatibilität sicherstellen

Ein häufiges Problem bei faltbaren Geräten im Querformat oder bei Berechnungen des Seitenverhältnisses in Szenarien wie Multifenster, Desktop-Fenster oder angeschlossene Displays ist, dass die Kameravorschau gestreckt, gedreht oder zugeschnitten wird.

Achten Sie darauf, dass die Kameravorschau nicht gestreckt oder gedreht wird.

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

Mit diesen vier Lösungen können Sie sicherstellen, dass sich die Kameravorschau richtig an jede Fenstergröße oder Ausrichtung anpasst:

Lösung 1: Jetpack CameraX (bevorzugt) 

Die einfachste und robusteste Lösung ist die Verwendung der Jetpack CameraX-Bibliothek. Das UI-Element PreviewView verarbeitet alle Komplexitäten der Vorschau automatisch:

• PreviewView wird korrekt an Sensorausrichtung, Gerätedrehung und Skalierung angepasst.
• „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 festlegen, um die Vorschau bei Bedarf mit Letterboxing zu versehen.

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

Lösung 2: CameraViewfinder 

Wenn Sie eine vorhandene Camera2-Codebasis verwenden, ist die Bibliothek CameraViewfinder (abwärtskompatibel mit API-Level 21) eine weitere moderne Lösung. Sie vereinfacht die Anzeige des Kamerafeeds, indem sie ein TextureView oder SurfaceView verwendet und alle erforderlichen Transformationen (Seitenverhältnis, Skalierung und Drehung) für Sie anwendet.

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

Lösung 3: Manuelle Camera2-Implementierung 

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

• Rufen Sie die Ausrichtung des Kamerasensors (z. B. 0, 90, 180, 270 Grad) aus CameraCharacteristics ab.
• Rufen Sie die aktuelle Displaydrehung des Geräts ab (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 Ihres Ausgabetyps Surface mit dem Seitenverhältnis der Kameravorschau übereinstimmt, um Verzerrungen zu vermeiden.

Wichtig:Beachten Sie, dass die Kamera-App möglicherweise in einem Teil des Bildschirms ausgeführt wird, entweder im Multifenster- oder Desktop-Fenstermodus oder auf einem angeschlossenen Display. Aus diesem Grund sollte die Bildschirmgröße nicht verwendet werden, um die Abmessungen des Kamerasuchers zu bestimmen. Verwenden Sie stattdessen Fenstermesswerte. Andernfalls riskieren Sie eine gestreckte Kameravorschau.

Weitere Informationen finden Sie im Entwicklerleitfaden Kameravorschau und im Video Your Camera app on different form factors.

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

Wenn Sie nicht viele Kamerafunktionen benötigen, ist es eine einfache und unkomplizierte Lösung, grundlegende Kameraaktionen wie das Aufnehmen eines Fotos oder Videos mit der Standardkameraanwendung des Geräts auszuführen. In diesem Fall können Sie einfach ein Intent verwenden, anstatt eine Kamera-Bibliothek zu integrieren. Das erleichtert die Wartung und Anpassung.

Weitere Informationen finden Sie unter Camera 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.

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

Möglicherweise haben Sie Schaltflächen, Textfelder und Karten auf fillMaxWidth oder match_parent festgelegt. Auf einem Smartphone sieht das gut aus. Auf einem Tablet oder faltbaren Gerät im Querformat werden die UI-Elemente jedoch über den gesamten großen Bildschirm gestreckt. In Jetpack Compose können Sie mit dem Modifikator „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 unten auf dem Bildschirm möglicherweise nicht angezeigt. Wenn der Container nicht scrollbar ist, kann der Nutzer möglicherweise nicht fortfahren. In Jetpack Compose können Sie Ihrer Komponente einen Modifikator „verticalScroll“ hinzufügen:

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

Durch die Kombination von Einschränkungen für die maximale Breite mit vertikalem Scrollen stellen Sie sicher, dass Ihre App unabhängig von der Breite oder Höhe des App-Fensters funktionsfähig und nutzbar bleibt.

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, auf- und zuklappen oder die Größe Ihrer App dynamisch im Split-Screen- oder Desktop-Fenstermodus ändern.

Standardmäßig werden bei diesen Konfigurationsänderungen Ihre Aktivitäten zerstört und neu erstellt. Wenn Ihre App dieses Lebenszyklusereignis nicht richtig verwaltet, ist das für Nutzer frustrierend: Scrollpositionen werden auf den Anfang zurückgesetzt, halb ausgefüllte Formulare werden gelöscht und der Navigationsverlauf geht verloren. Damit die Anpassung nahtlos funktioniert, ist es wichtig, dass Ihre App den Status bei diesen Konfigurationsänderungen beibehält. Mit Jetpack Compose können Sie die Neuerstellung deaktivieren und stattdessen zulassen, dass die Fenstergröße geändert wird, um die Benutzeroberfläche neu zusammenzusetzen und den neuen verfügbaren Platz zu berücksichtigen.

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

Ausrichtung auf API-Level 37 bis August 2027

Wenn Ihre App diese Änderungen zuvor deaktiviert hat, wenn sie auf API-Level 36 ausgerichtet war, wirkt sich die Entfernung der Deaktivierungsoption für Android 17 erst dann 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 Änderungen 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 API-Level 37 ausgerichtet sein. Dieses Verhalten ist ab August 2027 für die Verteilung erforderlich.

Vorbereitung auf Android 17

Auf der Seite mit den Änderungen in Android 17 finden Sie alle Änderungen, die sich auf Apps in Android 17 auswirken. Wenn Sie Ihre App testen möchten, laden Sie Android 17 Beta 1 herunter und aktualisieren Sie auf targetSdkPreview = “CinnamonBun” oder verwenden Sie das Framework für die App-Kompatibilität, um bestimmte Änderungen zu aktivieren.

Die Zukunft von Android ist adaptiv und wir helfen Ihnen dabei, dorthin zu gelangen. Wenn Sie sich auf Android 17 vorbereiten, empfehlen wir Ihnen, unsere Leitfäden zum Erstellen adaptiver Layouts und unsere Qualitätsrichtlinien für große Bildschirme zu lesen. Diese Ressourcen sollen Ihnen helfen, mehrere Formfaktoren und Fenstergrößen sicher zu verwalten.

Warum warten? Bereiten Sie sich noch heute auf Android 17 vor.