Interfejsy API Androida 3.2

Poziom interfejsu API: 13

Android 3.2 (HONEYCOMB_MR2) to wersja platformy z dodatkowymi funkcjami dla użytkowników i programistów. W sekcjach poniżej znajdziesz omówienie nowych funkcji i interfejsów API dla programistów.

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

Platform Highlights

Nowe funkcje dla użytkowników

  • Optymalizacje 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 daje użytkownikom nowy sposób wyświetlania 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ą. Usługa systemowa udostępnia pliki aplikacjom z systemowego magazynu multimediów.

Nowe funkcje dla programistów

  • Rozszerzony interfejs API do zarządzania obsługą 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 interfejsy API obsługujące ekrany, które zapewniają większą kontrolę nad tym, jak aplikacje są wyświetlane na ekranach o różnych rozmiarach. Interfejs API wykorzystuje dotychczasowy interfejs API obsługujący ekrany, w tym ogólny model gęstości ekranu platformy, ale rozszerza go o możliwość precyzyjnego kierowania reklam na konkretne zakresy ekranów według ich wymiarów mierzonych w jednostkach pikseli niezależnych od gęstości (np. 600 dp lub 720 dp), a nie uogólnionych rozmiarach ekranów (takich jak duży lub bardzo duży).

Podczas projektowania UI aplikacji możesz nadal polegać na platformie, która abstrakcjonuje gęstość pikseli, co oznacza, ż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 wyraża ilość dostępnego miejsca za pomocą 3 nowych cech: smallestWidth, width i height.

  • smallestWidth ekranu to jego podstawowy minimalny rozmiar wyrażony w pikselach niezależnych od gęstości („dp”). Krótsza z tych 2 opcji wysokości lub 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.
  • W przeciwieństwie do tego szerokość i wysokość ekranu reprezentują bieżącą przestrzeń poziomą lub pionową dostępną dla układu aplikacji, mierzoną w jednostkach „dp” z wyłączeniem obszarów ekranu zarezerwowanych przez system. Szerokość i wysokość ekranu zmieniają się, gdy użytkownik przełącza orientację z poziomej na 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 zgodnie z bieżącą szerokością lub wysokością. Do tych celów interfejs API udostępnia te narzędzia:

  • nowe kwalifikatory zasobów do kierowania na układy i inne zasoby do minimalnej szerokości, szerokości lub wysokości;
  • Nowe atrybuty pliku manifestu służące do określania maksymalnego zakresu zgodności ekranu

Poza tym aplikacje mogą nadal wysyłać zapytania do systemu oraz zarządzać wczytywaniem interfejsu i zasobów w czasie działania, tak jak w poprzednich wersjach platformy.

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ść (ogólna) Wymiary (dp) najmniejszej szerokości (dp)
Telefon podstawowy mdpi 320 x 480 320
Mały tablet/duży telefon mdpi 480 x 800 480
Tablet 7-calowy mdpi 600 x 1024 600
Tablet 10-calowy mdpi 800x1280 800

W sekcjach poniżej znajdziesz więcej informacji o nowych kwalifikatorach ekranu i atrybutach pliku manifestu. Pełne informacje na temat korzystania z interfejsu API do obsługi ekranu znajdziesz w artykule Obsługa wielu ekranów.

Nowe kwalifikatory zasobów do obsługi ekranów

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 wspomnieliśmy powyżej, parametr najmniejszej szerokości ekranu jest stała, niezależnie od orientacji. Przykłady: sw320dp, sw720dp, sw720dp.
  • wNNNdp i hNNNdp – określa minimalną szerokość lub wysokość, na której powinien być używany zasób, mierzoną 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. Gdy dla danego ekranu kwalifikuje się wiele konfiguracji zasobów, system wybiera konfigurację, która jest najbardziej zbliżona. Aby mieć dokładną kontrolę nad tym, które zasoby są ładowane na danym ekranie, możesz oznaczyć zasoby jednym kwalifikatorem 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ę. Możesz określić największe i najmniejsze ekrany, na których aplikacja ma działać, a także największy ekran, na którym ma działać bez korzystania z nowego trybu zgodności ekranu systemu. 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 najmniejszej najmniejszej szerokości, przy której aplikacja może działać bez konieczności trybu 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 wielkości najmniejszej szerokości, z jaką ma działać aplikacja. 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 uznaje aplikację za niekompatybilną z urządzeniem, ale nie blokuje jej instalacji i uruchamiania.

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

Pełne informacje o używaniu nowych atrybutów znajdziesz w artykule Deklarowanie obsługi rozmiaru ekranu.

Tryb zgodności z ekranem

Android 3.2 oferuje nowy tryb zgodności z ekranem dla aplikacji z wyraźnym oświadczeniem, że nie obsługują ekranów tak dużych, jak ten, na którym działają. 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 ekranu może nie być odpowiedni dla wszystkich aplikacji, platforma umożliwia aplikacji wyłączenie go za pomocą atrybutów w pliku manifestu. Gdy aplikacja ją wyłączy, system nie będzie proponował trybu zgodności powiększenia jako opcji dla użytkowników, gdy aplikacja jest uruchomiona.

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 urządzeniach z ekranami o umiarkowanej gęstości, Android 3.2 wprowadza nową uproszczoną gęstość tvdpi o przybliżonej wartości dpi 213. 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

Ogólnie aplikacje nie powinny działać przy tej gęstości. Jeśli w przypadku ekranu o rozdzielczości 720p wymagane są dane wyjściowe, elementy interfejsu mogą być skalowane automatycznie przez platformę.

Platforma UI

  • Fragmenty
    • Nowa klasa Fragment.SavedState przechowuje informacje o stanie pobrane z instancji fragmentu za pomocą funkcji saveFragmentInstanceState().
    • Nowa metoda saveFragmentInstanceState() zapisuje bieżący stan instancji danego fragmentu. Stan może być później użyty podczas tworzenia nowej instancji Fragmentu, która odpowiada bieżącemu stanowi.
    • Nowa metoda setInitialSavedState() ustawia początkowy stan zapisanego stanu fragmentu przy pierwszej konfiguracji.
    • 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ł jawnie odłączony od interfejsu użytkownika.
    • Nowe metody attach() i detach() pozwalają aplikacji ponownie załączać lub odłączać fragmenty w interfejsie użytkownika.
    • Nowa metoda przeciążenia setCustomAnimations() umożliwia ustawienie określonych zasobów animacji, które będą uruchamiane podczas operacji wejścia/wyjścia, a zwłaszcza podczas wyskakującego stosu wstecznego. Obecna implementacja nie uwzględnia różnych zachowań fragmentów podczas usuwania elementów z bieżącego stosu.
  • Informacje o rozmiarze ekranu w ActivityInfo i ApplicationInfo
  • Pomoc dotycząca pobierania rozmiaru interfejsu WindowManager
    • Nowe metody getSize() i getRectSize() pozwalają aplikacjom na pobieranie 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 działać na starszych wersjach platformy, możesz korzystać z biblioteki pomocy do wersji 4 (biblioteki zgodności) dostępnej w pakiecie SDK Androida. Biblioteka pomocy w wersji 4 zawiera wersję interfejsu Fragment API, która jest zgodna z Androidem 1.6 (poziom 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 karty SD za pomocą interfejsu MTP API.

Grafika

Platforma IME

  • Nowa metoda getModifiers() do pobierania bieżącego stanu kluczy 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ć

Telefonia

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 funkcji, które umożliwiają aplikacjom określenie, czy wymagają wyświetlania w orientacji poziomej, pionowej czy w obu. Zadeklarowanie tych stałych oznacza, że aplikacji nie można zainstalować 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 telewizory) może zadeklarować jedną ze stałych, by zapewnić, że nie będzie dostępna na urządzeniach, które nie mają takiej orientacji.

    Jeśli dowolne z działań zadeklarowanych w żądaniu pliku manifestu są uruchamiane w określonej orientacji przy użyciu atrybutu android:screenOrientation, oznacza to również, że aplikacja wymaga takiej orientacji.

  • Inne stałe cechy

Raport o różnicach w interfejsie API

Szczegółowy widok wszystkich zmian w interfejsach API wprowadzonych w Androidzie 3.2 (poziom API 13) znajdziesz w raporcie o różnicach w interfejsie API.

Poziom interfejsu API

Platforma Android 3.2 udostępnia zaktualizowaną wersję platformy API. 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 korzystać w aplikacji z interfejsów API wprowadzonych w Androidzie 3.2, musisz skompilować aplikację przy użyciu biblioteki Androida dostępnej na platformie Android 3.2 SDK. W zależności od potrzeb może być też konieczne dodanie atrybutu android:minSdkVersion="13" do elementu <uses-sdk> w pliku manifestu aplikacji.

Więcej informacji znajdziesz w artykule Co to jest poziom interfejsu API?