Omówienie zasobów aplikacji (widoki)

Katalog

Typ zasobu

animator/

Pliki XML, które definiują animacje właściwości.

anim/

Pliki XML, które definiują animacje Tween. Animacje właściwości można też zapisywać w tym katalogu, ale w przypadku animacji właściwości zalecany jest katalog animator/, aby odróżnić te 2 typy.

color/

Pliki XML, które definiują listę kolorów stanu. Więcej informacji znajdziesz w artykule Lista stanów kolorów.

drawable/

Pliki bitmapowe (PNG, .9.png, JPG lub GIF) lub pliki XML, które są kompilowane do następujących podtypów obiektów rysowalnych:

• Pliki bitmapowe
• Pliki Nine-Patch (mapy bitowe o zmienianym rozmiarze)
• Listy stanowe
• Kształty
• Rysunki animacji
• Inne elementy rysowalne

Więcej informacji znajdziesz w artykule Zasoby rysowalne.

mipmap/

Pliki rysowalne dla różnych gęstości ikon programu uruchamiającego. Więcej informacji o zarządzaniu ikonami programu uruchamiającego za pomocą folderów mipmap/ znajdziesz w artykule Umieszczanie ikon aplikacji w katalogach mipmap.

layout/

Pliki XML, które definiują układ interfejsu użytkownika. Więcej informacji znajdziesz w artykule Zasób układu.

menu/

Pliki XML, które definiują menu aplikacji, np. menu opcji, menu kontekstowe lub podmenu. Więcej informacji znajdziesz w artykule Zasób menu.

raw/

dowolne pliki, które mają być zapisane w formie nieprzetworzonej; Aby otworzyć te zasoby za pomocą surowego InputStream, wywołaj funkcję Resources.openRawResource z identyfikatorem zasobu, czyli R.raw.filename.

Jeśli jednak potrzebujesz dostępu do oryginalnych nazw plików i hierarchii plików, rozważ zapisanie zasobów w katalogu assets/ zamiast w res/raw/. Pliki w assets/ nie mają identyfikatora zasobu, więc można je odczytać tylko za pomocą AssetManager.

values/

Pliki XML zawierające proste wartości, takie jak ciągi znaków, liczby całkowite i kolory.

Pliki zasobów XML w innych podkatalogach res/ definiują pojedynczy zasób na podstawie nazwy pliku XML, natomiast pliki w katalogu values/ opisują wiele zasobów. W przypadku pliku w tym katalogu każdy element podrzędny elementu definiuje pojedynczy zasób. Na przykład element tworzy zasób R.string, a element tworzy zasób R.color.

Każdy zasób jest zdefiniowany za pomocą własnego elementu XML, więc możesz nazwać plik dowolnie i umieścić w nim różne typy zasobów. Jednak w celu uniknięcia wątpliwości możesz umieścić unikalne typy zasobów w różnych plikach. Oto kilka przykładów konwencji nazw plików w przypadku zasobów, które możesz utworzyć w tym katalogu:

• arrays.xml w przypadku tablic zasobów (tablice z typem);
• colors.xml w przypadku wartości kolorów
• dimens.xml w przypadku wartości wymiarów
• strings.xml w przypadku wartości typu ciąg znaków
• styles.xml w przypadku stylów.

Więcej informacji znajdziesz w sekcjach Zasoby tekstowe, Zasoby stylu i Więcej typów zasobów.

xml/

Dowolne pliki XML, które można odczytać w czasie działania programu, wywołując funkcję Resources.getXML(). Należy tu zapisać różne pliki konfiguracji XML.

font/

Pliki czcionek z rozszerzeniami TTF, OTF lub TTC albo pliki XML zawierające element . Więcej informacji o czcionkach jako zasobach znajdziesz w artykule Dodawanie czcionki jako zasobu XML.

Konfiguracja

Wartości kwalifikatora

Opis

MCC i MNC

Przykłady:

mcc310

mcc310-mnc004

mcc208-mnc00

Kod kraju (MCC), opcjonalnie z kodem MNC z karty SIM w urządzeniu. Na przykład mcc310 to Stany Zjednoczone w przypadku dowolnego operatora, mcc310-mnc004 to Stany Zjednoczone w przypadku Verizon, a mcc208-mnc00 to Francja w przypadku Orange.

Jeśli urządzenie korzysta z połączenia radiowego (czyli jest telefonem GSM), wartości MCC i MNC pochodzą z karty SIM.

Możesz też użyć samego kodu MCC, np. aby uwzględnić w aplikacji zasoby prawne dotyczące danego kraju. Jeśli chcesz określić tylko język, użyj kwalifikatora język, pismo (opcjonalnie) i region (opcjonalnie). Jeśli używasz kwalifikatora MCC i MNC, rób to ostrożnie i sprawdź, czy działa on zgodnie z oczekiwaniami.

Zobacz też pola konfiguracji mcc i mnc, które wskazują odpowiednio bieżący kod kraju komórki i kod sieci komórkowej.

Język, pismo (opcjonalnie) i region (opcjonalnie)

Przykłady:

en

fr

en-rUS

fr-rFR

fr-rCA

b+en

b+en+US

b+es+419

b+zh+Hant

b+sr+Latn+RS

Język jest określany przez dwuliterowy kod języka ISO 639-2{:.external}, opcjonalnie po którym następuje dwuliterowy kod regionu ISO 3166-1-alpha-2{:.external} (poprzedzony małą literą r).

W kodach nie jest rozróżniana wielkość liter. Prefiks r służy do odróżnienia części regionu. Nie możesz określić samego regionu.

W Androidzie 7.0 (poziom interfejsu API 24) wprowadzono obsługę tagów języka zgodnych ze standardem BCP 47{:.external}, których możesz używać do kwalifikowania zasobów specyficznych dla danego języka i regionu. Tag języka składa się z ciągu co najmniej 1 podtagu, z których każdy doprecyzowuje lub zawęża zakres języka identyfikowanego przez cały tag. Więcej informacji o tagach językowych znajdziesz w artykule Tags for Identifying Languages{:.external}.

Aby użyć tagu języka BCP 47, połącz znak b+ z dwuliterowym kodem języka ISO 639-2{:.external} i opcjonalnie dodaj kolejne podtagi rozdzielone znakiem +.

Tag języka może się zmieniać w trakcie działania aplikacji, jeśli użytkownicy zmienią język w ustawieniach systemu. Więcej informacji o tym, jak może to wpłynąć na aplikację w czasie działania, znajdziesz w artykule Obsługa zmian konfiguracji.

Pełny przewodnik po lokalizowaniu aplikacji na inne języki znajdziesz w artykule Lokalizowanie aplikacji.

Zobacz też metodę getLocales, która zawiera zdefiniowaną listę ustawień regionalnych. Lista zawiera język podstawowy.

Płeć gramatyczna użytkownika. Używane w przypadku języków, w których występuje rodzaj gramatyczny.

Jeśli na przykład musisz udostępnić różne zasoby użytkownikom posługującym się językiem francuskim, możesz użyć katalogów takich jak te:

res/
  values-fr/
    strings.xml (domyślne ciągi znaków z nieokreśloną płcią)
  values-fr-masculine/
    strings.xml (ciągi znaków z rodzajem męskim)
  values-fr-feminine/
    strings.xml (ciągi znaków z rodzajem żeńskim)
  values-fr-neuter/
    strings.xml (ciągi znaków z rodzajem nijakim)

Zobacz: Rodzaj gramatyczny w Androidzie.

Zobacz też metodę konfiguracji getGrammaticalGender(), która wskazuje rodzaj gramatyczny.

Dodano na poziomie API 34.

Kierunek układu

ldrtl

ldltr

Kierunek układu aplikacji. ldrtl oznacza „layout-direction-right-to-left”. ldltr oznacza „layout-direction-left-to-right” i jest domyślną wartością niejawną.

Może to dotyczyć dowolnego zasobu, np. układów, elementów rysowalnych lub wartości.

Jeśli na przykład chcesz udostępnić konkretny układ dla języka arabskiego i ogólny układ dla każdego innego języka zapisanego od prawej do lewej, takiego jak perski czy hebrajski, użyj katalogów w tym formacie:

res/
layout/
main.xml (układ domyślny)
layout-ar/
main.xml (układ dla języka arabskiego)
layout-ldrtl/
main.xml (dowolny język pisany od prawej do lewej z wyjątkiem arabskiego, ponieważ kwalifikator języka „ar” ma wyższy priorytet)

Uwaga: aby włączyć w aplikacji funkcje układu od prawej do lewej, musisz ustawić wartość SupportsRtl na „true” i wartość TargetSdkVersion na 17 lub wyższą.

Dodano na poziomie API 17.

Najmniejsza szerokość

swdp

Przykłady:

sw320dp

sw600dp

sw720dp

itd.

Najkrótszy wymiar obszaru ekranu dostępnego dla aplikacji. W przypadku okna aplikacji jest to krótszy z dostępnych wymiarów wysokości i szerokości okna.smallestWidth Możesz też myśleć o tym jako o „najmniejszej możliwej szerokości” okna. Możesz użyć tego kwalifikatora, aby interfejs aplikacji miał szerokość co najmniej  dps.

Jeśli na przykład układ wymaga, aby jego najmniejszy wymiar obszaru ekranu wynosił co najmniej 600 dp, możesz użyć tego kwalifikatora, aby utworzyć zasoby layoutu w katalogu res/layout-sw600dp/. System używa tych zasobów tylko wtedy, gdy najmniejszy wymiar dostępnego ekranu wynosi co najmniej 600 dp, niezależnie od tego, czy ten wymiar jest postrzeganą przez użytkownika wysokością czy szerokością. Najmniejsza szerokość może się zmienić, jeśli rozmiar okna zostanie zmieniony, co spowoduje zmianę dostępnej szerokości lub wysokości, lub jeśli okno zostanie przeniesione, co może spowodować zmianę wcięć systemowych.

Używanie najmniejszej szerokości do określania ogólnego rozmiaru ekranu jest przydatne, ponieważ szerokość jest często czynnikiem decydującym o projektowaniu układu. Interfejs użytkownika często przewija się w pionie, ale ma dość sztywne ograniczenia dotyczące minimalnej przestrzeni potrzebnej w poziomie.

Dostępna szerokość jest też kluczowym czynnikiem przy określaniu, czy używać układu z 1 panelem na telefonach, czy układu z wieloma panelami na tabletach. Dlatego prawdopodobnie najbardziej zależy Ci na tym, jaka jest najmniejsza możliwa szerokość na każdym urządzeniu.

Najmniejsza szerokość urządzenia uwzględnia dekoracje ekranu i interfejs systemu. Jeśli na przykład urządzenie ma na ekranie elementy interfejsu, które zajmują miejsce wzdłuż osi o najmniejszej szerokości, system deklaruje, że najmniejsza szerokość jest mniejsza niż rzeczywisty rozmiar ekranu, ponieważ są to piksele ekranu niedostępne dla interfejsu.

Oto niektóre wartości, których możesz użyć w przypadku typowych rozmiarów ekranu:

• 320 – w przypadku urządzeń o takich konfiguracjach ekranu:
• 240x320 ldpi (telefon QVGA)
• 320 x 480 mdpi (telefon)
• 480x800 hdpi (urządzenie o dużej gęstości)
• 480 – w przypadku ekranów takich jak 480 x 800 mdpi (tablet/telefon);
• 600 – w przypadku ekranów takich jak 600 x 1024 mdpi (7-calowy tablet).
• 720 – w przypadku ekranów takich jak 720 x 1280 mdpi (10-calowy tablet).

Jeśli aplikacja udostępnia wiele katalogów zasobów z różnymi wartościami kwalifikatora smallestWidth, system używa tego, który jest najbliższy wartości smallestWidth urządzenia (ale jej nie przekracza).

Dodano na poziomie 13 interfejsu API.

Zobacz też atrybut android:requiresSmallestWidthDp, który deklaruje minimalną wersję smallestWidth, z którą Twoja aplikacja jest zgodna, oraz pole konfiguracji smallestScreenWidthDp, które zawiera wartość smallestWidth urządzenia.

Więcej informacji o projektowaniu na różne ekrany za pomocą tego kwalifikatora znajdziesz w artykule Projektowanie elastyczne i adaptacyjne z użyciem widoków.

Dostępna szerokość i wysokość

wdp

hdp

Przykłady:

w720dp

w1024dp

h720dp

h1024dp

itd.

Określa minimalną dostępną szerokość lub wysokość ekranu (w dp jednostkach zdefiniowanych przez wartość ), przy której używany jest zasób. Te wartości konfiguracji są porównywane z bieżącą szerokością i wysokością wyświetlacza, gdy orientacja urządzenia zmienia się z pionowej na poziomą i odwrotnie, gdy urządzenie jest składane lub rozkładane albo gdy system wchodzi w tryb wielu okien lub z niego wychodzi. W trybie wielu okien wartości odzwierciedlają szerokość i wysokość okna zawierającego aplikację, a nie szerokość i wysokość ekranu urządzenia. Podobnie w przypadku aktywności osadzonych wartości dotyczą szerokości i wysokości poszczególnych aktywności, a nie szerokości i wysokości ekranu. Więcej informacji znajdziesz w artykule Osadzanie aktywności.

Dostępna szerokość i wysokość często przydają się do określania, czy używać układu wielopanelowego, ponieważ nawet na tablecie nie zawsze chcesz używać tego samego układu wielopanelowego w orientacji pionowej i poziomej. Dzięki temu możesz ich używać do określania minimalnej szerokości lub wysokości wymaganej w przypadku układu zamiast używać jednocześnie kwalifikatorów rozmiaru i orientacji ekranu.

Jeśli aplikacja udostępnia wiele katalogów zasobów z różnymi wartościami tych konfiguracji, system używa tego, który jest najbliższy (ale nie przekracza) bieżącej szerokości ekranu urządzenia. Najbliższy jest określany przez dodanie różnic między rzeczywistą szerokością ekranu a określoną szerokością do różnicy między rzeczywistą wysokością ekranu a określoną wysokością. Nieokreślone wysokości i szerokości mają wartość 0.

Wartości nie obejmują obszaru zajmowanego przez wstawki okna, więc jeśli urządzenie ma trwałe elementy interfejsu na krawędziach wyświetlacza, wartości szerokości i wysokości są mniejsze niż rzeczywiste wymiary ekranu, nawet gdy aplikacja jest wyświetlana od krawędzi do krawędzi za pomocą Window.setDecorFitsSystemWindows lub WindowCompat.setDecorFitsSystemWindows.

Niektóre dekoracje ekranu w orientacji pionowej, które nie są stałe (np. pasek stanu telefonu, który można ukryć w trybie pełnoekranowym), nie są tu uwzględniane. Nie są też uwzględniane dekoracje okien, takie jak pasek tytułu czy pasek działań, więc aplikacje muszą być przygotowane na nieco mniejszą przestrzeń niż ta, którą określają.

Uwaga: system wybiera zasób, który pasuje zarówno pod względem szerokości, jak i wysokości. Dlatego zasób, który określa oba te elementy, jest znacznie lepszy od zasobu, który określa tylko jeden z nich. Jeśli np. rzeczywisty ekran ma szerokość 720 dp i wysokość 1280 dp, a jeden zasób jest oznaczony jako w720dp, a drugi jako w700dp-h1200dp, ten drugi zostanie wybrany, mimo że pierwszy jest dokładnym dopasowaniem do tego, co określa.

Dodano na poziomie 13 interfejsu API.

Zobacz też pola konfiguracji screenWidthDp i screenHeightDp, które zawierają bieżącą szerokość i wysokość ekranu.

Więcej informacji o projektowaniu na różne ekrany za pomocą tego kwalifikatora znajdziesz w artykule Projektowanie elastyczne i adaptacyjne z użyciem widoków.

Rozmiar ekranu

small

normal

large

xlarge

• small: ekrany o rozmiarach podobnych do ekranu QVGA o niskiej gęstości pikseli. Minimalny rozmiar układu na małym ekranie to około 320 x 426 dp. Przykłady to QVGA o niskiej gęstości i VGA o wysokiej gęstości.
• normal: ekrany o rozmiarach podobnych do ekranu HVGA o średniej gęstości pikseli. Minimalny rozmiar układu dla normalnego ekranu to około 320 x 470 dp. Przykłady takich ekranów to WQVGA o niskiej gęstości pikseli, HVGA o średniej gęstości pikseli i WVGA o wysokiej gęstości pikseli.
• large: ekrany o rozmiarach podobnych do ekranu VGA o średniej gęstości pikseli. Minimalny rozmiar układu na dużym ekranie to około 480 x 640 dp. Przykłady to ekrany VGA i WVGA o średniej gęstości.
• xlarge: ekrany znacznie większe niż tradycyjny ekran HVGA o średniej gęstości pikseli. Minimalny rozmiar układu na ekranie o rozmiarze XL to około 720 x 960 dp. W większości przypadków urządzenia z bardzo dużymi ekranami są za duże, aby nosić je w kieszeni, i najprawdopodobniej są to urządzenia typu tablet. Dodano na poziomie interfejsu API 9.

Uwaga: użycie kwalifikatora rozmiaru nie oznacza, że zasoby są przeznaczone tylko na ekrany o tym rozmiarze. Jeśli nie podasz zasobów alternatywnych z kwalifikatorami, które lepiej pasują do bieżącej konfiguracji urządzenia, system może użyć zasobów, które są najlepiej dopasowane.

Uwaga: jeśli wszystkie zasoby używają kwalifikatora rozmiaru, który jest większy niż bieżący ekran, system ich nie używa, a aplikacja ulega awarii w czasie działania. Dzieje się tak na przykład, gdy wszystkie zasoby układu są oznaczone kwalifikatorem xlarge, ale urządzenie ma ekran o normalnym rozmiarze.

Dodano na poziomie API 4.

Zobacz też pole konfiguracji screenLayout, które wskazuje, czy ekran jest mały, normalny czy duży.

Więcej informacji znajdziesz w omówieniu zgodności ekranów.

Format ekranu

long

notlong

• long: długie ekrany, np. WQVGA, WVGA, FWVGA
• notlong: nie są to długie ekrany, takie jak QVGA, HVGA i VGA.

Dodano na poziomie API 4.

Zależy to wyłącznie od współczynnika proporcji ekranu (ekran long jest szerszy). Nie ma to związku z orientacją ekranu.

Zobacz też pole konfiguracji screenLayout, które wskazuje, czy ekran jest długi.

Okrągły ekran

round

notround

• round: okrągłe ekrany, np. okrągłe urządzenia do noszenia;
• notround: ekrany prostokątne, np. telefony lub tablety;

Dodano na poziomie interfejsu API 23.

Sprawdź też metodę konfiguracji isScreenRound, która określa, czy ekran jest okrągły.

Szeroka gama kolorów

widecg

nowidecg

• widecg: wyświetlacze z szeroką gamą kolorów, np. Display P3 lub AdobeRGB.
• nowidecg: wyświetlacze z wąską gamą kolorów, np. sRGB;

Dodano na poziomie interfejsu API 26.

Sprawdź też metodę konfiguracji isScreenWideColorGamut, która wskazuje, czy ekran ma szeroką gamę kolorów.

High Dynamic Range (HDR)

highdr

lowdr

• highdr: wyświetlacze o wysokim zakresie dynamiki,
• lowdr: wyświetlacze o niskim lub standardowym zakresie dynamicznym;

Dodano na poziomie interfejsu API 26.

Zobacz też metodę konfiguracji isScreenHdr, która określa, czy ekran obsługuje HDR.

Orientacja ekranu

port

land

• port: urządzenie jest w orientacji pionowej;
• land: urządzenie jest w orientacji poziomej;

Może się to zmienić w trakcie korzystania z aplikacji, jeśli użytkownik obróci ekran. Więcej informacji o tym, jak to wpływa na aplikację w czasie działania, znajdziesz w artykule Obsługa zmian konfiguracji.

Zobacz też pole konfiguracji orientation, które wskazuje bieżącą orientację urządzenia.

Tryb interfejsu

car

desk

television

appliance

watch

vrheadset

• car: urządzenie jest umieszczone w samochodowej stacji dokującej.
• desk: urządzenie jest umieszczone w stacji dokującej na biurko;
• television: urządzenie wyświetla obraz na telewizorze, zapewniając „10-stopową” odległość, w której interfejs użytkownika jest wyświetlany na dużym ekranie, od którego użytkownik jest oddalony, a korzystanie z urządzenia odbywa się głównie za pomocą pada kierunkowego lub innych interakcji bez użycia wskaźnika.
• appliance: urządzenie pełni funkcję sprzętu bez wyświetlacza.
• watch: urządzenie ma wyświetlacz i jest noszone na nadgarstku.
• vrheadset: urządzenie wyświetla obraz w goglach do rzeczywistości wirtualnej.

Dodano na poziomie API 8; telewizor dodano na poziomie API 13; urządzenie dodano na poziomie API 16; zegarek dodano na poziomie API 20; zestaw VR dodano na poziomie API 26.

Informacje o tym, jak aplikacja może reagować na włożenie urządzenia do stacji dokującej lub wyjęcie go z niej, znajdziesz w artykule Określanie i monitorowanie stanu i typu stacji dokującej.

Może się to zmienić w trakcie działania aplikacji, jeśli użytkownik umieści urządzenie w stacji dokującej. Niektóre z tych trybów możesz włączać i wyłączać za pomocą ikony UiModeManager. Więcej informacji o tym, jak to wpływa na aplikację w czasie działania, znajdziesz w artykule Obsługa zmian konfiguracji.

Tryb nocny

night

notnight

• night: noc
• notnight: w ciągu dnia

Dodano na poziomie API 8.

Może się to zmienić w trakcie działania aplikacji, jeśli tryb nocny pozostanie w trybie automatycznym (domyślnym). W takim przypadku tryb zmienia się w zależności od pory dnia. Ten tryb możesz włączyć lub wyłączyć za pomocą UiModeManager. Więcej informacji o tym, jak to wpływa na aplikację w czasie działania, znajdziesz w artykule Obsługa zmian konfiguracji.

Gęstość pikseli ekranu (dpi)

ldpi

mdpi

hdpi

xhdpi

xxhdpi

xxxhdpi

nodpi

tvdpi

anydpi

nnndpi

• ldpi: ekrany o niskiej gęstości, ok. 120 dpi.
• mdpi: ekrany o średniej gęstości (tradycyjne ekrany HVGA); około 160 dpi.
• hdpi: ekrany o wysokiej gęstości pikseli, ok. 240 dpi.
• xhdpi: ekrany o bardzo wysokiej gęstości, ok. 320 dpi. Dodano na poziomie API 8.
• xxhdpi: ekrany o bardzo wysokiej gęstości pikseli, około 480 dpi. Dodano na poziomie API 16.
• xxxhdpi: bardzo wysoka gęstość pikseli (tylko ikona programu uruchamiającego – patrz Obsługa różnych gęstości pikseli); około 640 dpi. Dodano na poziomie API 18.
• nodpi: używany w przypadku zasobów bitmapowych, które nie mają być skalowane w celu dopasowania do gęstości pikseli na urządzeniu.
• tvdpi: ekrany o rozdzielczości między mdpi a hdpi, czyli około 213 dpi. Nie jest to „podstawowa” grupa gęstości. Jest on przeznaczony głównie dla telewizorów o rozdzielczości 720p i większość aplikacji go nie potrzebuje. W przypadku paneli telewizyjnych o rozdzielczości 1080p użyj xhdpi, a w przypadku paneli telewizyjnych o rozdzielczości 4K użyj xxxhdpi. Dodano na poziomie 13 interfejsu API.
• anydpi: pasuje do wszystkich gęstości ekranu i ma pierwszeństwo przed innymi kwalifikatorami. Jest to przydatne w przypadku grafiki wektorowej. Dodano na poziomie API 21.
• nnndpi: używany do reprezentowania niestandardowych gęstości, gdzie nnn to dodatnia liczba całkowita określająca gęstość ekranu. W większości przypadków nie jest to używane. Korzystanie ze standardowych zakresów gęstości znacznie zmniejsza narzut związany z obsługą różnych gęstości ekranów urządzeń dostępnych na rynku.

Między 6 głównymi gęstościami (z pominięciem gęstości tvdpi) występuje współczynnik skalowania 3:4:6:8:12:16. Bitmapa 9x9 w rozdzielczości ldpi ma wymiary 12x12 w rozdzielczości mdpi, 18x18 w rozdzielczości hdpi, 24x24 w rozdzielczości xhdpi itd.

Uwaga: użycie kwalifikatora gęstości nie oznacza, że zasoby są przeznaczone tylko na ekrany o tej gęstości. Jeśli nie podasz zasobów alternatywnych z kwalifikatorami, które lepiej pasują do bieżącej konfiguracji urządzenia, system użyje zasobów, które są najlepiej dopasowane.

Więcej informacji o obsłudze różnych gęstości ekranu i o tym, jak Android może skalować mapy bitowe, aby dopasować je do bieżącej gęstości, znajdziesz w omówieniu zgodności z ekranem.

Typ ekranu dotykowego

notouch

finger

• notouch: urządzenie nie ma ekranu dotykowego.
• finger: urządzenie ma ekran dotykowy, który jest przeznaczony do bezpośredniej interakcji z użyciem palca.

Zobacz też pole konfiguracji touchscreen, które wskazuje typ ekranu dotykowego na urządzeniu.

Dostępność klawiatury

keysexposed

keyshidden

keyssoft

• keysexposed: urządzenie ma dostępną klawiaturę. Jeśli na urządzeniu jest włączona klawiatura programowa (co jest prawdopodobne), jest ona używana nawet wtedy, gdy klawiatura sprzętowa nie jest dostępna dla użytkownika lub gdy urządzenie nie ma klawiatury sprzętowej. Jeśli klawiatura programowa nie jest dostępna lub jest wyłączona, ta opcja jest używana tylko wtedy, gdy jest dostępna klawiatura sprzętowa.
• keyshidden: urządzenie ma dostępną klawiaturę sprzętową, ale jest ona ukryta i na urządzeniu nie jest włączona klawiatura ekranowa.
• keyssoft: na urządzeniu jest włączona klawiatura programowa, niezależnie od tego, czy jest widoczna.

Jeśli podasz zasoby keysexposed, ale nie podasz zasobów keyssoft, system użyje zasobów keysexposed niezależnie od tego, czy klawiatura jest widoczna, o ile w systemie jest włączona klawiatura programowa.

Może się to zmienić w trakcie korzystania z aplikacji, jeśli użytkownik otworzy klawiaturę sprzętową. Więcej informacji o tym, jak to wpływa na aplikację w czasie działania, znajdziesz w artykule Obsługa zmian konfiguracji.

Zobacz też pola konfiguracji hardKeyboardHidden i keyboardHidden, które wskazują odpowiednio widoczność klawiatury sprzętowej i widoczność dowolnego rodzaju klawiatury (w tym programowej).

Podstawowa metoda wprowadzania tekstu

nokeys

qwerty

12key

• nokeys: urządzenie nie ma klawiszy sprzętowych do wprowadzania tekstu.
• qwerty: urządzenie ma klawiaturę sprzętową QWERTY, niezależnie od tego, czy jest ona widoczna dla użytkownika.
• 12key: urządzenie ma sprzętową klawiaturę 12-klawiszową, niezależnie od tego, czy jest ona widoczna dla użytkownika.

Zobacz też pole konfiguracji keyboard, które wskazuje dostępną podstawową metodę wprowadzania tekstu.

Dostępność klawiszy nawigacyjnych

navexposed

navhidden

• navexposed: użytkownik ma dostęp do klawiszy nawigacyjnych.
• navhidden: klawisze nawigacyjne są niedostępne (np. gdy urządzenie jest zamknięte).

Może się to zmienić w trakcie korzystania z aplikacji, jeśli użytkownik wyświetli klawisze nawigacyjne. Więcej informacji o tym, jak to wpływa na aplikację w czasie działania, znajdziesz w artykule Obsługa zmian konfiguracji.

Zobacz też pole konfiguracji navigationHidden, które wskazuje, czy klawisze nawigacyjne są ukryte.

Podstawowa metoda nawigacji bezdotykowej

nonav

dpad

trackball

wheel

• nonav: urządzenie nie ma funkcji nawigacji poza ekranem dotykowym.
• dpad: urządzenie ma pad kierunkowy do nawigacji.
• trackball: urządzenie ma trackball do nawigacji.
• wheel: urządzenie ma koło kierunkowe do nawigacji (rzadko spotykane);

Zobacz też pole konfiguracji navigation, które wskazuje typ dostępnej metody nawigacji.

Wersja platformy (poziom interfejsu API)

Przykłady:

v3

v4

v7

itd.

Poziom API obsługiwany przez urządzenie. Na przykład v1 w przypadku poziomu interfejsu API 1 (urządzenia z Androidem 1.0 lub nowszym) i v4 w przypadku poziomu interfejsu API 4 (urządzenia z Androidem 1.6 lub nowszym). Więcej informacji o tych wartościach znajdziesz w dokumencie Poziomy interfejsu API Androida.