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”.
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
ihNNNdp
– 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()
idetach()
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.
- Nowa klasa
- informacje o rozmiarze ekranu w atrybutach ActivityInfo i ApplicationInfo.
ActivityInfo
dodajeCONFIG_SCREEN_SIZE
iCONFIG_SMALLEST_SCREEN_SIZE
jako maski bitów wconfigChanges
. Bity wskazują, czy aktywność może sama obsługiwać rozmiar i najmniejszy ekran.ApplicationInfo
dodaje polalargestWidthLimitDp
,compatibleWidthLimitDp
irequiresSmallestWidthDp
, które pochodzą z odpowiednich atrybutów<supports-screens>
w pliku manifestu aplikacji.
- Informacje pomocnicze dotyczące pobierania rozmiaru wyświetlacza z usługi WindowManager
- Nowe metody
getSize()
igetRectSize()
pozwalają aplikacjom korzystać z pełnego rozmiaru wyświetlacza.
- Nowe metody
- 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
.
- 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
- Metody
LocalActivityManager
,ActivityGroup
iLocalActivityManager
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
- Usługi komunalne w Point i PointF:
- Klasy
Point
iPointF
obejmują teraz interfejsParcelable
i metody narzędziowedescribeContents()
,readFromParcel()
iwriteToParcel()
.
- Klasy
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ć
- Stałe typu sieci
ConnectivityManager
dodaje stałeTYPE_ETHERNET
iTYPE_BLUETOOTH
.
Telefonia
- Nowa stała typu sieci
NETWORK_TYPE_HSPAP
.
Podstawowe narzędzia
- Usługi komunalne
- Nowy interfejs
Parcelable.ClassLoaderCreator
umożliwia aplikacji otrzymanie klasy ClassLoader, w której tworzony jest obiekt. - Nowe
adoptFd
,dup()
ifromFd()
do zarządzania obiektamiParcelFileDescriptor
.
- Nowy interfejs
- Binder i IBinder
- Nowa metoda
dumpAsync()
wBinder
iIBinder
pozwala aplikacjom wykonywać zrzuty ekranu do określonego pliku, zapewniając, że środowisko docelowe będzie wykonywane asynchronicznie. - Nowy kod transakcji protokołu
IBinder
TWEET_TRANSACTION
umożliwia aplikacjom wysyłanie tweetów do obiektu docelowego.
- Nowa metoda
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.
android.hardware.screen.landscape
– aplikacja wymaga wyświetlania w orientacji poziomej.android.hardware.screen.portrait
– aplikacja wymaga wyświetlacza w orientacji pionowej.
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
android.hardware.faketouch.multitouch.distinct
– aplikacja wymaga obsługi emulowanych danych wejściowych wielokrotnego użytku z odrębnym śledzeniem co najmniej 2 punktów.android.hardware.faketouch.multitouch.jazzhand
– aplikacja wymaga obsługi emulowanej funkcji wielokrotnego wyboru z odrębnym śledzeniem obejmującym co najmniej 5 punktów.
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.