Przygotowanie aplikacji na zmiany w zakresie możliwości 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 ich aplikacje będą działać wszędzie. Niezależnie od tego, czy użytkownicy wykonują wiele zadań na tablecie, rozkładają urządzenie, aby wygodnie czytać, czy uruchamiają aplikacje w środowisku okien na pulpicie, oczekują, że interfejs będzie wypełniał dostępną przestrzeń wyświetlania i dostosowywał się do pozycji urządzenia.

Wprowadziliśmy istotne zmiany w interfejsach API orientacji i możliwości zmiany rozmiaru, aby ułatwić adaptacyjne działanie, a jednocześnie zapewnić tymczasową możliwość rezygnacji, która pomoże Ci w przejściu. Widzimy już, że wielu deweloperów z powodzeniem dostosowuje się do tego przejścia, kierując aplikacje na docelowy poziom interfejsu API 36.

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

Zmiany w działaniu zapewniają, że ekosystem Androida oferuje spójne i wysokiej jakości wrażenia na wszystkich urządzeniach.

Co się zmienia w Androidzie 17

Aplikacje kierowane na Androida 17 muszą być zgodne z wycofywaniem atrybutów manifestu i interfejsów API środowiska wykonawczego wprowadzonych 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 przedstawiamy sprawdzone metody i narzędzia, które pomogą Ci uniknąć typowych problemów.

Od czasu Androida 16 nie wprowadziliśmy żadnych nowych zmian, ale nie można już zrezygnować z tych zmian. Przypominamy: gdy Twoja 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 mniejszych niż sw 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 używanie aplikacji zgodnie z jej żądanym działaniem.

Przygotowanie aplikacji

Aplikacje będą musiały obsługiwać układy poziome i pionowe dla rozmiarów ekranu w pełnym zakresie proporcji obrazu, w których użytkownicy mogą korzystać z aplikacji, w tym z okien o zmiennym rozmiarze. Nie będzie już można ograniczyć proporcji obrazu i orientacji do pionowej lub poziomej.

Testowanie aplikacji

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

Użyj Androida 17 Beta 1 z emulatorami Pixel Tablet i 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 zapewnić prawidłowe dostosowywanie układów. Możesz automatycznie sprawdzić interfejs i uzyskać sugestie dotyczące jego dostosowania za pomocą narzędzia Compose UI Check oraz symulować określone cechy wyświetlacza w testach za pomocą narzędzia DeviceConfigurationOverride.

W przypadku aplikacji, które historycznie ograniczały orientację i proporcje obrazu, często występują problemy z przekrzywionymi lub nieprawidłowo zorientowanymi podglądami z aparatu, 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.

Zapewnienie zgodności z aparatem

Częstym problemem w przypadku urządzeń składanych w orientacji poziomej lub obliczeń proporcji 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 aparatu.

Upewnij się, że podgląd z aparatu nie jest rozciągnięty ani obrócony.

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

Aby zapewnić prawidłowe dostosowywanie podglądu z aparatu do dowolnego rozmiaru okna lub orientacji, 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 proporcje obrazu z aparatu, zwykle przez wyśrodkowanie i przycięcie (FILL_CENTER).
• W razie potrzeby możesz ustawić typ skalowania na FIT_CENTER, aby dodać do podglądu czarne pasy.

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

Rozwiązanie 2. CameraViewfinder 

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

Więcej informacji znajdziesz w poście na blogu Introducing Camera Viewfinder oraz w przewodniku dla deweloperów Camera preview.

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 upewnić się, że obliczenia są aktualizowane przy każdej zmianie konfiguracji:

• Pobierz orientację czujnika aparatu (np. 0, 90, 180, 270 stopni) z CameraCharacteristics.
• Pobierz bieżący obrót ekranu urządzenia (np. 0, 90, 180, 270 stopni).
• Użyj wartości orientacji czujnika aparatu i obrotu ekranu, aby określić niezbędne przekształcenia dla SurfaceView lub TextureView.
• Aby zapobiec zniekształceniom, upewnij się, że proporcje obrazu wyjściowego Surface są zgodne z proporcjami obrazu podglądu z aparatu.

Ważne: pamiętaj, że aplikacja aparatu może działać w części ekranu, w trybie wielu okien, w oknach na pulpicie lub na podłączonym wyświetlaczu. Z tego powodu do określania wymiarów wizjera aparatu nie należy używać rozmiaru ekranu. 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 Camera preview oraz w filmie Your Camera app on different form factors.

Rozwiązanie 4. Wykonywanie podstawowych działań aparatu za pomocą intencji 

Jeśli nie potrzebujesz wielu funkcji aparatu, prostym i bezpośrednim rozwiązaniem jest wykonywanie podstawowych działań aparatu, 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ć konserwację i dostosowywanie. 

Więcej informacji znajdziesz w sekcji Camera intents.

Unikanie rozciągniętego interfejsu lub niedostępnych przycisków

Jeśli Twoja aplikacja zakłada określoną orientację urządzenia lub proporcje obrazu, może napotkać 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. Jednak 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 Twoją aplikację w orientacji poziomej na urządzeniu składanym lub tablecie, przyciski działania, takie jak Zapisz lub Zaloguj się u dołu ekranu, mogą być niewidoczne. Jeśli kontener nie jest przewijalny, użytkownik może nie móc kontynuować. W Jetpack Compose możesz dodać do komponentu modyfikator verticalScroll:

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

Łącząc ograniczenia maksymalnej szerokości z przewijaniem w pionie, zapewnisz, że Twoja aplikacja pozostanie funkcjonalna i użyteczna niezależnie od tego, jak szerokie lub wąskie 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 proporcji obrazu oznacza, że rozmiar okna aplikacji będzie się zmieniać znacznie częściej. Użytkownicy mogą obracać urządzenie, składać je lub rozkładać albo dynamicznie zmieniać rozmiar aplikacji w trybie podzielonego ekranu lub okien na pulpicie.

Domyślnie te zmiany konfiguracji powodują zniszczenie i ponowne utworzenie aktywności. Jeśli Twoja aplikacja nie zarządza prawidłowo tym zdarzeniem cyklu życia, użytkownicy będą mieli frustrujące doświadczenie: pozycje przewijania zostaną zresetowane do góry, częściowo wypełnione formularze zostaną wyczyszczone, a historia nawigacji zostanie utracona. Aby zapewnić płynne działanie adaptacyjne, ważne jest, aby aplikacja zachowywała stan podczas tych zmian konfiguracji. W Jetpack Compose możesz zrezygnować z ponownego tworzenia i zamiast tego zezwolić na zmiany rozmiaru okna, aby ponownie skomponować interfejs i odzwierciedlić nową ilość dostępnego miejsca.

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

Kierowanie na interfejs API na poziomie 37 do sierpnia 2027 r.

Jeśli Twoja aplikacja wcześniej zrezygnowała z tych zmian podczas kierowania na interfejs API na poziomie 36, usunięcie możliwości rezygnacji w Androidzie 17 będzie miało na nią wpływ dopiero wtedy, gdy będzie ona kierowana na interfejs API na poziomie 37. Aby pomóc Ci w planowaniu i wprowadzeniu niezbędnych zmian w aplikacji, przedstawiamy harmonogram, w którym te zmiany zaczną obowiązywać:

• Android 17: opisane powyżej zmiany będą podstawowym działaniem 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ą mieli możliwości rezygnacji.

Terminy kierowania na określony poziom interfejsu API są zależne od sklepu z aplikacjami. W Google Play nowe aplikacje i aktualizacje będą musiały być kierowane na interfejs API na poziomie 37. To działanie będzie obowiązkowe w przypadku dystrybucji w sierpniu 2027 r.

Przygotowanie na Androida 17

Wszystkie zmiany wpływające na aplikacje w Androidzie 17 znajdziesz na stronie zmian w Androidzie 17. Aby przetestować aplikację, pobierz Androida 17 Beta 1 i zaktualizuj 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 w tym pomożemy. Podczas przygotowywania się do Androida 17 zachęcamy do zapoznania się z naszymi przewodnikami dotyczącymi tworzenia układów adaptacyjnych oraz ze wskazówkami dotyczącymi jakości na dużych ekranach. Te materiały mają pomóc Ci w pewnym radzeniu sobie z różnymi urządzeniami i rozmiarami okien.

Nie czekaj. Zacznij przygotowywać się na Androida 17 już dziś.