Przygotowanie aplikacji na zmiany w zakresie zmiany rozmiaru i orientacji w Androidzie 17

W 2025 r. wraz z premierą Androida 16 przedstawiliśmy naszą wizję ekosystemu urządzeń, w którym aplikacje płynnie dostosowują się do każdego ekranu – telefonu, urządzenia składanego, tabletu, komputera, wyświetlacza samochodowego czy urządzenia XR. Użytkownicy oczekują, że aplikacje będą działać wszędzie. Niezależnie od tego, czy użytkownik korzysta z wielozadaniowości na tablecie, rozkłada urządzenie, aby wygodnie czytać, czy uruchamia aplikacje w środowisku okien na pulpicie, oczekuje, że interfejs użytkownika wypełni dostępną przestrzeń wyświetlania i dostosuje się do pozycji urządzenia.

Wprowadziliśmy istotne zmiany w interfejsach API dotyczących orientacji i zmiany rozmiaru, aby ułatwić dostosowywanie się do różnych warunków. Zapewniliśmy też tymczasową możliwość rezygnacji, aby ułatwić Ci przejście na nowe rozwiązanie. Widzimy już, że wielu deweloperów z powodzeniem dostosowuje się do tego przejścia, gdy docelowy poziom interfejsu API to 36.

Wraz z wydaniem wersji beta Androida 17 przechodzimy do kolejnego etapu naszej adaptacyjnej mapy drogowej: Android 17 (API na poziomie 37) usuwa możliwość rezygnacji przez deweloperów z ograniczeń dotyczących orientacji i możliwości zmiany rozmiaru na urządzeniach z dużym ekranem (sw > 600 dp). Jeśli kierujesz aplikację na interfejs API na poziomie 37, musi ona być w stanie dostosować się do różnych rozmiarów wyświetlacza.

Zmiany w działaniu zapewniają spójne i wysokiej jakości działanie ekosystemu Androida na wszystkich formatach urządzeń.

Zmiany w Androidzie 17

Aplikacje kierowane na Androida 17 muszą być zgodne z wycofywaniem atrybutów pliku manifestu i interfejsów API środowiska wykonawczego wprowadzonym w Androidzie 16. Zdajemy sobie sprawę, że dla niektórych aplikacji może to być duża zmiana, dlatego w dalszej części tego posta na blogu znajdziesz sprawdzone metody i narzędzia, które pomogą Ci uniknąć typowych problemów.

Od Androida 16 nie wprowadzono żadnych nowych zmian, ale deweloperzy nie mogą już zrezygnować z tej funkcji. Przypominamy, że gdy aplikacja działa na dużym ekranie – gdzie duży ekran oznacza, że mniejszy wymiar wyświetlacza jest większy lub równy 600 dp – ignorowane są te atrybuty manifestu i interfejsy API:

Uwaga:  jak wspomnieliśmy wcześniej w przypadku Androida 16, te zmiany nie dotyczą ekranów o szerokości mniejszej niż 600 dp ani aplikacji sklasyfikowanych jako gry na podstawie flagi android:appCategory. 

Użytkownicy zachowują też kontrolę. W ustawieniach proporcji obrazu użytkownicy mogą wyraźnie zgodzić się na korzystanie z zachowania aplikacji, o które prosi.

Przygotuj aplikację

Aplikacje będą musiały obsługiwać układy poziome i pionowe dla rozmiarów wyświetlania w pełnym zakresie proporcji, w których użytkownicy mogą korzystać z aplikacji, w tym w oknach o zmienianym rozmiarze, ponieważ nie będzie już możliwości ograniczenia proporcji i orientacji do pionowej lub poziomej.

Testowanie aplikacji

Pierwszym krokiem jest przetestowanie aplikacji po wprowadzeniu tych zmian, aby upewnić się, że działa ona prawidłowo na ekranach o różnych rozmiarach.

Używaj Androida 17 Beta 1 z emulatorami urządzeń Pixel Tablet i serii Pixel Fold w Android Studio i ustaw targetSdkPreview = “CinnamonBun”. Możesz też użyć systemu sprawdzania zgodności aplikacji, włączając flagę UNIVERSAL_RESIZABLE_BY_DEFAULT, jeśli Twoja aplikacja nie jest jeszcze kierowana na docelowy poziom interfejsu API 36.

Mamy dodatkowe narzędzia, które pomogą Ci zadbać o prawidłowe dostosowanie układów. Możesz automatycznie sprawdzać interfejs i otrzymywać sugestie dotyczące jego dostosowywania za pomocą Compose UI Check oraz symulować w testach określone cechy wyświetlania za pomocą DeviceConfigurationOverride.

W przypadku aplikacji, które w przeszłości miały ograniczone ustawienia orientacji i formatu obrazu, często występują problemy ze zniekształconymi lub nieprawidłowo zorientowanymi podglądami z kamery, rozciągniętymi układami, niedostępnymi przyciskami lub utratą stanu użytkownika podczas obsługi zmian konfiguracji. 

Przyjrzyjmy się kilku strategiom rozwiązywania tych typowych problemów.

Sprawdzanie zgodności kamery

Częstym problemem na urządzeniach składanych w orientacji poziomej lub w przypadku obliczania formatu obrazu w scenariuszach takich jak tryb wielu okien, tryb okien na pulpicie czy podłączone wyświetlacze jest rozciągnięty, obrócony lub przycięty podgląd z kamery.

Sprawdź, czy podgląd z kamery nie jest rozciągnięty ani obrócony.

Ten problem często występuje na urządzeniach z dużym ekranem i składanych, ponieważ aplikacje zakładają stałe relacje między funkcjami aparatu (takimi jak format obrazu i orientacja czujnika) a funkcjami urządzenia (takimi jak orientacja urządzenia i orientacja naturalna).

Aby podgląd z kamery prawidłowo dostosowywał się do dowolnego rozmiaru lub orientacji okna, rozważ te 4 rozwiązania:

Rozwiązanie 1. Jetpack CameraX (zalecane) 

Najprostszym i najbardziej niezawodnym rozwiązaniem jest użycie biblioteki Jetpack CameraX. Element interfejsu PreviewView został zaprojektowany tak, aby automatycznie obsługiwać wszystkie złożone aspekty podglądu:

• PreviewView prawidłowo dostosowuje się do orientacji czujnika, obrotu urządzenia i skalowania;
• PreviewView zachowuje współczynnik proporcji obrazu z kamery, zwykle przez wyśrodkowanie i przycięcie (FILL_CENTER).
• W razie potrzeby możesz ustawić typ skali na FIT_CENTER, aby wyświetlić podgląd w formacie letterbox.

Więcej informacji znajdziesz w artykule Implementowanie podglądu w dokumentacji CameraX.

Rozwiązanie 2. CameraViewfinder 

Jeśli używasz istniejącej bazy kodu Camera2, CameraViewfinder (zgodna wstecznie z interfejsem API na poziomie 21) jest kolejnym nowoczesnym rozwiązaniem. Upraszcza wyświetlanie przekazu z kamery, używając elementu TextureView lub SurfaceView i stosując wszystkie niezbędne przekształcenia (format obrazu, skalę i obrót).

Więcej informacji znajdziesz w poście na blogu Introducing Camera Viewfinder (w języku angielskim) oraz w przewodniku dla programistów Camera preview (w języku angielskim).

Rozwiązanie 3. Ręczna implementacja Camera2 

Jeśli nie możesz używać CameraX ani CameraViewfinder, musisz ręcznie obliczyć orientację i proporcje obrazu oraz zadbać o to, aby obliczenia były aktualizowane przy każdej zmianie konfiguracji:

• Pobierz orientację czujnika aparatu (np. 0, 90, 180, 270 stopni) z CameraCharacteristics
• Pobieranie bieżącego obrotu ekranu urządzenia (np. 0, 90, 180, 270 stopni)
• Użyj orientacji czujnika aparatu i wartości obrotu wyświetlacza, aby określić niezbędne przekształcenia dla SurfaceView lub TextureView.
• Aby uniknąć zniekształceń, upewnij się, że format obrazu wyjściowego Surface jest zgodny z formatem obrazu podglądu z kamery.

Ważne: aplikacja Aparat może być uruchomiona w części ekranu w trybie wielu okien lub okien na komputerze albo na podłączonym wyświetlaczu. Z tego powodu rozmiaru ekranu nie należy używać do określania wymiarów wizjera aparatu. Zamiast tego użyj danych okna. W przeciwnym razie podgląd z aparatu może być rozciągnięty.

Więcej informacji znajdziesz w przewodniku dla deweloperów Podgląd z kamery oraz w filmie Aplikacja Aparat na różnych urządzeniach.

Rozwiązanie 4. Wykonywanie podstawowych działań związanych z aparatem za pomocą intencji 

Jeśli nie potrzebujesz wielu funkcji aparatu, prostym rozwiązaniem jest wykonywanie podstawowych czynności, takich jak robienie zdjęć lub nagrywanie filmów, za pomocą domyślnej aplikacji aparatu na urządzeniu. W takim przypadku możesz po prostu użyć Intent zamiast integracji z biblioteką aparatu, aby ułatwić sobie konserwację i dostosowywanie. 

Więcej informacji znajdziesz w artykule Intencje związane z aparatem.

Unikaj rozciągniętego interfejsu i niedostępnych przycisków

Jeśli Twoja aplikacja zakłada określoną orientację urządzenia lub format obrazu, może mieć problemy, gdy będzie używana w różnych orientacjach lub rozmiarach okien.

Upewnij się, że przyciski, pola tekstowe i inne elementy nie są rozciągnięte na dużych ekranach.

Przyciski, pola tekstowe i karty mogły zostać ustawione na fillMaxWidth lub match_parent. Na telefonie wygląda to świetnie. Na tablecie lub urządzeniu składanym w orientacji poziomej elementy interfejsu rozciągają się na cały duży ekran. W Jetpack Compose możesz użyć modyfikatora widthIn, aby ustawić maksymalną szerokość komponentów i uniknąć rozciągnięcia treści:

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
    }
}

Jeśli użytkownik otworzy aplikację w orientacji poziomej na urządzeniu składanym lub tablecie, przyciski działań, takie jak Zapisz lub Zaloguj się, u dołu ekranu mogą być niewidoczne. Jeśli kontener nie jest przewijany, użytkownik może nie mieć możliwości kontynuowania. W Jetpack Compose możesz dodać do komponentu modyfikator verticalScroll:

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

Łącząc ograniczenia max-width z przewijaniem w pionie, możesz mieć pewność, że aplikacja pozostanie funkcjonalna i użyteczna niezależnie od tego, jak szerokie lub krótkie będzie okno aplikacji.

Zapoznaj się z naszym przewodnikiem na temat tworzenia układów adaptacyjnych.

Zachowywanie stanu podczas zmian konfiguracji

Usunięcie ograniczeń dotyczących orientacji i formatu obrazu oznacza, że rozmiar okna aplikacji będzie się zmieniać znacznie częściej. Użytkownicy mogą obracać urządzenie, składać je i rozkładać oraz dynamicznie zmieniać rozmiar aplikacji w trybie podzielonego ekranu lub w trybie okien na komputerze.

Domyślnie te zmiany konfiguracji powodują zniszczenie i ponowne utworzenie aktywności. Jeśli aplikacja nie będzie prawidłowo zarządzać tym zdarzeniem cyklu życia, użytkownicy będą mieli problemy: pozycje przewijania zostaną zresetowane do góry, wypełnione w połowie formularze zostaną wyczyszczone, a historia nawigacji zostanie utracona. Aby zapewnić płynne działanie aplikacji w różnych warunkach, musi ona zachowywać stan podczas zmian konfiguracji. W Jetpack Compose możesz zrezygnować z ponownego tworzenia i zamiast tego zezwolić na zmianę rozmiaru okna, aby ponownie skomponować interfejs, tak aby odzwierciedlał nową ilość dostępnego miejsca.

Zapoznaj się z naszym przewodnikiem na temat zapisywania stanu interfejsu.

Kierowanie na API na poziomie 37 do sierpnia 2027 r.

Jeśli Twoja aplikacja została wcześniej wyłączona z tych zmian, gdy była kierowana na poziom interfejsu API 36, usunięcie możliwości wyłączenia z Androida 17 będzie miało na nią wpływ dopiero wtedy, gdy będzie ona kierowana na poziom interfejsu API 37. Aby pomóc Ci w planowaniu i wprowadzaniu niezbędnych zmian w aplikacji, podajemy harmonogram wejścia w życie tych zmian:

• Android 17: opisane powyżej zmiany będą podstawowym sposobem działania na urządzeniach z dużym ekranem (najmniejsza szerokość ekranu > 600 dp) w przypadku aplikacji kierowanych na interfejs API na poziomie 37. Deweloperzy nie będą mogli zrezygnować z tej funkcji.

Terminy kierowania na określony poziom interfejsu API zależą od sklepu z aplikacjami. W przypadku Google Play nowe aplikacje i aktualizacje będą musiały być kierowane na poziom API 37. Wymóg ten będzie obowiązywać od sierpnia 2027 r.

Przygotowania do Androida 17

Wszystkie zmiany wpływające na aplikacje na Androidzie 17 znajdziesz na stronie ze zmianami w Androidzie 17. Aby przetestować aplikację, pobierz Androida 17 w wersji beta 1 i zaktualizuj go do wersji targetSdkPreview = “CinnamonBun” lub użyj systemu sprawdzania zgodności aplikacji, aby włączyć określone zmiany.

Przyszłość Androida jest adaptacyjna i chętnie Ci pomożemy w jej osiągnięciu. W ramach przygotowań do wprowadzenia Androida 17 zachęcamy do zapoznania się z naszymi przewodnikami dotyczącymi tworzenia adaptacyjnych układów oraz wskazówkami dotyczącymi jakości na dużych ekranach. Te materiały pomogą Ci bez problemu obsługiwać różne formaty i rozmiary okien.

Nie czekaj. Już dziś zacznij przygotowania do Androida 17.