Interfejsy API Androida 3.2

Poziom API: 13

Android 3.2 (HONEYCOMB_MR2) to przyrostowa wersja platformy, która daje użytkownikom i deweloperom nowe możliwości. W sekcjach poniżej znajdziesz omówienie nowych funkcji i interfejsów API dla programistów.

Dla deweloperów platforma Android 3.2 jest dostępna jako komponent do pobrania w pakiecie Android SDK. Platforma do pobrania zawiera bibliotekę i obraz systemu Androida, a także zestaw skórek do emulatora i inne elementy. Aby rozpocząć tworzenie i testowanie aplikacji na Androida 3.2, użyj Menedżera pakietu Android SDK, aby pobrać platformę do swojego pakietu SDK.

Najważniejsze informacje o platformie

Nowe funkcje dla użytkowników

  • Optymalizacja pod kątem większej liczby tabletów

    Android 3.2 zawiera wiele optymalizacji systemu, aby zapewnić użytkownikom wygodę korzystania z urządzeń z Androidem na większej liczbie tabletów.

  • Powiększenie zgodne z aplikacjami o stałym rozmiarze

    Android 3.2 wprowadza nowy tryb powiększenia zgodności, który umożliwia użytkownikom przeglądanie aplikacji o stałym rozmiarze na większych urządzeniach. Nowy tryb zapewnia skalowanie pikseli w standardowym interfejsie w przypadku aplikacji, które nie są przeznaczone do uruchamiania na większych ekranach, np. na tabletach. Nowy tryb jest dostępny dla użytkowników w postaci ikony menu na pasku systemowym w przypadku aplikacji, które wymagają obsługi zgodności.

  • Synchronizacja multimediów z karty SD

    Na urządzeniach obsługujących karty SD użytkownicy mogą teraz wczytywać pliki multimedialne bezpośrednio z karty SD do aplikacji, które ich używają. Udostępniamy pliki aplikacjom z systemowego magazynu multimediów.

Nowe funkcje dla programistów

  • Rozszerzone API do obsługi ekranów

    Android 3.2 wprowadza rozszerzenia interfejsu API obsługi ekranu, aby zapewnić deweloperom dodatkowe sposoby zarządzania interfejsem użytkownika aplikacji na różnych urządzeniach z Androidem. Interfejs API zawiera nowe kwalifikatory zasobów i nowe atrybuty pliku manifestu, które zapewniają większą kontrolę nad tym, jak aplikacje są wyświetlane w różnych rozmiarach, zamiast polegać na ogólnych kategoriach rozmiarów.

    Aby zapewnić jak najlepszy wyświetlacz w przypadku aplikacji o stałym rozmiarze i aplikacji z ograniczonym wsparciem dla różnych rozmiarów ekranu, platforma udostępnia też nowy tryb zgodności z powiększeniem, który renderuje interfejs na mniejszej powierzchni ekranu, a potem skaluje go, aby wypełnić dostępną przestrzeń na wyświetlaczu. Więcej informacji o interfejsie API obsługi ekranu i dostępnych w nim ustawieniach znajdziesz w sekcjach poniżej.

Omówienie interfejsu API

Interfejsy API obsługi ekranów

Android 3.2 wprowadza nowe ekrany, które obsługują interfejsy API, które dają większą kontrolę nad sposobem wyświetlania aplikacji na ekranach o różnych rozmiarach. Interfejs API opiera się na istniejącym interfejsie API obsługującym ekrany, w tym na ogólnym modelu gęstości ekranu, ale rozszerza go o możliwość dokładnego kierowania na określone zakresy ekranów według ich wymiarów mierzonych w niezależnych od gęstości pikseli jednostkach (np. 600 dp lub 720 dp szerokości) zamiast ogólnych rozmiarów ekranu (np. duży lub bardzo duży).

Podczas projektowania interfejsu aplikacji możesz nadal polegać na platformie, która zapewnia abstrakcję gęstości. Oznacza to, że aplikacje nie muszą kompensować różnic w rzeczywistej gęstości pikseli na różnych urządzeniach. Interfejs aplikacji możesz zaprojektować w taki sposób, aby wykorzystać dostępną przestrzeń poziomą lub pionową. Platforma określa ilość dostępnej przestrzeni za pomocą 3 nowych właściwości: smallestWidth, width i height.

  • smallestWidth ekranu to jego podstawowy minimalny rozmiar wyrażony w pikselach niezależnych od gęstości („dp”). Jest to mniejsza z wysokości i szerokości ekranu. W przypadku ekranu w orientacji pionowej najmniejsza szerokość jest zwykle określana na podstawie jego szerokości, a w przypadku orientacji poziomej – na podstawie wysokości. We wszystkich przypadkach najmniejsza wartość najmniejsza szerokość jest określana na podstawie stałej właściwości ekranu, a wartość nie zmienia się bez względu na orientację. Wartość smallestWidth jest ważna dla aplikacji, ponieważ reprezentuje najmniejszą możliwą szerokość, w której interfejs aplikacji musi zostać narysowany, bez uwzględnienia obszarów ekranu zarezerwowanych przez system.
  • Natomiast szerokość i wysokość ekranu to bieżąca pozioma lub pionowa przestrzeń dostępna na potrzeby układu aplikacji, mierzona w jednostkach „dp”, bez uwzględnienia obszarów ekranu zarezerwowanych przez system. Szerokość i wysokość ekranu zmieniają się, gdy użytkownik przełącza orientację poziomą lub pionową.

Interfejs API obsługujący nowe ekrany umożliwia zarządzanie interfejsem użytkownika aplikacji zgodnie z najmniejszym rozmiarem bieżącego ekranu. W razie potrzeby możesz też zarządzać interfejsem użytkownika w zależności od bieżącej szerokości lub wysokości. W tym celu interfejs API udostępnia te narzędzia:

  • Nowe predykatory zasobów do kierowania na układy i inne zasoby z minimalną najmniejszą szerokością, szerokością lub wysokością oraz
  • Nowe atrybuty pliku manifestu służące do określania maksymalnego zakresu zgodności ekranu

Podobnie jak w poprzednich wersjach platformy aplikacje nadal mogą wysyłać zapytania do systemu oraz zarządzać interfejsem użytkownika i wczytywaniem zasobów w czasie wykonywania.

Ponieważ nowy interfejs API umożliwia kierowanie na ekrany bardziej bezpośrednio za pomocą właściwości smallestWidth, width i height, warto poznać typowe cechy różnych typów ekranów. Tabela poniżej zawiera kilka przykładów z jednostkami „dp”.

Tabela 1. Typowe urządzenia z gęstością i rozmiarem w pikselach niezależnych od gęstości.

Typ Gęstość (uogólniona) Wymiary (dp) smallestWidth (dp)
Telefon podstawowy mdpi 320 x 480 320
Mały tablet/duży telefon mdpi 480 x 800 480
Tablet 7-calowy mdpi 600x1024 600
Tablet 10-calowy mdpi 800 x 1280 800

W sekcjach poniżej znajdziesz więcej informacji o nowych atrybutach ekranów i atrybutach pliku manifestu. Pełne informacje o używaniu interfejsu screensupport API znajdziesz w artykule Obsługa wielu ekranów.

Nowe kwalifikatory zasobów obsługujące ekrany

Nowe kwalifikatory zasobów w Androidzie 3.2 umożliwiają lepsze dopasowanie układów do zakresów rozmiarów ekranu. Za pomocą tych ograniczników możesz tworzyć konfiguracje zasobów przeznaczone dla określonej minimalnej wartości smallestWidth, bieżącej szerokości lub bieżącej wysokości, mierzonej w pikselach niezależnych od gęstości.

Nowe kryteria to:

  • swNNNdp — określa minimalną wartość smallestWidth, w której zasób powinien być używany, mierzony w jednostkach „dp”. Jak wspomniano powyżej, smallestWidth ekranu jest stały niezależnie od orientacji. Przykłady: sw320dp, sw720dp, sw720dp.
  • wNNNdp i hNNNdp – określa minimalną szerokość lub wysokość, w której zasób powinien być używany, mierzona w jednostkach „dp”. Jak już wspomnieliśmy, szerokość i wysokość ekranu zależą od jego orientacji i zmieniają się wraz z nią. Przykłady: w320dp, w720dp, h1024dp.

W razie potrzeby możesz też utworzyć wiele nakładających się konfiguracji zasobów. Możesz na przykład oznaczyć niektóre zasoby do użycia na ekranach o szerokości większej niż 480 dp, inne do użycia na ekranach o szerokości większej niż 600 dp, a jeszcze inne do użycia na ekranach o szerokości większej niż 720 dp. Jeśli do danego ekranu kwalifikuje się kilka konfiguracji zasobów, system wybierze tę, która najbardziej mu odpowiada. Aby dokładnie kontrolować, które zasoby są wczytywane na danym ekranie, możesz je otagować za pomocą jednego kwalifikatora lub połączyć kilka nowych lub istniejących kwalifikatorów.

Poniżej przedstawiamy kilka przykładów wykorzystania nowych kwalifikatorów w związku z typowymi wymiarami:

res/layout/main_activity.xml   # For phones
res/layout-sw600dp/main_activity.xml   # For 7” tablets
res/layout-sw720dp/main_activity.xml   # For 10” tablets
res/layout-w600dp/main_activity.xml   # Multi-pane when enough width
res/layout-sw600dp-w720dp/main_activity.xml   # For large width

Starsze wersje platformy będą ignorować nowe kwalifikatory, więc możesz je dowolnie łączyć, aby zapewnić, że aplikacja będzie wyglądać świetnie na każdym urządzeniu. Oto kilka przykładów:

res/layout/main_activity.xml   # For phones
res/layout-xlarge/main_activity.xml   # For pre-3.2 tablets
res/layout-sw600dp/main_activity.xml   # For 3.2 and up tablets

Szczegółowe informacje o korzystaniu z nowych kwalifikatorów znajdziesz w artykule Używanie nowych kwalifikatorów rozmiaru.

Nowe atrybuty pliku manifestu dotyczące zgodności z rozmiarem ekranu

Framework oferuje nowy zestaw atrybutów manifestu <supports-screens>, które umożliwiają zarządzanie obsługą różnych rozmiarów ekranu przez aplikację. W szczególności możesz określić największy i najmniejszy ekran, na którym ma działać Twoja aplikacja, a także największy ekran, na którym działa, bez konieczności wdrażania nowego trybu zgodności ekranu w systemie. Podobnie jak kwalifikatory zasobów opisane powyżej, nowe atrybuty pliku manifestu określają zakres ekranów obsługiwanych przez aplikację, jak określa najmniejszaSzerokość.

Nowe atrybuty w pliku manifestu do obsługi ekranów to:

  • android:compatibleWidthLimitDp="numDp" – ten atrybut umożliwia określenie maksymalnej wartości smallestWidth, przy której aplikacja może działać bez konieczności uruchamiania w trybie zgodności. Jeśli bieżący ekran jest większy niż określona wartość, system wyświetla aplikację w trybie normalnym, ale pozwala użytkownikowi opcjonalnie przełączyć się w tryb zgodności za pomocą ustawienia na pasku systemu.
  • android:largestWidthLimitDp="numDp" – ten atrybut umożliwia określenie maksymalnej wartości smallestWidth, w której aplikacja ma się uruchamiać. Jeśli bieżący ekran jest większy niż określona wartość, system wymusza przejście aplikacji w tryb zgodności, aby zapewnić jak najlepszy obraz na bieżącym ekranie.
  • android:requiresSmallestWidthDp="numDp" – ten atrybut umożliwia określenie minimalnej najmniejszej szerokości, na której może działać aplikacja. Jeśli bieżący ekran jest mniejszy niż określona wartość, system uzna aplikację za niezgodną z urządzeniem, ale nie uniemożliwi jej zainstalowania ani uruchomienia.

Uwaga: Google Play nie filtruje obecnie aplikacji na podstawie żadnego z tych atrybutów. Obsługa filtrowania zostanie dodana w późniejszej wersji platformy. Aplikacje, które wymagają filtrowania na podstawie rozmiaru ekranu, mogą używać dotychczasowych atrybutów <supports-screens>.

Szczegółowe informacje o korzystaniu z nowych atrybutów znajdziesz w artykule Deklarowanie obsługi rozmiaru ekranu.

Tryb zgodności z ekranem

Android 3.2 udostępnia nowy tryb zgodności z ekranem dla aplikacji, które wyraźnie deklarują, że nie obsługują ekranów tak dużych jak ten, na którym są uruchomione. Ten nowy tryb „powiększenia” jest skalowany w pikselach – renderuje aplikację w mniejszym obszarze ekranu, a następnie skaluje piksele, aby wypełnić aktualny ekran.

Domyślnie system oferuje tryb zgodności ekranu jako opcję dla użytkownika w przypadku aplikacji, które tego wymagają. Użytkownicy mogą włączać i wyłączać tryb powiększenia za pomocą elementu sterującego na pasku systemowym.

Ponieważ nowy tryb zgodności z ekranem może nie być odpowiedni dla wszystkich aplikacji, platforma umożliwia wyłączenie tego trybu za pomocą atrybutów pliku manifestu. Gdy aplikacja wyłączy tę funkcję, system nie będzie oferować użytkownikom trybu zgodności „zoom” podczas jej działania.

Uwaga: ważne informacje o tym, jak zarządzać trybem zgodności w aplikacjach, znajdziesz w artykule Nowy tryb aplikacji na dużych ekranach na blogu dla deweloperów aplikacji na Androida.

Nowa gęstość ekranu dla telewizorów i podobnych urządzeń o rozdzielczości 720p

Aby zaspokoić potrzeby aplikacji działających na telewizorach 720p lub podobnych z ekranami o umiarkowanej gęstości, w Androidzie 3.2 wprowadzono nową gęstość (tvdpi) o przybliżonej rozdzielczości 213 dpi. Aplikacje mogą wysyłać zapytania o nową gęstość w densityDpi i używać nowego kwalifikatora tvdpi do oznaczania zasobów dla telewizorów i podobnych urządzeń. Na przykład:

res/drawable-tvdpi/my_icon.png   # Bitmap for tv density

Zwykle aplikacje nie muszą obsługiwać takiej gęstości. W sytuacjach, w których dane wyjściowe są potrzebne na ekranie 720p, platforma może automatycznie skalować elementy interfejsu.

Platforma UI

  • Fragmenty
    • Nowa klasa Fragment.SavedState zawiera informacje o stanie pobrane z instancji z fragmentem za pomocą obiektu saveFragmentInstanceState().
    • Nowa metoda saveFragmentInstanceState()zapisuje bieżący stan instancji podanego fragmentu. Stan może być później użyty podczas tworzenia nowej instancji Fragmentu, która odpowiada bieżącemu stanowi.
    • Nowa metoda setInitialSavedState()ustala początkowy zapisany stan fragmentu podczas jego tworzenia.
    • Nowa metoda wywołania onViewCreated() informuje fragment, że onCreateView()wrócił, ale zanim jakikolwiek zapisany stan został przywrócony w widoku.
    • Metoda isDetached() określa, czy fragment został wyraźnie odłączony od interfejsu użytkownika.
    • Nowe metody attach() i detach() umożliwiają aplikacji ponowne dołączanie i odłączanie fragmentów w interfejsie.
    • Nowa metoda przeciążenia setCustomAnimations() umożliwia ustawienie konkretnych zasobów animacji do wykonania operacji wejścia/wyjścia, a w szczególności podczas wyjmowania elementów ze stosu. Obecna implementacja nie uwzględnia różnych zachowań fragmentów podczas usuwania elementów z bieżącego stosu.
  • Informacje o rozmiarze ekranu w sekcjach ActivityInfo i ApplicationInfo
  • Pomocnicze funkcje służące do uzyskiwania rozmiaru wyświetlacza z WindowManagera
    • Nowe metody getSize() i getRectSize() umożliwiają aplikacjom uzyskanie nieprzetworzonego rozmiaru wyświetlacza.
  • Nowe publiczne style „holograficzne”
    • Platforma udostępnia teraz szereg publicznych stylów „holograficznych” (tekstu, widżetów i kart na pasku działań). Pełną listę znajdziesz w sekcji R.style.
  • Funkcje LocalActivityManager, ActivityGroup i LocalActivityManager są teraz wycofane.
    • Nowe aplikacje powinny używać fragmentów zamiast tych klas. Aby nadal korzystać z usługi w starszych wersjach platformy, możesz użyć biblioteki pomocy (biblioteki zgodności) w wersji 4, która jest dostępna w pakiecie Android SDK. Biblioteka obsługi wersji 4 udostępnia wersję interfejsu Fragment API, która jest zgodna z Androidem 1.6 (poziom interfejsu API 4).
    • W przypadku aplikacji tworzonych na Androida 3.0 (poziom interfejsu API 11) lub nowszego karty są zwykle wyświetlane w interfejsie za pomocą nowego interfejsu API ActionBar.newTab() i powiązanych interfejsów API do umieszczania kart w obszarze paska czynności.

Platforma mediów

  • Aplikacje korzystające z dostawcy multimediów platformy (MediaStore) mogą teraz odczytywać dane multimediów bezpośrednio z wymiennej karty SD, jeśli jest to obsługiwane przez urządzenie. Aplikacje mogą też bezpośrednio wchodzić w interakcję z plikami na karcie SD, korzystając z interfejsu MTP API.

Grafika

Platforma IME

  • Nowa metoda getModifiers() służąca do pobierania bieżącego stanu klawiszy modyfikujących.

Ramka USB

  • Nowa metoda getRawDescriptors() pobierania nieprzetworzonych deskryptorów USB dla urządzenia. Za pomocą tej metody możesz uzyskać dostęp do deskryptorów, które nie są obsługiwane bezpośrednio przez interfejsy API wyższego poziomu.

Sieć

Połączenia telefoniczne

Podstawowe narzędzia

Nowe stałe funkcji

Platforma dodaje nowe stałe funkcje sprzętowe, które możesz zadeklarować w pliku manifestu aplikacji, aby poinformować podmioty zewnętrzne, takie jak Google Play, o wymaganych możliwościach sprzętowych i programowych. Te i inne stałe funkcji deklarujesz w elementach pliku manifestu <uses-feature>.

Google Play filtruje aplikacje według atrybutów <uses-feature>, aby mieć pewność, że są one dostępne tylko na urządzeniach, które spełniają ich wymagania.

  • Stałe funkcje dotyczące wymagań dotyczących orientacji poziomej lub pionowej

    Android 3.2 wprowadza nowe stałe funkcje, które pozwalają aplikacjom określić, czy wymagają wyświetlacza w orientacji poziomej, pionowej czy w obu tych sieciach. Zadeklarowanie tych stałych wartości wskazuje, że aplikacja nie może być zainstalowana na urządzeniu, które nie obsługuje powiązanej orientacji. Jeśli z kolei jedna lub obie te stałe nie są zadeklarowane, oznacza to, że aplikacja nie preferuje niezadeklarowanych orientacji i może być zainstalowana na urządzeniu, które ich nie obsługuje.

    Typowa aplikacja, która działa poprawnie zarówno w orientacji poziomej, jak i pionowej, zwykle nie wymaga deklaracji wymagań dotyczących orientacji. Aplikacja zaprojektowana głównie pod kątem jednej orientacji, np. aplikacja na telewizor, może zadeklarować jedną z tych stałych wartości, aby nie była dostępna na urządzeniach, które nie obsługują tej orientacji.

    Jeśli którakolwiek z aktywności zadeklarowanych w pliku manifestu ma być wykonywana w określonej orientacji, za pomocą atrybutu android:screenOrientation, oznacza to również, że aplikacja wymaga tej orientacji.

  • Inne stałe funkcji

Raport o różnicach w interfejsie API

Szczegółowe informacje o wszystkich zmianach w interfejsie API w Androidzie 3.2 (poziom interfejsu API 13) znajdziesz w raporcie o różnicach w interfejsie API.

Poziom API

Platforma Android 3.2 udostępnia zaktualizowaną wersję interfejsu API frameworku. Interfejs API Androida 3.2 ma przypisany identyfikator liczbowy (13), który jest przechowywany w samym systemie. Ten identyfikator, zwany „poziomem interfejsu API”, umożliwia systemowi prawidłowe określenie, czy aplikacja jest zgodna z systemem, zanim zostanie zainstalowana.

Aby używać w aplikacji interfejsów API wprowadzonych w Androidzie 3.2, musisz skompilować aplikację z użyciem biblioteki Androida dostępnej w pakiecie SDK Androida 3.2. W zależności od potrzeb możesz też dodać atrybut android:minSdkVersion="13" do elementu <uses-sdk> w pliku manifestu aplikacji.

Więcej informacji znajdziesz w artykule Co to jest poziom dostępu API?.