Interfejsy API Androida 3.2

Poziom API: 13

Android 3.2 (HONEYCOMB_MR2) to dodatkowa wersja platformy, która dodaje nowe możliwości dla użytkowników i deweloperó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 pakietu Android SDK, który można pobrać. Platforma do pobrania zawiera bibliotekę Androida i obraz systemu, a także zestaw skórek emulatorów. Aby zacząć programować lub testować Androida w wersji 3.2, pobierz platformę do swojego pakietu SDK za pomocą Menedżera pakietów Android SDK.

Najważniejsze funkcje platformy

Nowe funkcje dla użytkowników

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

    Android 3.2 oferuje różne optymalizacje, które zapewniają wygodę użytkowników korzystających z szerszej gamy tabletów.

  • Powiększenie zgodności w przypadku aplikacji o stałym rozmiarze

    W Androidzie 3.2 wprowadziliśmy 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 do standardowego rozciągania interfejsu w przypadku aplikacji, które nie zostały przystosowane do wyświetlania na większych ekranach, np. na tabletach. Nowy tryb jest dostępny dla użytkowników po kliknięciu ikony menu na pasku systemu w przypadku aplikacji wymagających zapewnienia zgodności.

  • Synchronizacja multimediów z karty SD

    Na urządzeniach obsługujących kartę SD użytkownicy mogą teraz wczytywać pliki multimedialne z tej karty bezpośrednio w aplikacjach, które z nich korzystają. Aplikacje z systemowego magazynu multimediów udostępniają pliki aplikacji.

Nowe funkcje dla programistów

  • Rozszerzony interfejs API do zarządzania ekranami

    Android 3.2 wprowadza rozszerzenia do interfejsu API do obsługi ekranu, dając programistom dodatkowe sposoby zarządzania interfejsem aplikacji na wielu różnych urządzeniach z Androidem. Interfejs API zawiera nowe kwalifikatory zasobów i nowe atrybuty pliku manifestu, które zapewniają dokładniejszą kontrolę nad tym, jak aplikacje wyświetlają się w różnych rozmiarach, zamiast korzystać z uogólnionych kategorii rozmiarów.

    Aby zapewnić jak najlepsze wyświetlanie aplikacji o stałym rozmiarze i aplikacji o ograniczonej obsłudze różnych rozmiarów ekranów, platforma ta udostępnia również nowy tryb zgodności z powiększeniem, który renderuje interfejs na mniejszym ekranie, a potem skaluje go w celu wypełnienia miejsca dostępnego na wyświetlaczu. Więcej informacji o interfejsie Screen support API i jego opcjach znajdziesz w sekcjach poniżej.

Omówienie interfejsu API

Interfejsy API obsługi ekranów

W Androidzie 3.2 wprowadzamy nowe ekrany z obsługą interfejsów API, które dają większą kontrolę nad tym, jak aplikacje wyświetlają się na ekranach o różnych rozmiarach. Interfejs API jest oparty na istniejącym interfejsie API do obsługi ekranów, w tym z uogólnionego modelu gęstości ekranu platformy, ale dodatkowo umożliwia precyzyjne kierowanie na konkretne zakresy ekranów według ich wymiarów mierzonych w jednostkach pikseli niezależnych od gęstości (takich jak 600 dp lub 720 dp) zamiast ogólnych rozmiarów ekranu (takich jak duży lub bardzo duży).

Podczas projektowania UI aplikacji możesz polegać na platformie, która zapewni abstrakcję gęstości. Oznacza to, że aplikacje nie muszą kompensować różnicy w rzeczywistej gęstości pikseli na różnych urządzeniach. Interfejs aplikacji możesz zaprojektować odpowiednio do ilości dostępnego miejsca w poziomie lub pionie. Platforma określa ilość dostępnego miejsca za pomocą 3 nowych cech: smallestWidth, width i height.

  • Wartość smallestWidth na ekranie to podstawowy minimalny rozmiar, mierzony w pikselach niezależnych od gęstości („dp”). Jest krótsza od szerokości lub wysokości ekranu. W przypadku ekranu w orientacji pionowej wartość najmniejszej szerokości jest zwykle określana na podstawie szerokości, a w orientacji poziomej – wysokości. We wszystkich przypadkach wartość najmniejsza jest określana na podstawie stałej cechy ekranu i nie zmienia się niezależnie od orientacji. Parametr najmniejszej szerokości jest ważny w przypadku aplikacji, ponieważ reprezentuje najkrótszą możliwą szerokość, w której trzeba narysować interfejs aplikacji. Nie uwzględnia ona obszarów ekranu zarezerwowanych przez system.
  • W przeciwieństwie do tego szerokość i wysokość ekranu reprezentują bieżącą poziomą lub pionową przestrzeń dostępną na potrzeby 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 zmienia orientację z poziomej na pionową.

Nowy interfejs API do obsługi ekranów umożliwia zarządzanie interfejsem aplikacji odpowiednio do najmniejszej szerokości bieżącego ekranu. W razie potrzeby można też zarządzać interfejsem użytkownika według aktualnej szerokości lub wysokości. Interfejs API udostępnia te narzędzia:

  • nowe kwalifikatory zasobów do kierowania na układy i inne zasoby z minimalną wartością najmniejszą, szerokością i wysokością;
  • Nowe atrybuty pliku manifestu do określania maksymalnego zakresu zgodności ekranu aplikacji

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

Nowy interfejs API umożliwia bardziej bezpośrednie kierowanie na ekrany na podstawie parametrów najmniejszej, szerokości i wysokości, dlatego warto poznać typowe cechy różnych typów ekranów. W tabeli poniżej znajdziesz przykłady mierzone w jednostkach „dp”.

Tabela 1. Typowe urządzenia mają gęstość i rozmiar w dp.

Typ Gęstość (ogólne) Wymiary (dp) najmniejsza szerokość (dp)
Telefon podstawowy MDPI 320 × 480 320
Mały tablet/duży telefon MDPI 480 × 800 480
Tablet 7-calowy MDPI 600 × 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 o korzystaniu z interfejsu API obsługi ekranu znajdziesz w artykule Obsługa wielu ekranów.

Nowe kwalifikatory zasobów dotyczące obsługi ekranów

Nowe kwalifikatory zasobów w Androidzie 3.2 pozwalają lepiej kierować układy na różne rozmiary ekranów. Za pomocą kwalifikatorów możesz tworzyć konfiguracje zasobów zaprojektowane pod kątem określonej minimalnej szerokości, bieżącej szerokości lub bieżącej wysokości mierzonej w pikselach niezależnych od gęstości.

Nowe kwalifikatory:

  • swNNNdp – określa w jednostkach „dp” minimalną szerokość, w której ma być używany zasób. Jak już wspomnieliśmy, najmniejsza szerokość ekranu jest stała niezależnie od orientacji. Przykłady: sw320dp, sw720dp, sw720dp.
  • wNNNdp i hNNNdp – określa minimalną szerokość lub wysokość zasobu, która ma być używana, mierzoną w jednostkach „dp”. Jak już wspomnieliśmy, szerokość i wysokość ekranu zależą od orientacji ekranu i zmieniają się przy każdej zmianie orientacji. 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 otagować niektóre zasoby do użytku na ekranie szerszym niż 480 dp, inne do szerszych niż 600 dp, a inne do szerszych niż 720 dp. Gdy do danego ekranu kwalifikuje się wiele konfiguracji zasobów, system wybiera konfigurację, która jest najbliższa dopasowaniu. Aby precyzyjnie kontrolować, które zasoby są ładowane na danym ekranie, możesz oznaczyć zasoby jednym kwalifikatorem lub połączyć kilka nowych bądź istniejących kwalifikatorów.

Biorąc pod uwagę typowe wymiary wymienione wcześniej, przedstawiamy kilka przykładów wykorzystania nowych kwalifikatorów:

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 ignorują nowe kwalifikatory, dzięki czemu możesz je zestawiać ze sobą, aby aplikacja dobrze prezentowała się 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

Więcej informacji o korzystaniu z nowych kwalifikatorów znajdziesz w artykule Używanie nowych kwalifikatorów rozmiaru.

Nowe atrybuty pliku manifestu zapewniające zgodność z rozmiarem ekranu

Platforma udostępnia nowy zestaw atrybutów pliku manifestu <supports-screens>, które pozwalają zarządzać obsługą aplikacji dla różnych rozmiarów ekranów. W szczególności możesz wskazać największe i najmniejsze ekrany, na których ma działać Twoja aplikacja, a także największy ekran, na którym została zaprojektowana bez konieczności włączania nowego trybu zgodności z ekranem systemu. Podobnie jak opisane powyżej kwalifikatory zasobów, nowe atrybuty w pliku manifestu określają zakres ekranów obsługiwanych przez aplikację (zgodnie z wartością najmniejszą.

Nowe atrybuty pliku manifestu do obsługi ekranu to:

  • android:compatibleWidthLimitDp="numDp" – ten atrybut umożliwia określenie maksymalnej wartości najmniejszej szerokości, na której może działać aplikacja bez konieczności użycia trybu zgodności. Jeśli bieżący ekran jest większy niż określona wartość, system wyświetla aplikację w trybie normalnym, ale umożliwia użytkownikowi opcjonalnie włączenie trybu zgodności przez ustawienie na pasku systemu.
  • android:largestWidthLimitDp="numDp" – ten atrybut umożliwia określenie maksymalnej wartości najmniejszej szerokości, na której ma działać aplikacja. Jeśli bieżący ekran jest większy niż określona wartość, system wymusza na aplikacji tryb zgodności z ekranem, aby zapewnić jak najlepsze wyświetlanie na bieżącym ekranie.
  • android:requiresSmallestWidthDp="numDp" – ten atrybut umożliwia określenie minimalnej wartości najmniejszej szerokości, w której może działać aplikacja. Jeśli bieżący ekran jest mniejszy niż podana wartość, system uzna aplikację za niekompatybilną z urządzeniem, ale nie uniemożliwi jej zainstalowania i uruchomienia.

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

Pełne informacje o korzystaniu z nowych atrybutów znajdziesz w sekcji Deklarowanie obsługi rozmiaru ekranu.

Tryb zgodności z ekranem

Android 3.2 udostępnia w aplikacjach nowy tryb zgodności ekranu z wyraźną informacją, że nie obsługują one ekranów o większej wielkości. Nowy tryb „powiększenia” jest skalowany za pomocą pikseli – renderuje aplikację na mniejszym ekranie, a następnie skaluje piksele, by wypełnić bieżący ekran.

Domyślnie system oferuje użytkownikowi tryb zgodności ekranu w przypadku aplikacji, które go wymagają. Użytkownicy mogą włączać i wyłączać tryb powiększenia za pomocą elementów sterujących na pasku systemu.

Nowy tryb zgodności ekranu może nie być odpowiedni w przypadku niektórych aplikacji, dlatego platforma zezwala aplikacji na jego wyłączenie za pomocą atrybutów manifestu. Gdy aplikacja jest wyłączona, system nie oferuje użytkownikom trybu zgodności „powiększenia”, gdy aplikacja jest uruchomiona.

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

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

Aby sprostać potrzebom aplikacji działających na telewizorach o rozdzielczości 720p lub podobnej z ekranami o średniej gęstości, w Androidzie 3.2 wprowadziliśmy nową ogólną gęstość (tvdpi) o przybliżonej gęstości 213 dpi. Aplikacje mogą wysyłać zapytania o nową gęstość w obrębie densityDpi i używać nowego kwalifikatora tvdpi do tagowania zasobów dotyczących telewizorów i podobnych urządzeń. Na przykład:

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

Ogólnie aplikacje nie powinny obsługiwać takiej gęstości. Jeśli potrzebne są dane wyjściowe do wyświetlania na ekranie 720p, platforma może automatycznie skalować elementy interfejsu.

Platforma UI

  • Fragmenty
    • Nowa klasa Fragment.SavedState zawiera informacje o stanie pobrane z instancji fragmentu za pomocą saveFragmentInstanceState().
    • Nowa metoda saveFragmentInstanceState() zapisuje bieżący stan instancji danego fragmentu. Stanu można użyć później podczas tworzenia nowej instancji fragmentu pasującego do bieżącego stanu.
    • Nowa metoda setInitialSavedState() ustawia początkowy zapisany stan fragmentu podczas jego tworzenia.
    • Nowa metoda wywołania zwrotnego onViewCreated() powiadamia fragment kodu, który zwrócił onCreateView(), ale przed przywróceniem zapisanego stanu do widoku.
    • Metoda isDetached() określa, czy fragment został wyraźnie odłączony od interfejsu użytkownika.
    • Nowe metody attach() i detach() pozwalają aplikacji na ponowne dołączenie lub odłączenie fragmentów w interfejsie użytkownika.
    • Nowa metoda przeciążenia setCustomAnimations() umożliwia skonfigurowanie określonych zasobów animacji tak, aby uruchamiały się podczas operacji wejścia/wyjścia, a zwłaszcza podczas wywoływania stosu wstecznego. Istniejąca implementacja nie uwzględnia różnych zachowań fragmentów podczas wywoływania stosu wstecznego.
  • informacje o rozmiarze ekranu w atrybutach ActivityInfo i ApplicationInfo.
  • Informacje pomocnicze dotyczące pobierania rozmiaru wyświetlacza z usługi WindowManager
  • Nowe publiczne style „holograficzne”
    • Platforma udostępnia teraz różne publiczne style „holograficzne”, takie jak tekst, widżety na pasku działań i karty. Pełną listę znajdziesz w sekcji R.style.
  • Metody LocalActivityManager, ActivityGroup i LocalActivityManager zostały wycofane
    • Nowe aplikacje powinny używać fragmentów fragmentów zamiast tych klas. Aby nadal działać na starszych wersjach platformy, możesz skorzystać z Biblioteki pomocy do wersji 4 (biblioteka zgodności), która jest dostępna w pakiecie Android SDK. Biblioteka pomocy dla wersji 4 udostępnia interfejs Fragment API w wersji zgodnej z Androidem do wersji 1.6 (poziom API 4).
    • W przypadku aplikacji utworzonych na Androidzie 3.0 (poziom interfejsu API 11) lub nowszym karty są zwykle wyświetlane w interfejsie przy użyciu nowego interfejsu ActionBar.newTab() i powiązanych z nim interfejsów API do umieszczania kart w pasku działań.

Struktura mediów

  • Aplikacje korzystające z dostawcy multimediów platformy (MediaStore) mogą teraz odczytywać dane multimedialne bezpośrednio z wymiennej karty SD (jeśli jest to obsługiwane przez urządzenie). Aplikacje mogą też wchodzić w bezpośrednie interakcje z plikami karty SD za pomocą interfejsu MTP API.

Grafika

Platforma IME

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

Platforma USB

  • Nowa metoda getRawDescriptors() do pobierania nieprzetworzonych deskryptorów USB dla urządzenia. Możesz użyć tej metody, aby 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

Stałe nowych cech

Platforma dodaje nowe stałe funkcji sprzętowych, które można zadeklarować w plikach manifestu aplikacji, aby przekazywać informacje firmom zewnętrznym, takim jak Google Play, o wymaganych funkcjach sprzętu i oprogramowania. Te i inne stałe cech deklarujesz w elementach manifestu <uses-feature>.

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

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

    W Androidzie 3.2 wprowadzono nowe stałe funkcje, dzięki którym aplikacje mogą określać, czy mają wyświetlać się w orientacji poziomej, pionowej czy w obu tych przypadkach. Zadeklarowanie tych wartości stałych oznacza, że aplikacji nie można instalować na urządzeniu, które nie oferuje powiązanej orientacji. Jeśli natomiast co najmniej jedna stała nie jest zadeklarowana, aplikacja nie ma preferencji dla niezadeklarowanych orientacji i może zostać zainstalowana na urządzeniu, które ich nie obsługuje.

    W przypadku typowej aplikacji, która działa poprawnie zarówno w orientacji poziomej, jak i pionowej, nie trzeba deklarować wymogu orientacji. Aplikacja przeznaczona głównie do wyświetlania w jednej orientacji (np. na telewizory) może zadeklarować jedną ze stałych, aby mieć pewność, że nie będzie ona dostępna dla urządzeń w innej orientacji.

    Jeśli dowolne z aktywności zadeklarowanych w żądaniu pliku manifestu uruchamiają się w określonej orientacji przy użyciu atrybutu android:screenOrientation, oznacza to również, że aplikacja wymaga tej orientacji.

  • Inne stałe cechy

Raport Różnice w interfejsie API

Szczegółowe informacje o wszystkich zmianach dotyczących interfejsów API w Androidzie 3.2 (poziom 13 interfejsów API) znajdziesz w raporcie Różnice w interfejsach API.

Poziom API

Platforma Android 3.2 udostępnia zaktualizowaną wersję interfejsu API platformy. Do interfejsu API Androida 3.2 jest przypisany identyfikator w postaci liczby całkowitej (13), który jest przechowywany w samym systemie. Ten identyfikator, nazywany „poziomem interfejsu API”, pozwala systemowi przed jej zainstalowaniem prawidłowo określić, czy aplikacja jest z nim zgodna.

Aby korzystać z interfejsów API wprowadzonych w Androidzie 3.2, należy skompilować aplikację do biblioteki Androida udostępnianej na platformie SDK Androida 3.2. 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.