Lokalizowanie aplikacji

Android działa na wielu urządzeniach w wielu regionach. Aby dotrzeć do jak największej liczby użytkowników, zadbaj o to, aby aplikacja obsługiwała tekst, pliki audio, liczby, walutę i grafikę w sposób odpowiedni do regionu, w którym jest używana.

Na tej stronie znajdziesz sprawdzone metody lokalizacji aplikacji na Androida.

Musisz dysponować praktyczną znajomością języka Kotlin lub języka Java, wczytywaniem zasobów Androida, deklarowaniem elementów interfejsu użytkownika w języku XML, zagadnieniami programistycznymi, takimi jak cykl życia działania, oraz ogólnymi zasadami internacjonalizacji i lokalizacji.

Warto korzystać z platformy zasobów Androida, aby oddzielić zlokalizowane aspekty aplikacji od jej kluczowych funkcji.

  • Umieść większość lub całą zawartość interfejsu użytkownika w plikach zasobów w sposób opisany na tej stronie i w omówieniu zasobów aplikacji.
  • Z kolei działanie interfejsu użytkownika jest określane przez kod w języku Kotlin lub Java. Jeśli np. użytkownicy wpisują dane, które muszą być formatowane lub sortowane w zależności od języka, do ich zautomatyzowanego przetwarzania możesz używać Kotlin lub języka programowania Java. Na tej stronie nie omawiamy, jak zlokalizować kod w języku Kotlin lub w Javie.

Krótki przewodnik po lokalizowaniu ciągów tekstowych w aplikacji znajdziesz w artykule o obsłudze różnych języków i kultur.

Omówienie: przełączanie zasobów na Androidzie

Zasoby to ciągi tekstowe, układy, dźwięki, grafika i wszelkie inne dane statyczne, których potrzebuje aplikacja na Androida. Aplikacja może zawierać wiele zbiorów zasobów, z których każdy jest dostosowany do innej konfiguracji urządzenia. Gdy użytkownik uruchamia aplikację, Android automatycznie wybiera i wczytuje zasoby, które najlepiej pasują do urządzenia.

Ta strona dotyczy lokalizacji i regionu. Pełny opis przełączania zasobów oraz wszystkie typy konfiguracji, które możesz określić, takie jak orientacja ekranu czy typ ekranu dotykowego, znajdziesz w sekcji Udostępnianie zasobów alternatywnych.

Podczas pisania aplikacji tworzysz domyślne i alternatywne zasoby, których będzie używać Twoja aplikacja. Gdy użytkownicy uruchamiają Twoją aplikację, system Android wybiera zasoby do wczytania w zależności od ustawień regionalnych urządzenia. Aby utworzyć zasoby, umieszczasz pliki w specjalnie nazwanych podkatalogach katalogu res/ projektu.

Dlaczego zasoby domyślne są ważne

Gdy aplikacja działa w dowolnym języku, dla którego nie podano tekstu dla danego języka, Android wczytuje domyślne ciągi znaków z: res/values/strings.xml. Jeśli nie ma tego domyślnego pliku lub brakuje w nim ciągu znaków, którego potrzebuje aplikacja, aplikacja nie będzie działać i wyświetli komunikat o błędzie. Przykład poniżej pokazuje, co może się stać, gdy domyślny plik tekstowy jest niekompletny.

Przykład:

Kod aplikacji oparty na Kotlin lub Javie odnosi się tylko do 2 ciągów znaków: text_a i text_b. Aplikacja zawiera zlokalizowany plik zasobów (res/values-en/strings.xml), który zawiera definicje text_a i text_b w języku angielskim. Aplikacja zawiera też domyślny plik zasobów (res/values/strings.xml) zawierający definicję dla text_a, ale nie dla text_b.

  • Gdy ta aplikacja jest uruchamiana na urządzeniu z językiem ustawionym na angielski, może ona działać bez problemu, ponieważ res/values-en/strings.xml zawiera oba wymagane ciągi tekstowe.
  • Jednak gdy ta aplikacja zostanie uruchomiona na urządzeniu z ustawionym językiem innym niż angielski, użytkownik zobaczy komunikat o błędzie i przycisk Wymuś zamknięcie. Aplikacja się nie wczytuje.

Aby temu zapobiec, sprawdź, czy plik res/values/strings.xml istnieje i czy definiuje każdy potrzebny ciąg znaków. Ta sytuacja dotyczy wszystkich typów zasobów, a nie tylko ciągów tekstowych. Musisz utworzyć zestaw domyślnych plików zasobów zawierających wszystkie zasoby wywoływane przez Twoją aplikację, takie jak układy, elementy rysowane czy animacje. Informacje na temat testowania znajdziesz w sekcji Testowanie zasobów domyślnych.

Skorzystaj z zasobów dotyczących lokalizacji

W tej sekcji omówiono tworzenie zasobów domyślnych i alternatywnych. Wyjaśniono też, w jaki sposób zasoby są przypisywane w pierwszej kolejności, a także jak odwoływać się do zasobów w kodzie.

Tworzenie zasobów domyślnych

Umieść domyślny tekst aplikacji w tym języku: res/values/strings.xml. W przypadku tych ciągów użyj języka domyślnego, czyli języka, którego oczekujesz, aby mówić większość użytkowników aplikacji.

Domyślny zestaw zasobów zawiera też wszystkie domyślne elementy rysowane i układy oraz może zawierać inne typy zasobów, np. animacje. Te zasoby znajdują się w tych katalogach:

  • res/drawable/: wymagany katalog zawierający co najmniej 1 plik graficzny na ikonę aplikacji w Google Play
  • res/layout/: wymagany katalog zawierający plik XML, który określa układ domyślny
  • res/anim/: wymagane, jeśli masz jakiekolwiek foldery (res/anim-<qualifiers>)
  • res/xml/: wymagane, jeśli masz jakiekolwiek foldery (res/xml-<qualifiers>)
  • res/raw/: wymagane, jeśli masz jakiekolwiek foldery (res/raw-<qualifiers>)

Wskazówka: sprawdź w kodzie każde odwołanie do zasobu Androida. Upewnij się, że każdy zasób ma zdefiniowany zasób domyślny. Sprawdź też, czy domyślny plik z ciągami znaków jest kompletny: plik zlokalizowany może zawierać podzbiór ciągów tekstowych, natomiast plik default z ciągiem tekstowym musi zawierać je wszystkie.

Tworzenie zasobów alternatywnych

Ważnym aspektem lokalizowania aplikacji jest zapewnienie tekstu alternatywnego dla różnych języków. W niektórych przypadkach udostępniasz również alternatywną grafikę, dźwięki, układy i inne zasoby związane z regionami.

Aplikacja może określać wiele katalogów res/<qualifiers>/, a każdy z nich ma inne kwalifikatory. Aby utworzyć zasób alternatywny dla innego języka, możesz użyć kwalifikatora określającego język lub kombinację języka i regionu. Nazwa katalogu zasobów musi być zgodna ze schematem nazewnictwa opisanym w sekcji Udostępnianie zasobów alternatywnych. W przeciwnym razie aplikacja nie będzie mogła skompilować.

Przykład:

Załóżmy, że domyślnym językiem aplikacji jest angielski i chcesz przetłumaczyć cały tekst aplikacji na francuski, a cały tekst z wyjątkiem tytułu aplikacji na japoński. W tym przypadku utworzysz 3 pliki strings.xml, z których każdy będzie przechowywany w katalogu zasobów właściwych dla danego języka:

  1. res/values/strings.xml
    Zawiera tekst w języku angielskim obejmujący wszystkie ciągi znaków używane przez aplikację, w tym tekst ciągu o nazwie title.
  2. res/values-fr/strings.xml
    Wszystkie ciągi zawierają tekst w języku francuskim, w tym title.
  3. res/values-ja/strings.xml
    Wszystkie ciągi tekstowe zawierają tekst w języku japońskim z wyjątkiem title.

Jeśli Twój kod oparty na Kotlin lub Javie odnosi się do R.string.title, w środowisku wykonawczym dzieje się to w ten sposób:

  • Jeśli na urządzeniu jest ustawiony dowolny język inny niż francuski, Android wczytuje title z pliku res/values/strings.xml.
  • Jeśli urządzenie ma ustawiony język francuski, Android wczytuje title z pliku res/values-fr/strings.xml.

Jeśli urządzenie jest ustawione na język japoński, Android wyszukuje title w pliku res/values-ja/strings.xml. Ponieważ jednak plik nie zawiera takiego ciągu, Android wraca do wartości domyślnej i wczytuje title w języku angielskim z pliku res/values/strings.xml.

Które zasoby mają pierwszeństwo?

Jeśli wiele plików zasobów pasuje do konfiguracji urządzenia, Android ustala, który plik najlepiej wykorzystać, na podstawie zestawu reguł. Wśród kwalifikatorów, które mogą być określone w nazwie katalogu zasobów, niemal zawsze pierwszeństwo ma język regionalny.

Przykład:

Załóżmy, że aplikacja zawiera domyślny zestaw grafik i 2 inne zestawy kart graficznych zoptymalizowane pod kątem innej konfiguracji urządzenia:

  • res/drawable/
    Zawiera domyślną grafikę.
  • res/drawable-small-land-stylus/
    Zawiera grafikę zoptymalizowaną do użytku z urządzeniem, które wymaga wprowadzania danych za pomocą rysika, i ma ekran o małej gęstości QVGA w orientacji poziomej.
  • res/drawable-ja/
    Zawiera grafikę zoptymalizowaną do użytku w języku japońskim.

Jeśli aplikacja działa na urządzeniu skonfigurowanym do używania języka japońskiego, Android wczytuje grafikę z res/drawable-ja/, nawet jeśli urządzenie, które wymaga wprowadzania danych wejściowych rysika, i ma ekran o niskiej gęstości QVGA w orientacji poziomej.

Wyjątek: jedyne kryteria, które mają pierwszeństwo przed językiem w procesie wyboru, to kod kraju mobilnego (MCK) i kod sieci komórkowej (MNC).

Przykład:

Załóżmy, że masz taką sytuację:

  • Kod aplikacji wywołuje metodę R.string.text_a
  • .
  • Dostępne są 2 odpowiednie pliki zasobów:
    • res/values-mcc404/strings.xml, która zawiera text_a w domyślnym języku aplikacji, w tym przypadku w języku angielskim.
    • res/values-hi/strings.xml, w tym text_a w języku hindi.
  • Aplikacja działa na urządzeniu, które ma taką konfigurację:
    • Karta SIM jest połączona z siecią komórkową w Indiach (MCK 404).
    • Język jest ustawiony na hindi (hi).

Android wczytuje język text_a z aplikacji res/values-mcc404/strings.xml (w języku angielskim), nawet jeśli na urządzeniu jest ustawiony język hindi. Dzieje się tak, ponieważ podczas wyboru zasobów Android preferuje dopasowanie MCK zamiast dopasowania języka.

Proces wyboru nie zawsze jest tak prosty, jak sugerują te przykłady. Bardziej szczegółowe informacje o tym procesie znajdziesz w artykule o tym, jak Android znajduje najlepszy pasujący zasób. Wszystkie kwalifikatory zostały opisane i wymienione w odpowiedniej kolejności na stronie omówienie zasobów aplikacji.

Odwoływanie się do zasobów w kodzie

W kodzie aplikacji opartym na Kotlin lub Javie odwołujesz się do zasobów za pomocą składni R.resource_type.resource_name lub android.R.resource_type.resource_name. Więcej informacji znajdziesz w artykule o uzyskiwaniu dostępu do zasobów aplikacji.

Zarządzaj ciągami znaków na potrzeby lokalizacji

W tej sekcji znajdziesz sprawdzone metody zarządzania ciągami tekstowymi związanymi z lokalizacją.

Przenieś wszystkie ciągi do pliku string.xml

Podczas tworzenia aplikacji nie koduj na stałe żadnych ciągów tekstowych. Zamiast tego wszystkie ciągi znaków możesz zadeklarować jako zasoby w domyślnym pliku strings.xml, co ułatwi ich aktualizowanie i lokalizację. Ciągi tekstowe w pliku strings.xml można łatwo wyodrębnić, przetłumaczyć i zintegrować z aplikacją za pomocą odpowiednich kwalifikatorów bez konieczności wprowadzania zmian w skompilowanym kodzie.

Jeśli generujesz obrazy zawierające tekst, umieść je również w polu strings.xml i ponownie wygeneruj obrazy po przetłumaczeniu.

Zgodność z wytycznymi Androida dotyczącymi ciągów tekstowych w interfejsie

Projektując i tworząc UI, zwracaj szczególną uwagę na sposób, w jaki rozmawiasz z użytkownikami. Ogólnie rzecz biorąc, używaj zwięzłego stylu, który jest przyjazny, ale zwięzły, oraz używaj spójnego stylu we wszystkich interfejsach.

Zapoznaj się z zaleceniami dotyczącymi stylu Material Design dotyczące stylu pisania i wyboru słów. Sprawi to, że aplikacje będą wyglądać z perspektywy bardziej dopracowane, a użytkownicy będą mogli szybciej zrozumieć Twój interfejs.

W miarę możliwości zawsze używaj standardowej terminologii związanej z Androidem, np. w elementach interfejsu, takich jak pasek aplikacji, menu opcji, pasek systemu czy powiadomienia. Poprawne i spójne używanie terminów związanych z Androidem ułatwia tłumaczenie i daje użytkownikom lepsze rezultaty.

Podaj wystarczający kontekst dla zadeklarowanych ciągów znaków

Deklarując ciągi tekstowe w pliku strings.xml, pamiętaj, aby opisać kontekst, w którym jest on używany. Te informacje są nieocenione dla tłumacza i pomagają uzyskać lepsze tłumaczenie. Pomaga to też skuteczniej zarządzać ciągami znaków.

Oto przykład:

<!-- The action for submitting a form. This text is on a button that can fit 30 chars -->
<string name="login_submit_button">Sign in</string>

Warto podać kontekst, na przykład:

  • Do czego służy ten ciąg znaków? Kiedy i gdzie jest ona wyświetlana użytkownikowi?
  • Gdzie to jest w układzie? Na przykład tłumaczenia w przypadku przycisków są mniej elastyczne niż w polach tekstowych.

Oznaczaj fragmenty wiadomości, które nie zostaną przetłumaczone

Często ciągi tekstowe zawierają tekst, którego nie należy tłumaczyć na inne języki. Typowe przykłady to fragment kodu, obiekt zastępczy wartości, symbol specjalny i nazwa. Przygotowując tekst do tłumaczenia, wyszukaj i oznacz tekst w niezmienionej postaci, w którym nie ma tłumaczenia, aby tłumacz go nie zmienił.

Aby oznaczyć tekst, który nie zostanie przetłumaczony, użyj tagu zastępczego <xliff:g>. Oto przykładowy tag, który wskazuje, że nie można zmieniać tekstu "%1$s" podczas tłumaczenia, aby uniknąć uszkodzenia komunikatu:

<string name="countdown">
  <xliff:g id="time" example="5 days">%1$s</xliff:g> until holiday
</string>

Deklarując tag zastępczy, dodaj atrybut identyfikatora, który wyjaśnia, do czego służy dany symbol zastępczy. Jeśli Twoja aplikacja zastąpi później wartość zmiennej, podaj przykładowy atrybut, aby wyjaśnić oczekiwane użycie.

Oto kilka dodatkowych przykładów tagów zastępczych:

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<!-- Example placeholder for a special Unicode symbol -->
<string name="star_rating">Check out our 5
    <xliff:g id="star">\u2605</xliff:g>
</string>
<!-- Example placeholder for a URL -->
<string name="app_homeurl">
    Visit us at <xliff:g
    id="application_homepage">http://my/app/home.html</xliff:g>
</string>
<!-- Example placeholder for a name -->
<string name="prod_name">
    Learn more at <xliff:g id="prod_gamegroup">Game Group</xliff:g>
</string>
<!-- Example placeholder for a literal -->
<string name="promo_message">
    Please use the "<xliff:g id="promotion_code">ABCDEFG</xliff:g>" to get a discount.
</string>
...
</resources>

Lista kontrolna lokalizacji

Pełny przegląd procesu lokalizacji i rozpowszechniania aplikacji na Androida znajdziesz w artykule Tłumaczenie i lokalizowanie aplikacji.

Wskazówki dotyczące lokalizacji

Podczas lokalizowania aplikacji postępuj zgodnie z tymi wskazówkami.

Opracuj aplikację tak, aby działała w dowolnym języku

Nie zakładaj niczego o urządzeniu, na którym użytkownik uruchamia Twoją aplikację. Być może urządzenie ma sprzęt, którego się nie spodziewasz, albo ustawiony język jest niezaplanowany lub nie da się go przetestować. Zaprojektuj aplikację tak, aby działała prawidłowo lub w sposób płynny, bez względu na to, na jakim urządzeniu działa.

Ważne: sprawdź, czy aplikacja zawiera pełny zestaw domyślnych zasobów: uwzględniaj w nazwach folderów res/drawable/ i res/values/ bez dodatkowych modyfikatorów, które zawierają wszystkie obrazy i tekst potrzebne aplikacji.

Jeśli aplikacja nie ma nawet 1 zasobu domyślnego, nie będzie działać na urządzeniu z nieobsługiwanym językiem. Jeśli na przykład w pliku domyślnym res/values/strings.xml brakuje jednego ciągu znaków, którego potrzebuje aplikacja, to gdy aplikacja działa w nieobsługiwanym języku i próbuje wczytać język res/values/strings.xml, użytkownik zobaczy komunikat o błędzie i przycisk Wymuś zamknięcie.

Więcej informacji znajdziesz w sekcji Testowanie zasobów domyślnych.

Projektowanie elastycznego układu

Jeśli chcesz zmienić układ układu, aby pasował do określonego języka, możesz utworzyć alternatywny układ dla tego języka, np. res/layout-de/main.xml dla układu niemieckojęzycznego. ale może to utrudnić jej obsługę. Lepiej utworzyć jeden układ, który jest bardziej elastyczny.

Kolejną typową sytuacją jest język, który wymaga czegoś innego w swoim układzie. Możesz na przykład mieć formularz kontaktowy, który zawiera 2 pola imienia i nazwiska, gdy aplikacja jest uruchomiona w języku japońskim, i trzy z nich, jeśli aplikacja działa w innym języku. Możesz to zrobić na 2 sposoby:

  • Utwórz jeden układ z polem, które możesz automatycznie włączać i wyłączać w zależności od języka.
  • Upewnij się, że układ główny zawiera inny układ zawierający zmienne pole. Drugi układ może mieć różne konfiguracje dla różnych języków.

Unikaj tworzenia większej liczby plików zasobów i ciągów tekstowych, niż potrzebujesz

Prawdopodobnie nie musisz tworzyć alternatywnej wersji językowej dla każdego zasobu w aplikacji. Na przykład układ zdefiniowany w pliku res/layout/main.xml może działać w dowolnym języku, wtedy nie trzeba tworzyć żadnych plików układu alternatywnego.

Nie musisz też tworzyć alternatywnego tekstu dla każdego ciągu znaków. Załóżmy na przykład, że:

  • Domyślnym językiem aplikacji jest amerykański angielski. Każdy ciąg znaków używany przez aplikację jest zdefiniowany w usłudze res/values/strings.xml zgodnie z amerykańską pisownią w języku angielskim.
  • W przypadku kilku ważnych wyrażeń możesz podać pisownię w języku angielskim (brytyjskim). Chcesz używać tych alternatywnych ciągów tekstowych, gdy aplikacja jest uruchamiana na urządzeniu w Wielkiej Brytanii.

Aby to zrobić, utwórz mały plik o nazwie res/values-en-rGB/strings.xml, który będzie zawierał tylko te ciągi znaków, które są inne, gdy aplikacja działa w Wielkiej Brytanii. W przypadku wszystkich pozostałych ciągów aplikacja wraca do wartości domyślnych i używa elementów zdefiniowanych w res/values/strings.xml.

Używanie obiektu kontekstu Androida do ręcznego wyszukiwania języka

Język możesz wyszukać za pomocą obiektu Context udostępnionego przez Androida, jak w tym przykładzie:

Kotlin

val primaryLocale: Locale = context.resources.configuration.locales[0]
val locale: String = primaryLocale.displayName

Java

Locale primaryLocale = context.getResources().getConfiguration().getLocales().get(0);
String locale = primaryLocale.getDisplayName();

Korzystanie z usługi tłumaczenia aplikacji

Usługa tłumaczenia aplikacji jest zintegrowana z Konsoli Play. Dzięki temu możesz uzyskać natychmiastową wycenę i złożyć zamówienie w firmie tłumaczeniowej. Możesz zamówić tłumaczenie ciągów interfejsu aplikacji, tekstu na stronie aplikacji w Sklepie Play, nazw zakupów w aplikacji i tekstu kampanii reklamowej na jeden lub kilka języków.

Testuj zlokalizowane aplikacje

Przetestuj zlokalizowaną aplikację na urządzeniu lub za pomocą emulatora Androida. W szczególności przetestuj aplikację, aby się upewnić, że zawiera wszystkie niezbędne zasoby domyślne.

Testowanie na urządzeniu

Pamiętaj, że urządzenie, na którym testujesz, może znacznie różnić się od urządzeń dostępnych dla konsumentów w innych miejscach. Języki dostępne na Twoim urządzeniu mogą różnić się od tych na innych urządzeniach. Poza tym rozdzielczość i gęstość ekranu urządzenia mogą się różnić, co może mieć wpływ na wyświetlanie ciągów tekstowych i elementów rysowanych w interfejsie.

Aby zmienić język lub język na urządzeniu, użyj aplikacji Ustawienia.

Testowanie w emulatorze

Szczegółowe informacje o korzystaniu z emulatora znajdziesz w sekcji Uruchamianie aplikacji przy użyciu emulatora Androida.

Tworzenie i używanie niestandardowych ustawień regionalnych

„Niestandardowe” ustawienie regionalne to kombinacja języka lub regionu, której nie obsługuje obraz systemu Android. Aby przetestować, jak Twoja aplikacja działa w niestandardowym języku, utwórz w emulatorze niestandardowe ustawienie języka. Można to zrobić na 2 sposoby:

  • Użyj aplikacji Niestandardowe ustawienia regionalne, która jest dostępna na karcie aplikacji. Po utworzeniu niestandardowego języka możesz przełączyć się na niego, dotykając jego nazwy i przytrzymując ją.
  • Zmień język na niestandardowy z poziomu powłoki adb zgodnie z opisem w następnej sekcji.

Gdy ustawisz emulator na język, który nie jest dostępny w obrazie systemu Androida, system wyświetla się w języku domyślnym. Aplikacja zostanie jednak poprawnie zlokalizowana.

Zmień język emulatora z poziomu powłoki adb

Aby zmienić ustawienia języka w emulatorze za pomocą powłoki adb, wykonaj te czynności:

  1. Wybierz język, który chcesz przetestować, i określ jego tag języka BCP-47, np. fr-CA dla kanadyjskiego francuskiego.
  2. Uruchom emulator.
  3. Z poziomu powłoki wiersza poleceń na komputerze hosta uruchom to polecenie:
    adb shell
    lub, jeśli dołączasz urządzenie, określ, czy chcesz używać emulatora, dodając opcję -e:
    adb -e shell
  4. W wierszu poleceń powłoki adb (#) uruchom następujące polecenie:
    setprop persist.sys.locale [BCP-47 language tag];stop;sleep 5;start
    Zastąp sekcje w nawiasach odpowiednimi kodami z kroku 1.

    Aby na przykład przeprowadzić test w kanadyjskiej wersji francuskiej:
    setprop persist.sys.locale fr-CA;stop;sleep 5;start

Spowoduje to ponowne uruchomienie emulatora. Gdy pojawi się ekran główny, jeszcze raz uruchom aplikację. Będzie się ona wtedy uruchamiała w nowym języku.

Testowanie zasobów domyślnych

Aby sprawdzić, czy aplikacja zawiera wszystkie potrzebne zasoby tekstowe:

  1. Ustaw emulator lub urządzenie na język, którego Twoja aplikacja nie obsługuje. Jeśli na przykład aplikacja zawiera ciągi francuskie w funkcji res/values-fr/, ale nie zawiera żadnych ciągów hiszpańskich w polu res/values-es/, ustaw język emulatora na hiszpański. Aby ustawić nieobsługiwany język w emulatorze, możesz użyć aplikacji niestandardowego języka.
  2. Uruchom aplikację.
  3. Jeśli aplikacja wyświetli komunikat o błędzie i przycisk Wymuś zamknięcie, może oznaczać, że szuka ciągu znaków, który jest niedostępny. Sprawdź, czy plik res/values/strings.xml zawiera definicję każdego ciągu znaków używanego przez aplikację.

Jeśli test się powiedzie, powtórz go w przypadku innych typów konfiguracji. Jeśli na przykład aplikacja zawiera plik układu o nazwie res/layout-land/main.xml, ale nie zawiera pliku res/layout-port/main.xml, ustaw emulator lub urządzenie w orientacji pionowej i sprawdź, czy aplikacja działa.