Poziom API: 13
Android 3.2 (HONEYCOMB_MR2
) to przyrostowa wersja platformy, która dodaje nowe
dla użytkowników i deweloperów. W sekcjach poniżej znajdziesz omówienie
o nowych funkcjach i interfejsach API dla programistów.
Dla programistów platforma Android 3.2 jest dostępna jako dostępny do pobrania komponent Android SDK. Platforma do pobrania zawiera biblioteki Androida i obraz systemu, a także zestaw skórek emulatora i innych. Aby rozpocząć tworzenie lub testowanie wersji Androida 3.2, użyj Menedżera pakietów Android SDK, aby pobrać platformę do pakietu SDK.
Najważniejsze informacje o platformie
Nowe funkcje dla użytkowników
- Optymalizacje pod kątem większej liczby tabletów
Android 3.2 oferuje różne optymalizacje w systemie z myślą o wygodzie użytkowników szerokiej gamy 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żytkownicy mogą wyświetlać aplikacje o stałym rozmiarze na większych urządzeniach. Nowy tryb zapewnia do pikseli skalowana jako alternatywa dla standardowego rozciągania interfejsu użytkownika dla aplikacji, które nie zaprojektowany z myślą o większych ekranach, np. na tabletach. Nowy tryb to jest dostępna po kliknięciu ikony menu na pasku systemowym. Dotyczy to aplikacji, które muszą obsługę zgodności.
- Synchronizacja multimediów z karty SD
Na urządzeniach obsługujących kartę SD użytkownicy mogą teraz ładować pliki multimedialne z karty SD do aplikacji, które z nich korzystają. Obiekt systemu sprawia, że pliki dostępne dla aplikacji z systemowego sklepu multimedialnego.
Nowe funkcje dla programistów
- Rozszerzony interfejs API do zarządzania obsługą ekranów
Android 3.2 wprowadza rozszerzenia do interfejsu API do obsługi ekranu, dają programistom dodatkowe sposoby zarządzania interfejsem użytkownika aplikacji Urządzenia z systemem Android. Interfejs API zawiera nowe kwalifikatory zasobów i nowe w pliku manifestu, które dają dokładniejszą kontrolę nad aplikacje są wyświetlane w różnych rozmiarach, zamiast polegać na uogólnieniu kategorii rozmiarów.
Aby zapewnić najlepszą jakość wyświetlania w przypadku aplikacji o stałym rozmiarze i z ograniczeniami obsługuje różne rozmiary ekranów, a platforma udostępnia też nowe powiększenie. tryb zgodności, który najpierw renderuje interfejs na mniejszym ekranie, a potem go skaluje. do wypełnienia całego ekranu. Więcej informacji na temat API do obsługi ekranu i dostępne w nim opcje znajdziesz w sekcjach poniżej.
Omówienie interfejsu API
Interfejsy API związane z obsługą ekranów
W Androidzie 3.2 pojawiły się nowe ekrany, które obsługują interfejsy API, kontrolować, jak ich aplikacje są wyświetlane na ekranach o różnych rozmiarach. Opiera się on na istniejącym interfejsie API obsługującym ekrany, w tym uogólniony model gęstości ekranu, ale rozszerza go o możliwość precyzyjnego kierować reklamy na określone zakresy ekranów według ich wymiarów, mierzonych w niezależne od gęstości jednostki pikseli (np. 600 dp lub 720 dp), a nie według ich uogólnionych rozmiarów ekranów (np. duży lub bardzo duży).
Projektując interfejs aplikacji, nadal możesz polegać na platformie zapewnia abstrakcję gęstości, co oznacza, że aplikacje nie muszą kompensują różnice w rzeczywistej gęstości pikseli na różnych urządzeniach. Ty Potrafi zaprojektować interfejs aplikacji odpowiednio do dostępnych miejsc. Platforma wyraża ilość dostępnego miejsca za pomocą 3 nowych cechy: smallestWidth, width i height.
- smallestSzerokość to parametr minimalny dla rozmiaru ekranu, mierzone w jednostkach pikseli niezależnych od gęstości („dp”). Wysokość ekranu lub jest mniejsza. W przypadku ekranu w orientacji pionowej W orientacji poziomej jest określana na podstawie szerokości, na jego wysokości. We wszystkich przypadkach najmniejsza szerokość jest określana ze stałej cechy parametru ekranu, a wartość nie zmienia się bez względu na orientację. Najmniejsza szerokość jest ważny w zastosowaniach, ponieważ reprezentuje najmniejszą możliwą szerokość w którym należy narysować interfejs aplikacji (bez obszarów ekranu). zarezerwowane przez system.
- Szerokość i wysokość ekranu przedstawiają natomiast bieżąca przestrzeń pozioma lub pionowa dostępna dla układu aplikacji, mierzona w „dp” jednostek reklamowych, z wyłączeniem obszarów ekranu zarezerwowanych przez system. Szerokość wysokość ekranu zmienia się, gdy użytkownik przełączy orientację poziomą i pionowej.
Interfejs API został zaprojektowany pod kątem obsługi nowych ekranów, aby umożliwić Ci zarządzanie interfejsem aplikacji zgodnie z najmniejszą szerokością bieżącego ekranu. Możesz też zarządzać UI dostosowywany do bieżącej szerokości lub wysokości, w razie potrzeby. W tych celach interfejs API udostępnia następujące narzędzia:
- Nowe kwalifikatory zasobów do kierowania na układy i inne zasoby minimalna minimalna szerokość, szerokość lub wysokość oraz
- Nowe atrybuty pliku manifestu, które służą do określania maksymalnej wartości aplikacji zakres zgodności z ekranem
Ponadto aplikacje mogą nadal wysyłać zapytania do systemu i zarządzać interfejsem użytkownika oraz gdy zasoby są wczytywane w czasie działania, tak jak w poprzednich wersjach platformy.
Nowy interfejs API pozwala bardziej bezpośrednio kierować reklamy na ekrany o wymiarach najmniejszej szerokości, szerokości i wysokości, dobrze jest poznać typowe różne rodzaje ekranów. W tabeli poniżej znajdziesz niektóre przykładów mierzonych w „dp” jednostek reklamowych.
Tabela 1. Typowe urządzenia o gęstości i rozmiar w dp.
Typ | Gęstość (ogólna) | Wymiary (dp) | najmniejszej szerokości (dp) |
---|---|---|---|
Telefon podstawowy | mdpi | 320 × 480 | 320 |
Mały tablet/duży telefon | mdpi | 480 × 800 | 480 |
Tablet 7-calowy | mdpi | 600x1024 | 600 |
Tablet 10-calowy | mdpi | 800x1280 | 800 |
W sekcjach poniżej znajdziesz więcej informacji o nowych kwalifikatorach ekranu. i atrybuty w pliku manifestu. Pełne informacje o korzystaniu z ekranu support API, patrz Obsługa wielu opcji Ekrany.
Nowe kwalifikatory zasobów do obsługi ekranów
Nowe kwalifikatory zasobów w Androidzie 3.2 umożliwiają lepsze kierowanie na układy dla różnych rozmiarów ekranów. Korzystając z kwalifikatorów, możesz utworzyć zasób konfiguracje zaprojektowane z myślą o konkretnej minimalnej szerokości, najmniejszej szerokości lub bieżącej szerokości wysokość mierzona w pikselach niezależnych od gęstości.
Nowe kwalifikatory:
swNNNdp
– określa minimalną najmniejszą najmniejszą szerokość, na której zasób, którego należy użyć, mierzony w „dp” jednostek reklamowych. Jak wspomniano powyżej, najmniejsza szerokość ekranu jest stała, niezależnie od orientacji. Przykłady:sw320dp
,sw720dp
,sw720dp
.wNNNdp
ihNNNdp
– określa wartość minimalną, szerokość lub wysokość, na której powinien być używany zasób, mierzona w „dp”; jednostek reklamowych. Jako jak wspomnieliśmy powyżej, szerokość i wysokość ekranu zależą od orientacji i zmieniać ją wraz ze zmianą 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 oznaczyć tagiem niektóre zasoby na ekranach szerszych niż 480 pikseli. dp, inne powyżej 600 dp, a inne powyżej 720 dp. Kiedy dla danego ekranu kwalifikuje się wiele konfiguracji zasobów, wybiera konfigurację, która jest najbardziej dopasowana. Precyzyjna kontrola które zasoby są ładowane na danym ekranie, możesz oznaczyć zasoby tagiem kwalifikatora ani łączyć kilku nowych lub istniejących kwalifikatorów.
Oto kilka przykładów na podstawie typowych wymiarów wymienionych powyżej, można wykorzystać nowe kwalifikatory:
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 aby aplikacja dobrze się wyświetlała na każdym urządzeniu. Tutaj 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 na temat korzystania z nowych kwalifikatorów znajdziesz w sekcji Korzystanie z nowych kwalifikatory rozmiaru.
Nowe atrybuty w pliku manifestu zgodności z rozmiarem ekranu
Platforma udostępnia nowy zestaw atrybutów pliku manifestu <supports-screens>
, które pozwalają
i zarządzasz obsługą różnych rozmiarów ekranu w aplikacji.
W szczególności możesz określić największy i najmniejszy ekran, na którym aplikacja
z największym ekranem, na którym działa
bez konieczności korzystania z nowego ekranu
trybu zgodności. Podobnie jak w przypadku opisanych powyżej kwalifikatorów zasobów, nowa funkcja
atrybuty manifestu określają zakres ekranów, które obsługuje aplikacja,
zgodnie z wartością najmniejszej szerokości.
Nowe atrybuty w pliku manifestu do obsługi ekranów to:
android:compatibleWidthLimitDp="numDp"
– to pozwala określić maksymalną najmniejszą najmniejszą szerokość, dla której aplikacja które mogą działać bez trybu zgodności. Jeśli bieżący ekran jest większy niż system wyświetla aplikację w trybie normalnym, ale pozwala użytkownikowi opcjonalnie przełączyć się na tryb zgodności na pasku systemu.android:largestWidthLimitDp="numDp"
– to pozwala określić maksymalną najmniejszą najmniejszą szerokość, dla której aplikacja z myślą o działaniu. Jeśli obecny ekran jest większy niż określona wartość, system wymusza przejście aplikacji w tryb zgodności z ekranem, aby zapewnić wyświetlane na bieżącym ekranie.android:requiresSmallestWidthDp="numDp"
– to pozwala określić minimalną najmniejszą najmniejszą szerokość, dla której aplikacja może działać. Jeśli bieżący ekran jest mniejszy niż określona wartość, system uznaje aplikację za niekompatybilną z urządzeniem, ale nie zapobiega jej przed instalacją i uruchomieniem.
Uwaga: Google Play nie filtruje obecnie
aplikacji na podstawie dowolnego z powyższych atrybutów. Obsługą filtrowania będzie
dodane w jednej z kolejnych wersji platformy. Aplikacje, które wymagają
filtrowanie na podstawie rozmiaru ekranu może korzystać z istniejących funkcji <supports-screens>
.
Pełne informacje na temat korzystania z nowych atrybutów znajdziesz w sekcji Deklarowanie obsługi rozmiaru ekranu.
Tryb zgodności z ekranem
Android 3.2 oferuje nowy tryb zgodności z ekranem dla aplikacji wyraźnie zadeklarować, że nie obsługuje ekranów tak dużych jak ich działania. To nowe powiększenie jest jak piksel, renderuje aplikację na mniejszym ekranie, a potem skaluje piksele, wypełni bieżący ekran.
Domyślnie system oferuje użytkownikom tryb zgodności z ekranem. które tego wymagają. Użytkownicy mogą włączać i wyłączać tryb powiększenia za pomocą dostępnego elementu sterującego na pasku systemowym.
Ponieważ nowy tryb zgodności z ekranami może nie być odpowiedni dla wszystkich aplikacji, platforma umożliwia aplikacji jej wyłączenie przy użyciu pliku manifestu . Jeśli wyłączysz tę funkcję przez aplikację, system nie będzie obsługiwać powiększenia. zgodność jako opcję dla użytkowników, gdy aplikacja jest uruchomiona.
Uwaga: ważne informacje o tym, jak aby dowiedzieć się, jak sterować trybem zgodności w swoich aplikacjach, przeczytaj artykuł Nowy tryb aplikacji na dużych ekranach na urządzeniu z Androidem. Blog dla deweloperów.
Nowa gęstość ekranu dla telewizorów 720p i podobnych urządzeń
Aby zaspokoić potrzeby aplikacji działających na telewizorach 720p lub podobnych,
do ekranów o umiarkowanej gęstości, Android 3.2 wprowadza nową ogólną gęstość.
tvdpi
, przybliżoną rozdzielczość 213 dpi. Aplikacje, o które mogą wysyłać zapytania
nową gęstość w densityDpi
i może używać
nowy kwalifikator tvdpi
służący do oznaczania zasobów telewizyjnych i
na podobnych urządzeniach. Na przykład:
res/drawable-tvdpi/my_icon.png # Bitmap for tv density
Zwykle aplikacje nie muszą obsługiwać takiej gęstości. Sytuacje gdzie w przypadku ekranu o rozdzielczości 720p wymagane są dane wyjściowe, elementy interfejsu można skalować. automatycznie przez platformę.
Platforma interfejsu
- Fragmenty
- Nowa klasa
Fragment.SavedState
zawiera stan informacje pobrane z instancji fragmentu przezsaveFragmentInstanceState()
- Nowa metoda
saveFragmentInstanceState()
zapisuje bieżący stan instancji danego fragmentu. Stanu można użyć później podczas tworzenia nowej instancji fragmentu, który pasuje do bieżącego stanu. - Nowa metoda
setInitialSavedState()
ustawia początkowy stan zapisanego stanu fragmentu przy pierwszym utworzeniu. - Nowa metoda wywołania zwrotnego
onViewCreated()
powiadamia fragment, któryonCreateView()
ale przed przywróceniem jakiegokolwiek zapisanego stanu do widoku. - Metoda
isDetached()
określa, czy fragment został jawnie odłączony od interfejsu użytkownika. - Nowy:
attach()
idetach()
pozwalają aplikacji ponownie dołączać lub odłączać fragmenty w interfejsie użytkownika. - Nowa metoda przeciążenia
setCustomAnimations()
umożliwia ustawienie konkretnej animacji na potrzeby operacji wejścia/wyjścia, a zwłaszcza wtedy, i jeszcze bardziej rozwiniemy skrzydła. Obecna implementacja nie uwzględnia dla różnych sposobów zachowania fragmentów przy wydzielaniu tylnego stosu.
- Nowa klasa
- Informacje o rozmiarze ekranu w ActivityInfo i ApplicationInfo
ActivityInfo
dodaje użytkownikaCONFIG_SCREEN_SIZE
iCONFIG_SMALLEST_SCREEN_SIZE
jako maski bitowe w aplikacjiconfigChanges
. Bity określają, czy działanie może i samodzielnie obsługuje rozmiar i najmniejszy rozmiar ekranu.ApplicationInfo
dodanialargestWidthLimitDp
,compatibleWidthLimitDp
irequiresSmallestWidthDp
pól, wywodzący się z odpowiednich atrybutów<supports-screens>
w pliku manifestu aplikacji.
- Pomoc dotycząca pobierania rozmiaru interfejsu WindowManager
- Nowe metody
getSize()
igetRectSize()
pozwalają aplikacjom na pobieranie nieprzetworzonego rozmiaru wyświetlacza.
- Nowe metody
- Nowy publiczny „holograficzny” style
- Platforma ujawnia teraz wiele publicznych „holograficznych” style
do tekstu, a także widżetów i kart na pasku działań. Zobacz
R.style
, aby zobaczyć pełną listę.
- Platforma ujawnia teraz wiele publicznych „holograficznych” style
do tekstu, a także widżetów i kart na pasku działań. Zobacz
LocalActivityManager
,ActivityGroup
i InterfejsLocalActivityManager
został wycofany- .
- Nowe aplikacje powinny używać fragmentów zamiast tych klas. Do na starszych wersjach platformy, możesz skorzystać z pomocy Biblioteka (biblioteka zgodności) dostępna w pakiecie SDK Androida. Pomoc do wersji 4 Biblioteka udostępnia wersję interfejsu Fragment API zgodną ze standardem Android 1.6 (poziom API 4).
- Dla aplikacji działających na Androidzie 3.0 (poziom interfejsu API)
11) lub wyższej, karty są zwykle przedstawiane w interfejsie za pomocą
ActionBar.newTab()
i powiązane interfejsy API który pozwala umieścić karty w obszarze paska działań.
Struktura mediów
- Aplikacje korzystające z dostawcy multimediów platformy (
MediaStore
) mogą teraz odczytywać dane multimedialne bezpośrednio z wyjmowaną kartę SD, jeśli urządzenie ją obsługuje. Aplikacje mogą również i bezpośredniej interakcji z plikami na karcie SD za pomocą interfejsu API MTP.
Grafika
- Usługi komunikacyjne w punktach i PointF
Point
iPointF
klasy obejmują teraz interfejsParcelable
i metody narzędziowedescribeContents()
,readFromParcel()
iwriteToParcel()
.
platforma IME
- Nowa metoda
getModifiers()
dla pobranie bieżącego stanu klawiszy modyfikujących.
Platforma USB
- Nowa metoda
getRawDescriptors()
dla pobierania nieprzetworzonych deskryptorów USB dla urządzenia. Za pomocą metody dostępu do deskryptorów, które nie są obsługiwane bezpośrednio przez interfejsów API.
Sieć
- Stałe typu sieci
- Funkcja
ConnectivityManager
dodaje stałeTYPE_ETHERNET
iTYPE_BLUETOOTH
.
- Funkcja
Telefonia
- Nowa stała typu sieci
NETWORK_TYPE_HSPAP
.
Podstawowe narzędzia
- Usługi komunalne na wynajem
- Nowy interfejs
Parcelable.ClassLoaderCreator
zezwala aplikację otrzymującą obiekt ClassLoader, w którym tworzony jest obiekt. - Nowe
adoptFd
,dup()
ifromFd()
do zarządzaniaParcelFileDescriptor
obiektów.
- Nowy interfejs
- Binder and IBinder
- Nowa metoda
dumpAsync()
wBinder
iIBinder
pozwalają aplikacjom do określonego pliku, co zapewni, ż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
Nowe stałe cech
Platforma dodaje nowe stałe funkcji sprzętowych, które możesz zadeklarować.
w plikach manifestu aplikacji, aby informować podmioty zewnętrzne, takie jak Google
Podawanie niezbędnych funkcji sprzętu i oprogramowania. Deklarujesz te
i inne stałe cechy w elementach 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 cech dla wymagań 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 oznacza, że aplikacji nie można zainstalować na urządzeniu, które nie obsługuje powiązanej orientacji. Jeśli natomiast nie zostanie zadeklarowana co najmniej jedna ze stałych, oznacza to, że aplikacja nie preferuje niezadeklarowanych orientacji i można ją zainstalować na urządzeniu, które ich nie oferuje.
android.hardware.screen.landscape
– aplikacja wymaga wyświetlenia w w orientacji poziomej.android.hardware.screen.portrait
– aplikacja wymaga wyświetlenia w do orientacji pionowej.
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 jakiekolwiek działania zadeklarowane w żądaniu pliku manifestu są uruchamiane w określonej orientacji, za pomocą atrybutu
android:screenOrientation
, oznacza to również deklarowanie, że aplikacja wymaga takiej orientacji. - Inne stałe cech
android.hardware.faketouch.multitouch.distinct
– aplikacja wymaga obsługi emulowanej metody wprowadzania danych typu mulitouch z wyraźnym śledzeniem co najmniej 2 punktów.android.hardware.faketouch.multitouch.jazzhand
– aplikacja wymaga obsługi emulowanej metody wprowadzania danych typu mulitouch z wyraźnym śledzeniem co najmniej 5 punktów.
Raport o różnicach w interfejsie API
Szczegółowy widok wszystkich zmian interfejsu API w Androidzie 3.2 Poziom 13), patrz interfejs API Raportu różnic.
Poziom API
Android 3.2 udostępnia zaktualizowaną wersję platformy API. Interfejs API systemu Android 3.2 jest przydzielony identyfikator w postaci liczby całkowitej – 13 – czyli zapisanych w samym systemie. Ten identyfikator, nazywany „poziomem interfejsu API”, umożliwia stosowanie funkcji systemu pozwalającego poprawnie określić, czy aplikacja jest zgodna z systemu.
Aby skorzystać z interfejsów API wprowadzonych w Androidzie 3.2 w aplikacji,
musisz skompilować aplikację zgodnie z biblioteką Androida w bibliotece
z platformy Android 3.2 SDK. W zależności od potrzeb
może
trzeba też dodać android:minSdkVersion="13"
do elementu <uses-sdk>
w nagłówku aplikacji
pliku manifestu.
Więcej informacji znajdziesz w artykule Co to jest interfejs API Poziom?