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 XR. Użytkownicy oczekują, że aplikacje będą działać wszędzie. Niezależnie od tego, czy użytkownicy wykonują wiele zadań na tablecie, otwierają urządzenie, aby wygodnie czytać, czy uruchamiają aplikacje w trybie 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 tej zmiany, gdy kierują aplikacje na interfejs API na poziomie 36.

Teraz, wraz z wydaniem wersji beta Androida 17, przechodzimy do następnego etapu naszej adaptacyjnej mapy drogowej: Android 17 (poziom interfejsu API 37) usuwa możliwość rezygnacji dewelopera 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 wyświetlacza.

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 zachowania żądanego przez aplikację.

Przygotowanie aplikacji

Aplikacje będą musiały obsługiwać układy poziome i pionowe dla rozmiarów wyświetlacza 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 się 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 ze zniekształconymi 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 to, że podgląd z aparatu jest rozciągnięty, obrócony lub przycięty.

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 format obrazu i orientacja czujnika) a funkcjami urządzenia (takimi jak orientacja urządzenia i orientacja naturalna).

Aby mieć pewność, że podgląd z aparatu prawidłowo dostosowuje się 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 to wyświetlanie przekazu z kamery za pomocą TextureView lub SurfaceView i stosuje 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 wyświetlacza urządzenia (np. 0, 90, 180, 270 stopni).
• Użyj wartości orientacji czujnika aparatu i obrotu wyświetlacza, 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 trybie okien 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 będzie działać i będzie 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 i rozkładać lub dynamicznie zmieniać rozmiar aplikacji w trybie podzielonego ekranu lub trybie 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 na górę, wypełnione w połowie 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 sposobem działania na urządzeniach z dużym ekranem (najmniejsza szerokość ekranu > 600 dp) w przypadku aplikacji kierowanych na docelowy poziom interfejsu API 37. Deweloperzy nie będą mogli zrezygnować z tych zmian.

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

Przygotowanie na Androida 17

Wszystkie zmiany, które mają wpływ 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 na temat tworzenia układów adaptacyjnych oraz z 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 zwlekaj. Zacznij przygotowywać się na Androida 17 już dziś.