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 trybie 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 orientacji i zmiany rozmiaru, aby ułatwić dostosowywanie się do różnych warunków, a jednocześnie zapewniliśmy tymczasową możliwość rezygnacji, aby ułatwić Ci przejście na nowe rozwiązanie. Widzimy, ż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 (poziom interfejsu API 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 pliku 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 korzystanie z zachowania, o które prosi aplikacja.

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żyj Androida 17 w wersji beta 1 z emulatorami urządzeń 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 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świetlacza 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.

Sprawdź zgodność kamery

Częstym problemem na urządzeniach składanych w orientacji poziomej lub w przypadku obliczeń proporcji 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ż zastosowanie tych 4 rozwiązań:

Rozwiązanie 1. Jetpack CameraX (zalecane) 

Najprostszym i najbardziej niezawodnym rozwiązaniem jest użycie biblioteki Jetpack CameraX. Element interfejsu PreviewView jest 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, biblioteka CameraViewfinder (zgodna wstecznie z poziomem interfejsu API 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, skalowanie 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
• Pobierz bieżący obrót 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 aparatu może być uruchomiona w części ekranu w trybie wielu okien lub trybie okien na pulpicie 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 kamery 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 kamerą za pomocą intencji 

Jeśli nie potrzebujesz wielu funkcji aparatu, proste i nieskomplikowane rozwiązanie to 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ć konserwację i dostosowywanie. 

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

Unikaj 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. Na tablecie lub urządzeniu składanym w orientacji poziomej elementy interfejsu rozciągają się jednak na cały duży ekran. W Jetpack Compose możesz użyć modyfikatora widthIn, aby ustawić maksymalną szerokość komponentów i uniknąć rozciągania 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 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ć oraz dynamicznie zmieniać rozmiar aplikacji w trybie podzielonego ekranu lub w trybie okien na pulpicie.

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ą sfrustrowani: 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 aplikacji, musi ona zachowywać 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, 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 interfejs API na poziomie 36, usunięcie możliwości wyłączenia z Androida 17 będzie miało na nią wpływ dopiero wtedy, gdy będzie kierowana na interfejs API na poziomie 37. Aby pomóc Ci w zaplanowaniu działań i wprowadzeniu 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 korzystających z interfejsu 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. W sierpniu 2027 r. stanie się to obowiązkowe w przypadku dystrybucji.

Przygotowania do Androida 17

Wszystkie zmiany wpływające na aplikacje w 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 to adaptacyjność, a my pomożemy Ci ją osiągnąć. W ramach przygotowań do wprowadzenia Androida 17 zachęcamy do zapoznania się z naszymi przewodnikami dotyczącymi tworzenia układów adaptacyjnych oraz wskazówkami dotyczącymi jakości na dużych ekranach. Te materiały pomogą Ci bez obaw obsługiwać różne formaty i rozmiary okien.

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